Using CPU ABI to filter multiple APKs for an App in Google Play

[Lance_A_Intel]

Hello,

I have found documentation on the Android Developer site that states that the CPU ABI of a device can be used to filter the APK selected for a single application with multiple APKs to install from the Google Play store.

I was wondering what happens when there is a secondary ABI property on the device as is found on many Intel Android devices as follows:

[ro.product.cpu.abi2]: [armeabi-v7a]

[ro.product.cpu.abi]: [x86]

My situation is that an ISV has an application that has always been available on ARM, but has recently added a compatible application for IA. Instead of building a single APK (fat binary) they have developed two APKs being distributed under one name in Google Play using multiple APK support. I want to ensure that the IA version of their application is always installed on IA devices instead of the ARM version.

I could not find any documentation on this situation.

If there are APKs for both primary and secondary ABIs available for an application that is distributed with multiple APK support, will the APK for the primary ABI always be selected for installation?

[Xavier_H_Intel · Accepted solution]

Hi,

no, the APK for the primary ABI will not be automatically selected.

The store only checks the compatibility of the APKs that are available (without prioritizing any criteria) and returns the APK with the higher android:versionCode set.

So If your ISV set a higher versionCode number to the x86 APK, it will always be distributed to x86 devices.

To ensure the x86 versionCode is always the higher one, your ISV can use a convention such as this one: https://software.intel.com/en-us/android/articles/google-play-supports-cpu-architecture-filtering-for-multiple-apk 

[Lance_A_Intel]

Fantastic, thanks Xavier!

The info on the version code is just what I need.

[Cuong_P_]

Xavier H. (Intel) wrote:

Hi,

no, the APK for the primary ABI will not be automatically selected.

The store only checks the compatibility of the APKs that are available (without prioritizing any criteria) and returns the APK with the higher android:versionCode set.

So If your ISV set a higher versionCode number to the x86 APK, it will always be distributed to x86 devices.

To ensure the x86 versionCode is always the higher one, your ISV can use a convention such as this one: https://software.intel.com/en-us/android/articles/google-play-supports-c... 

Hello Xavier,

Is there any methods to find abi of a phone using code instead of  getprop ro.product.cpu.abi  . I need to find the exact abi of a phone so that i can copy the appropriate .so library to system/lib folder.