IssueTracker

Has anyone re-tried it? We switched back to RUN sdkmanager --package_file=$ANDROID_HOME/packages.txt in our Dockerfile back in March of 2021.

For what it's worth, I did a quick test with the latest CLI: 11076708 (https://developer.android.com/studio#downloads) on OSX and tried it with a simple:

./sdkmanager --sdk_root="../sdk" --package_file=deps.txt

Deps.txt:

platform-tools
extras;google;instantapps
build-tools;35.0.0-rc3

So perhaps this is now resolved? I haven't tried it with more packages

A note to the MinifyLibTest

In debug build our CompilationMode is debug which means obfuscation and optimization are disabled. Tree-shaking is still enabled as it is not affected by this CompilationMode.

So in order to test obfuscation, we need to use release build.

A question to Ian, I find the class file output by r8 is not being obfuscated. I guess that is not expected, right? The configuration for r8 looks correct to me. I remember there is a way to share all the details of a r8 invocation right? zerny@

Regarding debug build, it does indeed disable obfuscation and optimization as both break stack-traces / stepping behavior. Tree shaking is still enabled without explicitly disabling it.

You can generate a compiler input dump with all the inputs to the compiler. (There is also a BaseCompilerCommand.Builder.dumpInputToFile method on the builder, but it is not a public API so you may need to use a non-lib version of R8 to access it).

I think we should remove this from 8.1 beta blocking release list and probably address it in early canary because 1) it is not a regression, 2) the fix would potentially break some users because they need to add additional keep rules for a library module to make sure the consumer(app or another library) module are able to get those classes from the library module.

this should be fixed in one of the canary, so blocking beta only.

Some updates regarding this issue:

As we want to make consuming a library as project dependency consistent with consuming the same library that has been published to maven, we need to add the local file dependencies when doing the inter-project publishing for library modules.

This becomes a problem because from the consumer side, we also include file dependencies of library modules. It is part of the ArtifactScope.FILE

The challenge is how to exclude transitive file dependencies from library modules.

Option 1. Do not add this to runtimeElements when publishing -> don't seen to work, see https://gradle.slack.com/archives/C10J6STFZ/p1684347966414919

Option 2. Compute transitive file dependencies in the application by subtracting computeLocalFileDependencies -> it works for some cases but not sure it can work for all because computeLocalFileDependencies doesn't support attributes

Option 3. Publish file dependencies from library and use FilterSpec to exclude it in application, similar to packagedDependenciesClasspath -> I feel this might be a proper fix

Talked with Jerome, the consensus is to remove this from blocking list. The next step is to see if there is a simpler way to support this use case. (e.g. using included build and publish the library to local maven)

It does make sense to add support for the common use-case (library projects without local file dependencies) and to have a reasonable fallback for the other case (library projects with local file dependencies).

Stumbled upon this while looking at the list of 8.3 Beta bugs

As an additional note, library apiElements should contain non-minified classes as we'd expect external API surface of the library to be the same before and after minification. This is already the case, and no work is required here.

Is that really always the case? if you publish an AAR with obfuscation, you really want the API jar (<AAR>/api.jar) to contains the obfuscated code. I would think that the inter-project publication should be the same.

I agree that ideally we'd also compile against obfuscated classes. However, I'm concerned about blocking the compilation of downstream modules on R8.

Also, there is probably a debug variant of the consumer that will see non-obfuscated classes on the compile classpath. The IDE is also not helping as it does not know about obfuscation. So even if we do push for compile classpath to block on R8 and have obfuscated classes, users may still hit issues.

Proper seems to be introduction of api component that allows developers to specify the library API and consumers would compile only against sources in that component.

That makes sense for inter-project dependencies where the edit-build-deploy cycle would be impacted. I agree the api component would really be useful here.

Here is the doc I shared with Gradle about this issue https://docs.google.com/document/d/1B4e7N9gGk-DgXHGYtGIQSVJMxwJdvu2cFzzHUcsTLsA/edit (no feedback yet)

jedo@, can you evaluate this ticket again? (this one seems to caused quite a lot efforts but the impact is limited, not sure what is the best way moving forward)

I found https://stackoverflow.com/questions/77605786/how-to-run-proguard-r8-on-a-library-before-running-it-on-an-app-as-if-it-was-an - isn't that what this bug is about?

Soren, that is exactly this bug is about.

Moving this to P1. We really need to fix this.

I'm the person who asked the question Soren referenced in Stack Overflow. I'm taking note that this is a known bug that's gonna get fixed later on, and I'm glad to read that.

In the meantime, I found a workaround that I've described in my answer on SO: https://stackoverflow.com/a/77690962/6527252

Fixed with I5b773131437720291fe02a2897d4171596e33acd

Cool! Thank you!

Is that an AS or an AGP fix? Which version(s) will first get it?

It is AGP fix and you should be able to get it in AGP 8.4-alpha05

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 Jellyfish | 2023.3.1 Canary 4
• Android Gradle Plugin 8.4.0-alpha04

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!

@comment#37 even as soon as 8.4.0-alpha04, correct?

Yeah, feel free to try it out in 8.4.0-alpha04

I've just installed the release version of AGP 8.4.0 and can confirm that it resolves the issue. I can safely remove my workaround now, thank you.

Glad to know that it works out! Thanks for confirming.