Fix "App Not Installed" on Android: 8 Real Causes and How to Tell Them Apart

Android shows "App not installed" — or "App not installed as package appears to be invalid" — for a long list of unrelated failures. The real reason is written to logcat, which you cannot see without a development setup. So the practical approach is to identify the cause from the symptom.

Work through these in order. The first three account for the large majority of cases.

1. The file is an XAPK, not an APK

This is the single most common cause, and it is not really an error at all — it is a file-type mismatch.

An XAPK is an archive: a base APK plus split APKs for particular screen densities, languages or CPU architectures, and sometimes an OBB data file. Android's built-in package installer cannot open one. Tapping it in a file manager either does nothing or fails immediately.

How to tell: check the file extension. If it ends in .xapk, .apks or .apkm, this is your problem.

The fix: install the splits as a single session using a split-APK installer, or extract the base APK and install the splits alongside it. Installing only the base APK from inside the archive will often appear to work and then crash on launch, because the resources it expects are in the splits.

Several larger apps ship this way because of their size — KineMaster at 191.9 MB, VivaCut at 226.1 MB, and MX Player at 106.5 MB are all XAPK bundles rather than single APKs.

The full procedure — the three install routes, the free-space arithmetic, and the OBB problem on Android 11 and later — is in our guide to installing an XAPK.

> [!NOTE]

> The file type is listed on every download page here. Check it before you download, not after the install fails.

2. An existing copy is signed with a different key

Android refuses to replace an installed app with a build signed by a different certificate. This is a deliberate security boundary, not a bug — it is what stops an attacker from silently substituting a malicious build over a legitimate one.

How to tell: the app is already on the device, possibly from the Play Store or a different source, and the install fails instantly with no progress bar.

The fix: uninstall the existing copy completely, then install. Note that "completely" is doing real work in that sentence — see cause 3.

3. A leftover package registration under another profile

You uninstalled the old version and it still fails. This is the case that wastes the most time.

On a device with a work profile or multiple users, removing an app from one launcher can leave the package registered under another user. The old signature stays on record and continues to block the new build.

How to tell: you are certain you uninstalled it, and the failure is still immediate.

The fix: check every user profile and work profile on the device. If you have ADB available, adb shell pm list packages -u shows packages still registered including uninstalled-but-retained ones.

4. Your Android version is below the app's minimum

Each package declares a minSdkVersion. Below it, the installer refuses.

How to tell: compare your Android version against the app's stated minimum. The catalogue here spans Android 4.0+ through Android 10.0+, with the bulk of apps at 5.0+, 6.0+ or 8.0+ — so a device on Android 7 will hit this regularly.

The fix: find an older release of the app that supports your API level. There is no way around a minSdkVersion check on an unmodified device.

5. Wrong CPU architecture

Most current devices are arm64-v8a. Older and budget devices are armeabi-v7a. A few emulators and Chromebooks are x86 or x86_64. An APK built only for one will not install on another.

How to tell: you are on an older or low-cost device, and the app is one that ships architecture-specific builds.

The fix: download the build matching your device's ABI, or a universal APK that contains all of them. A file manager such as Solid Explorer will show you what is inside the package.

6. Insufficient storage

Installation needs meaningfully more free space than the file size — Android has to unpack the package, generate optimised code, and keep the original until it finishes.

How to tell: the failure happens partway through rather than instantly.

The fix: free up roughly three times the APK size. A 226 MB XAPK wants something in the region of 700 MB of headroom.

7. "Install unknown apps" is not granted

Modern Android grants sideloading permission per source app, not globally. The file manager or browser you are installing from needs the permission.

How to tell: you get a settings prompt, or nothing happens when you tap the file.

The fix: grant "Install unknown apps" to the specific app you are installing from. Granting it to your browser does not cover your file manager.

8. The download is incomplete or corrupt

A truncated download produces an invalid package. This is common on unstable connections and with mirrors that cut off large transfers.

How to tell: "package appears to be invalid" specifically, and often a file size that does not match what the download page states.

The fix: compare the SHA-256 hash of your file against the value published on its download page. If it does not match, delete it and download again — and treat a repeated mismatch from the same source as a reason to stop using that source.

Quick diagnosis

If none of these apply and you have ADB access, adb install -r yourfile.apk prints the actual failure code — INSTALL_FAILED_UPDATE_INCOMPATIBLE, INSTALL_FAILED_NO_MATCHING_ABIS, INSTALL_FAILED_INSUFFICIENT_STORAGE and so on. That turns the guessing above into a direct answer.

Every app named here resolves to a page in the FileCobra catalogue — the build fails if one does not. Versions, package sizes and system requirements are read from that catalogue rather than written by hand. Where our ingestion worker has fetched a release itself, it records a SHA-256 of the exact file we serve and publishes it on the app’s page. We do not run an antivirus lab: where a VirusTotal report exists we link it, and where none exists we say so rather than imply one.