Which Android APK fits my phone?
Choose arm64-v8a or armeabi-v7a using the app architectures your running Android system supports. A 64-bit processor alone is not enough.
Choose a publisher APK whose native architecture appears in your running Android system’s supported ABI list. arm64-v8a is 64-bit Arm; armeabi-v7a is 32-bit Arm. A 64-bit processor does not prove that the installed Android system supports 64-bit apps.
Published 2026-10-19 · Last updated 2026-10-19
Start with the publisher’s Android download
If the publisher links to Google Play, use that listing first: the store selects the package for the device. If the publisher offers separate APK files, check the running system’s supported app architectures before choosing one. Use the publisher’s own website or a repository it links to.
CPU capability, Android version and app ABI are separate checks. A device may have a 64-bit Arm processor while its installed Android system advertises only 32-bit app support. A newer device may support only 64-bit apps. Neither the model’s marketing name nor the number in “Android 16” establishes the app ABI list.
Read the APK architecture label
| APK label | Native code | Choose it when |
|---|---|---|
arm64-v8a | 64-bit Arm | The system lists arm64-v8a. |
armeabi-v7a | 32-bit Arm | The system lists armeabi-v7a. |
x86 / x86_64 | 32-bit / 64-bit x86 | The matching ABI is listed, for example by a suitable Android emulator or device. |
| Universal APK | May bundle multiple ABIs | The publisher says it includes your ABI and supports your Android version. “Universal” does not mean every device. |
Check the ABI list on the running device
If you already use a device-information app from a trusted source, look for its supported Android app ABI list, rather than just the processor’s instruction set or kernel architecture. The Android API name is Build.SUPPORTED_ABIS. The separate 32-bit and 64-bit ABI lists can help resolve ambiguous labels.
For a direct check from your computer, use Google’s SDK Platform Tools and its adb command:
- Follow Google’s USB debugging setup on your own device. Connect it by USB and accept the debugging authorization for your trusted computer.
- Run
adb devices. Continue when the intended device is listed asdevice. If multiple devices are connected, useadb -s SERIALin place ofadbin the commands below, using the serial shown for that device. - Read the advertised ABI properties:
adb shell getprop ro.product.cpu.abilist
adb shell getprop ro.product.cpu.abilist32
adb shell getprop ro.product.cpu.abilist64These commands read properties; they do not change firmware or install an APK. Turn off USB debugging when you finish if you do not normally use it.
Use the result to choose a package
Example: arm64-v8a,armeabi-v7a lists both app ABIs. Prefer the publisher’s arm64-v8a build when available. If the list contains only armeabi-v7a, choose that build; an Arm64-only native APK does not match the advertised system ABI.
If the list contains only arm64-v8a, do not assume a 32-bit-only APK will run. An empty result is not evidence of either architecture. Check the connection, the device’s documentation or the publisher’s support information before choosing. uname -m describes the kernel architecture and is not a substitute for the supported app ABI list.
When the ABI matches but installation still fails
- Minimum Android version: the app can require a newer Android release independently of its ABI.
- Package format: a split APK set is not necessarily a standalone APK. Follow the publisher’s installation instructions for the format it provides.
- App requirements: graphics features, device support, signatures or an existing installation can still affect compatibility.
Changing the APK filename or selecting a different download mirror cannot add a missing native ABI. This guide does not recommend replacing the operating system to force an unsupported app. For conflicting version numbers or download sources, use the official-source verification guide.