Fixed
Status Update
Comments
sh...@google.com <sh...@google.com>
ma...@gmail.com <ma...@gmail.com> #4
Also of note is the adb error when trying to install bad APK: INSTALL_FAILED_DEXOPT
ma...@gmail.com <ma...@gmail.com> #5
load dex files over 5Gb. -> load dex files over 5Mb.
ma...@gmail.com <ma...@gmail.com> #6
Same here! Looking forward to a solution :)
Android Studio version: 0.8.12
buildToolsVersion 21.0.1
Gradle 1.11
Android Studio version: 0.8.12
buildToolsVersion 21.0.1
Gradle 1.11
js...@google.com <js...@google.com> #7
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.
--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.
ma...@gmail.com <ma...@gmail.com> #8
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?
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 (
js...@google.com <js...@google.com> #9
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 clearerhttps://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
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
ma...@gmail.com <ma...@gmail.com> #10
for Android studio use:
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
js...@google.com <js...@google.com> #11
I still have this issue and it's driving me nuts
tn...@google.com <tn...@google.com> #14
Apparently the IDE is running lint wrong, feeding lint mangled code, misinterpreting lint's results, or using cached values
The issue is the Kotlin compiler front end; when lint within AGP, we have to bundle and invoke our own copy of the Kotlin compiler front end. But when we run inside the IDE, we directly reuse the one from the Kotlin plugin; that way we don't have to re-analyze your code etc, so it's more performant. But that means that lint running in the IDE and lint running from AGP use potentially different versions of the front end.
ma...@gmail.com <ma...@gmail.com> #15
Good luck fixing this. Lint is important to the environment value of my
hobby. Let me know if I can be of any help.
On Tue, Nov 5, 2024 at 10:51 AM <buganizer-system@google.com> wrote:
hobby. Let me know if I can be of any help.
On Tue, Nov 5, 2024 at 10:51 AM <buganizer-system@google.com> wrote:
js...@google.com <js...@google.com> #16
Since CLI-side fix is already there, it's relatively easy(?) to port that to IDE-side, and actually ready; see attached screenshot.
Description
####################################################
Please provide all of the following information, otherwise we may not be able to route your bug report.
####################################################
1. Describe the bug or issue that you're seeing.
Lint produces an error for this code:
// The `produceState` API is used as an _alternative_ to model the
// UiState in the ViewModel and expose it in a stream of data.
val uiState: DetailsScreenUiState by produceState(
key1 = viewModel,
initialValue = DetailsScreenUiState(isLoading = true)
) {
val cityDetailsResult: Result<City> = viewModel.cityDetails
value = if (cityDetailsResult is Result.Success<City>) {
DetailsScreenUiState(city = cityDetailsResult.data)
} else {
DetailsScreenUiState(throwError = true)
}
}
But the program runs perfectly well.
2. Attach log files from Android Studio
2A. In the IDE, select the Help..Collect Logs and Diagnostic Data menu option.
2B. Create a diagnostic report and save it to your local computer.
2C. Attach the report to this bug using the Add attachments button.
3. If you know what they are, write the steps to reproduce:
3A. See code excerp above
3B.
3C.
In addition to logs, please attach a screenshot or recording that illustrates the problem.
For more information on how to get your bug routed quickly, see
Build: AI-242.23339.11.2421.12483815, 202410101554
AS: Ladybug | 2024.2.1 Patch 1
AI-242.23339.11.2421.12483815, JRE 21.0.3+-12282718-b509.11x64 JetBrains s.r.o., OS Windows 10(amd64) v10.0 , screens 1920x1080 (100%)
Android Gradle Plugin: 8.7.1
Gradle: 8.9
Gradle JDK: JetBrains Runtime 21.0.3
NDK: from local.properties: (not specified), latest from SDK: (not found)
CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: (not found)
Source: send_feedback_icon```