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.

The method Objects.requireNonNullElseGet is a bit special in terms of backporting, as it takes an argument of type Supplier, which was added in API level 24. For pure backporting (no desugared library) this method can only be backported from API level 24:

$ java -cp $ANDROID_HOME/cmdline-tools/latest/lib/r8.jar com.android.tools.r8.BackportedMethodList --min-api 24  | grep requireNonNullElse
java/util/Objects#requireNonNullElse(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
java/util/Objects#requireNonNullElseGet(Ljava/lang/Object;Ljava/util/function/Supplier;)Ljava/lang/Object;

Setting minSdk below 24 (without using desugared library) this is the DEX for the test code.

.method public test(Ljava/lang/String;)V
    .locals 1
    .param p1, "s"    # Ljava/lang/String;

    .line 8
    const-string v0, "test"

    invoke-static {p1, v0}, Ldk/gjesse/jdk11desugaredlibrary/ObjectsTest$$ExternalSyntheticBackport0;->m(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;

    .line 9
    new-instance v0, Ldk/gjesse/jdk11desugaredlibrary/ObjectsTest$1;

    invoke-direct {v0, p0}, Ldk/gjesse/jdk11desugaredlibrary/ObjectsTest$1;-><init>(Ldk/gjesse/jdk11desugaredlibrary/ObjectsTest;)V

    invoke-static {p1, v0}, Ljava/util/Objects;->requireNonNullElseGet(Ljava/lang/Object;Ljava/util/function/Supplier;)Ljava/lang/Object;

    .line 15
    return-void
.end method

with only Objects.requireNonNullElse getting backported.

With desugared library enabled this change, due to two things

1. desugared library adds support for Supplier
2. Objects is no longer backported, but implemented by desugared library

The "tool" com.android.tools.r8.ir.desugar.desugaredlibrary.lint.DesugaredMethodsList is used for desugared library:

java -cp $ANDROID_HOME/cmdline-tools/latest/lib/r8.jar com.android.tools.r8.ir.desugar.desugaredlibrary.lint.DesugaredMethodsList --min-api 15 --desugared-lib META-INF/desugar/d8/desugar.json --lib $ANDROID_HOME/platforms/android-34/android.jar --desugared-lib-jar desugar_jdk_libs-2.0.4.jar | grep Objects
java/util/Objects

(META-INF/desugar/d8/desugar.json is from https://maven.google.com/web/index.html?q=desu#com.android.tools:desugar_jdk_libs_configuration:2.0.4 and desugar_jdk_libs-2.0.4.jar is https://maven.google.com/web/index.html?q=desu#com.android.tools:desugar_jdk_libs:2.0.4).

The line java/util/Objects indicate that all methods of Objects are supported.

With desugared library (for any minSdk) this is the DEX for the test code:

# virtual methods
.method public test(Ljava/lang/String;)V
    .locals 1
    .param p1, "s"    # Ljava/lang/String;

    .line 8
    const-string v0, "test"

    invoke-static {p1, v0}, Lj$/util/Objects;->requireNonNullElse(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;

    .line 9
    new-instance v0, Ldk/gjesse/jdk11desugaredlibrary/ObjectsTest$1;

    invoke-direct {v0, p0}, Ldk/gjesse/jdk11desugaredlibrary/ObjectsTest$1;-><init>(Ldk/gjesse/jdk11desugaredlibrary/ObjectsTest;)V

    invoke-static {p1, v0}, Lj$/util/Objects;->requireNonNullElseGet(Ljava/lang/Object;Ljava/util/function/Supplier;)Ljava/lang/Object;

    .line 15
    return-void
.end method

Thanks for that explanation Søren.

So, when I tried this with the latest Koala canary, it looks like things are working correctly. For the following code:

Objects.requireNonNullElse
Objects.requireNonNullElseGet

Both AGP and Studio correctly will not flag the first call.

The second call is flagged as an API error. But if I turn on core library desugaring, then that warning also goes away, both in AGP and in Studio.

There is still the issue of the builtin Java 9 APIs inspection in IntelliJ -- again, not a lint bug, but it is a Studio bug. Original submitter, can you file that one? And can you confirm (if you're not seeing warnings for these) that you are in fact using library desugaring and a recent Studio?

I've filed b/331857025 for the other issue. I'm going to close this as working unless I hear back that the above scenario is in fact still causing Android lint warnings (not the "Usage of API documented as @since 9+" warning from IntelliJ) when core library desugaring is turned on.

thanks for filing the bug!

using library desugaring and a recent Studio?

yes I am, I have desugaring in all modules + using Koala Canary 2 now.

I will have to switch back to Jelly fish anyhow due to Koala being (to put it mildly) a runaway memory and cpu lover... which makes it nearly unusable (but that's another issue) so I might not be able to follow up on the new bug in the short term.

On studio-main I can still repro the following false positive from https://issuetracker.google.com/331857025#comment16:

1. Create a new project
2. Enable desugaring, run Gradle sync
3. Add a usage of java.util.Objects#requireNonNullElse

Lint warning:

Call requires API level 30 (current min is 26): java.util.Objects#requireNonNullElse

Just tested this with Koala.1 Beta 1, and something seems to not be right with lint (see results below). Not exactly sure where the integration is not working.

Using the test from comment #9 (repro project git clone sso://user/sgjesse/B327670482) and and looking at the lint messages in the IDE I get:

The expected messages should be:

Looking at the DEX after compiling the code it is desugared as expected:

Running the command line version of the D8 lint info generation tool the output looks correct.

As far as I can see the BackportedMethodList D8 tool generated the correct desugared methods:

minApi 21 no library desugaring:

java -cp build/libs/r8.jar com.android.tools.r8.BackportedMethodList --min-api 21 --lib third_party/android_jar/lib-v34/android.jar | grep Objects

java/util/Objects#checkFromIndexSize(III)I
java/util/Objects#checkFromIndexSize(JJJ)J
java/util/Objects#checkFromToIndex(III)I
java/util/Objects#checkFromToIndex(JJJ)J
java/util/Objects#checkIndex(II)I
java/util/Objects#checkIndex(JJ)J
java/util/Objects#isNull(Ljava/lang/Object;)Z
java/util/Objects#nonNull(Ljava/lang/Object;)Z
java/util/Objects#requireNonNullElse(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;

requireNonNullElse is desugared.

minApi 24 no library desugaring:

java -cp build/libs/r8.jar com.android.tools.r8.BackportedMethodList --min-api 24 --lib third_party/android_jar/lib-v34/android.jar | grep Objects

java/util/Objects#checkFromIndexSize(III)I
java/util/Objects#checkFromIndexSize(JJJ)J
java/util/Objects#checkFromToIndex(III)I
java/util/Objects#checkFromToIndex(JJJ)J
java/util/Objects#checkIndex(II)I
java/util/Objects#checkIndex(JJ)J
java/util/Objects#requireNonNullElse(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;
java/util/Objects#requireNonNullElseGet(Ljava/lang/Object;Ljava/util/function/Supplier;)Ljava/lang/Object;

requireNonNullElse and requireNonNullElseGet are desugared.

minApi 21 with library desugaring:

java -cp build/libs/r8.jar com.android.tools.r8.BackportedMethodList --min-api 21 --lib third_party/android_jar/lib-v34/android.jar --desugared-lib src/library_desugar/jdk11/desugar_jdk_libs.json | grep Objects

java/util/Objects#checkFromIndexSize(JJJ)J
java/util/Objects#checkFromToIndex(JJJ)J
java/util/Objects#checkIndex(JJ)J```

Neither requireNonNullElse nor requireNonNullElseGet is mentioned, but META-INF/desugar/d8/lint/compile_api_level_30/desugared_apis_30_1.txt from the desugared library configuration artifact contains:

java/util/Objects

So all of Objects is desugared.

We need to track down where the information is lost.

Shouldn't this be a P1 and Koala.1 RC blocker?

not as far as I'm concerned - this is a warning only which I can just ignore. The app compiles and works perfectly fine.

Methinks you guys have more important P1's to fix. If you need inspiration, then look at #127100532 (not related to this one at all, I'm just being ... now)

I think I found the problem.

Here's the desugaring files used in the IDE:

modelArtifact?.desugaredMethodsFiles = {ArrayList@83951}  size = 2
 0 = {File@84956} "/Users/tnorbye/.gradle/caches/transforms-4/5126fdfcbb5a995f09b8be45eb610aef/transformed/desugar_jdk_libs_configuration_nio-2.0.4-desugar-lint.txt"
 1 = {File@84957} "/Users/tnorbye/.gradle/caches/transforms-4/fc5ceb7b5de2ee8487ba96f4a79c6608/transformed/D8BackportedDesugaredMethods.txt"

What we do with these files is to "merge" them. This was just reading all the signatures from both files and sorting them. When lint is checking methods it just does a binary search.

But in this case, we're getting these methods from the d8 backport list:

java/util/Objects#checkFromIndexSize(JJJ)J
java/util/Objects#checkFromToIndex(JJJ)J
java/util/Objects#checkIndex(JJ)J

And we're getting this method from the library desugaring list:

java/util/Objects

This means that we end up with this in the signature list:

java/util/Objects
java/util/Objects#checkFromIndexSize(JJJ)J
java/util/Objects#checkFromToIndex(JJJ)J
java/util/Objects#checkIndex(JJ)J

This is wrong; the first line implies that all the other three are included. But in a binary search, if our midpoint hits one of the specific methods, we'll conclude that the match must be later in the list, so we'll falsely decide the method isn't there.

I need to fix the merging of signature files to not just concatenate but to drop specific methods and fields if the other file lists the whole class.

I don't think this is a recent regression, but I think this is showing up now through a combination of the desugaring files including newly fully backported classes, and there's luck involved based on how binary search proceeds.

So I see two bugs listed in your table in comment #16: (1) With core library desugaring on, we incorrectly flag both requireNonNullElse and requireNonNullElseGet. I've uploaded a fix for that (ag/27323706). (2) With core library desugaring off, and minSdkVersion 24, lint flags requireNonNullElseGet.

For the second one, I see that lint is passed this single database file: /Users/tnorbye/.gradle/caches/transforms-4/6cf6a445b18927988f27d9e2411efbbe/transformed/D8BackportedDesugaredMethods.txt

And that file does not contain requireNonNullElseGet:

$ grep Objects /Users/tnorbye/.gradle/caches/transforms-4/6cf6a445b18927988f27d9e2411efbbe/transformed/D8BackportedDesugaredMethods.txt | grep requireNon
java/util/Objects#requireNonNull(Ljava/lang/Object;)Ljava/lang/Object;
java/util/Objects#requireNonNull(Ljava/lang/Object;Ljava/lang/String;)Ljava/lang/Object;
java/util/Objects#requireNonNullElse(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;

Is this a problem in AGP/sync? cc: Scott

Found the issue in AGP for the second bug. When calling D8DesugaredMethodsGenerator.generate the minSdk is not passed, so it defaults to 1. Therefore changing from 21 to 24 does not make a difference (except for the red squiggles under Supplier goes away). When building the BackportedMethodListCommand an additional call to setMinApiLevel on the builder with the actual minSdk is missing here.

Running the command line version of the tool without --min-api gives exactly the list in comment #20.

java -cp build/libs/r8.jar com.android.tools.r8.BackportedMethodList --lib third_party/android_jar/lib-v34/android.jar | grep Objects | grep requireNon

java/util/Objects#requireNonNull(Ljava/lang/Object;)Ljava/lang/Object;
java/util/Objects#requireNonNull(Ljava/lang/Object;Ljava/lang/String;)Ljava/lang/Object;
java/util/Objects#requireNonNullElse(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;

Ok, I already fixed the lint desugared-file-merging thing yesterday (https://cs.android.com/android-studio/platform/tools/base/+/4d7d46888f3e7d5c7730124ed05001c08beaf201). Over to Scott for the AGP issue.

Bingran, can you take this one?

From #21:

When building the BackportedMethodListCommand an additional call to setMinApiLevel on the builder with the actual minSdk is missing here.

(2) With core library desugaring off, and minSdkVersion 24, lint flags requireNonNullElseGet

Fixed with Ib00094d61dbc26ff49928855ebe8dcdedf5ecf48

Close the ticket based on comment #20 as the other issue has been fixed with ag/27323706

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 Koala Feature Drop | 2024.1.2 Canary 6
• Android Gradle Plugin 8.6.0-alpha06

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!

glad to confirm this is now working fine :)

Even with Plugin 8.5.0