Real-device QA
Real-Device Testing for Flutter and React Native Android Apps
Build a risk-based real-device matrix for Flutter and React Native Android apps, covering release builds, native integrations, lifecycle, performance, permissions, and OEM differences.
Automated unit and component tests protect application logic. Real Android devices reveal a different class of failure: OEM lifecycle behaviour, permission surfaces, system UI, cameras, biometrics, deep links, keyboards, memory pressure, thermal limits, and release-build integration.
Use automation, emulators, and devices for different jobs
| Layer | Best signal | Typical limitation |
|---|---|---|
| Unit / widget / component | Fast logic and UI-state regression | Mocks can hide native and environment behaviour |
| Integration / E2E on emulator | Repeatable journey and Android-version coverage | Hardware, performance, OEM services, and user environment differ |
| Release build on real device | Actual installation, native integration, lifecycle, and feel | Smaller matrix and slower execution |
Flutter's official testing overview distinguishes unit, widget, and integration tests and notes that integration tests generally run on a real device or emulator. React Native's guidance similarly treats end-to-end tests as the highest-confidence layer while warning about their cost and potential flakiness. Keep the pyramid broad at the bottom and use devices for high-risk workflows.
Build a risk-based device matrix
- Audience: choose Android versions, regions, manufacturers, and screen sizes from actual target users.
- Hardware: include only capabilities the app relies on—camera, GPS, biometrics, NFC, Bluetooth, microphone, or sensors.
- Risk: add a lower-memory device, the latest Android version, and one OEM with aggressive background management when background work matters.
- Form factor: test a tablet, foldable, or resizable window when the product claims support or analytics justify it.
- Network: cover loss, high latency, switching, captive portals, and metered data where relevant.
Flutter release-build checks
- Run critical integration journeys against a release-like build, not only debug mode
- Verify plugin-backed permissions, camera, notifications, deep links, WebViews, and platform views on devices
- Check startup, shader or animation smoothness, image memory, large lists, and isolate-heavy work on lower-capability hardware
- Test app links, flavour configuration, signing-dependent services, and obfuscation or symbol upload if used
- Remember that Flutter's standard integration tooling may not control every native system surface; test those interactions manually or with appropriate tooling
React Native release-build checks
- Exercise a signed release build with the development menu and Metro unavailable
- Verify native modules, architecture settings, JavaScript engine, deep links, push notifications, and over-the-air update rules if applicable
- Test cold start, navigation transitions, long lists, images, bridge or interop-heavy flows, and memory pressure on representative hardware
- Background, lock, process death, permission changes, and activity recreation restore safe state
- E2E selectors use stable accessibility or test identifiers rather than fragile visual text where appropriate
Record device evidence that developers can use
For every issue, capture framework and app version, build type, device model, Android version, OEM skin where relevant, starting state, shortest steps, expected result, actual result, frequency, network, and permission state. Attach logs or recordings only when they do not expose secrets or personal data.
Retest on the original device first, then one contrasting device to distinguish an environment-specific fix from a general regression. Feed stable scenarios back into automated coverage where the maintenance cost is justified.