IssueTracker

We need the following info:

• if Java library desugaring is enabled
• min version of com.android.tools:desugar_jdk_libs library
• min r8 version - Søren is that really needed, or there is no dependency between desugar_jdk_libs and R8?

For the relationship between the desugared library and the version of R8 there will be a dependency, so that for instance version 2.0.0 of com.android.tools:desugar_jdk_libs could require at least R8 3.2.X. Now the com.android.tools:desugar_jdk_libs dependency should carry enough information to fail if not supported by the current version of R8. Until now the only dependency is that R8 2.0.X is required. I am preparing a section on DAC with this matrix, which initially will be small. So for com.android.tools:desugar_jdk_libs no explicit R8 version should be needed as well, except for better/earlier error reporting.

However, there might be other reasons for requiring a specific R8 version:

• the code in the AAR might use a method which is only backported from a specific R8 version (e.g. List.of which was added recently). This is not something new, and could have happened before as well. We cannot easily check the code in the AAR, as some code might (indirectly) be guarded by an API level check, so that the backporting in not necessarily needed.
• the code in the AAR is compiled with a more recent javac (e.g. JDK 11 or JDK 17), and that could mandate a lower R8 bound. This is also not new, but here we could check the code when building the AAR.

If using a library with desugaring enabled, the build should fail (or at least give warning) when desugaring is not enabed in the library/application that depends on such library

Could we get an update on prioritization? I'm updating Android API Guidelines right now, and it's unfortunate that library developers still can't use core library desugaring over a year later:

Libraries targeting SDK < 26 *must not* use `java.time.*` until the AAR format
supports advertising core library desugaring requirements (see
[b/203113147](https://issuetracker.google.com/203113147)).

Bumping this since it overlaps with class verification out-of-lining being built into R8 / D8. We can't stop manually out-of-lining new API references until we're able to specify minimum required R8 / D8 versions.