Testing practice: For Know the supported range, define a reproducible starting state, perform one controlled change at a time and record the result. Good testing evidence helps another person repeat the same path without guessing what happened.
Evidence quality: A useful report separates observation from theory. Record version, device context, steps, expected result and actual result while removing passwords, authentication codes and unrelated personal information from evidence.
Know the supported range
The app's minimum and target platform choices define important compatibility boundaries.
Testing should include the minimum supported release and versions where behaviour changed significantly.
Permissions evolve
Android has changed how location, notifications, media and other permissions are requested and scoped.
Verify both first-time prompts and previously denied states on relevant versions.
System UI changes
Back navigation, status bars, keyboards and system dialogs can appear or behave differently across releases.
Test workflows that depend on those system surfaces.
APIs may be unavailable
Newer platform features require fallback or guarded code when older versions are supported.
A successful build does not guarantee the runtime path is safe on every supported OS.
Upgrade paths matter
Users may update Android or the app without clearing existing data.
Include upgrade scenarios, not only fresh installations.
Common mistakes to avoid
- Testing only the newest Android.
- Assuming permission behaviour never changes.
- Ignoring upgrade state.
Practical checklist
- List supported versions.
- Test minimum OS.
- Check permissions.
- Check system navigation.
- Test app upgrades.
Frequently asked questions
Why test old Android if the app compiles?
Compilation does not prove every runtime path works on older APIs.
Can permissions differ by Android version?
Yes. Platform permission models evolve.
Is a fresh install enough?
No. Existing users may carry data and permission state across updates.