Status Update
No update yet.
Comments
au...@google.com
tn...@google.com
ra...@google.com
js...@google.com
js...@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.
js...@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 (
tn...@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
au...@google.com
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
tn...@google.com
sp...@google.com
Re-opening this bug because of #13. Feel free to close or reassign to me if you think that's out of scope of the original bug, Tor.
tn...@google.com
This is happening because AndroidX turns off lint's bytecode verifier. It's the bytecode verifier that figures out a lint jar is using incompatible APIs, detects that it's the analysis API, and then does bytecode patching in order for things to work. Without the bytecode verifier you're running the original lint checks which are using nonexistent classes -- because the analysis API has changed.
(It looks like this is done in a modified version of gradlew, line 41: export ANDROID_LINT_SKIP_BYTECODE_VERIFIER=true.)
Longer term you'll want to update the AndroidX source base to use the new analysis APIs directly, but if you do that now the new AndroidX libraries won't work with older AGPs and IDEs so I guess holding off a cycle or two is good.
I'm marking this bug as fixed since we've used it to track the external issue that AndroidX lint checks stopped working in 8.7.0-alpha04, which is now fixed by the bytecode verifier. If there's additional work to be done on AndroidX' internal setup let's use a different issue for it (since this bug will be referenced in release notes, the fix is going into canaries etc.)
fs...@google.com
Thanks for explaining Tor, that makes sense. I've filed
js...@google.com
an...@google.com
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Ladybug Feature Drop | 2024.2.2 Canary 1
- Android Gradle Plugin 8.8.0-alpha01
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
an...@google.com
The fixes for this issue are now also available in:
- Android Studio Ladybug | 2024.2.1 Beta 2
- Android Gradle Plugin 8.7.0-beta02
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
md...@gmail.com
We are grateful
Description
We are in the process of upgrading AndroidX to AGP version 8.7.0-alpha04 (or higher) and have run into an issue with some existing published lint checks which are now failing due to
java.lang.NoClassDefFoundError: org/jetbrains/kotlin/analysis/api/session/KtAnalysisSessionProviderWe currently run with
ANDROID_LINT_SKIP_BYTECODE_VERIFIER=true, enabling the bytecode verifier correctly skips these checks.However, if I understand the situation the incompatibility will still cause these recently published checks to be disabled until users are able to upgrade to a version published after AndroidX has upgraded, and in addition to that those same checks on the new version will be disabled for anyone using a version prior to 8.7.0-alpha04.
I see we're doing some