Status Update
Comments
xo...@google.com <xo...@google.com> #2
xa...@google.com <xa...@google.com> #3
for the "out" bundle issue, this seems indeed an issue. for the second one reported adding "debugUpdateAPKArtifact" to the path, this WAI as there can more more than one transformer and we need to automatically separate them so they do not use the same output folder. for #3, I will look at it but it might be difficult to change it at this time.
xo...@google.com <xo...@google.com> #4
xa...@google.com <xa...@google.com> #5
Hello, this is a P1 S1 issue for a while now, and it's blocking us from upgrading to AGP 4.2 and further. What's the current status? And do you have plans to backport it to 4.2.x?
so...@google.com <so...@google.com> #6
no we don't have a plan to backport this. why is this blocking you from upgrading ?
sp...@google.com <sp...@google.com> #7
We sign apk's and bundles via internal service, and i don't know another way to interact with artifacts;
Yesterday i ended up with some ugly workaround:
xo...@google.com <xo...@google.com> #8
I commented on the merge request but to summarize :
you can set your signing tasks output folder to wherever you need to be :
artifacts.use(target.tasks.signedApkTaskProvider(this)).configure { signedDirProperty.set(File("/path/to/where/you/want/your/signed/files")) }
if you don't set it, then we will set a directory automatically.
xo...@google.com <xo...@google.com> #9
Thanks, Jerome!
sp...@google.com <sp...@google.com> #10
I checked that we do have correct behavior for FILE based artifacts like bundle :
> Task :app:debugUpdateArtifact
originalArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/intermediates/bundle/debug/signDebugBundle/app-debug.aab
updatedArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/bundle/debug/app-debug.aab
however, we still seem to not be consistent for the DIRECTORY based artifacts like APK:
> Task :app:debugUpdateAPKArtifact
Input folder: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/apk/debug
Output folder: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/intermediates/apk/debug
Input file: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/apk/debug/app-debug.apk
Alex, can you have a look ?
am...@google.com <am...@google.com> #11
correction, I was not correct about FILE being correct.
Instead of :
updatedArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/bundle/debug/app-debug.aab
it should be
updatedArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/app-debug.aab
``
sp...@google.com <sp...@google.com> #12
Two requests are created as they are API changes
am...@google.com <am...@google.com> #13
Fix will be available in Android Studio F/AGP 8.0 Canary 2 Release
sp...@google.com <sp...@google.com> #14
I tried to use it and at first look, it looks like everything works as expected. Thanks!
am...@google.com <am...@google.com> #15
The big issue is, that the current AGP 7.4.0 is broken. I tried to use this API and it is still broken in 7.4.0, it is probably really in AGP 8 :-(
sp...@google.com <sp...@google.com> #16
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) androidTestAndroidManifest.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 thetestNamespace
DSL - (2) If
AndroidProject.androidTestNamespace != null
&&AndroidProject.androidTestNamespace != namespace
, set thetestNamespace
DSL withAndroidProject.androidTestNamespace
. - (3) If instead
AndroidProject.androidTestNamespace == namespace
, set thetestNamespace
DSL withAndroidProject.androidTestNamespace + ".test"
and warn the user that their androidTest code might no longer compile because the namespace of their androidTestR
class has changed fromAndroidProject.androidTestNamespace
toAndroidProject.androidTestNamespace + ".test"
, so they might need to modify their androidTest source code accordingly.
xa...@google.com <xa...@google.com> #17
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.
sp...@google.com <sp...@google.com> #18
I filed
sp...@google.com <sp...@google.com> #19
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".
xo...@google.com <xo...@google.com> #20
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?
xo...@google.com <xo...@google.com> #22
Thanks. (But not in the test project from -alpha09
).
sp...@google.com <sp...@google.com> #23
Ah, yes, looks like that change was merged in -alpha10
.
xo...@google.com <xo...@google.com> #24
OK. I've implemented the behaviour in 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.
sp...@google.com <sp...@google.com> #25
Thanks! Closing this bug as I still have
al...@booking.com <al...@booking.com> #26
After upgrading to Android Gradle Plugin 8.0.1 and moving all namespaces from Manifests to build scripts, my android tests started failing, giving me the following error:
Caused by: java.lang.ClassNotFoundException: Didn't find class "com.myapp.android.test.TestApplication"
The problem seems to be related to the namespace: the namespace for android tests is %namespace% + ".test". When the OS tries to load a component that is declared in Manifest with a relative path like android:name=".TestApplication" it uses the test namespace and eventually cannot find it on the classpath.
Is there a way to fix this?
sp...@google.com <sp...@google.com> #27
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?
al...@booking.com <al...@booking.com> #28
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.
It worked well with "package" in Manifest.
Just wonder, is this the only solution?
sp...@google.com <sp...@google.com> #29
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.
al...@booking.com <al...@booking.com> #30
xa...@google.com <xa...@google.com> #31
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.
sp...@google.com <sp...@google.com> #32
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
Description
See Issue 176931684 for reference.
Basically AndroidTest variants do not the correct value for the package name for their
R
classes. We need to fix this.This would be a source level breaking change for project and we would need support in the Upgrade Assistant to fix it.
We need to discuss timing but in all likelihood that would be done in AGP 8.0