IssueTracker

Thanks for the report. Would it be possible for you to share a zip dump of the inputs to R8, including the app's class files, keep rules, etc.? This should enable us to reproduce the build.

You can generate this by running:

./gradlew assembleRelease --no-daemon -Dcom.android.tools.r8.dumpinputtodirectory=/path/to/r8/dumps

See also https://r8.googlesource.com/r8/+/refs/heads/main/doc/compilerdump.md.

Thanks for sharing. Looking at the code from the dump it is not immediately clear why this would fail with a NullPointerException. Would it be possible for you to also share the APK that is not working?

Would it be possible for you to share a small project that reproduces this?

The dump shared in comment #3 is a debug build, which does not seem to reproduce the issue.

Thanks for sharing the reproduction. This is now fixed in R8 8.0.46 and 8.1.46. R8 8.0.46 and 8.1.46 should make it into AGP 8.0.2 and AGP 8.1.0-beta4, respectively.

Until that is released you can build with R8 8.0.46 by making the following change to settings.gradle or settings.gradle.kts.

pluginManagement {
    buildscript {
        repositories {
            mavenCentral()
            maven {
                url = uri("https://storage.googleapis.com/r8-releases/raw")
            }
        }
        dependencies {
            classpath("com.android.tools:r8:8.0.46")
        }
    }
}

I've attached a project which demonstrates when a build will break in case (3) from #16.

In this project, the app gets its namespace ("com.example.namespace") from the package attribute of the AndroidManifest.xml.

The AndroidTest component gets its namespace from the testApplicationId, and it's the same namespace as the app's.

The AndroidTest component calls com.example.namespace.R.string.app_android_test_string in ExampleInstrumentedTest, which compiles as-is (./gradlew :app:assembleAndroidTest), but if we add namespace "com.example.namespace" to the DSL, then it doesn't compile anymore because the AndroidTest component's namespace becomes "com.example.namespace.test".

Thanks for the test project.

What are the downsides of preserving the workingness of the project by adding testNamespace "com.example.namespace" in the case that there is a collision, like in this test project? It builds successfully for me, but maybe there are subsequent problems?

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.