What does a device cloud actually rent you when you ask for a real device rather than a virtual one?
answer
- one is an object, one is a process
- what can be copied and what cannot
- charge, heat and wear are real
- an image can start again; a handset cannot
- the unit arrives with a history
basics
~20 sA real target is physical hardware racked at the provider, with its own chip, screen, radio, battery and heat, usually shared between tenants and finite. A virtual target is software started on server hardware, those properties simulated or absent.
solid answer
~50 sA hosted fleet holds two kinds of target and the difference is physical. A **real device** is a handset or tablet racked in the provider's facility: it has its own processor, the manufacturer's own platform build, a screen made of real pixels, sensors, a battery that charges and discharges, and heat that builds under load until the platform throttles. There is a finite quantity of any given model, a unit cannot be copied, and it is usually passed between tenants. A **virtual target** is software the provider starts on server hardware, such as a browser in a container or an emulated handset environment, so battery, radio, sensors and thermal behaviour are simulated or simply absent, and another instance can be started from the same image whenever compute is free. Renting the first is renting an object; renting the second is renting a process.
go deeper
Be able to say plainly what each kind of target is: hardware in a rack against software started from an image, and name a couple of properties only the hardware has.
Be ready to trace the consequences: why supply, residue and unset inputs such as charge and temperature all follow from one being an object and the other a process.
Expect to be asked how you would tell a hardware-only failure from a bad test, and what evidence about the target you would capture at the start of a run to make that separation possible.
Be ready to reason about a fleet as a whole: which properties genuinely require hardware, what each kind of target costs you in operational unpredictability, and how you keep that reasoning current.
When a hosted browser or device cloud offers you a "real device" and a "virtual" one, it is not describing two grades of the same thing. It is describing two different kinds of object with different physics, and almost everything else about the service follows from that difference. ## What is on the other end A **real target** is hardware. Somewhere in the provider's facility there is a handset or tablet in a rack, plugged into power and into a host machine that drives it. It runs the manufacturer's own platform build, on the manufacturer's own chip, with a real display, real sensors and a real battery. It is a physical object: it can be busy, it can be warm, it can be broken, and it can be retired. It cannot be duplicated. A **virtual target** is a process. The provider starts software on ordinary server hardware, from an image it keeps: a browser inside a container, or an emulated or simulated handset environment presenting the same automation interface. Nothing about it is unique. Given free compute, the same image can be started again, and again. ## What the physical target has that the virtual one does not - **A battery**, which holds a charge, discharges under load, and drives platform behaviour such as power-saving modes that restrict background work. - **Thermal behaviour**: sustained work heats the chassis, and a hot handset throttles its own processor to protect itself. - **The manufacturer's platform build**, including the vendor's own modifications, rather than a generic image. - **Real sensors and radios**, whose presence is genuine even though what they are connected to inside a data centre is a question you have to ask. - **Wear**: storage, battery and connectors age, and the unit eventually leaves the fleet. A virtual target has none of these as physical facts. Where the automation interface exposes something equivalent, it is simulated: a battery level you can set rather than one that drains, a location that is declared rather than measured, a network condition that is imposed by software. ## Real and virtual, side by side | property | real target | virtual target | |---|---|---| | what it is | hardware in a rack | software from an image | | supply | finite units the provider owns | grows with server capacity | | duplication | impossible | routine | | battery and heat | genuine, and they affect behaviour | simulated or absent | | platform build | the manufacturer's | an image the provider assembles | | end of a session | the unit is returned | the instance is disposable | ## Why the difference reaches your suite The first place it shows up is **availability**. A virtual target starts when there is compute for it; a real one starts when that particular unit is free, and the rarer the model, the more that matters. The second is **residue**. A disposable instance is trivially replaced by a fresh one, so a virtual lane tends to start from a known image. A physical unit is not disposable, so returning it to a usable condition happens in place, and that is a procedure rather than a guarantee. The third is **variance you did not set**. A racked handset arrives at whatever charge and temperature the previous run left it. Those are inputs to your test that your test did not choose, and on a virtual target they mostly do not exist. ## What to do about it in your own suite - Assert the target you actually got at the start of the run: model, platform version, screen metrics, locale and timezone as the session reports them. - Set explicitly whatever your test depends on rather than trusting the starting condition, and clean up what you created. - Record availability and duration separately for your real lane and your virtual lane; averaging them hides the interesting one. - When a failure appears only on the hardware lane, keep battery state and thermal throttling on your list of candidate causes before you call the test flaky. - Ask the provider what a racked handset's network path actually is, rather than assuming a live carrier link, and write the answer down where the suite's owners will see it. ## The short version for an interview Renting a virtual target is renting a **process**: cheap to start, cheap to discard, plentiful, and honest about being an approximation of hardware. Renting a real target is renting an **object**: finite, shared, physical, carrying its own history, and the kind that can tell you what the manufacturer's own build does on the manufacturer's own silicon. A fleet mixes them because they are good at different things, and the service properties you have to plan around, availability and residue above all, come straight from which kind you asked for.
- Why does a real device's battery level matter to an automated test at all?Because the platform changes its own behaviour according to it. Below a threshold the operating system may enter a power-saving mode that restricts background work, delays scheduled tasks, dims the display or reduces processor frequency. A survey app that syncs in the background can therefore behave differently on a unit at low charge, and the test did not set that input. On a virtual target the equivalent value is usually declared rather than lived.
- Is a virtual target simply an inferior copy of the real one?No. It is a different object with different strengths. It starts when compute is free rather than when a particular unit is free, it can be started many times over from the same image, and it gives a repeatable starting condition. What it does not give is the manufacturer's build running on the manufacturer's silicon, with genuine battery, thermal and sensor behaviour. A fleet holds both because they answer different questions.
A virtual target is like a photocopy of a workspace: run off another whenever you need one. A real handset is the tool itself, borrowed from a shared tool library, so it comes back part-charged, warm, and however the last borrower left it, and if it is out, you wait.
saying these in an interview costs you the question
- Calls a virtual target the same device, only faster
- Assumes a racked handset is on a live carrier network
- Thinks battery and temperature are inputs a test simply chooses
- Expects a real device to start on request like a virtual one
- Describes a virtual target as a real device with sensors switched off