IssueTracker

It seems the print is benign so I'll remove it; Could be worth it to find out how the message carrying information about "cb 0" (0 is not a valid color buffer handle) ever arrives to that line though

I agree with Sergey -- while I think it's fine to remove some logging messages that aren't necessary, the root problem here is that Studio shows everything emitted as if they are errors, with one notification bubble per message. We don't do that for other tools that Studio launches, and in particular, this isn't specific to the "cb 0" message I showed here; there were earlier (different) error messages during the boot as well.

This behavior was requested specifically by the emulator team (vharron@ iirc, so at least 3-4 years ago). Let me see if I have any more details on why this was requested.

I couldn't find any relevant threads. IIRC, the main concern at that time was that warnings at startup (e.g. missing acceleration) really needed to be bubbled up to the users. If that is not an issue anymore, and the emulator team only wants errors to be visible, then the proposed change SGTM.

Yes, I vaguely remember that in some cases, you'd hit run, and then the emulator would fail to start (for example aborting because of some missing thing it needed), so we needed a way to surface these reasons. I don't know if there are any fatal startup errors like this. It seems like there are several things we could do here:

(1) Simplest: just reroute the errors into the log, and if emulator fails to start, that's where people can look. (I think that's what Sergey has already implemented?)

(2) If emulator could update itself to prefix truly fatal error messages in some way (such as error:) and use that for only fatal/exit(-1) reasons, then we could multiplex the output -- errors are shown in notifications as today, everything else is silently dumped to the log

(3) Hold on to the emulator output, and if there's a problem starting the emulator (say if it exits within a few seconds), then show all the emulator output.

I can reproduce the issue. But it's quite odd what's going on: I suspect the bug might actually be in AGP.

Adding this task at the end of app/build.gradle:

abstract class PrintTask extends DefaultTask {
    @Input abstract Property<String> getText()
    @TaskAction void exec() { println(getText().get()) }
}

androidComponents {
    onVariants(selector()) { variant ->
        tasks.register(variant.name + "BuildProperties", PrintTask) { t ->
            def buildType = android.buildTypes[variant.buildType]
            def text = "minifyEnabled=" + buildType.minifyEnabled.toString() + "\n"
            text += "testCoverageEnabled=" + buildType.testCoverageEnabled.toString() + "\n"
            text += "debuggable=" + buildType.debuggable.toString() + "\n"
            text += "profileable=" + buildType.profileable.toString() + "\n"
            text += "proguardFiles=" + buildType.proguardFiles.toString() + "\n"
            text += "postProcessingProguardFiles=" + buildType.postprocessing.getProguardFiles(EXPLICIT) + "\n"
            t.text.set(text)
        }
    }
}

I can see that the property is correctly copied:

$ ./gradlew :app:productionBenchmarkReleaseBuildProperties :app:productionReleaseBuildProperties --stacktrace
Reusing configuration cache.

> Task :app:productionReleaseBuildProperties
minifyEnabled=true
testCoverageEnabled=false
debuggable=false
profileable=false
proguardFiles=[]
postProcessingProguardFiles=[/Users/.../development/mre/app/build/intermediates/default_proguard_files/global/proguard-defaults.txt-8.3.2, /Users/.../development/mre/app/proguard-rules.pro]


> Task :app:productionBenchmarkReleaseBuildProperties
minifyEnabled=true
testCoverageEnabled=false
debuggable=false
profileable=true
proguardFiles=[]
postProcessingProguardFiles=[/Users/.../development/mre/app/build/intermediates/default_proguard_files/global/proguard-defaults.txt-8.3.2, /Users/.../development/mre/app/proguard-rules.pro]


BUILD SUCCESSFUL in 340ms
2 actionable tasks: 2 executed
Configuration cache entry reused.

Nevertheless, the content of the proguard configuration in the build folder does not have the content of custom proguard file proguard-rules.pro.

Passing this to AGP team: to reproduce please use provided project but you can remove the baseline profile modules and the baseline profile dependency in the app module to speed up the build.

I've simplified the repro project a little bit for the AGP team, removing the baseline profile gradle plugin to ensure it's not related: https://drive.google.com/file/d/1BqC6ZdEaxY7kgi-BeW-mW5HMG4A9SBO-/view?usp=sharing

To print build properties (to see the property is copied):

./gradlew :app:anotherReleaseBuildProperties :app:releaseBuildProperties

To verify proguard mapping configuration content (that will confirm the rule is not in anotherRelease:

./gradlew :app:assembleAnotherRelease :app:assembleRelease
grep -C1 SuppressViolation app/build/outputs/mapping/release/configuration.txt
grep -C1 SuppressViolation app/build/outputs/mapping/anotherRelease/configuration.txt

Over to AGP with improved repro

Any update on this one?

It still affects the Baseline Profiles integration (building the benchmarkRelease) in projects where release.postprocessing is used. Both AGP 8.5.2 and 8.6.0-rc01 seem to have this issue.

This has been fixed in https://android.googlesource.com/platform/tools/base/+/08356be7b624ad785f01b390554b80b14838229f and will target AGP 8.7.0-alpha09.

Looking forward to try the fix.

Will it be backported to AGP 8.6.x or 8.5.x?

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 | 2024.2.1 Canary 9
• Android Gradle Plugin 8.7.0-alpha09

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!