IssueTracker

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Ladybug Feature Drop | 2024.2.2 Canary 3
• Android Gradle Plugin 8.8.0-alpha03

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

Hello, it's in my first comment, but I'll put it here too:

Android Studio -> Ladybug Feature Drop | 2024.2.2 with OS Windows 11

Android Device -> Android 15

No log

Since I updated Android Studio to Ladybug Feature Drop, my phone with Android 15 does not have the latest changes of my app; with Android Studio Ladybug it was working fine and this didn't happen to me.

Seeing the same issue. It only started to occur recently but I always have to CTRL+R (Run) twice from Android Studio (Ladybug Feature Drop | 2024.2.2) for changes of (Compose) code to take effect. I deploy to an emulator with API 35.

Checking Always install with package manager in the run config as comment 35 of issue 182882359 suggested seems to have fixed the problem but now I'm missing some deploy optimizations :(

Android Studio log files are attached.

Studio Build: #AI-242.23726.103.2422.12816248
Version of Gradle Plugin: 8.8.0
Version of Gradle: 8.11.1
Version of Java: OpenJDK Runtime Environment Temurin-21.0.5+11 (build 21.0.5+11-LTS)
OS: macOS 15.2

The log contains 67 deployments and 49 of them used the path that by-pass the package manager.

Checking Always install with package manager in the run config as comment 35 of issue 182882359 suggested seems to have fixed the problem but now I'm missing some deploy optimizations :(

Yes, doing so will limit you to the slower deployment path for very small changes.

Would it be possible for you to turn that back on and give it a few more tries? Once you run into this issue, could you provide us with both the logs as well as the full logcat from the device?

Would it be possible for you to turn that back on and give it a few more tries?

You mean turn off, right? So Always install with package manager should not be checked?

You mean turn off, right? So Always install with package manager should not be checked?

Yes. I mean don't have that checkbox selected. Sorry for the confusion.

See attached AS diagnostic data and Logcat output.

Again, much appreciate your time on this:

Here are the last 8 install from the log. I redacted protential personal info from the log.

2025-01-16 15:59:31 size='42.421.583', fingerprint='9d273afbbf4db665a91a0f8145b315fadc3a767a', modTime='2025-01-16T14:59:29.253560515Z', acTime='2025-01-16T14:59:29.900170731Z'
2025-01-17 06:53:17 size='42.421.583', fingerprint='9d273afbbf4db665a91a0f8145b315fadc3a767a', modTime='2025-01-16T14:59:29.253560515Z', acTime='2025-01-17T05:53:04.390040484Z'
2025-01-17 07:05:36 size='39.775.816', fingerprint='55092113b1f019801ae4f9af200298cb25338dc0', modTime='2025-01-17T06:05:24.653149734Z', acTime='2025-01-17T06:05:28.225081073Z'
2025-01-17 07:14:34 size='39.775.816', fingerprint='55092113b1f019801ae4f9af200298cb25338dc0', modTime='2025-01-17T06:05:24.653149734Z', acTime='2025-01-17T06:14:32.944690539Z'
2025-01-17 07:30:47 size='39.775.816', fingerprint='55092113b1f019801ae4f9af200298cb25338dc0', modTime='2025-01-17T06:05:24.653149734Z', acTime='2025-01-17T06:30:37.579180742Z'
2025-01-17 07:34:33 size='39.775.816', fingerprint='78acf53c8c11931a92a3eee9ddce91d39ed6077a', modTime='2025-01-17T06:34:32.444681602Z', acTime='2025-01-17T06:34:32.871689717Z'
2025-01-17 07:35:17 size='39.775.816', fingerprint='78acf53c8c11931a92a3eee9ddce91d39ed6077a', modTime='2025-01-17T06:34:32.444681602Z', acTime='2025-01-17T06:35:17.545567038Z'
2025-01-17 07:35:57 size='42.425.620', fingerprint='5ee5531c7f0bf3aaa79946972e5b10a86ae2d0ea', modTime='2025-01-17T06:35:55.187378498Z', acTime='2025-01-17T06:35:56.488512388Z'

Do you roughly remember what you were doing today? You were only seeing that with the checkbox off, right?

The first deploy of 2025-01-17 was the same deploy from the previous day?

There was also 5 deployments after that. The output APK exactly same size but only have 2 different checksum. Were you deploying zero changes for 5 times? Were you running into issue in those builds?

Finally the very last deploy seems to have significant changes sizes wise. Did you see expected changes?

What I did is I deployed the application to the emulator. This was a cold start of the application. Then I did a minor code change and just added a Compose modifier (background(Color.Red)) to an element to see if it has any effect. I executed CTRL+R, the app was relaunched but the change wasn't there. Then I CTRL+R again and the change was visible.

Thanks for the info!

I'll attempt to map out each change to each install:

9d273afbbf4db665a91a0f8145b315fadc3a767a:

• Installed twice.
• Full install with package manager.

55092113b1f019801ae4f9af200298cb25338dc0:

• 3MB drop in size.
• Intalled 3 times.
• All Full installs.

78acf53c8c11931a92a3eee9ddce91d39ed6077a:

• No change in APK size.
• Full install once. And then package manager skip (mostly like nothing was pushed because APK unchanged)

