IssueTracker

Okay. I tried a bunch of agp+android studio versions

The last working version was classpath("com.android.tools.build:gradle:7.4.0-alpha06")

once I moved to

classpath("com.android.tools.build:gradle:7.4.0-alpha07") then things start breaking on firebase app dist.

Scott, assigning to you as it seem to complain the zip is not aligned while packaging which is very puzzling considering the steps...

OP, when you build the APK with AGP, are you doing any post-processing on the APK and/or do you have any custom tasks that are modifying the APK?

Can you try to verify the alignment of your APK with zipalign locally (zipalign is included in build-tools):

zipalign -c -v 4 foo.apk

Not doing any post processing. No custom tasks. I will try to verify alignment now. Give me a sec.

Scenario 1:

built my apk with agp alpha09, but didn't update firebase (bom = 30.2.0)
/Users/idle/Library/Android/sdk/build-tools/31.0.0/zipalign -c -v 4 app-release.apk

"Verification succesful"

Scenario 2:

built my apk with agp alpha09, but I DID update firebase (bom = 30.3.1)
/Users/idle/Library/Android/sdk/build-tools/31.0.0/zipalign -c -v 4 app-release.apk

"Verification FAILED"

Scenario 3:

built my apk with agp alpha09, with androidx.splash rc01
/Users/idle/Library/Android/sdk/build-tools/31.0.0/zipalign -c -v 4 app-release.apk

"Verification succesful"

Scenario 4:

built my apk with agp alpha09, with androidx.splash 1.0.0
/Users/idle/Library/Android/sdk/build-tools/31.0.0/zipalign -c -v 4 app-release.apk

"Verification FAILED"

In both failed cases if I do | grep BAD I get

 7216334 junit/runner/logo.gif (BAD - 2)
 7217354 junit/runner/smalllogo.gif (BAD - 2)

In the cases where zipalign verification fails, is the APK generated by a clean build (e.g., ./gradlew clean :app:assembleRelease)?

Does verification succeed if you add this to your build.gradle?

android {
    packagingOptions {
        exclude 'junit/runner/logo.gif'
        exclude 'junit/runner/smalllogo.gif'
    }
}

In the cases where zipalign verification fails, is the APK generated by a clean build (e.g., ./gradlew clean :app:assembleRelease)?

I clean before i generate the apk using the Android Studio menu for generating an apk

Does verification succeed if you add this to your build.gradle?

I assume it will, but let me try. Any reason why changing from androidx.splash 1.0.0-rc01 to 1.0.0 stable (which is 0 changes. all it changed was the dependency version) that it fails verification. It seems like something else is wrong that's a bit deeper than just adding these two exclude statements.

It seems like something else is wrong that's a bit deeper than just adding these two exclude statements.

I agree, but I'd like to find a workaround for you in the meantime.

I think I'll probably need a repro project to get to the bottom of it. In your other thread, it sounded like you weren't able to create a repro project... any luck since then?

I was not able to create a repro unfortunately. As soon as I started to prune things out of my project it started to succeed.

Similarly. firebase came out with a new version. and if i use that new version... then it also succeeds. 🤯

I'm glad to hear there is a workaround for now (and i learned something new about zipalign). I will try to create a repo project again later today when I have about an hour or so free to play around with it, but for now I will just commit the

android {
    packagingOptions {
        exclude 'junit/runner/logo.gif'
        exclude 'junit/runner/smalllogo.gif'
    }
}

to my codebase because that did the trick for me. Everything works. Thank you for your quick response and helpful debugging steps.

Thanks!

not able to get a repro case. literally any minor thing i change makes this verify successfully. im a bit out of ideas. the only thing i can think of that might help is why is junit being packaged into my app.

and i think the reason for that is that I depend on okhttp3:mockwebserver:4.10.0

implementation("junit:junit:4.13.2") // Needed because mockwebserver has a dependency on it. This can be removed in okhttp 5+

so the apps i ship through firebase have a mockwebserver using okhttpmockwebserver, but version 4+ requires junit while okhttp 5+ (not yet released), removes this dep.

so maybe just playing around with adding junit as a dependency to an actual app might help repro?

source: https://github.com/square/okhttp/issues/7249#issuecomment-1105109861

maybe still owrth checking out as there could be other deps that end up with the same issue. idk. just trying to be helpful i guess. but as for me. im going to consider this case closed. excluding the above like you mentioned has unblocked my team. cheers

Thanks for looking into it!

I agree it's strange they have an implementation dependency on junit, and I'm glad they're removing it in okhttp 5+.

I'll go ahead and close this bug for now.

This is fixed by Change-Id: I12ec8785cd4dbb6e523c66b4620ed2388f448822, which will be in AGP 7.4.0-rc01 and 8.0.0-alpha08.

Thanks for filing the bug, OP. Your observation in comment #2 that alpha07 was the first broken version helped me find the root cause.

FUCK YEAH! Glad I was helpful! Appreciate you working through it with me here. Cheers. Once I update to alpha08 I will remove the workaround I added. cheers

I filed Issue 243705209 to track #17.

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.