Fixed
Status Update
Comments
sg...@google.com <sg...@google.com> #2
[Comment deleted]
ap...@google.com <ap...@google.com> #4
Also of note is the adb error when trying to install bad APK: INSTALL_FAILED_DEXOPT
ap...@google.com <ap...@google.com> #5
load dex files over 5Gb. -> load dex files over 5Mb.
ap...@google.com <ap...@google.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
ap...@google.com <ap...@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.
ap...@google.com <ap...@google.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 (
ap...@google.com <ap...@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
ap...@google.com <ap...@google.com> #10
for Android studio use:
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
dexOptions {
additionalParameters = ['--multi-dex', '--set-max-idx-number=40000']
}
ap...@google.com <ap...@google.com> #11
I still have this issue and it's driving me nuts
ap...@google.com <ap...@google.com> #14
Project: r8
Branch: 8.0
commit 7b9dea5b4c29b5aa9dde2e4a7db4cb28b68c9caf
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:43:32 2023
Fix test after changing API level for rewriting of JDK-8272564
Bug: b/271408544
Change-Id: I67552a7fb13657ac9b4fb706592754d74d1b0653
M src/test/java/com/android/tools/r8/desugar/jdk8272564/Jdk8272564Test.java
https://r8-review.googlesource.com/76887
Branch: 8.0
commit 7b9dea5b4c29b5aa9dde2e4a7db4cb28b68c9caf
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:43:32 2023
Fix test after changing API level for rewriting of JDK-8272564
Bug:
Change-Id: I67552a7fb13657ac9b4fb706592754d74d1b0653
M src/test/java/com/android/tools/r8/desugar/jdk8272564/Jdk8272564Test.java
ap...@google.com <ap...@google.com> #15
Project: r8
Branch: 8.0
commit 2a7c539ec35668c77b0eacb27612d7a5d8a2d11a
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:43:21 2023
Also apply the rewriting for JDK-8272564 up to Andorid R
Bug: b/271408544
Change-Id: I240de7d301677668b9c13b3b49c7b7951e6434b6
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
https://r8-review.googlesource.com/76886
Branch: 8.0
commit 2a7c539ec35668c77b0eacb27612d7a5d8a2d11a
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:43:21 2023
Also apply the rewriting for JDK-8272564 up to Andorid R
Bug:
Change-Id: I240de7d301677668b9c13b3b49c7b7951e6434b6
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
ap...@google.com <ap...@google.com> #16
Project: r8
Branch: 4.0
commit ce3a4742ffec584560975df35ddae726ebdad65e
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:44:41 2023
Fix test after changing API level for rewriting of JDK-8272564
Bug: b/271408544
Change-Id: I67552a7fb13657ac9b4fb706592754d74d1b0653
M src/test/java/com/android/tools/r8/desugar/jdk8272564/Jdk8272564Test.java
https://r8-review.googlesource.com/76890
Branch: 4.0
commit ce3a4742ffec584560975df35ddae726ebdad65e
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:44:41 2023
Fix test after changing API level for rewriting of JDK-8272564
Bug:
Change-Id: I67552a7fb13657ac9b4fb706592754d74d1b0653
M src/test/java/com/android/tools/r8/desugar/jdk8272564/Jdk8272564Test.java
ap...@google.com <ap...@google.com> #17
Project: r8
Branch: 4.0
commit 608e9673999593f6c107570c7cd1df6d55e20c3a
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:44:31 2023
Also apply the rewriting for JDK-8272564 up to Andorid R
Bug: b/271408544
Change-Id: I240de7d301677668b9c13b3b49c7b7951e6434b6
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
https://r8-review.googlesource.com/76889
Branch: 4.0
commit 608e9673999593f6c107570c7cd1df6d55e20c3a
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:44:31 2023
Also apply the rewriting for JDK-8272564 up to Andorid R
Bug:
Change-Id: I240de7d301677668b9c13b3b49c7b7951e6434b6
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
ap...@google.com <ap...@google.com> #18
Project: r8
Branch: 8.0
commit 7b9dea5b4c29b5aa9dde2e4a7db4cb28b68c9caf
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:43:32 2023
Fix test after changing API level for rewriting of JDK-8272564
Bug: b/271408544
Change-Id: I67552a7fb13657ac9b4fb706592754d74d1b0653
M src/test/java/com/android/tools/r8/desugar/jdk8272564/Jdk8272564Test.java
https://r8-review.googlesource.com/76887
Branch: 8.0
commit 7b9dea5b4c29b5aa9dde2e4a7db4cb28b68c9caf
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:43:32 2023
Fix test after changing API level for rewriting of JDK-8272564
Bug:
Change-Id: I67552a7fb13657ac9b4fb706592754d74d1b0653
M src/test/java/com/android/tools/r8/desugar/jdk8272564/Jdk8272564Test.java
ap...@google.com <ap...@google.com> #19
Project: r8
Branch: 8.0
commit 2a7c539ec35668c77b0eacb27612d7a5d8a2d11a
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:43:21 2023
Also apply the rewriting for JDK-8272564 up to Andorid R
Bug: b/271408544
Change-Id: I240de7d301677668b9c13b3b49c7b7951e6434b6
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
https://r8-review.googlesource.com/76886
Branch: 8.0
commit 2a7c539ec35668c77b0eacb27612d7a5d8a2d11a
Author: Søren Gjesse <sgjesse@google.com>
Date: Fri Mar 03 08:43:21 2023
Also apply the rewriting for JDK-8272564 up to Andorid R
Bug:
Change-Id: I240de7d301677668b9c13b3b49c7b7951e6434b6
M src/main/java/com/android/tools/r8/utils/InternalOptions.java
sg...@google.com <sg...@google.com> #20
Backported to 8.0.33, 4.0.55 and 3.3.91 for AGP 8.0, 7.4 and 7.3 respectively. To use a specific R8 version merge the following into settings.gradle
or settings.gradle.kts
:
pluginManagement {
buildscript {
repositories {
mavenCentral()
maven {
url = uri("https://storage.googleapis.com/r8-releases/raw")
}
}
dependencies {
classpath("com.android.tools:r8:8.1.4-dev")
}
}
}
Description
From the issuehttps://github.com/android/android-test/issues/1642 reported on Espresso 3.5.1 it looks as if the rewrite for JDK-8272564 need to be applied to API level 28-30.
This was first applied before 26, but after b/231450655 it was also applied on API level 26 and 27. However the Espresso issue indicate that this can also cause issues on API level 28-30.
The failure is
The code as
androidx.test.espresso.matcher.ViewMatchers.getMismatchDescriptionString(ViewMatchers.java:3)
isHow that ends up in
org.hamcrest.BaseDescription.appendValueList(BaseDescription.java:76)
I cannot explain.If the JDK-8272564 rewrite is applied the
java.lang.IncompatibleClassChangeError
does not happen.