Optimizing Bundle Sizes for Android

ditto sdk size the ditto sdk for android is a fairly large package the bulk of the size is made up of native binaries compiled from native rust code which unlike kotlin and java need to be compiled for each cpu type (abi) that the sdk will be used on we currently support https //developer android com/ndk/guides/abis#sa supported by the android ndk this means that there are 4 native binaries included inside the android archive aar file we publish to https //central sonatype com/artifact/live ditto/ditto/versions below are various options to reduce the size of your application package these change aspects of the ditto sdk as it is included inside your app’s final apk file publishing to google play store if you publish your app to the google play store, the easiest way to https //developer android com/topic/performance/reduce apk size is to package your app as an https //developer android com/guide/app bundle this format allows google play to generate optimized apks for each device configuration so that users download packages streamlined for their specific device publishing to private distribution channels if your app is distributed privately to enterprise users via an mdm system, check with your mdm vendor to see whether they integrate with https //www android com/enterprise/management/ if so, they may support android app bundles ( aab files) and automatic package optimization however, if your mdm system does not support this, there are several options for manually optimizing the size of your app package compress native binaries the native binaries included with the android ditto sdk are included in an app’s package in uncompressed form by default however, setting the uselegacypackaging value to true in your app’s gradle configuration will change this to store the binaries in compressed form compressed binaries will take up less space and help to reduce the app’s final apk file size in your app’s build gradle( kts) file, add the following jnilibs block inside the packaging block gradle (groovy android { packagingoptions { jnilibs { uselegacypackaging = true } } } gradle (kotlin) android { packaging { jnilibs { uselegacypackaging = true } } } compressed binaries has shown to reduce a simple demo app’s size by 50% this uselegacypackaging build option can also be controlled using the (deprecated) android\ extractnativelibs attribute https //developer android com/guide/topics/manifest/application element#extractnativelibs on the \<application> element in the android manifest this option used to be available using the android bundle enableuncompressednativelibs gradle property caveats while this uselegacypackaging option can help to reduce your final apk file size, it is important to be aware of the side effects of changing this setting and to test your application to understand how it will behave increased app launch time as compressed binaries need to be decompressed increased app install size as uncompressed binaries are copied into app’s data directory app updates through the google play store will be larger more details https //developer android com/topic/performance/reduce apk size#extract false https //developer android com/build/releases/past releases/agp 4 2 0 release notes#compress native libs dsl https //developer android com/build/releases/past releases/agp 3 6 0 release notes#extractnativelibs exclude unused cpu architectures if your app does not need to support all of the different types of cpus (abis) that the ditto sdk supports, you can configure your build to exclude the unwanted files there are two main approaches to this the first is to just exclude the one or more abis that you don’t want the second approach is more extreme and involves building multiple apks, each with only a single abi, but it is more complicated to deploy including only a single abi has shown to reduce a simple demo app’s size by 70% in order to use either of these approaches you need to understand the cpu architecture (abi) of all the devices you will be deploying your app to excluding the abi for a device and then attempting to run the app on a device that uses the missing abi will cause the ditto sdk to crash single apk with reduced abis this approach is very simple and just excludes one or more ditto native binaries from your app package in your app’s build gradle( kts) file, add an ndk block inside the defaultconfig block like so gradle (groovy) android { defaultconfig { ndk { abifilters clear() abifilters("arm64 v8a", "armeabi v7a", "x86 64", "x86") } } } gradle (kotlin) android { defaultconfig { ndk { abifilters clear() abifilters addall(listof("arm64 v8a", "armeabi v7a", "x86 64", "x86")) } } } the example snippet above adds all 4 abis that are contained in the ditto android sdk reduce this list to just the abis of the devices that your app is deployed to android devices with intel cpus ( x86 abis) are rare nowadays, but chromebooks often have these types of cpus for more details about this ndk abifilters configuration, see https //developer android com/ndk/guides/abis#gc caveats your app will crash with message "native library failed to load" if run on a device that uses an abi excluded using this method separate apks for each supported abi this is the most involved process but it yields the absolute smallest apk size possible there are several caveats with this approach but it may be necessary if your deployment system has very limited requirements add the following splits block to your app’s build gradle( kts) file inside the android block gradle (groovy) android { splits { abi { enable = true reset() include("arm64 v8a", "armeabi v7a", "x86 64", "x86") universalapk = false } } } gradle (kotlin) android { 	 splits { abi { isenable = true reset() include("arm64 v8a", "armeabi v7a", "x86 64", "x86") isuniversalapk = false } } } the above configuration will generate a separate apk for each abi listed above in the include configuration you may remove any abis that your environment doesn’t need for more details see about the splits abi gradle configuration, see https //developer android com/build/configure apk splits#configure abi split note that the google play store requires each apk you publish to have a unique versioncode check with your mdm system’s requirements as to what their app versioning policies are a strategy for generating a unique versioncode for each apk is detailed in the https //developer android com/build/configure apk splits#configure apk versions guide for more information about this topic, see https //developer android com/google/play/publishing/multiple apks#versioncodes caveats single abi apks need to be carefully deployed to the correct devices via mdm apk versioning can be more complicated, depending on your mdm system’s requirements