You are staring at two MicroG files with almost identical names, and the only difference is a string of letters at the end: one says arm64-v8a, the other says armeabi-v7a. Pick the wrong one and the install either refuses outright or you end up running a slower build for no reason. Pick the right one and the whole thing is a two-minute job. The confusing part is that the choice has almost nothing to do with your phone’s brand, its Android version, or how much RAM it has — it depends on one specific thing called the ABI, and most phones never show it to you in Settings.
There is one shortcut worth knowing before you read any further. If you download MicroG from our MicroG download page, you do not need to make this choice at all: the file there is a universal build that runs on ARM64, older 32-bit ARM, and x86 phones alike. This guide is for the moment you meet split files somewhere else — on the upstream project’s pages, in an APK archive, or in a guide that links separate builds — and need to know which one is yours.
The short answer: Check your phone’s ABI first, then match it exactly. If the list includes arm64-v8a, download the arm64-v8a file. If it only lists armeabi-v7a, download the armeabi-v7a file — a 64-bit file will not install on that phone. If you cannot check, or you only see one file, use a universal build (the one on our download page) rather than guessing. A 32-bit file will run on a 64-bit phone, but a 64-bit file will never run on a 32-bit phone or 32-bit ROM.
What arm64-v8a and armeabi-v7a actually mean
ABI stands for Application Binary Interface. In plain language, it is the instruction set your phone’s processor speaks, plus the rules an app must follow to talk to it. An APK built for one ABI contains native code compiled for that instruction set. Android will only install a build whose ABI matches what the phone (and its ROM) can run.
Think of it like a plug and a socket. A 64-bit phone can usually accept a 32-bit plug as well, because it still understands the older instructions. A 32-bit phone cannot accept a 64-bit plug at all — the instructions are simply not in its vocabulary. That one-way compatibility is the whole story of this guide, and it explains why the wrong choice fails in one direction but merely works less efficiently in the other.
| ABI | What it is | Typical phones |
|---|---|---|
arm64-v8a |
64-bit ARM — the current standard | Almost every Android phone sold in India in recent years, including budget models |
armeabi-v7a |
32-bit ARM — the older standard | Older phones, some very cheap devices, and phones running a 32-bit ROM on 64-bit hardware |
x86 / x86_64 |
Intel-style processors, not ARM | Rare on phones; mostly emulators on a PC and a few tablets |
A common trap follows from that table. “My phone has a 64-bit processor” is not the same as “my phone runs a 64-bit ROM.” Some manufacturers ship 64-bit-capable hardware with a 32-bit version of Android, usually to save memory on low-RAM models. On such a phone, the processor could run arm64 code, but Android will not let it — the phone reports only armeabi-v7a, and only the 32-bit file will install. That is why you check the ABI Android reports, not the processor name on a spec sheet.
MicroG itself makes the stakes lower than they look. It is not a heavy game or a video editor where native code decides frame rates. The practical difference between the arm64 and armeabi builds of MicroG is compatibility and, at most, small efficiency differences in its native components — not whether your patched apps sign in, which is decided by MicroG’s settings, Self-Check, and your account setup. So the goal here is simply: get a build that installs cleanly and matches your phone. Chasing a “faster” ABI you cannot run gains nothing.
How to check your phone’s ABI in two minutes
Android does not put the ABI on the About Phone screen, so use one of these three methods. They are listed from most reliable to quickest, and all three are free.
Method 1: ADB (most reliable, needs a computer)
If you already use ADB — for example, following our guide to blocked installs on Android 14, 15 and 16 — this is one command. With USB debugging on and the phone connected, run:
adb shell getprop ro.product.cpu.abi
The phone answers with a single value, such as arm64-v8a or armeabi-v7a. That is the primary ABI: download the file that matches it. For the full list of ABIs the phone supports, run adb shell getprop ro.product.cpu.abilist instead — a phone that answers arm64-v8a,armeabi-v7a,armeabi can run both 64-bit and 32-bit builds, while one that answers only armeabi-v7a,armeabi is 32-bit only, whatever its processor.
Method 2: A device-info app (easiest, no computer)
Install a hardware-info app from the Play Store or F-Droid — Droid Hardware Info, DevCheck, and AIDA64 all show the ABI — then look for a field labelled CPU ABI, Instruction Sets, or Supported ABIs. The value you want is exactly the same string ADB gives: arm64-v8a or armeabi-v7a. Two warnings here. First, download the info app itself from a store you trust, not from a random APK mirror, for the same reason you should get MicroG from a trusted source. Second, ignore the app’s marketing fields about “64-bit CPU” and read the ABI field specifically — as explained above, a 64-bit CPU with a 32-bit ROM still reports armeabi-v7a, and that reported value is what decides your download.
Method 3: The rule of thumb (only if you cannot check)
If you genuinely cannot run either method, the odds favour arm64: most phones bought new in India in the last several years are 64-bit. But “most” is not a check, and this is exactly the situation where you should not guess. Use the universal build from our download page instead of betting on arm64. A universal (sometimes called “fat” or multi-ABI) APK contains the native code for several ABIs in one file, so Android picks the right one at install time. The file is larger, but you download it once, and the guesswork disappears.
The decision table: which file to download
| What your phone reports | Download this | Why |
|---|---|---|
arm64-v8a (alone or first in the list) |
arm64-v8a build | Native match; the build Android will prefer |
Only armeabi-v7a |
armeabi-v7a build | The only split build that will install on this phone |
x86 or x86_64 |
x86 / x86_64 build, or a universal build | ARM builds will not install on an x86 device |
| You cannot check, or you see several files and are unsure | Universal build | Android picks the right native code itself |
Two filename habits will help you read download pages. First, the ABI is usually at the end of the filename, just before .apk — for example microg-…-arm64-v8a.apk versus microg-…-armeabi-v7a.apk. A file with no ABI in its name is usually either universal or a build whose page should say so; if the page says neither, treat it as unverified and prefer a source that states the ABI plainly. Second, do not confuse the ABI with the version number or with other suffixes a build may carry (such as an icon variant). The ABI decides compatibility; the rest is packaging.
What happens if you pick the wrong file
The failure modes are different in each direction, and recognising them saves you from chasing the wrong fix:
- 64-bit file on a 32-bit phone or ROM: Android refuses the install. You may see “App not installed”, “This app isn’t compatible with your phone”, or a parse-style error, depending on the installer. This is not a corrupt download and it is not a signature problem — it is the ABI mismatch itself. The fix is the armeabi-v7a file (or a universal build), not re-downloading the same file. If you have already ruled out an ABI mismatch and still get “App not installed”, the cause is usually an old MicroG build with the same package name still on the phone — see our package-conflict fix.
- 32-bit file on a 64-bit phone: It installs and runs. Android runs 32-bit native code on 64-bit devices for compatibility. You lose nothing important for MicroG, and there is no need to reinstall just because you later learn the phone is 64-bit — though if you are setting up a phone from scratch, the arm64 build is the tidier choice. Do not let anyone tell you a working 32-bit install is “broken” for this reason alone.
- ARM file on an x86 device (or the reverse): Same refusal as the first case. Emulator users hit this most: an Android emulator on a PC often reports x86_64, and an ARM MicroG build will not install on it. Use the x86_64 build or a universal build for the emulator.
One more confusion to clear up: Android version and ABI are independent. A phone on Android 14 can be 32-bit, and a phone on Android 10 can be 64-bit. Upgrading Android does not change the ABI, and a newer Android version is never a reason to switch from armeabi-v7a to arm64-v8a. Only the reported ABI decides.
After you install: verify, don’t assume
Whichever build you installed, finish the same way. Open MicroG Settings → Self-Check and confirm the core items are ticked. Then add your Google account under MicroG → Accounts only after Self-Check looks right, and only then install the patched apps that depend on MicroG. If Self-Check shows missing permissions, grant them from MicroG’s app-info page (on Android 13 and later, use the “Allow restricted settings” option first if a toggle is greyed out). If the install itself failed, work through the failure above before touching permissions — a permission cannot fix a file that never installed.
For the official project background behind all of this — what MicroG is, which builds the project publishes, and how it replaces Google Play Services — the reference point is microg.org. Our own download page stays the simplest route for most readers precisely because it removes this decision: one universal file, verified against the project’s releases, with the install steps beside it.
Our verdict
For most readers in India, the honest summary is short. If your download page offers a universal build, take it and skip this entire question — that is why our download page offers one. If you are faced with split files, spend the two minutes checking your ABI (ADB or a device-info app) and match it exactly: arm64-v8a for a 64-bit phone, armeabi-v7a for a 32-bit phone or 32-bit ROM, x86 only for emulators and the rare x86 device. Never guess arm64 on an unchecked phone, never reinstall a working 32-bit build out of embarrassment, and never mistake a 64-bit processor name for a 64-bit ROM. The ABI is a fact about your phone, not a preference — check it once, and the file choice makes itself.
Frequently asked questions
How do I know if my phone is arm64 or armeabi?
Check the ABI Android reports, not the processor name. Run adb shell getprop ro.product.cpu.abi from a computer, or open a device-info app (such as Droid Hardware Info or DevCheck) and read its CPU ABI field. arm64-v8a means 64-bit; armeabi-v7a only means 32-bit, even if the processor itself is 64-bit capable.
Can I install the arm64-v8a MicroG file on a 32-bit phone?
No. Android will refuse the install because the phone cannot run 64-bit native code. Download the armeabi-v7a build or a universal build instead. Re-downloading the same arm64 file will fail the same way every time.
Will the armeabi-v7a file work on my 64-bit phone?
Yes. Android runs 32-bit apps on 64-bit phones for compatibility, so the install succeeds and MicroG works. The arm64 build is the neater match if you are starting fresh, but a working 32-bit install does not need replacing.
Do I need to choose at all if I download from csvtoexcel.site?
No. The file on our download page is a universal build that covers ARM64, older 32-bit ARM, and x86, so Android picks the right code for your phone. You only need this guide when a source offers separate arm64 and armeabi files.
Does the ABI affect MicroG’s features or sign-in?
No, not in any way that matters to daily use. Sign-in, Self-Check results, and patched-app compatibility are decided by MicroG’s version, its settings and permissions, and whether your ROM supports signature spoofing — not by whether the native code is 64-bit or 32-bit. Pick the build that installs; do not chase an ABI for extra features.
My phone is a budget model with 2 GB of RAM. Does that make it 32-bit?
Not necessarily. RAM size and ABI are unrelated: there are 64-bit phones with 2 GB of RAM and 32-bit phones with more. Low RAM is a common reason manufacturers ship a 32-bit ROM on 64-bit hardware, which is why the reported ABI — not the RAM figure — is the thing to check.
Not sure which build your phone needs? Our MicroG homepage points you to the right download and the complete setup guide.