Passing on a Pixel is not a background test
BuilderHelp's field app spends real time out of the foreground — uploading a receipt, finishing a sync that started on site wifi, waiting on a push when the office changes a job. Those paths can look healthy on a Pixel and in an AOSP emulator, then die on a Galaxy that quietly put the app to sleep or a Xiaomi that never granted autostart. Device testing for background work is not "did the happy path run once." It is "did it survive the OEM's battery policy after the user stopped looking."
Stock Android is the baseline, not the product
Google's App Standby buckets, Doze, and background execution limits are real constraints, and they are also the ones every emulator and Pixel will reproduce. You can inspect the bucket with adb, force Doze, and watch WorkManager defer. That work belongs in CI. It is not enough for an app that crews install on whatever Android phone they already own.
OEMs ship a second policy layer on top. Samsung One UI maintains sleeping and deep-sleeping app lists that tighten jobs, alarms, and eventually background activity based on how long the app sat unused. Xiaomi's MIUI and HyperOS deny autostart for third-party apps by default and add their own battery saver screens. Oppo, OnePlus, Vivo, and others each have a "protect this app" or "auto-optimize" switch that is off until someone finds it.
A pass on stock behavior proves you respect the platform contract. It does not prove a Samsung sleeping list or a Xiaomi autostart denial will leave your sync alive. Those are different products wearing the same Play Store icon.
What the field app actually needs after the screen goes dark
For BuilderHelp, the risky surface is not a button tap. It is the work that continues when the crew puts the phone in a pocket: a photo or invoice upload that was mid-flight, a sync that still has a queue, a notification that a job assignment changed while they were on a ladder. If that work only runs while the activity is visible, the product is lying about being a field tool.
That means the test plan has to name the background contracts explicitly. Which jobs must run after the user leaves the app? Which uploads must resume after process death? Which pushes must arrive without the app being opened for three days? Write those down before you pick devices. A matrix built from "popular phones" will still miss the failure if nobody exercises the sleeping path.
Endeo's Android build has a narrower background surface — less continuous work than a contractor field client — but the same rule applies wherever you rely on deferred sync or notification delivery. If the feature assumes the OS will wake you, the OEM gets a vote.
Build the matrix from the killers, not the market-share chart
We already treat device catalogs as dependency lists for Pencil and radio behavior. OEM battery skins belong on that same list. A useful Android set for background work is small and intentional: a Pixel or clean AOSP baseline, a Samsung One UI device for sleeping and deep-sleeping lists, and at least one aggressive autostart skin — typically Xiaomi or a similar HyperOS / ColorOS device that crews actually carry.
Mid-range hardware matters here more than the flagship. Thermal throttling and memory pressure show up sooner on constrained SoCs, and OEM cleaners are often harsher on "unused" apps when the phone is fighting for RAM. A short smoke on a new S-series phone can hide what a three-day-idle A-series phone will do to your WorkManager chain.
Cloud device farms help for breadth. Keep one local Samsung and one local aggressive-OEM handset for reproduction: you need to open the OEM battery screens, toggle sleeping lists, deny autostart, and watch what your upload queue does. A farm session that only launches the UI will not create those states.
Reproduce the states the OEM invents
On the Pixel baseline, force standby buckets and battery restriction with adb and confirm the app degrades on purpose — longer sync deferral, fewer alarms, clear user-visible recovery when they reopen the app. That is your control group.
On Samsung, put the app into sleeping and deep sleeping from Device care and leave it unused long enough for the policy to stick. Confirm whether uploads resume, whether pushes still arrive, and whether the next cold start explains what was held. On Xiaomi-class skins, leave autostart off and "no restrictions" unset, reboot, and see whether background work ever starts without a manual open.
Also re-check after an OS or OEM update on a physical device when you can. Several skins reset battery exemptions and autostart after OTA. A permission you won in onboarding is not a permanent fixture; treating it as one is how a field app "randomly" stops syncing a month after install.
Make the product honest when the OEM wins
You will not whitelist every skin from code. Some devices require a settings path only the user can walk. The engineering job is to detect that background work is being starved, surface a specific recovery — not a generic "something went wrong" — and deep-link or document the OEM screen when you know it.
The other half is scope. If a flow cannot survive deep sleep without a foreground service and a notification the user will tolerate, say so in the acceptance criteria. Quiet immortal background sync is not a default Android offers anymore, and OEM layers made the default even quieter. Design the field workflow so a reopen can catch up, and so the office side does not assume a pocketed phone is a live socket.
Before we call a release tested for background behavior, the device note names the OEM states we forced: standby bucket or battery restriction on Pixel, sleeping/deep sleeping on Samsung, autostart-denied reboot on the aggressive skin, and what still worked. If those rows are blank, we tested the demo — not the phone the crew owns.