IssueTracker

Please provide the requested information to proceed further. Unfortunately the issue will be closed within 7 days if there is no further update.

We have shared this with our product and engineering team and will update this issue with more information as it becomes available.

Thanks for reporting this issue.

COARSE_LOCATION typically takes location information from the nearby cell tower. If many users are near the same cell tower, each of those users will be given the same position. Using a FINE position will give much more detailed information.

Also, in certain areas, for privacy reasons, a less-exact location will be given, and that less-exact location might be identical for many users. Again, a fine-location configuration will return more precise location data.

We believe with reference to the above comment, your query has been answered, hence closing the bug. Please feel free to re-open the issue in the future if desired.

Additional thoughts on #1

1. Let the APK module compile all the code and ignore the AAR Consumer ProGuard settings

This option should not only ignore the consumer rules of the AAR module, but should technically INCLUDE the normal proguard rules of the AAR module since the APK module is compiling the AAR code.

If any proguard rules are applying mapping files then the mapping files will need to be merged together.

Thank you for sharing the sample project, I can now see what's going on.

Running with ./gradlew :app:assembleRelease --debug, logs show [R8] Program classes: ... and one of the entries is MyApplication/library-plugin/build/intermediates/runtime_library_classes_jar/release/classes.jar.

Then:

unzip -l  /usr/local/google/home/gavra/Downloads/MyApplication/library-plugin/build/intermediates/runtime_library_classes_jar/release/classes.jar
Archive:  /usr/local/google/home/gavra/Downloads/MyApplication/library-plugin/build/intermediates/runtime_library_classes_jar/release/classes.jar
  Length      Date    Time    Name
---------  ---------- -----   ----
        0  1981-01-01 01:01   com/
        0  1981-01-01 01:01   com/my/
        0  1981-01-01 01:01   com/my/library/
        0  1981-01-01 01:01   com/my/library/core/
        0  1981-01-01 01:01   com/my/library/core/plugin/
        0  1981-01-01 01:01   com/my/library/core/plugins/
        0  1981-01-01 01:01   com/my/library/core/plugins/sample/
      495  1981-01-01 01:01   com/my/library/core/plugin/BuildConfig.class
      605  1981-01-01 01:01   com/my/library/core/plugins/sample/MyCoolPluginThatDoesMagic.class

Also ./gradlew :lib-plug:outgoingVariants --all shows:

- Variant : android-classes-jar
       - Attributes
          - com.android.build.api.attributes.AgpVersionAttr          = 7.3.1
          - com.android.build.api.attributes.BuildTypeAttr           = release
          - com.android.build.gradle.internal.attributes.VariantAttr = release
          - org.gradle.usage                                         = java-runtime
       - Artifacts
          - build/intermediates/runtime_library_classes_jar/release/classes.jar (artifactType = android-classes-jar)

confirming that AGP does not publish runtime classes correctly.

DBC: I'd like to caution against using applymapping as part of any library distribution. R8 has very limited support for apply mapping and it is mostly focused on enabling testing of a library/APK by allowing test references to be remapped. We don't have any official support for distributing mapping files for clients of a library to then use as part of their build. The interactions between -applymapping and other keep rules and debug flags is largely undefined.

In other words, it is fine to use -applymapping as part of building various artifacts to ensure consistency of your artifacts, but -applymapping should never be part of AAR rules. If names need stable values when distributed to clients those should have fixed names via -keepX rules.

Agreed, this is what I meant when I mentioned the mapping files in #11.

In other words, it is fine to use -applymapping as part of building various artifacts to ensure consistency of your artifacts, but -applymapping should never be part of AAR rules. If names need stable values when distributed to clients those should have fixed names via -keepX rules.

Ivan, how does agp not publish runtime classes correctly? I am not sure what is the expected behavior vs current behavior based on your comment #12.

I have not looked at the sample application, but based on comment #8, when building the release variant, the com/my/library/core/plugins/sample/MyCoolPluginThatDoesMagic.class should not be part of the published jar.

When library project uses R8, jar that it publishes to the runtimeElements should be the minified one. At the moment, we publish non-minified classes, which is incorrect. See our test that should be modified to capture this.

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.

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.