Android QA That Covers the Devices Your Users Actually Own
We build and run your Android test coverage across real OEM devices, API levels, and screen classes - closing the gap between CI green and Play Store crashes.
You might be experiencing...
Android app QA is harder than it looks because the Android ecosystem is not one platform - it is hundreds of them. The same APK runs on a stock Google Pixel, a Samsung Galaxy with One UI gesture overrides, a Xiaomi device where the OS will silently kill your background service if it decides your app is a battery drain, and a 2021 mid-range phone still on Android 11. Emulator coverage misses most of this.
The pitfalls that cause real production incidents fall into four categories. First, OEM fragmentation: Samsung, Xiaomi, and Oppo each layer their own UX modifications on top of AOSP, changing how notifications behave, how background processes are managed, and in some cases how touch events are dispatched. Second, battery optimization killing services: Doze mode and App Standby Buckets are documented Android behavior, but OEM-specific kill lists (Xiaomi’s MIUI autostart manager, for example) are not - and they break background sync, location updates, and FCM delivery in ways that only show up on real hardware. Third, permissions model drift: each Android release since API 23 has tightened or restructured permissions - the photo picker at API 33, the approximate-vs-precise location split at API 31, MANAGE_EXTERNAL_STORAGE restrictions at API 30 - and apps that were not built with these in mind show broken flows on newer OS versions without any obvious crash. Fourth, Espresso reliability: tests that rely on implicit timing instead of proper IdlingResource registration pass locally and fail in CI, or pass on emulators and fail on real devices under load.
Our managed QA service covers the full lifecycle, but for Android teams with an immediate fragmentation or flake problem, the sprint engagement above gets you a stable, real-device-backed suite in two weeks. Book a discovery call at /contact/ to scope it against your actual crash data.
Engagement Phases
Device Matrix and Risk Audit
We cross-reference your Play Console install data with Android market share by region to build a prioritized OEM and API-level coverage matrix. We audit your existing Espresso and UiAutomator tests for common failure modes - missing idling resources, animations not disabled, hardcoded delays - and map gaps against your critical user flows. We document OEM-specific risks (Samsung One UI gesture nav, Xiaomi MIUI autostart restrictions, Oppo ColorOS notification behavior) so nothing is left to guesswork.
Test Suite Build and Real-Device Execution
We write or extend Espresso instrumentation tests and UiAutomator cross-app flows, adding proper IdlingResource hooks so tests wait on async work rather than sleeping. Background service behavior and Doze mode handling are tested against App Standby Buckets (active, working-set, frequent, rare) using Firebase Test Lab physical devices. We run the full suite across your priority OEM matrix using Firebase Test Lab sharding to keep runtime manageable, supplementing with BrowserStack real devices for OEMs not covered by Firebase.
CI Integration and Regression Pack
We wire the suite into your existing CI (GitHub Actions, Bitrise, or CircleCI) with nightly Firebase Test Lab runs on the top device slice and a fast smoke layer on emulators for PR gates. We hand over a battery-optimization regression pack - a targeted set of tests that exercise background work, foreground services, WorkManager constraints, and FCM delivery - designed to catch OEM-specific kills before they reach staged rollout.
Deliverables
Before & After
| Metric | Before | After |
|---|---|---|
| OEM coverage on critical flows | Pixel + 1-2 Samsung emulators | Top 8 OEM models by install share, including Xiaomi and Oppo variants |
| Espresso flake rate in CI | Intermittent - tests retried 3 times to get a passing run | Stable - IdlingResources registered correctly, animations disabled, retries reserved for infrastructure failures only |
| Background service crash detection | Found in production via Android Vitals ANR reports | Caught in pre-release testing against Doze and OEM battery optimization scenarios |
Tools We Use
Frequently Asked Questions
Do you test on real Android devices or emulators?
Both, with purpose. <strong>Emulators</strong> are fast and good for PR-gate smoke tests where you need sub-5-minute feedback. <strong>Real devices on Firebase Test Lab</strong> are essential for rendering accuracy, touch latency, OEM skin behavior, and anything touching camera, Bluetooth, or GPS. For OEMs not available on Firebase (certain Xiaomi and Oppo models), we use BrowserStack App Automate.
How do you handle Samsung One UI and Xiaomi MIUI differences?
We treat OEM skins as first-class test targets, not afterthoughts. <strong>Samsung One UI</strong> changes gesture navigation, edge panel behavior, and how split-screen is triggered. <strong>Xiaomi MIUI</strong> and <strong>Oppo ColorOS</strong> both have aggressive autostart managers that silently kill background services - we test your WorkManager and foreground service declaration explicitly against these kill lists. We document every OEM-specific workaround we find so your dev team can patch upstream.
We already have some Espresso tests - can you build on them rather than rewriting?
Yes, and that is the preferred starting point. We audit your existing suite for the most common Espresso reliability problems - <strong>missing IdlingResource registrations</strong> (the leading cause of timing-dependent flake), animations left enabled in test builds, and hardcoded Thread.sleep calls masking real async races. We fix those first, extend coverage where gaps exist, and migrate any legacy UiAutomator 1.x tests to UiAutomator 2.
How do you test background services and push notifications reliably?
Background behavior is one of the hardest things to test on Android because <strong>Doze mode and App Standby Buckets</strong> change when the system defers work, and OEM battery optimizers add another unpredictable kill layer on top. We use WorkManager's TestDriver to force deferred tasks to run in tests, adb shell commands to simulate Doze transitions, and Firebase Test Lab's physical devices (not emulators) for FCM delivery tests since the emulator's FCM stack is not representative.
What does this engagement cost?
It depends on the scope - how many services your app uses, the depth of your existing test coverage, and whether you need a one-time sprint or ongoing test maintenance. <strong>Book a discovery call</strong> at <a href='/contact/'>remote.qa/contact</a> and we will scope it precisely against your Play Console crash data and coverage gaps.
Complementary Services
Ship Quality at Speed. Remotely.
Book a free 30-minute discovery call with our QA experts. We assess your testing gaps and show you how an AI-augmented QA team can accelerate your releases.
Talk to an Expert