IssueTracker

As I understand it, we need to migrate namespace definitions both from AndroidManifest.xml and from implicit definitions from applicationId / testApplicationId? Is that right? So an 8.0 project would have a

namespace <n>
testNamespace <tn>

where <n> is taken from AndroidManifest.xml package definitions if present, and applicationId if not, and <tn> is testApplicationId if present and <n>.test if not?

Sorry for the confusion. AGP would change how it computes the namespace for the androidTest variant. All the Upgrade assistant would need to do is update the source code for the import of the R class.

OK! And, I think, this should happen at the same time as the namespace declaration is migrated from AndroidManifest.xml?

It's unrelated, but it is possible that we move 8.0 to also only declare the namespace into the DSL. I would make it a separate refactoring because they are not tied at all.

I would consider first adding the right new value to models (as a new property) and then, to avoid Studio interpreting manifests and build configurations, just update to whatever the synced value of this new property is.

Updated version of this in #16 below

Currently, AUA removes the package attribute from the main manifest and instead specifies that value via the namespace DSL.

In addition to that, AUA should:

• (1) Check for a package attribute in the (possibly non-existent) androidTest AndroidManifest.xml. If there's a value there, it should be removed from that manifest, and if it's not equal to namespace + ".test", it should be specified via the testNamespace DSL.
  • If namespace == testNamespace, this is problematic because the androidTest and regular R classes will have the same namespace. Not sure what the best behavior is here? Maybe an error explaining that the user should first reset the androidTest AndroidManifest's package attribute and change the androidTest source code package accordingly?
• (2) Compare the new testNamespace with the old AndroidProject.androidTestNamespace from the model. If they are different, search the androidTest source code for references to an R class namespaced with AndroidProejct.androidTestNamespace, and change the namespace to testNamespace.

Regarding the requirements in comment#7, (1) is implemented as of ag/17392097, apart from the special handling of namespace == testNamespace. (2) is as yet unimplemented.

I have a draft implementation for the second part of (1) from comment#7, at ag/18467546, to handle the case where the inferred namespace and testNamespace are equal. Is there any documentation we can point to explaining how the user should proceed? (My in-window space budget for explanatory text is pretty limited).

+Amy

Amy, would it make sense to add documentation about setting the namespace for testing? Similar to what we have here.

It could mention the following:

• the default test namespace is namespace + ".test"
• to customize the test namespace, use the testNamespace DSL
• If setting a value for testNamespace, users should not set the same value as namespace, otherwise the test and tested R and BuildConfig classes will have the same namespace.

Yeah definitely, I can draft it and send you a CL. Thanks! Looks like we might need to update this section too: https://developer.android.com/guide/topics/manifest/manifest-element#package. Currently the package attribute is only used to set the applicationId when you first create your project, right (assuming people are setting the namespace using the DSL)?

Would it also be helpful to add a release note about this? I guess it's technically not new with Chipmunk, but looks like we didn't mention it in the last couple stable releases.

Looks like we might need to update this section too: https://developer.android.com/guide/topics/manifest/manifest-element#package

Yes, setting the package attribute in the manifest is deprecated, will cause build warnings in AGP 7.3.0, and will cause build errors in AGP 8.0.

Currently the package attribute is only used to set the applicationId when you first create your project, right (assuming people are setting the namespace using the DSL)?

The namespace DSL will always trump the package attribute, even when determining the applicationId. E.g., if a dev sets package to "com.example.package", namespace to "com.example.namespace", and doesn't set the applicationId explicitly in the DSL, the applicationId will be "com.example.namespace".

Would it also be helpful to add a release note about this? I guess it's technically not new with Chipmunk, but looks like we didn't mention it in the last couple stable releases.

I think a 7.3 release note and an 8.0 release note since we're warning starting in 7.3 and will break the build in 8.0 when the manifest has a package attribute.

Gotcha, thanks--sent you cl/449846661, to start. Is the warning/removal happening in certain Dolphin/EE preview releases, or not until the stable releases?

Thanks!

Yes, the warning started in AGP 7.3.0-alpha04.

I expect we'll switch to an error in an early AGP 8.0 alpha.

Okay sounds good, I added the Dolphin preview release note to cl/450515477 (messed up the previous CL) as well. Please let me know if you need help whenever the EE canary with the update is released!

Updated version of #7:

Currently, AUA removes the package attribute from the main manifest and instead specifies that value via the namespace DSL.

In addition to that, AUA should:

• (1) Check for a package attribute in the (possibly non-existent) androidTest AndroidManifest.xml. If there's a value there, it should be removed from that manifest , and if it's not equal to namespace + ".test", it should be specified via the testNamespace DSL.
• (2) If AndroidProject.androidTestNamespace != null && AndroidProject.androidTestNamespace != namespace, set the testNamespace DSL with AndroidProject.androidTestNamespace.
• (3) If instead AndroidProject.androidTestNamespace == namespace, set the testNamespace DSL with AndroidProject.androidTestNamespace + ".test" and warn the user that their androidTest code might no longer compile because the namespace of their androidTest R class has changed from AndroidProject.androidTestNamespace to AndroidProject.androidTestNamespace + ".test", so they might need to modify their androidTest source code accordingly.

LGTM. We should make sure to have a dac page ready (I guess for both the removal of the package attribute, and the potential conflict between namespace and testNamespace and point the users to it whenever AUA does anything related to this change.

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.