5ee5531c7f0bf3aaa79946972e5b10a86ae2d0ea:

• Happened once.
• Gain back the 3M in size.
• No full install with Package manager skip yet change is visible.

So of the 8 install. The package manager optimization happened twice. First time was unchanged APK and the final time was when the change was actually visible.

There is something really strange about the 3M drop in size and also 5 builds of identical size with 2 unique checksums.

I would like to redirect this for the build team to have a look.

I am also seeing something similar in 387045804#comment6

Identical APK size with a different checksum isn't necessarily a red flag (e.g. just changing a value resource or constant value or switching between two different method calls backward and forward in a composable all might result in this)

Things that would be expected to cause a dramatic change in size without code or project changes: switching between different variants where some have r8 enabled and others haven't, but that doesn't seem to be the case here (all deploys are of app/build/intermediates/apk/debug/app-debug.apk) or not injecting the ABI of the target device (but that also seems to not be the case here)

Looking more closely ApkChecker is logging the file-system file size of the APK, and ZipFlinger tries quite hard to update the APK in place - so identical sized APKs with different content (and a bit of wasted space) are not at all unexpected.

Things that would be expected to cause a dramatic change in size without code or project changes: switching between different variants where some have r8 enabled and others haven't, but that doesn't seem to be the case here (all deploys are of app/build/intermediates/apk/debug/app-debug.apk) or not injecting the ABI of the target device (but that also seems to not be the case here)

I think from comment#10, the user has been mostly just adding backgroundColor(Color.Red) modifiers to a few composables. I don't think build varient was changed. R8 was most likely not invoke due to being a debug build and unlikely to prune 3MB of bytecode from adding a modifier.

@sj1981: Is there anything else you can tell us more about the project in question? Is it split into mutiple modules?

The assumptions are correct. The build variant debug was unchanged and R8 was also not involved.
The project consists of about 80 Gradle modules but for this change only one module should have been recompiled.

However, I had to reinstall macOS for some other reasons and now I can't reproduce this behavior anymore but a colleague still has the same problem. He didn't reinstall macOS.

However, I had to reinstall macOS for some other reasons and now I can't reproduce this behavior anymore but a colleague still has the same problem. He didn't reinstall macOS.

Can you ask your colleague to pay attention to the build output from the Gradle when they encounter the issue?

It should contain task status on rather the module is UP-To-DATE.

Task :app:dexBuilderDebug UP-TO-DATE

Also, if you can report back with the immediate idea.log and logcat it would be great.

100% only happening since Ladybug Feature Drop 2024.2.2, and happening for me also with an Android 13 real device

1. Run app
2. make any changes to your code
3. Run again
4. changes are not applied
5. Run again
6. changes are applied

The only safe bet to apply changes are uninstalling the app, this is insane! Please fix!

We are still actively investigating this issue.

In the meantime, for everybody who reported this issue, does checking the checkbox (see details here)

Always install with package manager

allows to deploy again (with understandably lower speed). If the checkox solves it, the issue could be in the deployer stack. If it doesn't it would mean it is an AGP issue.

Also see b/394408279. At least in that bug, we've resolved it specifically to an issue with restarting the activity.

If you are seeing this issue, can you please try:

1. Help > Edit Custom VM Options
2. Add the line -Drundebug.install.use.pm.terminate=false
3. Restart IDE

There have likely been two seperate causes for this bug; both should be resolved.

Run Cofigurations w/ Missing Build Steps

Comment #27, I believe you have been bitten by the issue referred to here: https://developer.android.com/studio/known-issues#run-config-missing-gradle. To (hopefully) resolve your issue:

Click Run/Debug Configurations > Edit Configurations, click the active run configuration and confirm that there is a "Gradle-aware Make" step in the "Before launch" section.

If you update your Studio version, try to run your app, and see a message about "No Build" similar to comment #27, this is most likely the issue.

App Not Correctly Restarting After Deployment

If your changes are not deploying, and you are forced into any of the following scenarios:

• Changes require pressing run twice to deploy
• Changes do not appear until killing/restarting the app after deployment
• Changes require uninstalling/reinstalling the app

We believe the issue to be related to a bug in how Studio stops/restarts the app after installation on Android API levels >= 33 (Android 13/Tiramisu onwards).

We have rolled out a server config flag that should disable this incorrect behavior. This server flag will be picked up upon restarting Studio; in addition, subsequent releases of Studio will also have this incorrect behavior disabled.

Given the above, I am marking this as closed for now; if you are on this bug and still seeing incorrect deployment behavior that does not fit into either of the above categories, we should open a new high priority bug to track that down.

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Studio Ladybug Feature Drop | 2024.2.2 Patch 1
• Android Gradle Plugin 8.8.1

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

The fixes for this issue are now also available in:

• Android Studio Meerkat Feature Drop | 2024.3.2 Canary 5
• Android Gradle Plugin 8.10.0-alpha05

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

The fixes for this issue are now also available in:

• Android Studio Meerkat | 2024.3.1 RC 2
• Android Gradle Plugin 8.9.0-rc02

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Android 16 beta 3

Further fixes for this issue are now available in:

• Android Studio Ladybug Feature Drop | 2024.2.2 Patch 2
• Android Gradle Plugin 8.8.2

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.