-
Notifications
You must be signed in to change notification settings - Fork 395
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build-apks fails in conjunction with coreLibraryDesugaringEnabled #182
Comments
desugar_jdk_libs is not currently fully supported in bundletool for applications with minSdk less than 21. This decision is made because even if we implement such support it will be very limited as on devices with sdk below 21 legacy multidex support is required for such apps: https://developer.android.com/studio/build/multidex#mdex-gradle. And legacy multidex support + desugar_jdk_libs has a limitation: desugar_jdk_libs requires to have its own dex file that on devices with sdk <= 21 will be loaded after the main dex file with all activities and fragments. This means that a developer won't be able to use any Java 8 classes/interfaces as field types, method parameters, or method return types in subclasses of Activity, Fragment. Java 8 classes will work correctly only as local variables and in helper classes. |
Is this only a limitation of bundletool or would an Android App Bundle submitted to Play Store suffer from the same limitations? |
The same limitations. Would you still find desugar lib useful even if you won’t be able to use Java 8 types as field types, method parameters, or method return types in subclasses of Activity, Fragment as mentioned above? |
If I know these limitations, I would still find desugar lib useful, and restrict the use of Java 8 types to helper classes. Are these limitations officially documented? Do they also apply if I build a traditional APK? I have been deploying an APK to an API 16 device, and was able to make use of java.time.LocalDate as field type of an Activity class without problem. |
They are still applicable to regular APKs as this is platform limitation. Information on how desugaring works as well as why it produces second dex file is explained in a good way here: https://jakewharton.com/d8-library-desugaring/#second-dex. Legacy multidex (multiple dex files on platforms below 21) is explained here: https://developer.android.com/studio/build/multidex#mdex-pre-l. What is primary dex file, what should be included inside primary dex file and why application may produce NoClassDefFoundError. |
I think bundletool currently supports desugaring for bundles without feature modules with limitations described above. And I will keep this issue open to have it on our radar for bundles with coreLibraryDesugaringEnabled and feature modules. |
Still no solution? |
both enabling/disabling desugar in following issue
as explained above DEX merging failed, any workaround for this issue? |
Implemented in bundletool 1.7.0. |
Describe the bug
The build-apks command fails on an app with coreLibraryDesugaringEnabled and minSdk = 16
Bundletool version(s) affected
1.2.0
Stacktrace
To Reproduce
I have patched android/app-bundle-samples in order to showcase the problem with the DynamicCodeLoadingKotlin sample: mtotschnig/app-bundle-samples@af6cec9
Expected behavior
build-apks should generate APKs to allow local testing.
Known workaround
None.
Environment:
JVM: 1.8.0_144 (Oracle Corporation 25.144-b01)
OS: Mac OS X 10.15.6 x86_64
The text was updated successfully, but these errors were encountered: