Establish the package scope
Start with the exact APK or split set under review:
apkanalyzer files list app.apk
Look for entries such as lib/arm64-v8a/libexample.so, lib/armeabi-v7a/ or lib/x86_64/. An ABI describes the native binary interface; it is not the Android API level. Android ABI reference.
If the APK is a base split, native libraries may be in a companion configuration APK. Absence from the base alone is not evidence that the complete installation contains no native code.
Interpret common layouts
| Observation | Possible meaning |
|---|---|
| Several ABI directories | A universal or multi-architecture package |
| Only one ABI directory | A targeted package or deliberately limited support |
| No native libraries in a standalone APK | The package may be managed-code-only |
| One SDK missing from an ABI | That device path may fail at library loading |
Check every required native dependency for each supported architecture. Including an arm64 version of your own library does not help if a critical vendor library is available only for another ABI.
Diagnose installation and runtime separately
An installation error about incompatible native code concerns package compatibility. A later UnsatisfiedLinkError may involve a missing library, a missing symbol, load order or an incompatible dependency—not merely the top-level directory name.
Record the exact library and exception. Compare the package inventory with the build's ABI filters and the vendor's supported artifacts. Do not fix a missing dependency by copying an unrelated .so into the APK after signing.
Verify with a representative device matrix
Test the architectures your distribution promises. Emulation is useful, but a successful x86_64 emulator run does not establish arm64 native behavior. If Play generates architecture-specific packages, inspect those outputs rather than only a universal debug APK.
APKLint's analyzer can surface native ABI names and structural information. For complete native compatibility, use the original build, Android's analysis commands and real installation/runtime tests. An ABI match is necessary for relevant native code but not sufficient for full device compatibility.
Build a library-by-architecture matrix
For an app with two native libraries, create rows for each library and columns for each ABI the product intends to support. Mark a cell only when the relevant artifact actually contains that binary. If your own library exists for arm64 and x86_64 but a required vendor library exists only for arm64, an x86_64 build does not become complete merely because the top-level directory is present.
Trace a missing cell to the dependency's published artifacts or your native build configuration. Check the selected version and packaging exclusions before changing ABI filters. Removing an architecture from the product may be a valid deliberate choice, but describe the resulting support change. Copying a binary from another architecture into the missing directory cannot make its machine code compatible.
Read a native loading failure precisely
Imagine installation succeeds but opening the camera feature produces an UnsatisfiedLinkError. Record the library and error details, then check whether the file is absent, an expected symbol is missing or a dependent library cannot be loaded. The Android ABI guide defines the architecture contract, while the actual error tells you which part of loading failed.
Use the same release artifact that failed, including the relevant ABI split. A universal debug APK can contain binaries that are missing from the delivered release set. Keep the inventory from both only if the comparison is explicitly labelled; otherwise the extra debug library can hide the distribution defect you are investigating.
Test the native feature on representative supported architectures and record the operation, not merely app launch. A library may be loaded lazily when a document, image or media operation begins. Also preserve symbols appropriate to the exact native build for later crash diagnosis. Matching the ABI directory is one prerequisite for execution; it does not establish page-size support, minimum-platform compatibility or correctness of the native code itself.
Sources and further reading
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
