Multi arch support for Android

[teobugslayer]

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]

Awesome, thanks for putting this into its own subject.

One item that you do need to make sure that is correct is the versioncode. See: https://androidbycode.wordpress.com/2015/06/30/android-ndk-version-code-scheme-for-publishing-apks-per-architecture/ covers the requirements on the versioncode much better than the official docs: http://developer.android.com/google/play/publishing/multiple-apks.html Basically each apk platform needs a apk prefix. Xyyy where X is the platform code; and yyy is my code.

Example:
If I set my version code to 105, then build a Arm-v8 then the version code ends up being:
3105. .

[Plamen5kov]

In the fourth case:

"If a pluging is missing requested architecture, stop the build. This does not apply when only jars or aars are used [Android runtime]"

.aar files can contain .so files so we should take care of that too.

[teobugslayer]

@Plamen5kov - updated the text, thank you!

[slavchev]

👍

[blagoev]

@teobugslayer some notes
The apk limit is 100MB currently.

We need to think support for all scenarios in http://developer.android.com/google/play/publishing/multiple-apks.html

Also if there is no 64bit libs in my app why the option is mandatory. A 32bit app will run fine on 64 bit devices.

I think we should package a single apk by default (and as per the guidance) and introduce complexity only when user wants it. And If he wants it allow all possible options. The tns build tools should not constrain the developer.

[teobugslayer]

@blagoev, when we switch to using combined 32 and 64 bit {N} runtime, there always will be 64 bit code in the APK. We can either make the option mandatory (again, only for the "publish" command"), or default to something which we consider "safe", like, 32-bit only build, all build, or something else. Opinions?

[blagoev]

@teobugslayer for the publish command only it is ok to have this to be mandatory. If there are no other 64bit libs in the project we can build against a 32bit only runtime. We just need to make sure the build fails if there is one plugin which does not have a 64bit library on 64 builds.