Android App Compatibility Testing: Go Beyond minSdk

Build a risk-based device matrix

Choose boundaries rather than dozens of nearly identical devices. Include the minimum supported Android version, a recent target-relevant version, representative screen sizes and every shipped native architecture. Add tablets, foldables, TV, Wear or automotive only when the app supports those experiences.

The Android 16 KB page-size guidance deserves a separate native-code check where applicable; it is not equivalent to screen density or APK ZIP compression.

Test tasks, not only screens

For a document tool, follow selection, processing, cancellation, output sharing and process restoration. For a game, test starting a level, backgrounding, returning, saving progress and handling a denied ad or notification permission.

Include offline and slow-network states. A spinner that never ends on a lost connection is a compatibility problem users experience even if the app never crashes.

Use release-like artifacts

Test a signed, optimized build with production-like configuration and safe test services. Debug builds may use different endpoints, certificates, network trust rules or permissions. Preserve mapping files and native symbols so release-only failures remain diagnosable.

A compatibility checklist should record version code, OS, device or emulator, scenario, expected outcome and actual outcome. “Passed Android testing” is too vague to reproduce.

Interpret automated checks conservatively

APKLint can help inspect minimum SDK and declared package characteristics. It does not run the application through this matrix. Android's permission model and module configuration explain the declarations, but manual interaction and device testing remain necessary.

Release only when known exceptions are documented and acceptable. Do not advertise support for a form factor solely because its emulator installed the APK once.