Status Update
No update yet.
Comments
vi...@google.com
je...@google.com
nc...@meta.com
je...@google.com
[Deleted User] <[Deleted User]>
Android Studio version: 0.8.12
buildToolsVersion 21.0.1
Gradle 1.11
le...@gmail.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.
ca...@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 (
je...@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
nc...@meta.com
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
ga...@google.com
xa...@google.com
ro...@sentry.io
Did this fix make it to the 7.4.0 stable release?
nc...@meta.com
According to
On the React Native side of things, we had to un-bump AGP to 7.3 as this was a major blocker for us. We also have to tell users to don't update Android Studio as Electric Eel was released today and it will prompt users to update => Resulting in broken builds.
pe...@gmail.com
ha...@gmail.com
Everything is jammed till then
je...@google.com
So far, it is scheduled for Feb 1st which looks likely at this point.
[Deleted User] <[Deleted User]>
The error does not seem to be fixed in 7.4.1. Can you confirm this is indeed released?
nc...@meta.com
Actually the issue looks like fixed on our end. We're bumping React Native to use AGP 7.4.1 and the addGeneratedSourceDirectory API here:
Thanks for working on this folks even if it took longer to land than expected
je...@google.com
#19, I am sorry, there was a misunderstanding with the release team. they had an even more urgent fix to push which was 7.4.1 and the normal dot release that contains this fix got pushed to 7.4.2 which is looking to be couple of weeks away (still working the date with them). So sorry for the wrong info, It surprised me too.
nc...@meta.com
That's confusing as the issue seems effectively fixed in 7.4.1, also in the reproducer I linked:
pe...@gmail.com
For a workmate it also failed on his first try. We might see tomorrow.
Not sure yet, but it might be flaky now, depending on some cache or other internals.
I'll report back if I know more but it's good to know about the new target of 7.4.2. Really sad this kind of thing can't make it into a .0 release as prio 0 bug, especially since it *was* ready.
Maybe you guys can take this as a feedback and improve something, feels like it just hit a process / politics wall.
ar...@gmail.com
je...@google.com
this might be due to a third party plugin. do you have a small project to reproduce the issue ?
can you provide a stack trace ?
Description
> Android Public Tracker > App Development > Android Studio > Gradle > Android Gradle Plugin
but I don't have permission to do so.
## Expected Result
AGP Variant API works well between 7.4.0-beta05 and 7.4.0-rc01
## Observed Results
Bumping AGP from 7.4.0-beta05 to 7.4.0-rc01 results in a build failure with the following message:
```
> Task :example:mapDebugSourceSetPaths FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':example:mapDebugSourceSetPaths'.
> Querying the mapped value of map(provider(java.util.Set)) before task ':example:reproducerdebugTask' has completed is not supported
```
It seems like AGP is querying the value of the `@OutputDirectory` of the task I created `example:reproducerdebugTask`.
## Reproducer
You can find a small reproducer here:
Specifically this commit shows a working setup with AGP 7.4 beta5
-
Bumping to RC01 causes the failure:
-
I've also configured the CI so you have a clean environment where you can easily reproduce.
The command to reproduce upon cloning is `./gradlew :example:assembleDebug`.
## Further Context
This issue was noticed upstream on React Native here:
as we're using a similar pattern inside the React Native Gradle Plugin.