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.

I think it is fine to extend the AAR format to say that library desugaring is required. However, if we start to use it for JetPack libraries developers have to accept the license referenced for the library (see https://maven.google.com/web/index.html?q=jdk#com.android.tools:desugar_jdk_libs:2.0.3).

Weird, I could have sworn I had a CL up when I wrote that comment. Docs changes pending.

Also, ping! It's been ~1.5 years and we still can't use Java 8 language APIs in most Jetpack libraries.

To recap our discussion above:

Based on #2 and #3, library authors can specify javaLibraryDesugaring to be true and a minDesugarJdkLibs version to be used by consumer modules. No r8 version is needed at this moment.

Not sure about how we gonna do regarding the license from comment #11, so it it out of the scope of the aar metadate work?

Let me know if there is any misunderstanding, I am going to send out a CL soon. :)

Thank you for picking this up!

Not sure about how we gonna do regarding the license from comment #11, so it it out of the scope of the aar metadate work?

Yeah, that's a Jetpack policy decision. GPLv2+classpath is even more lenient than Apache 2.0 in this case, so I don't see any problems there.

When users specify javaLibraryDesugaring to be true via dsl but don't specify minDesugarJdkLibs, do we want to have a "default" minDesugarJdkLibs written into aar metadata? For example, we have a default minAgpVersion in aar metadata which is 1.0.0.

Soren, do you have some insights?

I don't think we should have a default version, but require the dependency to be specified with version, com.android.tools:desugar_jdk_libs:2.0.0. Right now we have versions 1.1.x, 1.2.x and 2.0.x, and the AGP (and then implicitly D8/R8 version) is specified in this table. So depending on how old an AGP the AAR should support the corresponding version has to be selected. If possible use version 2.0.0, if only supporting AGP 7.4 and above is OK.

From version 2.0.0 we have the additional complication that there are 3 different variants:

com.android.tools:desugar_jdk_libs_minimal:2.0.0
com.android.tools:desugar_jdk_libs:2.0.0
com.android.tools:desugar_jdk_libs_nio:2.0.0

I think we can ignore the minimal one. However, if the AAR specify the desugar_jdk_libs variant and the app specified the desugar_jdk_libs_nio variant, then the desugar_jdk_libs_nio variant should be used, as that includes the desugar_jdk_libs variant - and the other way around as well.

This is not nice to have such special handling, and we should find the right way to set this up. One thing I have sees is that guava has a dependency on listenablefuture version 9999.0-empty-to-avoid-conflict-with-guava to override other listenablefuture future dependencies. Same way we could make desugar_jdk_libs_nio have a dependency on desugar_jdk_libs version 9999.0 which is an empty artifact.

I don't think we should have a default version, but require the dependency to be specified with version

In that case, we could write desugarJdkLibs into AAR metadata like com.android.tools:desugar_jdk_libs:2.0.0 If we find javaLibraryDesugaring is true but no desugarJdkLibs, we don't compare desugar jdk dependency version from aar and the version specified in app

However, if the AAR specify the desugar_jdk_libs variant and the app specified the desugar_jdk_libs_nio variant, then the desugar_jdk_libs_nio variant should be used

Do we want to throw errors(build fails) if AAR requires desugar_jdk_libs_nio but app specifies desugar_jdk_libs? Or we just want to "upgrade" the variant to desugar_jdk_libs_nio?

If we want to do the "upgrade", that seems to be another scope of work where the desugarJdkLibs variant affects the variant used in the app. It is good to bring it up so that we can add the variant info into AAR, but I think we could tackle the "variant conflicts resolving" part in a separate ticket. This one is more about checking if the consumer meets the requirement from the aar metadata. In terms of the validation part, we could compare the versions regardless of variants and throw errors if the app version is lower than the version from AAR. Sounds good?

If we want to fail the build, we can do that as part of the validation. In this case, we will compare both version and variant.

I think we can ignore the minimal one

Can you clarify on this point in the context of my previous question?

This is not nice to have such special handling

From AGP point of view, I don't think we would have too much special handling here.

Right now we have versions 1.1.x, 1.2.x and 2.0.x, and the AGP (and then implicitly D8/R8 version) is specified in this table.

I wonder how does the compatibility requirement between AGP and desugar lib version come into play here. Can you share a case where we need throw error messages based on AGP version?

sgjesse@, can you share your thoughts regarding #18?

First of all I agree that when building the AAR we should just write the desugarJdkLibs artifact name used by the module into the AAR, i.e. whatever value is set for the dependency coreLibraryDesugaring in the module. That should be the only information needed in the AAR.

It would be great if picking the right desugar_jdk_libs when using desugared library in the app and through several AARs with different flavors and versions could use the normal Maven version resolution, so that the AAR could just add a coreLibraryDesugaring dependency to the apps dependencies:

dependencies {
  coreLibraryDesugaring(com.android.tools:desugar_jdk_libs:2.0.0)  // explicitly added by the developer
  coreLibraryDesugaring(com.android.tools:desugar_jdk_libs_nio:2.0.3)  // implicitly added from one AAR
  coreLibraryDesugaring(com.android.tools:desugar_jdk_libs:1.1.8)  // implicitly added from another AAR
}

