Status Update
Comments
sg...@google.com <sg...@google.com> #2
I can reproduce this (thanks for the repro project!)
It looks like the problem is that the desugared api list from r8 contains this entry:
java/util/Collection#removeIf(Ljava/util/function/Predicate;)Z
but the bytecode here doesn't match -- it's java/util/ArrayList. Collection isn't a directly implemented interface or a direct super class, it's an interface on the super super class. The most efficient thing runtime wise would be for the signature list to inline this method on all implemented subclasses. But I should probably at least for now go and make the desugared API lookup do something similar to what it does for API lookup -- search through all super classes and interfaces as well. This isn't a new problem, so I'm very surprised this hasn't come up before (or it has, and I've forgotten).
cl...@google.com <cl...@google.com> #3
(I have a pending CL that was working to improve the handling of fields now that r8 handles desugaring fields, I'll try to dust that off and combine the fix in there.)
sk...@gmail.com <sk...@gmail.com> #4
I went to implement this, and hooked up inheritance search when analyzing the source file containing the call.
However, lint also handles the case where the library being analyzed is not using core library desugaring (for example, it may be a plain Java library). But when that library is consumed in a downstream app module, where library desugaring is turned on, lint then processes the partial results from the library and filters each violation through the desugaring allowlist.
At this point, it's tricky to do the inheritance search -- this happens when we no longer have a compilation environment and can do class inheritance lookups. So there are three possible solutions.
First, we pay the cost up front -- even when you're not using core library desugaring, we record whether the method is potentially library desugared if turned on. (This is also tricky because at this point we don't know which exact desugaring library version is used, which determines the exact list of APIs).
Or, more expensively, for every API violation of this type we store all the potential super class and interface names for each result...
Or, we handle this in the code which generates the desugaring API list, inlining all subclasses affected. This could be quite a long list, but on the other hand this list is really only intended to be machine readable.
sk...@gmail.com <sk...@gmail.com> #5
This is partially fixed now; it's fully fixed for the sample project, but in the scenario I described in comment 4, it works if you also configure library desugaring to be on in the library.
sk...@gmail.com <sk...@gmail.com> #6
likely related:
Objects.requireNonNullElse
Objects.requireNonNullElseGet
are now also showing this same false positive warning.
Android Studio Koala | 2023.3.2 Canary 2 gradle 8.6 plugin: 8.3.1
cl...@google.com <cl...@google.com> #7
This seems unrelated. Can you file a new bug?
Specifically, for Objects.requireNonNullElse
I am not seeing a lint API error, but I am seeing a warning from IntelliJ's built-in Java inspections. These should probably not show up in Android modules. I swear we've fixed that before but I'm assuming something changed to break that.
For Objects.requireNonNullElseGet
I do see a lint API warning for that. But, that's not a recent change, right? I looked at R8's desugaring list and that method is not there. So that method does crash at runtime, right?
sk...@gmail.com <sk...@gmail.com> #8 Restricted
el...@gmail.com <el...@gmail.com> #9
sk...@gmail.com <sk...@gmail.com> #10
aha - so requireNonNullElseGet is not magical after all :)
Please let me know if I should still file a new bug.
tx
sk...@gmail.com <sk...@gmail.com> #11
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
- desugared library adds support for
Supplier
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 desugar_jdk_libs-2.0.4.jar
is
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
cl...@google.com <cl...@google.com> #12
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?
cl...@google.com <cl...@google.com>
ch...@google.com <ch...@google.com> #13
I've filed
cl...@google.com <cl...@google.com> #14
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.
sk...@gmail.com <sk...@gmail.com> #15
On studio-main I can still repro the following false positive from
- Create a new project
- Enable desugaring, run Gradle sync
- Add a usage of
java.util.Objects#requireNonNullElse
Lint warning:
Call requires API level 30 (current min is 26): java.util.Objects#requireNonNullElse
sk...@gmail.com <sk...@gmail.com> #16
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 git clone sso://user/sgjesse/B327670482
minApi | desugared library | requireNonNullElse | equireNonNullElseGet |
---|---|---|---|
21 | No | No lint message | Call requires API level 30 (and Call requires API level 24 on Supplier ) |
24 | No | No lint message | Call requires API level 30 |
21 | Yes | Call requires API level 30 | Call requires API level 30 |
The expected messages should be:
minApi | desugared library | requireNonNullElse | equireNonNullElseGet |
---|---|---|---|
21 | No | No lint message | Call requires API level 30 (and Call requires API level 24 on Supplier ) |
24 | No | No lint message | No lint message |
21 | Yes | No lint message | No lint message |
Looking at the DEX after compiling the code it is desugared as expected:
minApi | desugared library | requireNonNullElse | equireNonNullElseGet |
---|---|---|---|
21 | No | Desugared (backport) | Call to java.util.Objects through an D8 outline |
24 | No | Desugared (backport) | Desugared (backport) |
21 | Yes | Desugared (to target j$.util.Objects ) |
Desugared (to target j$.util.Objects ) |
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.
sk...@gmail.com <sk...@gmail.com> #17
Shouldn't this be a P1 and Koala.1 RC blocker?
il...@gmail.com <il...@gmail.com> #18
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)
cl...@google.com <cl...@google.com> #19
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.
el...@gmail.com <el...@gmail.com> #20
So I see two bugs listed in your table in
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
sk...@gmail.com <sk...@gmail.com> #21
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
Running the command line version of the tool without --min-api
gives exactly the list in
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;
sk...@gmail.com <sk...@gmail.com> #24
(2) With core library desugaring off, and minSdkVersion 24, lint flags requireNonNullElseGet
Fixed with Ib00094d61dbc26ff49928855ebe8dcdedf5ecf48
Close the ticket based on
pu...@gmail.com <pu...@gmail.com> #25
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!
cl...@google.com <cl...@google.com> #26
glad to confirm this is now working fine :)
Even with Plugin 8.5.0
pu...@gmail.com <pu...@gmail.com> #27
minSDK is 21 and my testing device on which these crashes happen is a Pixel 4a running Android 13 (latest beta QRP).
pu...@gmail.com <pu...@gmail.com> #28
Compling for minSDK 24, app still crashes but a bit later with a different problem:
java.lang.NoClassDefFoundError: Failed resolution of: Lj$/util/DesugarTimeZone;
Using com.android.tools:desugar_jdk_libs:2.0.2
.
pu...@gmail.com <pu...@gmail.com> #29
For the time being, I had to downgrade to AGP 7.4.1 as latest alpha AGP is completely broken for release builds (works fine for debug builds as long as minification is disabed).
Using AGP 7.4.1 with com.android.tools:desugar_jdk_libs:2.0.2
and Gradle 8.0.
AGP 7.4.1 also works fine with latest AS Giraffe so no need to downgrade AS.
il...@gmail.com <il...@gmail.com> #30
Still happening with:
Android Studio Giraffe | 2022.3.1 Canary 5
classpath "com.android.tools.build:gradle:8.1.0-alpha05"
coreLibraryDesugaring "com.android.tools:desugar_jdk_libs:2.0.2"
java.lang.NoClassDefFoundError: Failed resolution of: Lj$/util/DesugarTimeZone;
at l52.<clinit>(SourceFile:14)
at m52.<clinit>(SourceFile:24)
at rg0.<clinit>(SourceFile:1)
at sg0.<clinit>(SourceFile:13)
at d24.b(SourceFile:12)
at w70.e(SourceFile:890)
at w82.e(SourceFile:156)
at i91.get(SourceFile:25)
at o72.get(SourceFile:14)
at n80.f(SourceFile:52)
at m91.d(SourceFile:106)
at m91.e(SourceFile:145)
at com.google.firebase.provider.FirebaseInitProvider.onCreate(SourceFile:38)
at android.content.ContentProvider.attachInfo(ContentProvider.java:2451)
at android.content.ContentProvider.attachInfo(ContentProvider.java:2421)
at com.google.firebase.provider.FirebaseInitProvider.attachInfo(SourceFile:13)
at android.app.ActivityThread.installProvider(ActivityThread.java:7462)
at android.app.ActivityThread.installContentProviders(ActivityThread.java:6973)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6744)
at android.app.ActivityThread.-$$Nest$mhandleBindApplication(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2133)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7872)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
fa...@gmail.com <fa...@gmail.com> #31
when i use apk-viewer embedded in Android Studio and load mapping.txt the class shows up, also it works fine when I am using gradle-plugin version 7.4.1
Android Studio Giraffe | 2022.3.1 Canary 5
classpath "com.android.tools.build:gradle:8.1.0-alpha05"
coreLibraryDesugaring "com.android.tools:desugar_jdk_libs:2.0.2"
java.lang.NoClassDefFoundError: Failed resolution of: Lj$/time/format/DateTimeFormatter;
cl...@google.com <cl...@google.com> #32
Hi bingran@
It seems desugared library does not work at all in release mode in the latest Giraffe (AGP 8.1.0-alpha06) and all previous Giraffe. It works in Flamingo.
To reproduce:
- create an "Empty Views Activity" project,
- set desugared library (
https://developer.android.com/studio/write/java8-support#library-desugaring ), - set minifyEnabled true in release and do not alter the code in any way (not using desugared library)
It works fine in debug.
It crashed for me at start-up in release mode with:
java.lang.NoClassDefFoundError: Failed resolution of: Lj$/util/DesugarCollections;
at androidx.fragment.app.l0.<init>(SourceFile:44)
at androidx.fragment.app.u.<init>(SourceFile:13)
at androidx.fragment.app.v.<init>(SourceFile:9)
It seems that desugared library but all class names are minified. Do you have any clue? It seems release without shrinking the program but shrinking only desugared library works. Everything works fine in our local tests which let me believe (maybe wrongly) that agp is not passing the keep rules or flags correctly. Did you enable keep rules with trace reference or something like that?
bi...@google.com <bi...@google.com>
bi...@google.com <bi...@google.com> #33
It turns out the desugared apis are there but has been obfuscated when dexing with l8. If I disable obfuscation just like what we already do for non-minified release build, it works.
bi...@google.com <bi...@google.com> #34
Clement, is that expected?
When dexing desugar library with l8, we pass the program dex files generated from r8 so in theory l8 should be able to obfuscate the desugar library based on the usage from program dex files? Or apart from the program dex files, we need to pass more to l8? e.g. mapping file?
cl...@google.com <cl...@google.com> #35
I understand that desugared library has been obfuscated and that should not be the case. The keep rules (either output by R8 or through tracereference) should have prevented obfuscation. This used to work and this is still now fully tested in our test suite.
Your text confuses me. L8 should take as input the desugared library jar and not the dex files generated from r8.
Did you change the way the keep rules are generated for L8 for example by using trace reference instead of the direct r8 output? Are the keep rules identical? It seems to me the issue would be that the keep rules are incorrect.
For example, in the case above, I suspect that instead of generating:
-keep class j$.util.DesugarCollections {...}
We now have:
-keep class java.util.DesugarCollections {...}
How can I see the keep rules that agp generates for L8 a given build? I may be able to do it with dumps.
cl...@google.com <cl...@google.com> #36
Ok I figured it out.
The issue is that agp generates keep rules throught tracereference which looks like:
-keep,allowobfuscation class j$.util.concurrent.ConcurrentHashMap
We should essentially do the same but without the "allowobfuscation".
This could imply building the TraceReference command with something along the lines of:
TraceReferencesKeepRules.builder()
.setAllowObfuscation(false)
Could you fix this Bingran? I think this is P1 or P0.
cl...@google.com <cl...@google.com> #37
It would be nice if AGP could have a regression test for that too btw.
bi...@google.com <bi...@google.com> #38
With what #36 suggests, we are not doing obfuscation for desugar library apis in all the cases, right?
br...@gmail.com <br...@gmail.com> #39 Restricted
ra...@gmail.com <ra...@gmail.com> #40
- Giraffe Canary 8
- AGP 8.1.0-alpha08
- Kotlin 1.8.10
- Gradle 8.0.2
- Desugar 2.0.2
- minSdk 23
- targetSdk 33
- JDK 17
Also tested R8 dev builds but it's the same. Any suggest for a temporary workaround?
tr...@gmail.com <tr...@gmail.com> #41
ey...@gmail.com <ey...@gmail.com> #42
I have the same issue as in java.lang.NoClassDefFoundError: Failed resolution of: Lj$/util/DesugarTimeZone;
) using:
- AGP 8.1.0-alpha09
- Kotlin 1.8.10
- Gradle 8.0.2
- Desugar 2.0.2
- minSdk 24
- targetSdk 33
- JDK 17
The crash only started happening after updating from AGP 8.0.0-beta05 to AGP 8.1.0-alpha09.
I tried adding the proguard rules mentioned in allowobfuscation
and the crash still occurs.
If I set isMinifyEnabled = false
then the crash goes away.
Is there any way we can workaround this without downgrading to AGP 8.0.0?
Here's the full unobfuscated crash:
java.lang.NoClassDefFoundError: Failed resolution of: Lj$/util/DesugarTimeZone;
at com.google.firebase.encoders.json.JsonDataEncoderBuilder$TimestampEncoder.<clinit>(SourceFile:14)
at com.google.firebase.encoders.json.JsonDataEncoderBuilder.<clinit>(SourceFile:24)
at com.google.firebase.crashlytics.internal.model.serialization.CrashlyticsReportJsonTransform.<clinit>(SourceFile:1)
at com.google.firebase.crashlytics.internal.persistence.CrashlyticsReportPersistence.<clinit>(SourceFile:13)
at com.google.firebase.crashlytics.internal.common.SessionReportingCoordinator.create(SourceFile:12)
at androidx.camera.video.Recorder$$ExternalSyntheticLambda2.create(SourceFile:982)
at com.google.firebase.tracing.ComponentMonitor$$ExternalSyntheticLambda0.create(SourceFile:18)
at com.google.firebase.FirebaseApp$$ExternalSyntheticLambda0.get(SourceFile:25)
at com.google.firebase.components.Lazy.get(SourceFile:14)
at com.google.firebase.components.ComponentRuntime.doInitializeEagerComponents(SourceFile:52)
at com.google.firebase.components.ComponentRuntime.initializeEagerComponents(SourceFile:35)
at com.google.firebase.FirebaseApp.initializeAllApis(SourceFile:71)
at com.google.firebase.FirebaseApp.initializeApp(SourceFile:36)
at com.google.firebase.FirebaseApp.initializeApp(SourceFile:7)
at com.google.firebase.provider.FirebaseInitProvider.onCreate(SourceFile:12)
at android.content.ContentProvider.attachInfo(ContentProvider.java:2451)
at android.content.ContentProvider.attachInfo(ContentProvider.java:2421)
at com.google.firebase.provider.FirebaseInitProvider.attachInfo(SourceFile:13)
at android.app.ActivityThread.installProvider(ActivityThread.java:7474)
at android.app.ActivityThread.installContentProviders(ActivityThread.java:6985)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6756)
at android.app.ActivityThread.-$$Nest$mhandleBindApplication(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2129)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7884)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
Caused by: java.lang.ClassNotFoundException: j$.util.DesugarTimeZone
at com.google.firebase.encoders.json.JsonDataEncoderBuilder$TimestampEncoder.<clinit>(SourceFile:14)
at com.google.firebase.encoders.json.JsonDataEncoderBuilder.<clinit>(SourceFile:24)
at com.google.firebase.crashlytics.internal.model.serialization.CrashlyticsReportJsonTransform.<clinit>(SourceFile:1)
at com.google.firebase.crashlytics.internal.persistence.CrashlyticsReportPersistence.<clinit>(SourceFile:13)
at com.google.firebase.crashlytics.internal.common.SessionReportingCoordinator.create(SourceFile:12)
at androidx.camera.video.Recorder$$ExternalSyntheticLambda2.create(SourceFile:982)
at com.google.firebase.tracing.ComponentMonitor$$ExternalSyntheticLambda0.create(SourceFile:18)
at com.google.firebase.FirebaseApp$$ExternalSyntheticLambda0.get(SourceFile:25)
at com.google.firebase.components.Lazy.get(SourceFile:14)
at com.google.firebase.components.ComponentRuntime.doInitializeEagerComponents(SourceFile:52)
at com.google.firebase.components.ComponentRuntime.initializeEagerComponents(SourceFile:35)
at com.google.firebase.FirebaseApp.initializeAllApis(SourceFile:71)
at com.google.firebase.FirebaseApp.initializeApp(SourceFile:36)
at com.google.firebase.FirebaseApp.initializeApp(SourceFile:7)
at com.google.firebase.provider.FirebaseInitProvider.onCreate(SourceFile:12)
at android.content.ContentProvider.attachInfo(ContentProvider.java:2451)
at android.content.ContentProvider.attachInfo(ContentProvider.java:2421)
at com.google.firebase.provider.FirebaseInitProvider.attachInfo(SourceFile:13)
at android.app.ActivityThread.installProvider(ActivityThread.java:7474)
at android.app.ActivityThread.installContentProviders(ActivityThread.java:6985)
at android.app.ActivityThread.handleBindApplication(ActivityThread.java:6756)
at android.app.ActivityThread.-$$Nest$mhandleBindApplication(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2129)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7884)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:936)
`
bi...@google.com <bi...@google.com> #43
Fixed with I6290c3f7f041b9b8330e69e4e5dbf5dbb187d550 which should be available in AGP 8.1 beta01. Thanks everyone for reporting this issue!
ey...@gmail.com <ey...@gmail.com> #44
Is there a version of R8 that we can use before beta 1 is related?
bi...@google.com <bi...@google.com> #45
Unfortunately I don't think changing the r8 version works. The only workaround(but not recommended) is to configure AGP task.
sk...@gmail.com <sk...@gmail.com> #46
Is the fix available in AGP 8.1.0-alpha10?
bi...@google.com <bi...@google.com> #47
re #46, not in 8.1.0-alpha10, it is available from AGP 8.1 beta01
ey...@gmail.com <ey...@gmail.com> #48
It's listed in the 8.1.0-alpha11 changelog.
bi...@google.com <bi...@google.com> #49
Can you point me to that change log?
bi...@google.com <bi...@google.com> #51
Actually our release schedule has changed and it should be available from 8.1.0-alpha11.
Description
After recent updates to Android Studio, the Gradle plugin, and other libraries, my app works just fine on debug builds with coreLibraryDesugaring enabled (v1.1.6 and v2.0.0).
However, when building the release version, it crashes right at the beginning with this stack trace:
Happens on all API levels.
Disabling core library desguaring entirely fixes the issue, as I don't rely on any desugared APIs.
Project details:
Android Studio version: Giraffe 2022.3.1 Canary 1. Android Gradle Plugin version: 8.1.0-alpha01. Kotlin version: 1.8.0. Gradle version (in wrapper): gradle-8.0-rc-1
Hope you fix this soon.