On a shared real device at a hosted provider, what can carry over from the previous tenant's session?
answer
- what a procedure can reach, and what it cannot
- an image is discarded; hardware is cleaned
- signed in, granted, downloaded, configured
- charge and heat are not settings
- never depend on a reset you did not run
basics
~20 sAnything the cleaning between sessions did not reach: installed apps and their data, signed-in accounts, granted permissions, clipboard, downloads, browser profile and system settings like locale. Battery charge and temperature carry over regardless, because they are physical, not configured.
solid answer
~50 sThe split is between state a cleaning procedure can reach and state that is physical. Reachable state is everything the platform stores: your application and its data, signed-in accounts and credential stores, granted runtime permissions, the clipboard, downloads and files in shared storage, installed certificates and network or proxy configuration, browser cookies and profile, and system settings such as language, timezone and display size. Whether any particular one of those was actually cleared before your session is a property of the provider's procedure, and that is something to establish by asking rather than to assume. Physical state is not reachable at all: the battery sits at whatever charge the previous run left, the chassis at whatever temperature that run produced, and storage carries the wear it has accumulated. The safe posture is to set what your test needs explicitly and assert it before the first step.
go deeper
Know that a shared real device may arrive with somebody else's leftovers, and that your test should set what it needs rather than trusting what it finds.
Be ready to list the categories of state that can survive a hand-over and to explain why a physical unit is cleaned in place while a virtual one is simply replaced.
Expect a scenario: a case passes on hardware but proves nothing because an account was already signed in. Explain how you would detect that, and what setup and teardown you would mandate.
Be ready to set the standard for many teams: what every suite must assert at session start, what it must clean unconditionally, and what the organisation should ask a provider and record.
A hosted real-device fleet hands the same physical unit to tenant after tenant, which raises a question a virtual lane rarely has to answer: what does the next session start from? The useful framing is not "does the provider reset the device" but "which kinds of state could survive at all, and which of those can any procedure reach". ## Why hardware is cleaned rather than replaced For a virtual target, resetting and discarding are effectively the same operation: the instance came from an image, so throwing it away and starting another gives a known condition at the cost of a scheduling decision. A handset cannot be discarded and remade. It can be swapped for another unit of the same model, but that unit is a physical object with a history of its own, so somewhere a device has to be **returned to a usable condition in place**. That is a procedure rather than a guarantee, and procedures have properties that a fresh image does not: - They take time on hardware the provider also wants busy. - They can be partial, covering the common cases and not the unusual ones. - They can fail, on a device that is in an unexpected condition. - They can be interrupted, if the previous run died rather than ended. This does not say any provider cleans badly. It says the mechanism differs in kind, and that difference is what you plan around. ## The state a device can carry Grouped by where it lives, and each is something you can check from your own session: - **Applications**: builds installed by an earlier run, including an older build of the app under test. - **Application data**: databases, preferences, caches and saved files belonging to those builds. - **Identity**: accounts signed into the platform or into apps, tokens in credential stores, saved passwords. - **Permissions**: runtime grants such as location, camera or storage, already answered for an app. - **Shared storage**: downloads, photographs, screen recordings and exported files. - **Clipboard**: whatever was last copied, which a form may paste unasked. - **Network configuration**: saved wireless networks, proxy settings, installed certificates, virtual private network profiles. - **Browser state**: cookies, site storage, cached credentials and an entire profile if a browser was used. - **System settings**: language, region, timezone, date, display size, accessibility options, developer options. For a field-survey app this matters concretely: a surveyor's flow starts by signing in and granting location, so if an earlier session left an account signed in and location granted, your test never exercises the path it claims to cover, and it passes. ## What no reset reaches Some state is not configuration at all, and no procedure can return it to a chosen value: - **Battery charge**, which sits wherever the previous run left it, and which drives platform power-saving behaviour. - **Temperature**, since a chassis that has just run a heavy suite is warm and a warm handset throttles. - **Wear**, in storage and battery health, accumulating over the unit's life. These are inputs your test did not set and cannot set. They are also a genuine explanation for a failure that appears on the hardware lane and nowhere else, worth having on the list before anybody reaches for the word flaky. ## Reachable, physical, and what to do about each | kind of state | example | can a procedure reach it | your move | |---|---|---|---| | application | an older build still installed | yes | install the build you mean to test | | identity | an account already signed in | yes | sign out first, sign in explicitly | | permission | location already granted | yes | set the grant your case requires | | system setting | timezone from another tenant | yes | set and assert it in setup | | battery charge | a part-drained unit | no | observe it, record it, expect variance | | temperature | a warm chassis | no | treat throttling as a candidate cause | ## Establish rather than assume The provider's internal procedure is not visible from inside a session, so separate what you can see from what you have to be told: 1. Observe, every run: what the platform reports about itself, whether your app is present, whether an account is signed in, what the battery reports, what locale and timezone are set. 2. Ask, once, and write the answer where the suite's owners will find it: what happens between sessions, what happens when a run dies mid-session, and whether the unit can be updated in place. 3. Design as though neither answer is reliable; both can change without telling you. ## What the suite should actually do The rule that survives all of this is simple: **do not depend on a reset you did not perform**. Install the build you are testing. Clear application data yourself rather than trusting it is clear. Set locale, timezone and permissions explicitly, and assert them before the first meaningful step, so a wrong starting condition fails loudly instead of producing a mysterious result later on. Then clean up unconditionally at the end, so a failure does not leave a signed-in account behind for whoever gets the unit next. That has a confidentiality dimension as well as a correctness one, but correctness alone is reason enough to write the teardown.
- Why is leftover state especially dangerous for a test that covers sign-in and permissions?Because it silently skips the path under test. If an account is already signed in and location is already granted, the case never reaches the screens it exists to verify, yet it ends green. The failure mode is a passing test that proves nothing, which is worse than a red one. Signing out and revoking or explicitly setting the grant in setup turns that into a real exercise of the flow.
- How would you tell leftover state from a genuine product defect?Capture the starting condition before the first step: what is installed, who is signed in, which permissions are granted, and what locale and timezone are set. If the failure correlates with a starting condition your setup did not create, it is residue. If the same failure reproduces from a starting condition you established yourself, it is the product. Without that capture the argument is unresolvable and usually ends in a re-run.
- Does the same reasoning apply to a virtual browser target in a hosted fleet?The categories shrink but the rule holds. A virtual target is cheap to replace, so a fresh instance is the natural implementation, but you still have not verified it. Browser profile state, cookies, site storage and cached credentials are exactly the kind of thing that would carry over if an instance were reused. Establishing a known profile from your own harness costs little and removes the question entirely.
saying these in an interview costs you the question
- Assumes every provider factory-resets a device between tenants
- Treats a green test as proof the starting condition was clean
- Thinks battery and temperature can be reset like a setting
- Ignores clipboard, certificates and system settings as leftover state
- Writes teardown that only runs when the test passes