Add a way to restart the device (control center + usb-debug), not just shut down

[ObjSal]

Summary

Please add a way to restart a Passport Prime — both as a UI action and as a usb-debug/MCP command. Today the only power action is a full shutdown, and on a remotely-driven device that is a one-way door.

What exists today

• On device: a long power-press opens the control center, and its only power action is "Shut Down". There is no Restart.
• Over usb-debug: foundation-passport-drive has power (short = lock, --long = control center) and reboot-samba. There is no ordinary reboot. reboot_to_samba is a bootloader/flashing mode, not a warm restart, and is not something you want to land in on a device you cannot physically reach.

So "turn it off and on again" — the first recovery step for any device — is currently only available to someone holding the device.

Why this matters beyond convenience

A shutdown cannot be undone remotely: once the device is off it no longer enumerates on USB, so no host command can bring it back. Combined with two other behaviours, an attended-only recovery becomes an unattended-run killer:

1. usb-debug refuses UI commands while the device is locked. Verified just now: get_version and get_process_list still answer, while screenshot, power_button and input are refused with "device is locked". That is sound security and I am not asking you to change it — but it does mean a lock cannot be undone from the host either, because entering the PIN is input.
2. Modal system alerts cannot be driven. The grant-on-first-use permission sheet is drawn by gui-app-alerts (a separate process from the app), and neither tap nor swipe reaches it — 0.00% of content pixels change across before/after captures, while the identical injected tap dismisses the same sheet in the hosted simulator. So an app awaiting a first-use grant blocks the whole screen until a human touches it.

Put together: a device can reach a state where the screen is blocked by something the host cannot dismiss, and the only remedies are a physical touch or a shutdown that ends remote access entirely. That is exactly where ours is right now.

Request

1. "Restart" in the control center, alongside "Shut Down". Useful for every user, not just automation — restarting is a normal recovery step and today it costs a shutdown plus a physical power-on.

2. A reboot command over usb-debug/MCP — a normal warm restart, explicitly not SAM-BA. Developer-Mode gated, exactly like the rest of the interface.

3. Please consider allowing (2) while the device is locked. This is the part that actually unblocks remote operation, so it is worth stating the reasoning rather than just asking:

   • A reboot reveals nothing and grants nothing — the device comes back locked and PIN-gated, data at rest untouched. It is not a read primitive.
   • The alternative recovery available to a host today is the shutdown, which is strictly more destructive to availability and is already permitted from the control center.
   • The realistic threat is denial-of-service by someone with physical USB access and Developer Mode enabled — who can already pull the cable, or hold the power button.

   If you would rather keep every command behind the unlock, that is a defensible call and I would understand it; in that case (1) alone still helps, and I would ask that the refusal message say so explicitly.

Context

We drive full UI suites against real hardware over usb-debug (the harness behind our sideloaded apps), and this session ran a 14-leg regression board on-device unattended. The gap only shows up when something goes wrong: with no restart, an automated run that meets a modal sheet or a stray lock cannot recover without someone in the room.

Related: #9 (permission denial aborts apps), #13 (simulator input injection, now shipped — thank you), #15 (file read/write over MCP). Happy to test a build against our suites, as before.

[badicsalex]

neither tap nor swipe reaches it — 0.00% of content pixels change across before/after captures, while the identical injected tap dismisses the same sheet in the hosted simulator.

This sounds like a separate bug. Modals should be visible on screenshots and taps should be routed towards them.

We do have an issue on HW, that when the screen is turned off, the screenshot and tap MCPs seem to work, but screens are not actually updated (no vsync interrupt to drive the animations), and taps are just silently discarded. We have a fix in the pipeline: we will just disallow these operations when the screen is off and have instructions on the method that usually the screen needs to be turned back on by tapping the power button.

---

As for the ability to do a regular reset over usb-debug: that's a good idea.

---

IIRC we will also allow power button, screenshot and tap when the device is locked. (Although this is somewhat dubious security-wise)
EDIT: We only allow these in development firmware, not on production units, disregard.

