> ## Documentation Index
> Fetch the complete documentation index at: https://docs.phoneuse.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Zero software footprint

> What the physical tier claims about a device under test, and what it does not.

On the physical tier, nothing is installed on the device under test. A
mechanical actuator presses the glass the way a person does, and a camera
observes what a person would see.

That is the whole claim, and this page exists to state it precisely, because
an imprecise version of it would be worth less than nothing.

## What the claim is

**Zero software footprint** means the device under test runs no phonebase
software. Nothing is installed on it. Nothing is injected into it. It is not
rooted, jailbroken, or modified. It has no debug channel open for our benefit.

**True fidelity** is the consequence. What the device reports is what a real
person's device would report, because from the device's point of view nothing
unusual is happening to it. Input arrives as a finger arriving. Output leaves
as light leaving a screen.

That combination is why the tier is worth its cost. It is slower and scarcer
than injecting input, and a physically actuated press takes as long as a press
takes.

## Why it follows from the mechanism

On the software tier something has to run on or against the device to inject
an event. That is the right default for most work and it is what you want for
speed. It also means there is something present that was not there before.

The physical tier removes the mechanism rather than hiding it. There is no
agent to detect because there is no agent. There is no injected event to
distinguish from a real one because the event is a real one, produced by
something touching the screen.

You do not have to take that on trust in the abstract: it is visible in the
device's own capability declaration. A device on this tier reports
`screenshot: "camera"` rather than a framebuffer capture, and `uiTree: false`,
because there is no privileged view of the interface to read. The absence of
those abilities **is** the absence of the footprint. See
[Capabilities](/devices/capabilities).

## What the claim is not

Be exact about the boundaries, in both directions.

**It is scoped to the physical tier.** The software and HID tiers work
differently by design, and neither makes this claim. If a device's
`fidelityTier` is not `physical`, this page is not describing it.

**It is about the device under test, not about the whole system.** A
mechanical actuator is a machine, and it is connected to something. The claim
is about the device's own state, which is where fidelity is decided.

**It is not a statement about what you should automate.** Zero footprint
concerns how faithfully a device behaves, not what you are permitted to do
with an application. The terms you operate under are still yours to observe.

## What it is for

The tier earns its cost where the difference between a real device and an
instrumented one is the thing under test:

* **Onboarding and sign in flows**, including a code delivered to a real SIM
  on the device you are testing, end to end, with nothing intercepting it.
* **Behaviour that varies with device state**, where an instrumented device is
  a different device and therefore not evidence.
* **Final verification before release**, on real hardware in real conditions,
  after the faster tiers have found everything they can find.

Use the cheapest tier that can falsify what you are testing, and move up when
the failure you are hunting needs more reality than that tier can give you.

## Related

<Columns cols={2}>
  <Card title="Device tiers" href="/devices/tiers">
    How input reaches a device on each tier.
  </Card>

  <Card title="Frame retention" href="/security/frame-retention">
    What happens to what the camera sees.
  </Card>
</Columns>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.