Titanium JIRA Archive
Titanium SDK/CLI (TIMOB)

[TIMOB-26373] Android: Option to split apk's produced from builds based on CPU architecture arm64-v8a armeabi-v7a x86

GitHub Issuen/a
TypeNew Feature
PriorityCritical
StatusClosed
ResolutionWon't Do
Resolution Date2020-03-24T03:38:03.000+0000
Affected Version/sn/a
Fix Version/sn/a
Componentsn/a
Labelsn/a
ReporterMuhammad Ahmed Fahad
AssigneeEric Merriman
Created2018-02-12T04:43:53.000+0000
Updated2020-03-24T03:38:03.000+0000

Description

Since Ti SDK 7.0.0, the performance of the app on arm64-v8a devices has increased notably but at the same time the size of the produced apk files have become much larger due to the one apk file containing native libs for all 3 platforms: arm64-v8a, armeabi-v7a and x86. It would be good to have an option to produce split apk's based on the respective 3 architecture (in addition to the one big .apk which has the all native libs for all 3 platforms). e.g.) Current Build Output: MyApp.apk (100MB) Desired: MyApp.apk (100MB) MyApp_arm64-v8a.apk (50MB) MyApp_armeabi-v7a.apk (50MB) MyApp_x86.apk (50MB)

Comments

  1. Ewan Harris 2018-02-28

    [~fahad86] It is currently possible to build for specific abis using the abi tag under the android section of the tiapp.xml. Take a look at https://www.appcelerator.com/blog/2017/07/optimising-titanium-app-file-sizes/ and http://docs.appcelerator.com/platform/latest/#!/guide/tiapp.xml_and_timodule.xml_Reference-section-src-29004921_tiapp.xmlandtimodule.xmlReference-abi
  2. Muhammad Ahmed Fahad 2018-03-01

    @Ewan Harris, thanks for the info. Would it be possible to output all binaries in the same build rather than building individually for each architecture manually? e.g. arm64-v8a armeabi-v7a x86 all
  3. Muhammad Ahmed Fahad 2018-03-01

    I assume that the android version code will need to be bumped manually :(
  4. Muhammad Ahmed Fahad 2018-03-01

    Or we can tie an android version code to each abi element e.g.) all x86 armeabi-v7a arm64-v8a
  5. Joshua Quick 2018-05-01

    You really only need the ARMv7 architecture when releasing your APK. ARM64 devices support running ARMv7. And x86 Atom devices are rare, but I do know they can run ARMv7 apps via "libhoudini" through emulation. You can also specify multiple architectures in your "tiapp.xml" to pick and choose which architectures you want like the below. This excludes the x86 architecture and keeps ARMv7 and ARM64. 
       <ti:app xmlns:ti="http://ti.appcelerator.org">
      <android>
         <abi>armeabi-v7a,arm64-v8a</abi>
      </android>
   </ti:app>
    Alternatively, if you only want the x86 and ARMv7 architectures like how it worked before Titanium 7.0.0, then you can do this... 
       <ti:app xmlns:ti="http://ti.appcelerator.org">
      <android>
         <abi>armeabi-v7a,x86</abi>
      </android>
   </ti:app>
    _Thanks goes to [~gmathews] for testing out the above and proving that it works._
  6. Sharif AbuDarda 2018-05-04

    Hello [~fahad86], Please follow up with the guide provided by Joshua Quick above. Let us know the how it went. Thanks.
  7. Muhammad Ahmed Fahad 2018-05-04

    Hello. Thanks for the suggestion. One of the main reasons I separate apk's is that it makes the download size of the app smaller (hopefully) prompting more storage space conscious users to download the app. Also I've noticed a slight improvement in app performance with the inclusion of arm64-v8a native libs. But I also understand that building all apks at once would require a lot of manual work on the user side like maintaining version numbers which wouldn't be an ideal user experience. Currently this is what I do: 
               <abi>x86</abi>
           <!--<abi>armeabi-v7a</abi>-->
           <!--<abi>arm64-v8a</abi>-->
           <!--<abi>all</abi>-->
           <manifest android:installLocation="auto" android:versionCode="188">
    I build for each abi (top to bottom) increasing the android:versionCode with each build. It's quite a manual and lengthy process but works fine for me. Please feel free to close this item/thread. Thanks and Regards
  8. Joshua Quick 2018-05-04

    [~fahad86], thanks for your feedback. This is definitely a good thing to discuss. I know that gradle supports generating multiple APKs for each architecture (as well as by density to split image resources). I've never split it by architecture before, but my understanding is if you do create a universal APK that supports all architectures as well as separate APKs per architecture, then the universal APK has to be assigned a separate versionCode, right? That is, you can't have a universal APK that has the same versionCode as APKs having individual architectures. You said you have to increment the versionCode for each abi build, so, I assume this has been your experience. Although my understanding is if you don't create a universal APK, then each APK split by abi can use the same versionCode. If you can share your personal experience with this, then that would be great. Personally, I've always preferred the convenience of having 1 universal APK from a testing/support standpoint. But I can understand the argument of reducing the download/install size of an APK as well. Also, if we were to support building multiple APKs by architecture, would you be okay with us limiting it to production/release builds? That is, test/development builds would never be split and always universal. I'm thinking this because our current build/run process via Appcelerator Studio or the "appc run" command line really only expects one APK and I don't want us to overcomplicate it.
  9. Muhammad Ahmed Fahad 2018-05-08

    Thanks Joshua. I wasn't aware that we can use the same version number for different architecture builds. Thanks! I used to build the 'all' .apk to serve it via CDN servers (rather than Google PlayStore). But I realised that I can upload the "armeabi-v7a" version instead as it would be compatible with all devices. I would only want multiple apk's to be built before deploying to the PlayStores and NOT during development. Thanks and Regards
  10. Muhammad Ahmed Fahad 2018-05-21

    Looks like we've got something new from Google to look into: App Bundle: https://developer.android.com/guide/app-bundle/
  11. Joshua Quick 2018-05-21

    Yeah, that's good timing on Google's part. Looks like exactly what we need. Although we need to test how well it works on Android 4.x since those older OS versions do not support multiple APKs for a single app. Google states (quote below) that they combine the APKs into a single APK for older OS versions. I hope that works well. bq. for devices running Android 4.4 (API level 20) and lower, Google Play automatically serves a single APK that’s optimized for the device's configuration. It looks like the only downside with using "Android App Bundles" is you can't use Google Play "Expansion Files". Meaning that the grand total of all of your split APKs can't exceed 100 MB. I know Titanium doesn't directly support expansion files (there is a 3rd party module though), but I'd like to keep the door open for us to possibly support it in the future. Other than that, I think Android App Bundles is a good solution.
  12. Muhammad Ahmed Fahad 2020-03-24

    This issue can be *closed* as we have app bundles now.
  13. Joshua Quick 2020-03-24

    Thanks for the reminder [~fahad86]. As of Titanium 9.0.0, we now support app bundles (ie: \*.AAB files). See [TIMOB-26434] for details.

JSON Source