Capture the exact failure
Record whether the message appears in Google Play, Android's installer or the app after launch. Include the device model, Android version, app package and version, installation source, and exact error text. Do not include account passwords or device identifiers unnecessarily.
| Where it fails | First checks |
|---|---|
| Play listing unavailable | Country, account, device catalog and target-API availability |
| Installer rejects package | SDK minimum, signatures, ABI, required splits and file integrity |
| App installs but crashes | Native libraries, runtime APIs and initialization |
An installer error such as INSTALL_FAILED_NO_MATCHING_ABIS points to a different investigation than an update signature mismatch.
Compare manifest and device requirements
Inspect minSdkVersion, required uses-feature declarations and native library directories. A camera permission can interact with feature filtering; declare optional hardware accurately when the application genuinely works without it.
For native code, compare the packaged ABIs with the device's supported architectures. A 64-bit processor does not guarantee the device supports every 32-bit runtime. Android's ABI documentation is a better reference than guessing from a marketing model name.
Check whether the package is complete
An app installed from a bundle may require a base APK plus configuration or feature splits. Copying only base.apk can produce an incomplete installation. Use a supported bundletool workflow with your own authorized artifact instead of combining files from unrelated versions.
APKLint's compatibility checker helps inspect declared requirements. It cannot override Play's country filters, sign an update with the original key, or make an incompatible native library execute.
Decide what to change
Developers should correct an accidental restriction only after testing the newly included devices. Users should obtain the app from its legitimate publisher and avoid disabling protections to force an unknown package through.
See module SDK settings and manifest declarations for the underlying controls. Preserve the original error in the support record so the eventual fix is tied to evidence.
Check whether an optional feature became a requirement
Imagine a notes app whose scanner uses the camera but whose manual-entry workflow works without one. If the manifest implies that camera hardware is required, a device without that feature can be filtered out even though the app's core workflow would function. Inspect the final uses-feature declarations and permission implications, then mark hardware optional only if the implementation genuinely handles its absence.
The Google Play filtering guide explains how declared and inferred requirements affect availability. Removing a filter expands the supported population and therefore needs runtime testing. It is not merely a store-listing change.
Use the failure stage to choose the next check
If Play says the app is unavailable, review the relevant device catalog and distribution restrictions through the app's authorized account. If Android rejects a local package, preserve the installer error and compare minimum API, ABI, signature and split completeness. If installation succeeds but launch crashes, collect the runtime stack and investigate the actual code or native library failure.
For a native application, compare the device-supported ABIs with packaged libraries rather than inferring support from the processor's marketing name. For an app generated from a bundle, obtain the correct device-targeted package set through a supported workflow. A copied base APK may be incomplete even when its manifest appears compatible.
After correcting an accidental restriction, test the formerly excluded device class with the feature unavailable. The notes app should offer manual entry and explain the scanner limitation without crashing. Also exercise the scanner on a supported camera device to ensure the change did not disable its normal path. Keep platform version, device characteristics, artifact identity and distribution channel with the result. Avoid promising that a compatibility checker can bypass account availability, manufacture a missing native ABI or repair an unrelated signing identity. Its package evidence narrows the investigation; the actual installation and feature tests establish whether the corrected release supports that device.
Sources and further reading
- Android Developers: Configure the app module
- Android NDK: Android ABIs
- Android Developers: App manifest overview
Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.
Android inspection tools and practical release guides. About APKLint · Report a correction
