Multi arch support for Android

Multi arch support for Android

Overview

Users of NativeScript face conflicting goals when using architecture-dependant native code (*.so files). During development they want to build their program very quickly to iterate very fast. They usually develop for x86 emulator (like Genymotion or Visual Studio) and arm-based testing devices.

When publishing to Google Play Store, they may need to split the archive to avoid the 100 MB file size limit currently imposed.

Additional obstacle is that 64-bit Android does not allow mixing 64-bit and 32-bit architecture-dependent native code. When a single dependency introduces a 64-bit .so file, all dependencies must be 64-bit as well. This can easily slip during development, when people usually use 32-bit devices and emulators.

Proposed work flow

We need to solve these problems in couple of places: The CLI, the Docs and the Gradle scripts

I propose this behavior:

• Android runtime introduces aarch64 build [Android runtime]
• introduce options to control the architectures included in the apk during build:
  • –arch all (default), armeabi-v7a, arm64-v8a, x86, x86_64. Multiple architectures are allowed. The names are the IDs taken from Android docs [CLI]
• this option must be passed to the gradle build script [CLI, Android runtime]
• Gradle build script builds the correct apk [Android runtime]
• If a pluging is missing requested architecture, stop the build. This does not apply when only jars are used [Android runtime]
• The option is mandatory for the future publish command. It is also mandatory for build --release (but see bellow for comments). When building without --release, it is not mandatory. [CLI]
• document the proper structure of NativeScript plugin to allow including of .so files. See http://docs.nativescript.org/runtimes/android/getting-started/project-structure and http://docs.nativescript.org/plugins/plugins [@ErjanGavalji]

iOS

Apple has different requirements for publishing to App Store. I believe that build and publish commands can differ in this case. iOS specific functionality should be addressed in a dedicated issue.

Comments:

• If we make --arch mandatory for building in release mode, AppBuilder team will need to revise the BpcTooling to introduce it. Also, this may not be the optimal behavior for the user.

[NathanaelA]

Please note the 64 bit version of the library seems to be coming along for the ride anyway; so now the APK files are 10 megs JUST for the runtimes. Can this be moved up in priority. This does make NS look horrible compared to other solutions. And the issue is WAY more import than silly things like than #1420 which has a critical rating .

[Plamen5kov]

Hi @vbresults you can use this PR, where abi split configuration is respected and once tns build android is ran there are two resulting apk files:

testapp-debug-x86.apk
testapp-debug-armeabi-v7a.apk

I can’t tell if there will be functionality enabled in cli to help with the workflow for 3.0, but you would be able to edit the app.gradle file and it’s changes will be respected.