Status Update
Comments
xa...@google.com <xa...@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
au...@google.com <au...@google.com> #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.
sp...@google.com <sp...@google.com> #4
I shared the APK and instructions to reproduce over email. Let me know if you have any trouble reproing the crash.
sp...@google.com <sp...@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.
sp...@google.com <sp...@google.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
Description
AndroidLintTask
lists the lint baseline file (e.g.lint-baseline.xml
) as an@InputFiles
property, but the file is also functioning as an@Output
of the task, since Lint, as documentedThis isn't good practice in Gradle, and leads to some odd behavior.
For instance, if you:
gradlew app:lint -Dlint.baselines.continue=true
, generating a new baseline filegradlew app:lint -Dlint.baselines.continue=true
The baseline file is not re-created, since Gradle observes the same "before" state for both invocations and marks the task as
Up-To-Date
(Gradle doesn't include the file in the "after" snapshot for the task because the file isn't marked as an@Output
). A fix/workaround is pending for this particular issue, but there may be other issues inherent to this non-idiomatic use of the Gradle API.This comment proposes a fix in AGP for the broader issue.