Inventory all native libraries
Use the Android 16 KB guide to understand ELF alignment and APK packaging requirements. List .so files for each supported ABI and identify their owners.
The Unity build guide explains the Android output pipeline. Use the engine version's supported toolchain and plugin guidance rather than applying arbitrary linker flags to prebuilt binaries.
Check two separate layers
| Layer | What to validate |
|---|---|
| ELF binary | Load-segment alignment and runtime assumptions |
| APK packaging | Appropriate alignment of uncompressed native entries |
| Runtime code | No hard-coded assumptions about 4 KB pages |
| Dependency set | Every included plugin, not just the engine |
Passing a ZIP alignment check alone does not prove every ELF library is compatible.
Replace incompatible prebuilt plugins
A precompiled .so generally needs a compatible release from its publisher or a rebuild from authorized source with the supported toolchain. Repacking the APK cannot change the binary's internal load-segment design.
Track plugin versions and request explicit compatibility evidence when the publisher's documentation is unclear.
Test the actual release
Use a supported 16 KB test environment and install the final artifact. Exercise plugin initialization and less common native paths, not only the first scene.
Also retain tests on supported conventional devices so the correction does not create a new compatibility regression.
Keep evidence per library
APKLint can help inventory native entries and package structure. It cannot establish complete page-size compatibility from the presence of arm64-v8a alone. Record ELF/package checks, plugin versions and runtime results for the exact distributed build before claiming compatibility.
Build a compatibility inventory for engine and vendor code
Suppose the engine has been upgraded but the game still packages an older voice-chat plugin. Inspect every native library in the final delivered architecture, including the plugin's transitive native dependencies. An engine release that supports a page-size requirement cannot rewrite an incompatible precompiled vendor library automatically.
The Android page-size guide separates binary alignment, package alignment and runtime compatibility. Record the owner and version for each library, then retain the applicable ELF inspection result. Inspect the package's native-entry alignment separately. These are different layers: a correctly aligned ZIP entry can still contain a binary whose load segments are unsuitable.
Exercise the native feature on a verified test environment
Confirm that the test environment actually uses the intended page size before installing the candidate. Open the game, enter voice chat, leave and reconnect, and exercise any native codec or capture path that initializes later. A successful opening scene may never load the library that requires attention. Save the observed environment details and the exact installed artifact identity with the result.
If a plugin fails the static checks, obtain a compatible release from its maintainer or rebuild authorized source using the supported toolchain. Renaming the library, compressing it differently or copying an arm64 binary into another directory cannot change its ELF load layout. A linker option only affects binaries that are actually rebuilt; it does not modify unrelated prebuilt inputs.
Review native code that assumes a fixed page size when calculating memory boundaries. Static alignment checks cannot prove those runtime calculations are correct. Follow the platform guidance for querying the required values and test the affected allocation, mapping or protection behavior through representative features. Keep the change within the engine and plugin versions that the project supports.
After replacing a dependency, repeat conventional supported-device tests as well as the page-size-specific test. Check startup, saved-state loading, native feature initialization and update installation. For bundle distribution, inspect and test the generated delivery artifacts rather than relying exclusively on an unrelated local APK. The final evidence should show which libraries were checked, which vendor updates were applied and which native paths were exercised; an ABI label alone establishes none of those results.
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
