Status Update
No update yet.
Comments
ra...@google.com
sp...@google.com
sp...@google.com
za...@gmail.com
sp...@google.com
za...@gmail.com
za...@gmail.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.
za...@gmail.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 (
sp...@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
an...@google.com
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
ju...@yahooinc.com
sp...@google.com
Thanks for the info!
If you use AGP 8.8.0-alpha02 or newer, do you still need the workaround in #13?
ju...@yahooinc.com
sp...@google.com
Thanks for the info. Any chance you can create a repro project hitting the MissingValueException? I wasn't able to repro it on my side previously.
ju...@yahooinc.com
Any chance you can create a repro project hitting the MissingValueException? I wasn't able to repro it on my side previously.
Apologies, this would not be something I would have the chance to do with my current workload.
I did note though, that when swapping freeCompilerArgs.append/appendAll for freeCompilerArgs.add/addAll the failure re-emerged. This is of interest to me since append* gets removed in Gradle 8.8:
ju...@yahooinc.com
Update:
The issue did lie in our usage of freeCompilerArgs. Traced the issue back to the following format in root build.gradle.kts. This setup had worked prior to upgrading to 2.0.0. Was able to work around the issue once I was aware of what caused it.
subprojects {
tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile>().configureEach {
compilerOptions {
freeCompilerArgs.add(*any arg here*)
}
}
}
You should be able to reproduce now with this setup in any project.
sp...@google.com
Thanks for the update! I filed
Description
I've been trying out kotlin test fixtures in AGP 8.5 was surprised to find that classes compiled by these tasks were using the jvm-target of our running JDK (22) in our case, and not the one our convention plugin sets for all KotlinCompile tasks (17).
After some digging and disallowChanges use to track down who was overriding this, it looks like AGP sources kotlinOptions from
android.kotlinOptions? tbh I didn't realize this DSL still existed, and kinda wonder why. Is this intentional? Confirmed that if I manually set these values separately, it works as expected.Could these be deduped (or at least source from the same convention as other KGP tasks?). The reason I ask is because this means to use testFixtures, our convention plugin would have to add a separate, somewhat duplicate code path to configure kotlin options just for AGP test fixtures that uses legacy APIs (i.e.
kotlinOptionsand not the new property-basedcompilerOptions).