Status Update
Comments
mk...@google.com <mk...@google.com>
je...@google.com <je...@google.com> #2
Here is the stacktrace:
java.lang.VerifyError: Verifier rejected class WN: android.app.Notification$Style WN.h(android.app.Person, android.app.PendingIntent) failed to verify: android.app.Notification$Style WN.h(android.app.Person, android.app.PendingIntent): [0x4] can't resolve returned type 'Reference: android.app.Notification$Style' or 'Unresolved Reference: android.app.Notification$CallStyle' (declaration of 'WN' appears in base.apk!classes4.dex)
at Tj.<init>(SourceFile:17)
at kT1.<init>(SourceFile:23)
at aL1.<init>(SourceFile:293)
at bh4.get(SourceFile:1606)
at cL1.a(SourceFile:29)
at cL1.e(SourceFile:17)
at s1i.getValue(Unknown Source:17)
at dL1.a(SourceFile:11)
at RQ1.b(Unknown Source:2)
at EQ1.execute(SourceFile:15)
at lU1.handleMessage(SourceFile:18)
at android.os.Handler.dispatchMessage(Handler.java:106)
at N52.dispatchMessage(SourceFile:7)
at android.os.Looper.loop(Looper.java:237)
at android.os.HandlerThread.run(HandlerThread.java:67)
Unfortunately, I can't share the dex2oat
logs for this as I'm running into
al...@google.com <al...@google.com>
[Deleted User] <[Deleted User]> #3
Thanks for the report. Can you share the APK failing and give suggestions to force the error such that I can see the entire logcat on device. The outline is looking correct so I believe the error is someplace else and logcat will show that.
al...@google.com <al...@google.com> #4
I shared the APK and instructions to reproduce over email. Let me know if you have any trouble reproing the crash.
al...@google.com <al...@google.com> #5
Thank you for the dump and information. Turns out that behavior of the verifier changed on Android 11 and 12 but was reverted again. I am working on a fix that should be easy to merge to the 4.0 branch.
Note that the verification error is actually also easy to create by manual outlining, but our pattern just emphasize it.
mi...@gmail.com <mi...@gmail.com> #6
Branch: main
commit b7b22190797c9b74218fb1d2fdfb497a9be9fb3b
Author: Morten Krogh-Jespersen <mkroghj@google.com>
Date: Mon Mar 20 13:03:38 2023
[ApiModel] Insert CheckCast for return values causing verification error
Bug:
Change-Id: I2479d669217d90f057fa248fcea0f0f27faf91a6
M src/main/java/com/android/tools/r8/androidapi/ComputedApiLevel.java
M src/main/java/com/android/tools/r8/ir/code/Return.java
M src/main/java/com/android/tools/r8/ir/conversion/IRConverter.java
M src/main/java/com/android/tools/r8/ir/desugar/apimodel/ApiInvokeOutlinerDesugaring.java
A src/main/java/com/android/tools/r8/ir/optimize/RemoveVerificationErrorForUnknownReturnedValues.java
M src/main/java/com/android/tools/r8/utils/AndroidApiLevelUtils.java
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
M src/test/java/com/android/tools/r8/apimodel/ApiModelManualOutlineWithUnknownReturnTypeTest.java
M src/test/java/com/android/tools/r8/apimodel/ApiModelOutlineHorizontalMergingTest.java
M src/test/java/com/android/tools/r8/apimodel/ApiModelOutlineInstanceInitializerTest.java
M src/test/java/com/android/tools/r8/apimodel/ApiModelOutlineWithUnknownReturnTypeTest.java
cm...@google.com <cm...@google.com> #7
Branch: main
commit 88dd6ed0006725301bcbe88942e474569c9aa1b1
Author: Morten Krogh-Jespersen <mkroghj@google.com>
Date: Mon Mar 20 12:43:54 2023
[ApiModel] Add tests for introducing verification issues when outlining
Bug:
Change-Id: I5684a12bf42422bb96122422e063ffd0503fb5e5
M src/main/java/com/android/tools/r8/utils/AndroidApiLevel.java
A src/test/java/com/android/tools/r8/apimodel/ApiModelManualOutlineWithUnknownReturnTypeTest.java
A src/test/java/com/android/tools/r8/apimodel/ApiModelOutlineWithUnknownReturnTypeTest.java
cm...@google.com <cm...@google.com> #8
thanks for the fix. if this can be backported to 4.0 that would be great
fr...@gmail.com <fr...@gmail.com> #9
Branch: 8.0
commit e1cdcb66b3a225076a41b646a2684d150a594693
Author: Rico Wind <ricow@google.com>
Date: Tue Mar 21 18:58:29 2023
Version 8.0.39
Bug:
Change-Id: Iad8a15631027cf587871f6c8df12a8b4c601296c
M src/main/java/com/android/tools/r8/Version.java
Description
The new Variant API SourceDirectoriesImpl.addGeneratedSourceDirectory() allows to add a custom task generating source files that need to be compiled within the build process, but does not add the generated source directory to the IDE model in TaskProviderBasedDirectoryEntryImpl .
It is used in replacement of the old API BaseVariantImpl.registerJavaGeneratingTask() that automatically added the generated source directories to the IDE model.
It seems to me that the old behavior should be maintained, i.e., either:
shouldBeAddedToIdeModel
totrue
by default in the constructor ofTaskProviderBasedDirectoryEntryImpl
,shouldBeAddedToIdeModel = true
when creatingTaskProviderBasedDirectoryEntryImpl
inaddGeneratedSourceDirectory
,addGeneratedSourceDirectory
for letting the user set the desired value ofshouldBeAddedToIdeModel
.Note that it should go the same way with SourceDirectoriesImpl.addStaticSourceDirectory() .
Also, I would personally not set the path of the output directory here if it has already been set by the user before calling
addGeneratedSourceDirectory
, since this overwriting is not documented and not obvious to the user. Or similarly toshouldBeAddedToIdeModel
, this behavior (setting or not the output directory) could be controlled through an optional argument toaddGeneratedSourceDirectory
.Please consider this other issue too that might be relevant as well (I did not try to reproduce it), it apppears not only in TaskProviderBasedDirectoryEntryImpl but also in ProviderBasedDirectoryEntryImpl .
Studio Build: #AI-213.7172.25.2211.8571212 (Android Studio Electric Eel | 2022.1.1 Canary 2)
Version of Gradle Plugin: 7.4.0-alpha02
Version of Gradle: 7.5-rc-1
Version of Java: 1.8
OS: Ubuntu 18.04