Your survey suite gets a real handset from a shared provider pool. What changes if that unit is allocated to your account instead?

A real-device cloud rents physical hardware, and the arrangement by which a unit reaches your session is a property of the service, not of your test code. The difference between a pooled unit and an allocated one is what each does to **supply** and to **state**. ## What the two arrangements actually are In a **shared pool**, the provider holds handsets that any tenant may be given. You ask for a model on a platform version, you are handed whichever matching unit is free, and when your session ends that unit becomes available to somebody else. In an **allocated** arrangement, a specific physical unit is set aside for your account for a period. It is still racked, powered and operated by the provider, but while the arrangement lasts it is not offered to other tenants. The distinction is about who the unit is offered to. It is not about how you drive it: the session still starts through the provider's remote endpoint and your suite's code is unchanged. ## Contention narrows, and that is what you are buying On a shared pool your competitor for a ruggedised handset is every other tenant who wants that same model. Their load is invisible to you and uncorrelated with your schedule. A survey suite that runs nightly may find the model free every night for weeks and then not free, for reasons that have nothing to do with your team. Allocation replaces that with contention you own: - Setting provider maintenance aside, the runs that can be holding the unit are your own. - Availability becomes a function of your schedule, which you are allowed to change. - A wait becomes a scheduling defect you can diagnose instead of weather you endure. - Variance in start time stops being a reason to retry blindly. Note what allocation is **not**. It does not make the unit permanently free. Your own overlapping lanes can hold it, and a run that crashes without releasing it still blocks the next one. The wait did not vanish; it changed owner. ## The state question inverts, and this is the part people get backwards The intuition is that dedicated hardware is cleaner. Mechanically the reverse is closer to the truth. A change of tenant is the moment at which anything might be returned to a known condition at all, so removing the change of tenant removes that moment. So on an allocated unit, what your last run installed, signed into, downloaded, granted or configured is what your next run starts from, unless something you wrote removed it. That is not automatically bad. Residue you produced is at least residue you can reason about, whereas a stranger's is not. But it has to be produced deliberately rather than inherited by accident. ## Shared against allocated | property | shared pool | allocated unit | |---|---|---| | who else competes | any tenant wanting that model | your own runs | | availability | varies with strangers' load | varies with your schedule | | between-run reset | whatever the provider does at hand-over | whatever your teardown does | | residue you inherit | a stranger's, unknown to you | your own, if you look | | absorbing a burst | another free unit may exist | no further unit appears | | physical history | unknown | made by your own suite | ## What you can observe, and what you must establish From inside a session you can observe a surprising amount, and all of it is on your side of the boundary: - what the platform reports about itself: model, platform version, screen metrics, locale, timezone - whether your application is already installed, and whether an account is already signed in - battery level and any power-saving or thermal indication the platform exposes What you cannot observe you must establish by asking, and then write down: - what cleaning, if any, happens between sessions under each arrangement - whether the unit's network path is the provider's network or a carrier link - what becomes of the unit's state when your run dies without running teardown - whether the unit may be updated in place, changing the platform under your suite ## Operating an allocated unit 1. Move the reset into your own setup: install the build under test, clear application data, set locale, timezone and permissions explicitly, and assert them before the first step runs. 2. Make teardown unconditional, so a failing test still removes accounts, application data and downloads rather than leaving them for tomorrow. 3. Record the observed starting state at the top of every run, so a later failure can be attributed to residue rather than argued about. 4. Watch the physical history you are now creating: a unit your own suite keeps busy runs warm, and a warm handset throttles. 5. Keep a route back onto a pooled unit, because an allocated unit that goes offline takes its whole lane with it. ## The judgment Allocation is a supply decision, not a hygiene one. It buys predictable availability and a physical history you author yourself; it costs elasticity, and it removes the hand-over that was the one moment at which anything might have been returned to a known condition. Take it for a start time you can schedule against, and write setup and teardown as though the unit remembers everything.