An APK’s minimum Android requirement is the lowest platform API level it declares through minSdk. targetSdk describes a different compatibility contract; it is not simply the oldest Android version the app needs. Meeting the minimum requirement does not establish that every other device, package or current installation rule is satisfied.
Sources reviewed 20 October 2026. Documentation-based explanation; no APK was modified or installed for this guide.
Read the two version labels differently
Android’s uses-sdk reference explains that these values are API-level integers. They are not the app’s marketing version or a phone’s hardware model number. Android rejects an installation when the platform API level is below the package’s declared minimum.
| Label | What it describes | What it does not prove |
|---|---|---|
| minSdk / minSdkVersion | The lowest declared Android API level required. | Support for every processor, feature or device above that level. |
| targetSdk / targetSdkVersion | The platform level the app targets for behavior compatibility. | That this is the minimum version required to install. |
| App release number | The publisher’s version for that app release. | An Android API level or a compatibility guarantee. |
For example, a high target level does not automatically mean an app needs a phone running that same Android release. Google’s compatibility overview distinguishes the minimum install requirement from target-dependent behavior changes. Developers can also make some newer features conditional on the system version.
Check the exact release, not just the app name
- Find your installed Android version in the device’s system information. Manufacturer menu names vary.
- Open the publisher’s current release information or genuine store listing.
- Confirm the requirement for the actual release and variant being offered.
- Keep processor architecture, required device features and package completeness as separate checks.
- Record the exact installer message if installation is rejected.
Do not translate an Android marketing version into an API number by guessing or adding digits. Use the publisher’s explicit requirement or Android’s official version reference when an API-level comparison is necessary. Our APK version-selection guide covers the broader release and update decision.
Why a very old APK may fail on a newer phone
Newer Android does not mean that every historical APK is installable. Android can impose a separate minimum target-level rule. For a concrete documented example, the Android 15 behavior changes say apps targeting below API 24 cannot be newly installed. The same documentation says such apps already installed before upgrading to Android 15 remain installed.
This is different from an APK requiring a newer Android version than your phone has. One check concerns the app’s declared minimum; the other concerns an obsolete target on a particular operating-system release. The Android 15 example is not a universal cutoff asserted for every later Android release. Read the rule for your actual system.
If a warning names an old target or deprecated SDK, ask the publisher for a maintained compatible release. Do not remove a working installation before understanding the update and recovery path.
Does changing the manifest make the app compatible?
Editing a declared number does not add missing platform APIs, rebuild native libraries or validate the app’s behavior. A modified package is also a different artifact whose origin and signing need investigation. This guide provides no procedure for bypassing installation protections. Ask the developer about a supported release instead of treating a label edit as a tested fix.
Check the other compatibility dimensions
When the Android requirement appears satisfied, investigate the remaining evidence. The ARM64 versus ARM guide concerns system-supported native architectures. The package-format guide explains why a base APK alone may not represent the full delivery. A signing conflict can concern an update rather than Android version.
Those checks answer different questions. Do not assume that downloading the ARM64 variant fixes a minimum-Android rejection or that choosing an older app release solves a signing mismatch.
Should I download an old APK for an old phone?
Only consider a release after checking the publisher’s supported options, maintenance status and required service access. The fact that an older package installs would not establish current support, account compatibility or safe behavior. Keep any important app data and recovery options intact while deciding.
What should I send the publisher?
Provide the phone model, Android version, exact release/variant, source and complete installation message. Ask which supported build is intended for that device. This gives the publisher more useful evidence than “latest APK failed.” Use our installation diagnosis for other failure stages and the Android guide directory for related help.
App stopped working after an Android update: record the failure stage
Additional support documentation reviewed 21 October 2026.
An app that will not install, a Play listing that excludes your device and an installed app that crashes are different symptoms. The timing of a system update alone does not identify the cause. Keep the existing installation and needed local data while collecting evidence.
| Failure stage | Record before changing anything |
|---|---|
| Play listing says incompatible | Exact listing, selected device and compatibility message |
| APK installer rejects a package | Exact message, source, package variant and Android version |
| Installed app crashes or will not open | Installed app version, failing action and whether other apps work |
| App opens but account content fails | Account/service error and connectivity, without exposing credentials |
For a Pixel, Google’s installed-app troubleshooting starts with restarting and checking system/app updates, then app-specific troubleshooting. Its data-clearing and uninstall steps carry data-loss warnings. Use your manufacturer’s instructions for other phones and preserve needed local work before any reset.
Google’s compatibility guidance says app support can change over time and recommends the developer for app-specific questions. Compare the documented requirement for your actual release, not a generic “works on Android” promise. Send support the phone model, Android/build information, app version, source and exact error. Do not attach private account data or full personal logs to a public report.
Google Play says an app is unavailable: check more than Android version
An unavailable listing is not automatically a minimum-Android failure. Google’s missing-app guidance separates device compatibility, Play-country availability, parental restrictions and removal from the store. Follow the reason actually shown; do not change your country or family settings simply to test a download.
- Open the intended app’s Play listing and its About this app/game information.
- Inspect compatibility for the account-linked active device. Google says the list includes devices active within the last 30 days and shows compatibility and required OS.
- If a region or account restriction is named, use the relevant official guidance instead of assuming an APK variant fixes it.
- Ask the publisher about supported options for your exact device when compatibility is unclear.
Record the listing URL, device model, Android version and full message. A store availability decision, a package installer rejection and an installed app crash require different evidence. Sideloading a similarly named file does not establish support, authenticity or access to the service.
