I am not sure, if I got this right. It seems it is doing the oposite. If I keep the flag android:extractNativeLibs set to true, the app is taking about 70MB of user's space (yeah...) but if I set this flag to false, the size of the app installed on the device jumps to about 95MB. So I am not sure if user would appreciate this.
With provisions such as Proguard, one can compress the APK file size and optimize libraries easily. Compressing images and using vector graphs are also useful in reducing app size.
You can compress an APK file (rar, zip), but it has to be decompressed in order to work. ProGuard is a free Java class file shrinker, optimizer, obfuscator, and preverifier. It detects and removes unused classes, fields, methods, and attributes. It optimizes bytecode and removes unused instructions.
This is a bit tricky. Your APK size is going to be larger when extractNativeLibs is set to false.
When extractNativeLibs is set to true (default) or not added to the manifest, your native libraries can be stored compressed in the APK. They are extracted by the PackageManager during installation, and a copy is put to /data/app/. As a result, there are two copies of the native library - a compressed in the APK, and an uncompressed in /data/app/.
This approach has the following advantages:
Drawbacks:
New approach introduced by Google in Marshmallow (Android 6) is enabled by setting extractNativeLibs to "false". It expects the libraries stored uncompressed in the APK (STORE method) and zipaligned. There's no need to extract them during installation. On app startup, the libraries can be loaded (memmapped) directly from the APK.
Advantages:
Disadvantages:
Expectedly, I didn't find a noticeable difference in loading performance of both options.
The extractNativeLibs="false" option could be useful for your if:
For example, for a game made with Unity, this option is hardly applicable because of the large native libraries.
Android App Bundles are a new distribution mechanism announced by Google Play, more details available on the official websites https://developer.android.com/platform/technology/app-bundle/ and https://developer.android.com/guide/app-bundle/
It has significant advantages over a traditional APK, one of the most important being the 150 Mb max size limit. Important: this is the download size, not the size of the app bundle itself or the generated APK. (APKs are generated by Play and delivered to the device on-the-fly, more details on how it works should be available on official Android resources).
When building an AAB, it has the extractNativeLibs flag set to "false" by default. However, as Google Play applies compression on top of the APKs delivered to the end device, this doesn't affect the download size. It means that this flag brings only benefits in case of Android App Bundles - faster installation, less size on disk at almost no additional cost because of no pressure towards the max size limit.
One confusing thing however is how to calculate the download size when you're close to the 150 Mb limit, because the AAB size is not an indication of the download size. There is a special command for that in the bundletool https://developer.android.com/studio/command-line/bundletool#measure_size, or you can try uploading it to Play directly. If your AAB is well under 150 Mb, there's no need to worry then.
(Update: using 150 Mb size limit instead of 500 Mb for app bundles; apparently 500 MB was available in developer preview but is not public as of now).
extractNativeLibs="false"
could be counterproductive if your APK contains multiple ABIs. Let's say you're using a library which is 10 MB for each ABI and can be compressed to 5 MB. If you have 3 ABIs, then the result is:
extractNativeLibs="true":
APK: 15 MB (3 x 5 MB)
Extracted: 10 MB
Total: 25 MB
extractNativeLibs="false":
APK: 30 MB (3 x 10 MB)
Extracted: 0 MB
Total: 30 MB
As of 2019, the recommended way to mitigate this is to use the Android App Bundle format.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With