[AGP] Add generated source directory to IDE model (Variant API) [232805583]

Fixed

Bug

Status Update

No update yet.

Description

[Deleted User]

created issue #1

May 17, 2022 10:51AM

The new Variant API SourceDirectoriesImpl.addGeneratedSourceDirectory() allows to add a custom task generating source files that need to be compiled within the build process, but does not add the generated source directory to the IDE model in TaskProviderBasedDirectoryEntryImpl.

It is used in replacement of the old API BaseVariantImpl.registerJavaGeneratingTask() that automatically added the generated source directories to the IDE model.

It seems to me that the old behavior should be maintained, i.e., either:

set shouldBeAddedToIdeModel to true by default in the constructor of TaskProviderBasedDirectoryEntryImpl,
pass shouldBeAddedToIdeModel = true when creating TaskProviderBasedDirectoryEntryImpl in addGeneratedSourceDirectory,
add an optional argument to addGeneratedSourceDirectory for letting the user set the desired value of shouldBeAddedToIdeModel.

Note that it should go the same way with SourceDirectoriesImpl.addStaticSourceDirectory().

Also, I would personally not set the path of the output directory here if it has already been set by the user before calling addGeneratedSourceDirectory, since this overwriting is not documented and not obvious to the user. Or similarly to shouldBeAddedToIdeModel, this behavior (setting or not the output directory) could be controlled through an optional argument to addGeneratedSourceDirectory.

Please consider this other issue too that might be relevant as well (I did not try to reproduce it), it apppears not only in TaskProviderBasedDirectoryEntryImpl but also in ProviderBasedDirectoryEntryImpl.

Studio Build: #AI-213.7172.25.2211.8571212 (Android Studio Electric Eel | 2022.1.1 Canary 2)

Version of Gradle Plugin: 7.4.0-alpha02

Version of Gradle: 7.5-rc-1

Version of Java: 1.8

OS: Ubuntu 18.04

Comments

mk...@google.com <mk...@google.com> May 18, 2022 12:05PM

Assigned to an...@google.com.

je...@google.com <je...@google.com> #2May 24, 2022 08:02PM

Reassigned to al...@google.com.

[Comment deleted]

al...@google.com <al...@google.com> Jun 3, 2022 03:53PM

Accepted by al...@google.com.

[Deleted User] <[Deleted User]> #3Jul 1, 2022 06:56PM

[Comment deleted]

al...@google.com <al...@google.com> #4Jul 22, 2022 06:50PM

Also of note is the adb error when trying to install bad APK: INSTALL_FAILED_DEXOPT

al...@google.com <al...@google.com> #5Sep 16, 2022 11:13PM

Marked as fixed.

load dex files over 5Gb. -> load dex files over 5Mb.

mi...@gmail.com <mi...@gmail.com> #6Sep 18, 2022 01:17PM

Same here! Looking forward to a solution :)

Android Studio version: 0.8.12
buildToolsVersion 21.0.1
Gradle 1.11

cm...@google.com <cm...@google.com> #7Oct 10, 2022 04:54PM

Accepted by cm...@google.com.

There is already an option in dx allowing to force generation of smaller dex files:
--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.

cm...@google.com <cm...@google.com> #8Oct 12, 2022 03:03PM

Marked as fixed.

Thanks for your quick response.

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 (

https://android.googlesource.com/platform/frameworks/multidex/+/master/library/src/android/support/multidex/MultiDex.java) but it would seem that ICS is the earliest supported platform. Is this correct?

fr...@gmail.com <fr...@gmail.com> #9Oct 13, 2022 03:50PM

The option is not documented in --help because it was designed for testing and we're not capable of documenting a reliable way to use it as a workaround of the linearalloc limit.

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

https://android-review.googlesource.com/#/c/108023/
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