Android is still 54% 32-bit. That changes how you ship apps.

The standard advice for Android app developers in 2025-2026 is "you can drop 32-bit support." Google requires 64-bit native code for new apps in Play Store since 2019. Most active devices, the conventional wisdom says, are 64-bit. Strip your armeabi-v7a build, ship arm64-v8a only, your APK is 30-40% smaller.

The conventional wisdom isn't wrong about the high-volume devices. It's wrong about the catalog as a whole.

The actual numbers

We pulled the primary ABI distribution from the Google Play device catalog. 28,077 devices total:

| Primary ABI | Devices | Share | |---|---:|---:| | armeabi-v7a (32-bit ARM) | 15,247 | 54.3% | | arm64-v8a (64-bit ARM) | 12,515 | 44.6% | | x86 (32-bit Intel/AMD) | 254 | 0.9% | | x86_64 (64-bit Intel/AMD) | 61 | 0.2% |

A majority of catalogged Android devices are still 32-bit by primary ABI.

"Devices in the catalog" is not the same as "devices being used"

Let's be honest about what this number means. The Google Play catalog includes every device that has ever passed Play Compatibility certification and continues to be eligible to install apps. That's not the same as monthly active devices. A 2014 Galaxy J1 still in the catalog isn't necessarily still in active use.

But "in the catalog" is the same as "your app might be installed on it tomorrow." Which is the question that matters if you're a developer.

The 15,247 32-bit-primary devices include:

• Almost the entire pre-2017 Android catalog. The first widely-shipped 64-bit Android chipset (Snapdragon 410, in budget phones) appeared in 2014, but didn't dominate until 2017.
• A long tail of post-2017 budget devices that shipped with 32-bit chipsets to hit price points (especially African and Indian-market phones using older MediaTek MT6739/MT6761).
• A surprising number of recent industrial / rugged / point-of-sale Android devices that intentionally use older 32-bit SoCs because the embedded software stack was certified against them and recertification is expensive.
• Set-top-box and TV-stick Android devices.

What this means in practice

If you ship an app only as arm64-v8a, you ship to 44.6% of the catalog. Your install funnel just lost more than half its potential install base.

In practice, the lost devices are mostly low-revenue users (older / cheaper / rural / industrial), and dropping them might be a deliberate choice. Google's own analytics dashboard shows higher 64-bit share among active install bases — closer to 80% in the developed-market app categories. But there's a gap between "your app's existing analytics" and "your app's potential reach in the global Android market."

If you're an app that's:

• Targeting emerging markets (Africa, Latin America, Southeast Asia), the 32-bit share of your install base will be much higher than 20%. Closer to 50-60% in some markets.
• A utility/system app that gets adopted on older devices, ditto.
• A messaging or social app trying to maximize global reach, you cannot drop 32-bit without a quantifiable user-cost analysis first.

If you're an app that's:

• A modern game with high system requirements anyway, drop 32-bit. Your customers don't have those phones.
• A productivity tool for English-speaking knowledge workers, drop 32-bit. Same reason.
• A bank or fintech app in the US/EU, drop 32-bit. Your KYC requirements probably exclude the device profile that's still 32-bit.

The advice "drop 32-bit" is correct for some apps and wrong for others. The catalog distribution gives you the worst-case bound: the 54% of the catalog that's 32-bit. Your actual user distribution is somewhere between that and Google's published global active-device numbers.

The architectural transition is happening, slowly

Looking at the data over time (using the API levels each device declares as a proxy for release cohort), the 32-bit / 64-bit crossover has been gradual:

• Pre-2015: virtually all 32-bit
• 2015-2017: mixed, leading edge of 64-bit
• 2018-2019: most flagships and mid-range 64-bit, budgets still 32-bit
• 2020-2022: 64-bit standard except in sub-$100 devices
• 2023+: practically every new flagship/mid-range is 64-bit, but the budget tail of 2024-2025 phones still includes 32-bit-only chipsets in some emerging markets

This means the 54% number isn't going away by 2027. Manufacturers are still actively shipping new 32-bit-primary devices to keep budget price points achievable. Helio A22 (2018), Helio A20 (2020), and various unbranded 4-core Cortex-A53 chipsets used in <$100 emerging-market phones in 2025 are still 32-bit-only.

What we'd advise

Three things if you're an app developer reading this:

1. Run the actual numbers on your install base. Google Play Console gives you ABI distribution per app. Don't trust general industry stats — your users are a slice, not the median.

2. If you must ship one ABI for size reasons, ship arm64-v8a and accept the install-base cost. Most app categories where size matters are also categories where the lost users are low-LTV.

3. If you're shipping a new app targeting the developing-world market, ship a fat APK with both ABIs (or split APKs and let Play Store route correctly). The bandwidth cost is yours; the user-lock-out cost is theirs.

Why this isn't widely discussed

The "drop 32-bit" advice circulates because it's correct for the developers writing about it — Western, mid-revenue app teams whose users skew toward newer hardware. They publish blog posts, those posts get linked, the advice cascades. The advice is not correct for anyone shipping to a global Android user base, but those teams don't write about it.

The catalog data shows the actual landscape. It's worth checking before you delete the armeabi-v7a directory from your build.

— Marcus