[ObjSal]

Correction to the motivation in this issue. Point 2 of "Why this matters beyond convenience" — that modal permission sheets cannot be driven by injected input — is wrong, and I have retracted it on #9.

The cause was my own tooling: usb-debug is single-claim, I had an mcp coprocess holding the interface, and the per-call CLI I was testing with was being refused with "Access denied (insufficient permissions)" before anything reached the device. I had silenced stderr, so I misread "no pixels changed" as "the sheet ignores input". Routed through the coprocess, a live grant sheet dismissed on the first tap (55.23% of the content area changed). gui-app-alerts is fine.

The request itself stands, and none of it depended on that claim:

• The control center offers only Shut Down — still no Restart. (Screenshot evidence unchanged.)
• A shutdown cannot be undone remotely: once off the device stops enumerating on USB.
• usb-debug refuses UI commands while the device is locked — this one I re-verified through the MCP path, so it is not the same mistake: get_version and get_process_list answer, while screenshot and power_button return "device is locked". A lock therefore cannot be undone from the host, because entering the PIN is itself input.

That last point is the real motivation, and it is sharper without the bad example: a short power-press locks the device, and from that moment there is no host-side path back — no restart, and no way to authenticate. That is a state an unattended run can enter by accident and cannot leave.

Which also means the part of the request that matters most is item 3: a reboot that is permitted while locked. Without it, a remote reboot would be refused exactly when it is needed.

[badicsalex]

I've created an internal ticket to make a shutdown and reboot command for usb-debug.

[tobyjaguar]

+1, and a design note worth having before that internal ticket gets implemented, since it could make the new command self-defeating.

Developer Mode does not survive a power cycle, at least on 1.4.0-beta3 — I just filed #17 on that. It's what gates the vendor 0xFF interface, so when it resets, usb-debug stops enumerating entirely.

Put together with a reboot-over-usb-debug command, the sequence for an unattended run is:

1. Host issues reboot over usb-debug.
2. Device comes back with Developer Mode off.
3. The debug interface is gone, so the host cannot reach the device — including to issue another reboot.

That's the same trap this issue is trying to escape, just moved one step later: the host would have a way out of a lock but would lose the channel on the way. And it's worse than the current state in one respect, because the command that strands you is one the host issued itself.

So the question for whoever picks up the internal ticket: should a usb-debug-initiated reboot preserve Developer Mode across the restart? My instinct is yes, and that it's defensible — the reboot was authenticated over a channel that only exists because Developer Mode is on, so preserving it doesn't widen the trust boundary the way persisting it across a cold boot would. A physical power-off could still clear it and keep the "unattended machine can't be left in debug mode" property intact.

To be clear about what I actually verified: I've confirmed the reset across a power cycle (device off, then on). I have not tested a soft restart, since there's no way to trigger one — which is this issue. So this is a flag on the interaction rather than a claim about how reboot will behave.

The host-side tell, if it's useful for testing: lsusb -d 1307:0165 -v | grep bNumInterfaces reports 2 with Developer Mode off (MSC + HID) and 3 with it on (adds vendor 0xFF). Cheap post-reboot assertion for whether the channel survived.

[badicsalex]

#17 made me realize that a reboot command is kindof useless on production units, let's continue there.

[tobyjaguar]

Withdrawing my suggestion above, in light of badicsalex's explanation on #17.

I argued that a usb-debug-initiated reboot should preserve Developer Mode, on the grounds that the reboot arrives over a channel which only exists while Developer Mode is on. That reasons about the wrong layer. The constraint isn't authorising the reboot — it's that the setting lives on a volume that cannot be mounted without the user's PIN. Authenticating the reboot doesn't produce the decryption key, so there is nothing to read on the way back up.

The reboot command is still worth having for the locked-device case your internal ticket covers. Just with no expectation that the debug channel survives it: the host would get the device out of a stuck state, not back into an automatable one.