This is a bit tricky. Your APK size is going to be larger when extractNativeLibs is set to false.
Old behavior
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:
- smaller APK size because the libraries are compressed
Drawbacks:
- increased installation size ("storage" or "on disk" in Settings=>Apps) because in addition to the APK, the extracted native libraries are taking space on disk
- longer installation times
- less optimizations from Google Play, for example when generating update patches
New behavior
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:
- decreased installation size ("storage" or "on disk" in Settings=>Apps) because there's no need to extract the libraries. Basically, the occupied space is usually just a bit more than the APK size
- no increase in the download size from Google Play, because it uses its own compression on top of APK
- optimized update patch generation by Google Play, resulting in smaller update sizes. If you update your native lib, the compressed version will have huge differences causing a larger patch, while a patch for an uncompressed library is going to be relatively small.
Disadvantages:
- larger APK size because the native libs are not compressed
Expectedly, I didn't find a noticeable difference in loading performance of both options.
Conclusion
The extractNativeLibs="false" option could be useful for your if:
- you don't care about the APK size - either it is well under 100 Mb limit or you are already using expansion files (OBB) and can handle the APK size increase
- you care about the update size of your app in Google Play
- your native libraries are not very large.
For example, for a game made with Unity, this option is hardly applicable because of the large native libraries.
UPDATE: Android App Bundles
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).
