September 13, 2026
Testing on Samsung One UI vs stock Android: what actually differs
The rack stopped being six identical Pixel 7a. Two Samsungs joined it, and the second Android is the part that matters — Settings layout, the default keyboard, twenty preinstalled packages, and a 32-bit ABI the Pixels cannot run.
For most of DeviceRent's life the rack was six Pixel 7a. Six identical phones, same SoC, same Android build, same everything. That was a deliberate choice — it made the hardware predictable and the bugs reproducible — and it was also, quietly, a limitation we were selling as a feature.
This week two Samsungs joined the rack: a Galaxy A16 and a Galaxy A54. Eight phones, three models, two very different Androids. This post is about why that second Android matters more than the phone count does.
"Android 16" is not one thing
Both Samsungs run Android 16. So do all six Pixels. If you only look at the version string, the rack is homogeneous.
Then you open Settings.
On a Pixel, Wi-Fi lives under Network & internet. On One UI it is a top-level Connections entry. The route to the Android version differs too — different section, different label, different depth. An Appium test that walks the Settings UI by text or by resource ID — and most of them do, somewhere — does not survive that move.
The differences that actually bite, in rough order of how often they break something:
- Settings information architecture. Different sections, different labels, different depth. Anything that automates a system setting is model-specific in practice, even when it is written to look generic.
- The default keyboard. Gboard on Pixel, Samsung Keyboard on Galaxy. Different package name, different autocorrect behaviour, different suggestion strip height — which quietly changes how much of your layout is visible when a field has focus.
- The preinstalled set. A Pixel arrives close to bare. Our A54 arrived with twenty third-party packages on it — Facebook, LinkedIn, Spotify and more, all preloaded by the manufacturer. If your app's behaviour depends on whether some other app is installed (share sheets, OAuth handoffs, "open in" intents), those are two different worlds.
- Permission and battery dialogs. OEM power management is not stock power management. A background job that survives a Pixel overnight is not evidence about a Samsung.
None of this is exotic. It is the ordinary surface area of shipping an Android app, and it is invisible to you if every device you test on came from the same manufacturer.
The one that is not a UI difference
The Galaxy A54 reports its supported ABIs as arm64-v8a, armeabi-v7a, armeabi.
Every Pixel 7a reports arm64-v8a and nothing else. The Pixel 7a is a 64-bit-only device: a 32-bit armeabi-v7a build cannot be installed on it at all, no matter what you do. pm install simply refuses.
That is not a cosmetic difference, and we found out about it the practical way — our APK install pre-flight reads the phone's own ABI list before it pushes anything, precisely so it can refuse a build in a second instead of failing three minutes into an upload. That check was written when the rack was one model. It was already correct; the copy around it was not, and two sentences on this site had to be rewritten when a phone with a 32-bit slice arrived.
If you ship native code, this is the kind of thing you want to discover on a rented phone, not in a crash report.
Why a farm of identical phones is a comfortable lie
There is a real argument for a narrow rack. Fewer variables, faster triage, no "well, it works on the other one". We made that argument honestly for months.
But a test suite's job is to tell you something about the phones your users hold, and the install base is not six Pixels. A suite that is green across six identical devices is, information-theoretically, a suite that is green on one device you ran six times. The second, third and fourth Pixel tell you almost nothing the first one did not.
Adding one Samsung changed that more than adding six more Pixels would have.
What is actually in the rack
Eight physical phones in the Netherlands, on ADB over Tailscale, billed by the minute at the same rate regardless of model:
- 6 × Google Pixel 7a — stock Android 16, 1080×2400, 64-bit only
- 1 × Samsung Galaxy A16 (SM-A165F) — One UI on Android 16
- 1 × Samsung Galaxy A54 (SM-A546B) — One UI on Android 16, 120 Hz panel, 32-bit ABI support
Every one of them is wiped between renters, and every one has a locked bootloader.
Where we are still the wrong answer
We would rather say this here than let you find it after signing up.
No root. Every phone in the rack is bootloader-locked with Verified Boot green and no su binary. If your work is Magisk modules or custom kernels, we cannot serve you. It is the request we get most and it is on the list.
No iOS. There is none, and none is planned.
Not forty models. Eight phones across three models is a small rack, and if your matrix genuinely needs breadth — foldables, glyph hardware, flagship camera sensors — we are not that yet. Those are marked as roadmap everywhere on this site rather than dressed up as inventory, and which one we buy next is decided by what people actually ask for.
A brand is not a capability. We own two mid-range Samsungs. That does not mean we can serve a 200MP flagship sensor, and we are not going to say "Samsung" and let you assume we can.
Try it
If you have been testing on one manufacturer because a second device lab was never worth the setup, this is the cheapest way to find out what you have been missing. Rent a Galaxy for a few minutes, run the part of your suite that touches Settings or the keyboard, and see what happens.
More from the workshop
September 2, 2026
Renting three phones at once: a feature the backend already had
We shipped multi-device rentals this week. The database had already enforced the limit for over a year — the only thing missing was a UI that let you click twice.
September 2, 2026
The phone that couldn't be cleaned: a dead end nobody could see
A phone can be marked available and still owe a wipe. When both were true at once it became unrentable and unwipeable at the same time — and nothing was watching for it.
September 2, 2026
Rebuilding the session page into an actual workbench
We turned the customer session page from a phone stuck in a 300px box into a stage-and-dock workbench across three staged releases, and found a real tap-scaling bug along the way.