Status Update
Comments
je...@google.com <je...@google.com>
ra...@google.com <ra...@google.com> #2
ra...@google.com <ra...@google.com> #3
je...@google.com <je...@google.com> #4
wk...@google.com <wk...@google.com> #5
al...@google.com <al...@google.com>
al...@google.com <al...@google.com> #6
Android Studio version: 0.8.12
buildToolsVersion 21.0.1
Gradle 1.11
al...@google.com <al...@google.com> #7
--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.
ca...@google.com <ca...@google.com> #8
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 (
al...@google.com <al...@google.com>
ra...@google.com <ra...@google.com> #9
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
al...@google.com <al...@google.com> #10
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
wk...@google.com <wk...@google.com> #11
ly...@gmail.com <ly...@gmail.com> #15
Is there release date of bundletool 1.11 with support for copying profiles into generated apk from bundles as follows from the
vi...@spotify.com <vi...@spotify.com> #16
al...@google.com <al...@google.com> #17
Fix is merged into 7.2 branch and will be available in Chipmunk/AGP 7.2 Patch 2 Release
li...@pinterest.com <li...@pinterest.com> #18
de...@google.com <de...@google.com> #19
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 Dolphin Beta 2 (2021.3.1.11)
- Android Gradle Plugin 7.3.0-beta02
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!
je...@gmail.com <je...@gmail.com> #20
Hi guys new here.. need your help to fix things right. Not for me I give you my word.. I had already refunded 2 times.. please don’t let your good system get exploited by malicious user that prey on end user. Really hope good pro skill guys like you all can keep a good image and uphold what’s right! Thanks again
je...@gmail.com <je...@gmail.com> #21
Even now I just notices the report I wrote to raise here but not under my name!? So many other user!!! Please help!
sh...@pinterest.com <sh...@pinterest.com> #22
jb...@twitter.com <jb...@twitter.com> #23
Hi there - just for clarification: the release notes here say this fix was merged for 7.2.1, back in May (patch 1):
However the discussion here in June indicates this will be part of 7.2.2 (which is unreleased afaik). Can anyone clear up this discrepancy?
jb...@twitter.com <jb...@twitter.com> #24
FYI for those following - it looks like AGP 7.2.2 was released yesterday so we should be unblocked to use baseline profiles with app bundles (I haven't yet verified personally).
ju...@arkea.com <ju...@arkea.com> #25
I have similar issue and just try it out the AGP 7.3.1.
The bad location of profile still remain in this release (com.android.tools.build.profiles instead of assets.dexopt)
Any update about this ?
Thanks
be...@google.com <be...@google.com> #26
Using the
- Build release bundle
- Extract apks
- Extract universal apk
- Inspect apk in Android Studio
The Baseline Profile can be found under assets/dexopt/baseline.prof{m}
when inspecting an apk, even though it is under com.android.tools.build.profiles
when inspecting an aab.
se...@gmail.com <se...@gmail.com> #27
je...@google.com <je...@google.com> #28
#27, please file a new bug, bonus if you include a repro case.
Description
go/baseline-profiles for context.
Currently when building app bundles, baseline profiles are not being packaged into
assets/dexopt/baseline.prof
.This causes the profiles to get dropped and the app is no longer optimized.