Fixed
Status Update
No update yet.
Comments
pu...@gmail.com
[Comment deleted]
ze...@google.com
tn...@google.com
sg...@google.com
Also of note is the adb error when trying to install bad APK: INSTALL_FAILED_DEXOPT
tn...@google.com
load dex files over 5Gb. -> load dex files over 5Mb.
sg...@google.com
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
sa...@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.
--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.
Description
Using: AS 2022.2.1 Canary 9, com.android.tools:desugar_jdk_libs:2.0.0, AGP 8.0.0-alpha09
Code below does not cause AS to show any warning that it is API 31+ only when
TypedArray#closeis invoked as part of a try-with-resources block:In fact, an IDE intention suggested that I converted my classic use to TypedArray (that is, calling
TypedArray#releaseafter use) to a try-with-resources block, which I did (since I saw no API warning I assumed it was either desugared or properly handled for all API levels by D8) only to see it crash on API < 31.It would be nice to have this call desugared or AS not suggesting to use try-with-resources on minApiSdk < 31 (which is probably pretty much all apps currently).