This should result in only adding com.android.tools:desugar_jdk_libs_nio:2.0.3 as a coreLibraryDesugaring dependency. Likewise

dependencies {
  coreLibraryDesugaring(com.android.tools:desugar_jdk_libs_nio:2.0.0)  // explicitly added by the developer
  coreLibraryDesugaring(com.android.tools:desugar_jdk_libs:2.0.3)  // implicitly added from one AAR
  coreLibraryDesugaring(com.android.tools:desugar_jdk_libs:1.1.8)  // implicitly added from another AAR
}

Should also result in only adding com.android.tools:desugar_jdk_libs_nio:2.0.3 as a coreLibraryDesugaring dependency.

So

dependencies {
  coreLibraryDesugaring(com.android.tools:X:A)  // explicitly added by the developer
  coreLibraryDesugaring(com.android.tools:Y:B)  // implicitly added from one AAR
  coreLibraryDesugaring(com.android.tools:Z:C)  // implicitly added from another AAR
}

Should result in coreLibraryDesugaring(com.android.tools:max(X,Y,Z):max(A,B,C)), where the name is sorted desugar_jdk_libs_nio > desugar_jdk_libs > desugar_jdk_libs_minimal. And version is sorting by semantic version.

I am not sure if there is any way we can handle this with just Maven logic. Using the Guava "hack" with com.android.tools:desugar_jdk_libs_nio:X.Y.Z depending on com.android.tools:desugar_jdk_libs:9999.0-empty-to-avoid-non-nio would not work for the second case, as that would result in com.android.tools:desugar_jdk_libs_nio:2.0.0 and not com.android.tools:desugar_jdk_libs_nio:2.0.3.

Also looking at Anatomy of an AAR file, how does AARs specify dependencies today?

Should result in coreLibraryDesugaring(com.android.tools:max(X,Y,Z):max(A,B,C)), where the name is sorted desugar_jdk_libs_nio > desugar_jdk_libs > desugar_jdk_libs_minimal. And version is sorting by semantic version

That sounds good to me. I think we have to handle it in AGP by checking the aar metadata when determining the core library dependency version. Not so sure about maven magic.

Given that, IIUC, we should only fail the build if coreLibraryDesugaring is not enabled in consumer(e.g. app, library) when the meta data of its aar dependency requires coreLibraryDesugaring to be enabled. We don't fail the build because of version or desugar lib variant.

building the AAR we should just write the desugarJdkLibs artifact name used by the module into the AAR,

We can write something like the following into the aar.

javaLibraryDesugaring=true
desugarJdkLibs=com.android.tools:desugar_jdk_libs_nio:2.0.3

i.e. whatever value is set for the dependency coreLibraryDesugaring in the module.

Normally we ask users to specify what goes into aar metadata via dsl, it seems we are writing things into aar metadata without users input. Should we provide the option for users for specifying javaLibraryDesugaring and desugarJdkLibs? If so, the value specified by the user override the value obtained from the actual set up(whether coreLibraryDesugaring is enabled and what desugar lib is being used)?

how does AARs specify dependencies today?

I think it is via gradle metadata(or pom if gradle metadata not exist) which is not packaged inside the aar.

I think that is correct:

com.android.tools:max(X,Y,Z):max(A,B,C))

where the name is sorted desugar_jdk_libs_nio > desugar_jdk_libs > desugar_jdk_libs_minimal. And version is sorting by semantic version.

Should we provide the option for users for specifying javaLibraryDesugaring and desugarJdkLibs

Let's extract those info from android.compileOptions.coreLibraryDesugaringEnabled and the dependency resolved for coreLibraryDesugaring, instead of asking users to specify from android.defaultConfig(buildType/flavor).aarMetadata because:

1. aarMetadata is variant specific but library desugaring is global.
2. we have enough info from existing dsl to write out metadata
3. if we see a need of allowing users to "override", we can support that later.

The work for adding core library desugaring related info to AAR metadata(mvp version) is done with I9203bd7919b7b55cd3b46ea5465ecc93f55771e3 which will be available from AGP 8.2.

This means the consumer(e.g. app) will be asked to enable library desugaring if there is a requirement from its dependencies. For androidx folks, the library desugaring info is written out to aar metadata automatically if you publish your library with 8.2+

Next step would be "integrate" desugar-jdk-lib variant & version from the dependency with the ones declared on the consumer side https://buganizer.corp.google.com/issues/289401250

We have a base (library) module in our app that defines coreLibraryDesugaring and is used by various other (library) modules of the same app. The "app" (application) module of the app is also defining coreLibraryDesugaring, so until AGP 8.1.x everything was working OK.

However, when updating to AGP 8.2.x it forces us to define coreLibaryDesugaring in all the intermediate (library) modules too.

Surely, this enforcement should apply only for application-type modules, not library-type ones too, right?

Any comment on my comment above? Should I open a new issue?

File a new issue, please.

Can you also link the new issue here? Thanks

I opened issue https://issuetracker.google.com/issues/341002194