IssueTracker

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 this problem on Android 11 emulator and I don't have a rooted Android 11 device on-hand.

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.

I shared the APK and instructions to reproduce over email. Let me know if you have any trouble reproing the crash.

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.

thanks for the fix. if this can be backported to 4.0 that would be great

I've backported the fix to version 4.0.58. Could you take that version for a spin to see if that solves the issues?

I verified the fix works. Thanks!

Thanks for reporting back and your help with this issue.

ชอบ

ชอบเรียนรู้

If namespace == testNamespace, then ./gradlew :app:assembleAndroidTest should fail. See here

Thanks. (But not in the test project from comment#19 which uses AGP -alpha09).

Ah, yes, looks like that change was merged in -alpha10.

OK. I've implemented the behaviour in comment#16, except that in the case of colliding names between main and androidTest packages we block the upgrade rather than upgrade to something that doesn't work: largely because there's no real way at the moment to conditionally hook the post-upgrade display (given that the post-upgrade display absolutely must display sync status and rollback recommendations/suggestions if appropriate). I think this is probably best (and consistent with other upgrade processors).

I think that's it for Upgrade Assistant support on this, apart from the precise canary when the new behaviour is activated: over to you, Scott.

Thanks! Closing this bug as I still have Issue 200682321 open to track updating the precise canary version.

Is there a way to fix this?

Can you use the fully qualified name instead of ".TestApplication"?

If that doesn't work for you, can you give more details so I can reproduce the issue? IIUC, the actual fully qualified class name is com.myapp.android.TestApplication, and android:name=".TestApplication is located in the androidTest AndroidManifest.xml... is that correct?

Using fully qualified name fixes the problem, but it is not an elegant solution for a huge project with hundred of modules with android tests where it all needs to be fixed manually.

Unfortunately, I can't think of another way to fix the problem.

It worked well with "package" in Manifest.

Yes, but we've opted to (1) disallow setting a value for package that is different than the (test) namespace and (2) disallow having namespace match testNamespace. (1) - because it is confusing, and (2) - because there can be unintended collisions of production vs test android resources.

Very sorry for the breaking change.

Isn't this issue more related to the change we made to the test applicationID as part of this change? It used to be that the test appID was computed badly based on the test package, but we change the computation (I don't remember exactly the change).

The relative path in the manifest is expanded based on testApplicationId, not the testNamespace (computed or explicit).

You should configure this to be what you expect it to be.

The relative path in the manifest is expanded based on testApplicationId, not the testNamespace (computed or explicit).

That was the old behavior, but AGP uses the namespace now, not the application ID. See Issue 213474165.