Intel® Developer Zone offers tools and how-to information for cross-platform app development, platform and technology information, code samples, and peer expertise to help developers innovate and succeed. Join our communities for Android, Internet of Things, Intel® RealSense™ Technology, and Windows to download tools, access dev kits, share ideas with like-minded developers, and participate in hackathon’s, contests, roadshows, and local events.
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.
However, building for x86 or ARM generates an APK containing only x86 or ARM .so files. This is fine, but these APKs have the exact same versionCode, the one set in AndroidManifest.xml. That means they can’t both be uploaded to the Play Store for the same application.
You can fix this by making Visual Studio 2015 generate both ARM and x86 APKs with different version codes by adding a custom ant rule.
Create a file named "custom_rules.xml" with this content:
<project name="custom_rules">
<available file="libs/x86" property="x86Dir.exists"/>
<available file="libs/armeabi-v7a" property="armDir.exists"/>
<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 and native-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.
References
