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

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