Status Update
No update yet.
Comments
xo...@google.com
xa...@google.com
xo...@google.com
xa...@google.com
so...@google.com
Android Studio version: 0.8.12
buildToolsVersion 21.0.1
Gradle 1.11
sp...@google.com
--set-max-idx-number=<value>
Unfortunately changing the default is not a solution since the linearAlloc limit can be reached at very different levels depending on the classes hierarchy and other criteria.
In addition for most applications, moving to multidex will only help to workaround the linearalloc limit for the installation. But the application will still crash against the same limit at execution. The only working use case where I know multidex can help with linearalloc is when the apk does not contains one application but distinct pieces running in separate process.
xo...@google.com
It's nice to know about that command line option. I do not see it in the output of 'dx --help', might be good to add that.
I'm not very familiar with the 'linearAlloc limit' issue outside of the context of the dexopt step. My sample app is able to run once the lower idx value is set, although I do not actually call into any of the library code that is bundled with the app. I assume it's undefined when/if the 'linearAlloc limit' will be hit in a large application on gb.
I'm a bit confused as to the platform compatibility of multidex given the 'linearAlloc limit' bug. What specific versions of Android are supported? The multidex code implies back to v4 (
xo...@google.com
The linearalloc limit is reached when loading classes. At install time dexopt is loading all classes contained in the dex so it's facing the limit immediately. At execution the limit may be reached after some delay dependending of the usage you have of the packaged classes. If you face it at install time but not at execution, this means you never trigger the loading of some classes. In a real application those never loaded classes should have been shrinked away manually or by Proguard. The exception is when there are different groups of classes in the dex files used in separate process.
About multidex library supported versions I've merged recently a change to try to be clearer
The summary is that the library should work down to API 4 (Donut), but below ICS applications will probably be hit by the linearalloc limit
sp...@google.com
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
am...@google.com
sp...@google.com
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.
am...@google.com
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!
sp...@google.com
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
packageattribute 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 thetestNamespaceDSL - (2) If
AndroidProject.androidTestNamespace != null&&AndroidProject.androidTestNamespace != namespace, set thetestNamespaceDSL withAndroidProject.androidTestNamespace. - (3) If instead
AndroidProject.androidTestNamespace == namespace, set thetestNamespaceDSL withAndroidProject.androidTestNamespace + ".test"and warn the user that their androidTest code might no longer compile because the namespace of their androidTestRclass has changed fromAndroidProject.androidTestNamespacetoAndroidProject.androidTestNamespace + ".test", so they might need to modify their androidTest source code accordingly.
xa...@google.com
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
I filed
sp...@google.com
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
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
Thanks. (But not in the test project from -alpha09).
sp...@google.com
Ah, yes, looks like that change was merged in -alpha10.
xo...@google.com
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
Thanks! Closing this bug as I still have
al...@booking.com
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
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
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
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
xa...@google.com
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
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
Basically AndroidTest variants do not the correct value for the package name for their
Rclasses. 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