Android hardware is always changing. Sometimes, the hardware change is highly visible, like from a regular screen to a wide screen or to an ultra-wide screen. And sometimes, it is not. If you are building apps for Android, I think you must be familiar with the device available in the market. Generally, there are two types. Some Android devices are 32-bit only. They are usually mobile devices for the low-end market or TV-devices. And the majority of mobile devices are 32/64-bit mixed mobile devices. Now, this is a bit different after the Pixel 7 is launched.
The first Android phone to be solely configured as 64-bit is the Pixel 7. And as forthcoming high-end SOC cannot run 32-bit code, this will be a big thing this year. Every developer should get ready for this. It is anticipated that 64-bit only will become the default option in the future, due to several advantages.
First, it is faster. 64-bit applications run faster because they have access to extra registers and adjustments that are not available to 32-bit apps. Secondly, it is safer. The bigger address space makes defense like ASLR more effective and the spare bits can be used to protect control full integrity. And the new hardware instructions get added to 64-bit but not 32-bit instruction sets. Thirdly, it improves system health. Removing support for 32-bit code, saves up to 150 megabytes of RAM, which has been used by the OS even when it is not running 32-bit apps. And finally, starting in 2023, high-end SOCs will no longer be able to run 32-bit code.
I think you also remember that from August 1, 2019, apps published on Google Play are required to support 64-bit architecture. So that doesn’t mean that you do not have to do anything and your app will be wandering without issue on these 64-bit only devices. Maybe have you ever tested your app on a 64-bit only environment? No, right. Because 64-bit only devices were not in the market before.
The Application Binary Interface (ABI) for each combination of CPU and instruction sets varies because different Android devices employ varying CPUs which support different instruction sets. How do I know if the device is a 64-bit only device or not? You may check the value of build supported ABIs. It will help you to see supported ABIs of the device and support 32-bit ABI will be an empty list on 64-bit only devices.
Okay, my phone is not a 64-bit-only device. What should I do? You can use the emulator. Starting from Android 12, the emulator is 64-bit only. Of course, we know that. Sometimes it’s just too difficult to test your app on an emulator. So very soon, you’ll be able to download a 64-bit only image for some older Pixel devices. Flashing it will make your Pixel a 64-bit only device, so you could do the testing. If you install your app with ADB, you could supply “–abi” as a parameter to indicate which libraries to install to the device. This also makes sure you are installing the 64-bit part of your app to the device, not the 32-bit one. By specifying the ABI to install, you will be able to install only the 64-bit part of your app to the device. If your APK doesn’t support 64-bit ABI, an error message will be shown. So what should you do after the install? Of course, testing.
Testing is so important and some SDKs or libraries may have wrong assumptions and may cause crashes in runtime. For example, the SDK may be still looking for the path /lib, not /lib64. The path /lib still exists in a 32/64-bit device, but it may or may not exist in the 64-bit only devices. So your app may work on most devices, but fail on some 64-bit only devices. Another example is about the new instruction set in the new architecture. These instructions such as PAC and BTI in ARMv9 may have compatibility issues. But some SDKs crash because of this. We will go through some specific examples next.
We have identified a few SDKs that are not compatible with 64-bit only devices. Most of these SDKs have released a new version, which fixed the problem. If you are using any of these SDKs, update it to the latest version. If you find an SDK having issues with 64-bit only devices, report to Android. Some old versions of SoLoader have a bug in identifying the library path when running in a 64-bit only environment. This also affects SDKs using SoLoader, such as React Native, Facebook Yoga, and Fresco. The recent release of SoLoader also fixed some other compatibility issues. So if you are using SoLoader, make sure you are using the latest version.
Similarly, some old versions of OpenSSL (prior to 1.1.1i) have a bug in a hand-written assembler that causes PAC failure. Again, check which version you are using and make sure you are using the new version with the fix. If your app is using some app shielding solutions, please make sure the solutions are working when PAC and BTI are enabled. Contact your vendor if you see an issue.
If you have published your app on Play, here is some good news for you. Google Play can tell you it’s your app affected by all versions of some popular library, such as SoLoader. And make sure you have Google Redfin 64-bit only in the Pre-launch report. Why? Because the Pre-launch report now supports testing with a 64-bit only hardware, which means you could identify many 64-bit related issues from the Pre-launch report. You could see the errors if your submitted package is having issues. Please make sure you visit Google Play Console so you don’t miss the message.
Thank you and enjoy.
Tags: 64-bit, android, apps, architecture, development
