If we use a single library that adds only few MBs for each architecture then overall “user cost” may be small and multiple APKs may not be worth the our effort. This means no additional overhead related to configuring build process and APK testing and maintenance (read here about supporting multiple APKs). If we downloaded app that contains native libraries only for arm64-v8a architecture it will not also be working when we share with the device supporting armeabi-v7a after sharing the APK file (other ways around this would work because arm-v8a is backward compatible).įrom a developer perspective, this solution gives single APK to maintain which can save us a lot of time. Users often share the application using Bluetooth or Hot-Spot via SHAREit or Xender (those apps have around 100-150M users). Keep in mind that in some emerging markets (like India) mobile data transfer is quite expensive. At the end, the user will use more mobile network data and wait longer for application to download install. This solution has pros and cons, so let’s consider two points of view - user perspective and developer perspective.įrom the user perspective, APK contains more libraries than user needs (two architectures instead of one), so this means bigger APK size. That’s why it may be the better idea to configure filters only for our release build.
The downside is that if we want to test our builds on emulator we usually need native libraries for x86/x86_64 architecture. We can apply ABI filters to default config to affect all the builds.
0 kommentar(er)
