在64位Android设备上从Google Play商店安装应用时，如果该应用支持，该应用是否以64位安装？

Question

The reason I ask is related to Google's recent communication https://developer.android.com/distribute/best-practices/develop/64-bit regarding apps needing to support 64-bit devices. I am pretty confident my app supports 64-bit devices based on the suggestions mentioned in the article. When I install it from Google Play, it works exactly as expected, however when I test the APK locally using the ADB command on 64-bit hardware (as Google suggested in this section 'Test your app on 64-bit hardware'), my app has UI issues. I'm not sure why it's behaving inconsistently.

Is it possible that somehow the 32-bit version is being installed when using Google Play and therefore works fine? I'm concerned my app may actually have problems when truly installed as 64-bit, so any clarification on the inconsistencies described above would be appreciated.

The device I'm testing with is a 'Moto X Pure Edition' running Android 7.0. It has a Snapdragon 808 CPU which uses ARM architecture. On the other hand, we don't see any '/lib' folder as the Google article suggests to check. Our app is hybrid, built with Ionic v3.

Answer 1

There is no such thing as "installing as 32 bit" or "installing as 64 bit". I'll try to explain. This gets a little complicated, and you don't provide many details about your app. There are a few possibilities for how you have chosen to build your app.

1. You have no native code in your app (no .so libraries). It was written entirely in Java or Kotlin, and none-of the third party libraries you use use native code either. In this case the lib/ subdirectory of your APK you'd expect to be empty.
2. You do have native code in your app, but you have .so files (libraries) for all ABIs . In this case in your APK you'd expect to see multiple subdirectories under lib/ in your APK, with names like x86 , armeabi-v7a , etc
3. You have native code in your app, but you are relying on ABI compatibility to work. That is your lib/ directory contains just armeabi-v7a as a subdirectory. x86, x86-64 and 64 bit ARM all emulate 32 bit ARM.
4. You have made more than one APK for each release of your app, one for each ABI. The is usually called multi-APK . So there is one for 64 bit ARM, one for 32 bit ARM, one for X86, one for X86 64 bit, etc.
5. You use the Android App Bundle , and let Google Play choose how to deliver your app.

By the way, I'd strongly recommend 5 as an option, it makes it much more likely the right thing will happen.

In the case of 1, 32 bit or 64bit doesn't matter. Any UI issues are caused by something else. Maybe the 64 bit phone allocates a bit more memory and your app doesn't perform well in low memory. Maybe the 64 bit phone is a bit faster and you've written your code with race conditions. Whatever it is, 64 vs 32 bit isn't the root cause.

In the case of 2, Google Play installs the same APK to every phone. But the device itself chooses which library (.so file) to load based on the processor. If one of your libraries was buggy on 64 bit that could be the issue.

In the case of 3, this is what Google's latest blog post is trying to stop. This won't be allowed to be published for new APKs. You need to properly support 64 bit devices by adding 64 bit native libraries. If this was the case, you could get bad UI performance by having the device emulate 32 bit arm on a 64 bit (possibly X86) device. You should switch to some other option, I'd recommend 5. This might not be you by the way, it might be some 3rd party library you depend on.

In the case of 4, Google Play does install different APKs to different devices based on processor type. Each different APK has a different version code. The device with a 64 bit processor will get the APK with the 64 bit libraries. If you are testing by putting the 32 bit version code on the 64 bit device using adb, you could indeed get bugs. However, if you were building and publishing different APKs for different APIs you would know it. Just install the right version code with adb .

In the case of 5, Google will install different APKs (in fact multiple different APK splits) to different devices. To test it, I'd recommend using a Google Play internal test track to verify to check exactly the right parts are installed which match Google Play.