How to Convert Android Apps From 32‑Bit to 64‑Bit

Google has made it clear that 32‑bit apps will soon disappear from the Play Store, and developers who haven’t yet migrated are feeling the pressure. The good news? Moving a project from 32‑bit to 64‑bit isn’t a full rewrite—just a series of careful adjustments. Below you’ll find a step‑by‑step guide that walks through the most common hurdles and shows how to keep your codebase healthy during the transition.

Why the Switch Matters

Modern devices run on 64‑bit processors, which can handle larger registers and address more memory. When an app sticks to a 32‑bit binary, it not only risks being filtered out of the store, it also loses out on performance boosts that native 64‑bit libraries provide. In short, a 64‑bit build = better speed, smoother graphics, and future‑proof compatibility.

Preparing Your Project

Before you open Android Studio, take a quick inventory. Knowing what you have makes the migration smoother.

• Native libraries – Any .so files compiled for armeabi‑v7a or x86 will need 64‑bit equivalents (arm64‑v8a, x86_64).
• Third‑party SDKs – Check the vendor’s documentation; many have already shipped 64‑bit AARs.
• Build scripts – Gradle files often lock ABI filters; you’ll have to relax those constraints.

Updating the Build Configuration

Open build.gradle (module level) and adjust the ndk block. If you previously had something like:

ndk {
abiFilters "armeabi-v7a", "x86"
}

Replace it with a broader list, or simply omit the filter to let Gradle package every available ABI:

ndk {
abiFilters "armeabi-v7a", "arm64-v8a", "x86", "x86_64"
}

Remember to bump the minSdkVersion only if your code truly requires a newer API; most apps can stay on the same level.

Recompiling Native Code

If you maintain C/C++ sources, the NDK will handle the heavy lifting. Here’s a quick checklist:

• Install the latest NDK via Android Studio’s SDK Manager.
• In Application.mk, set APP_ABI := arm64-v8a x86_64 alongside any 32‑bit ABIs you still support.
• Run ./gradlew assembleRelease and verify that both libyourlib.so variants appear in the apk under lib/arm64-v8a and lib/x86_64.

If you rely on external native libraries, ask the provider for 64‑bit builds. Most major SDKs (Firebase, Facebook, etc.) already publish them.

Handling Java/Kotlin Code

Pure Java or Kotlin doesn’t need recompilation for 64‑bit, but a few pitfalls can appear:

• Integer overflow – 64‑bit CPUs use the same 32‑bit int type, yet some native‑interop code assumes a pointer fits into an int. Replace such casts with long where appropriate.
• Third‑party libraries – If a library bundles a native component, the 64‑bit version must be present; otherwise you’ll see UnsatisfiedLinkError at runtime.
• ProGuard/R8 rules – Verify that keep rules still reference the correct package names; missing rules can cause classes to be stripped only in the 64‑bit build.

Testing on Real Devices

Emulators are convenient, but they sometimes mask subtle bugs. Deploy the APK to at least one physical device that runs a 64‑bit CPU (most phones from 2017 onward qualify). Watch out for:

• Crashes on startup – often a sign of missing native binaries.
• Memory‑related warnings – 64‑bit apps can use more RAM; monitor adb logcat for OutOfMemoryError spikes.
• Performance regressions – run a quick frame‑rate check on graphics‑heavy screens to ensure the new binaries actually improve rendering.

Common Gotchas and Quick Fixes

Duplicate Class Errors

When both 32‑bit and 64‑bit AARs contain the same Java class, Gradle may complain. The fix is usually to exclude the 32‑bit variant from the implementation line:

implementation ('com.example:library:1.2.3') {
exclude group: 'com.example', module: 'library-32'
}

Signing Issues

After the ABI change, the APK size often grows. Some older signing configs hit a size limit. Switching to the newer v2 signature scheme resolves most problems.

Google Play Console Warnings

If you upload a 64‑bit APK without a matching 32‑bit version, the console will flag “Missing 32‑bit version for devices that require it.” Decide whether you want a universal APK (both ABIs) or separate splits. Using bundle format usually lets Google handle the split automatically.

Final Checklist Before Release

• ✅ All native libraries compiled for arm64‑v8a and x86_64.
• ✅ No UnsatisfiedLinkError on a real 64‑bit device.
• ✅ ProGuard/R8 kept necessary classes.
• ✅ APK size within acceptable limits; signing uses v2 or later.
• ✅ Play Console reports “64‑bit required” satisfied.

Once those boxes are ticked, you can generate a release bundle and push it to the store with confidence. The migration might feel like a chore, but the performance gains and compliance with Google’s policies make it worthwhile. Happy coding!