Android APKs can support seven different architectures as defined by the presence of .so files (native libraries) in the lib/<ABI> folders in the APK. Where <ABI> corresponds to the supported architectures, that is, on Android: armeabi, armeabi-v7a, x86, mips, arm64-v8a, mips64, x86_64.
All the architectures are automatically supported in case there is no .so files inside an APK, but that’s not the case with Visual Studio* 2015 projects. APKs from Visual Studio* 2015 Android* application projects generate CPU-specific APKs, whether they’re C# (Xamarin) or Visual C++ projects.
It’s a good practice to support all the architectures Android* can run on, from a single APK. If it makes the APK too big or if it’s simply not possible to do so with a specific toolchain, it’s also possible for an application to have multiple APKs, each targeted to different architecture, on the Play* Store.
You must follow one simple rule for properly packaging and distributing multiple APKs: Version codes have to differ and be preferably ordered this way:
x86_64 versionCode > arm64-v8a > mips64 > x86 > mips > armeabi-v7a > armeabi
The reason for this rule is that the Play Store will always distribute the APK that has the highest version code, from the ones that are compatible with the client device. x86(_64) devices may be able to run ARM APKs too, so the highest version codes have to go to the x86_84 and x86 APKs in order for the right APKs to be distributed onto the devices that can run them better.
For Visual C# (Xamarin) projects
In debug mode, the .so files for all the architectures are embedded by default. That may give you the impression that everything is fine while you’re developing, but in fact, in release mode only armeabi libs are integrated by default.
To change that, open your application properties, and under Android Options, Advanced, tick all the architectures you want to support:
When you run a release build, the output will be an APK containing libs for all the selected architectures:
If you want to trim down the size of this APK, you can enable the build to generate one APK per architecture (the version codes will be correctly handled by default):
To see how to upload these multiple APKs to a single application on the Play Store you need to follow the steps described at the end of this article.
For Visual C++ projects
Visual C++ projects are enabled by default for two targets: ARM (armeabi-v7a) and x86.
<project name="custom_rules">
<available file="libs/x86" > <available file="libs/armeabi-v7a" > <target name="-pre-build-x86" if="x86Dir.exists" unless="armDir.exists">
<echo>prefixing version code with 5 (for x86 ABI).</echo>
<replaceregexp file="AndroidManifest.xml" match="android:versionCode.*([0-9]+).*"
replace='android:versionCode="5\1"'/>
</target>
<target name="-pre-build-arm" if="armDir.exists" unless="x86Dir.exists">
<echo>prefixing version code with 3 (for armeabi-v7a ABI).</echo>
<replaceregexp file="AndroidManifest.xml" match="android:versionCode.*([0-9]+).*"
replace='android:versionCode="3\1"'/>
</target>
<target name="-pre-build" depends="-pre-build-x86,-pre-build-arm" />
</project>
And put it next to the build.xml file, at the root of the Packaging project:
Once this is done, the version codes will be prefixed with a 5 for x86 APKs and a 3 for ARM APKs. This way the generated APKs can be uploaded straight to the Play Store, as described in the next section.
Publishing Multiple APKs to the Play Store
Go to the APK upload page and click “Switch to advanced mode” if you need to:
Then, upload your APKs with different ABI support and version codes. They should appear like on the APK management screen, with a summary of their differences and version codes:
If something isn’t right, you can use aapt from the Android build tools to check which versionCode andnative-code are supported by an APK:
>C:\Android\sdk\build-tools\23.0.0-preview\aapt.exe dump badging App1.apk
package: name='com.xhallade.test versionCode='81' versionName='1.0' platformBuildVersionName='5.1.1-1819727'
…
native-code: 'x86_64'
>
If you want to do the same directly from an Android device and check what .so files are getting installed at the same time, you can use Native Libs Monitor.
For more such Android resources and tools from Intel, please visit the Intel® Developer Zone
https://software.intel.com/en-us/articles/targeting-android-apps-on-x86-and-arm-based-devices-with-visual-studio-2015