IssueTracker

Thank you for the report and the supplied dump with the reproduction. I can confirm that the NPE is also present on HEAD, and I will look into it.

Quite a few of the class files in the dump has malformed inner-class attribute, where R8 reports e.g.:

Info in /tmp/tmpo67ucguh/program.jar:ofifmwrrhhmodsc/ψξψξψξξ.class:
Malformed inner-class attribute:
	outerTypeInternal: ofifmwrrhhmodsc/ψξψξψξξ
	innerTypeInternal: ofifmwrrhhmodsc/ψξψξψξξ$ψξξψξξξ
	innerName: ψξψξψξξ$ψξξψξξξ

These are ignored, so they should not be the reason for the NPE, but something to also look into.

I will backport this to the 8.0 and 4.0 branches.

Thank you very much for taking a look at this!

Is this fix related to the nullpointer or the malformed inner-class attributes ?

Do you have a separated ticket for it? Could you share it?

Answer to #comment6. This fix only addresses the NPE.

The malformed inner-class attributes is an issue with the input class files, and they where not related to the NPE. You will have to contact the supplier of the library where they are present if you would like to get rid of the "Info" messages (you will have to run ./gradlew --info ... to see them). From what I can see the issue is that the innerName: ψξψξψξξ$ψξξψξξξ should have been innerName: ψξξψξξξ.

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.