Device conditions
Put the device in the state where your bug happens.
Hold the battery at 12%, drop the network to a metro tunnel, switch the phone to Japanese. The settings apply to a phone while it runs. Most take effect at once and the app you are testing keeps running.
Three ways
A setting can be changed from three places.
What separates them is when the setting takes hold. One right now, one at the start of every test, one in the middle of a test.
- 1
From the panel, right now
Set the value in the panel next to the running device and apply it. It changes while the phone is on, and your app doesn't close.
- 2
From the environment, in every test
Save the same values to an environment. Prepare something like "Turkish phone" or "weak signal, low battery" once and reuse it in every test.
- 3
From a step, mid-test
Ready-made steps change the state during the test. Cut the network once checkout is on screen, then bring it back.
Mid-test
Change the state at the exact moment the bug would show.
The phone's state can be a step in the scenario. In this test the agent first goes to checkout. Then the connection drops to a subway tunnel, the speed falls to Edge and the connection cuts out at intervals. The agent places the order like that and checks whether the order was created only once.
Steps that can slot in the same way
- Drop the battery
- Make the phone ring
- Send an SMS
- Turn Wi-Fi off
- Turn the phone sideways
- Change the language
- Move the location
We tried it on our own apps
Bugs don't hide in normal use. They hide at the edges.
These bugs could be in your app too. Each one shows up only under a certain condition, like when the connection slows down, when the phone language changes, when the battery runs low or when a call comes in at checkout. We hid them in our own apps. TestSafe changed the condition itself in the middle of the test and caught the bug on video.
driver arriving, time left counting down
At 10% battery, the arrival time freezes
The battery drops to 10% while the driver is on the way. To save power the app stops updating the map, and the arrival time stops with it. The ride starts, but the screen still says 10 seconds.
TestSafe report
The ride ETA timer froze at 'ETA 10 s' and did not count down after waiting 15 seconds.
order summary open, connection slowed down
On a slow connection, one tap places two orders
The connection slows down on the order summary and Place order gets one tap. When the answer is late, the app quietly sends the order again. The customer thinks they ordered once, and the system has two orders.
TestSafe report
After restoring the connection and checking the Orders tab, I found that two identical orders (ORD-1006 and ORD-1005) had been placed simultaneously.
order summary open
Switching the phone to Japanese crashes the order screen
The phone language changes to Japanese on the order summary. The delivery date is now written 2026年10月3日. For the warehouse label the app keeps the first four letters of the month name. In Japanese the month name is shorter, so Place order closes the app.
TestSafe report
The app crashed immediately after the user tapped the 'Place order' button. It closed with java.lang.StringIndexOutOfBoundsException.
address form filled in
A call during checkout wipes the address form
The phone rings after the delivery address is filled in. When the call ends and the user goes back to the app, the form is empty and they are back in the cart. They have to type everything again.
TestSafe report
The app lost the progress of the filled-in address form after a phone call interruption, returning the user to the Cart screen instead.
Wireless Earbuds Pro open
The Reviews tab loads forever
Open the Reviews tab on Wireless Earbuds Pro. The server answers slowly for this product on purpose. The app should give up with an error after a while, but the spinner keeps turning.
TestSafe report
The app failed to load the reviews or provide an error message, remaining stuck on a loading spinner for the entire 20-second wait period.
card details entered
Rotating the phone empties the card form
Fill in the card form, rotate the phone, and every field is empty. The address form on the same flow survives, which is how you know it is the code and not the platform.
TestSafe report
When the screen rotated to landscape, all previously filled card fields lost their values. After rotating back to portrait the fields remained empty.
Conditions
Every setting has its own panel.
These are the panels as they exist in the product, opened against a running device. Each one applies on its own. A checkbox writes the same values into the environment so the next start comes up that way. Settings take effect at once.
These panels are the ones game studios use most. See how it works for games
The quickest way to see this is on something you already ship.
Book a demoQuestions
Fair questions, before you book
Is this the same as testing on a physical device?
Not identical, and it doesn't need to be. A full Android system runs in every environment, but the hardware underneath is our server, not a phone. Problems specific to a phone's own chipset or to a manufacturer's skin still show up on physical hardware. You keep checking a few physical phones before a release. What goes away is the shelf of phones kept on a desk for daily manual testing.
Will my app act differently because it isn't a physical phone?
The parts your app touches are the same as on a phone. Every environment boots an AOSP system image, and touches arrive through the same input path a physical screen uses, so the framework, the sensors and the input devices work the way they do on a phone. What we don't claim is a way around emulator detection. If your build blocks non-physical devices, say so on the call and we'll work through it.
Do Google Play services work?
Yes. Play services, the Play Store, GSF and Chrome are in the image, so the paths that depend on them (sign-in, push, purchase flows) run the way they would in a user's hand. Apps that refuse to start without GMS start here.
Do I have to change my app or add an SDK?
No. We install the exact build you ship, the same file that goes to the store, unmodified. There is no library to add, no build flavour to maintain, and nothing extra reaches the version your users download.
Who sets the conditions, me or the agent?
Either. Conditions can be written into the scenario, so a run always reaches checkout on a dying battery. Or you open the device panel and change them by hand while the run is going. Drop the signal now, switch the language now, and watch what the app does. Which condition groups an agent is allowed to touch is a permission you set, and a group that is off is never offered to the model at all.
How many environments can run at once?
Environments are containers rather than a shelf of phones, so a suite spreads across them instead of queueing for whichever device is free. Adding one takes seconds, with nothing to buy, rack or replace. How many run in parallel is a plan question, and we'll size it with you.
See it on your own build.
Book a demo and we'll set up the conditions your bug lives in, on your app, while you watch.