The button your glasses app doesn't own: Meta's capture-button privacy gesture

Build a camera app for Meta's smart glasses and sooner or later a capture just… fails. The stream was fine a second ago. Your code didn't change. What changed is that the person wearing the glasses touched the right temple.

That touch surface — the capture button — is a control your app doesn't own and can't override. This post is about what it actually does, why Meta built it that way, and what it took to make a firmware-enforced hardware gesture something you can test from a browser tab.

Two gestures, enforced below your app

On the wearer's side it's simple: tap the right temple to pause the camera (tap again to resume), hold it to stop capturing entirely. The privacy LED on the frame tracks the truth — lit while the camera is live, dark the moment it isn't — so the people around the wearer always know.

On the developer's side, it's stricter than it looks:

• Meta's Device Access Toolkit tells you the stream state (PAUSED), but ships no pause and no resume you can call. The state is observable, never writable.
• We probed the internal resume path on real hardware anyway, twice. Both times the glasses refused: the firmware ended the session rather than let software un-pause a camera the wearer had paused. This isn't a missing API — it's a boundary.
• Trying to be clever is punished. Tearing the stream down and rebuilding it to force a resume drops the whole connection, and doing it in the seconds after a pause can wedge the glasses for twenty.

We think this is the right call by Meta. A camera you wear on your face needs a physical, software-proof off switch — and bystanders need the LED to mean something. Any SDK for these devices has to treat that as a feature to embrace, not a limitation to paper over.

What "embracing it" looks like in an SDK

So the Extentos SDK models the gesture honestly, end to end:

• A capture attempted while paused returns a typed error — CaptureError.StreamPaused — whose message is already the right thing to tell your user: "The camera is paused. Tap the right temple of your glasses to resume the camera, then try again." Voice-assistant tools funnel that message straight to the model, so the assistant literally tells the wearer to tap their glasses.
• A pause mid-stream isn't an error at all. Live frames halt (your preview freezes) and resume on the next tap. A recording keeps rolling but captures no footage while paused — the final clip splices seamlessly across the gap, exactly what the hardware produces.
• A hold stops the session. Nothing the wearer does brings your stream back — your app re-arms it with its next camera use, riding the SDK's automatic recovery.

No workarounds, no reflection tricks, no teardown-and-pray. The wearer's finger wins; your app responds gracefully.

The button isn't the only authority

Months of hardware runs later, chasing what looked like a random mid-stream death, we learned the firmware holds one more opinion about your camera stream: it won't let one live forever.

Leave a stream armed and the glasses end the entire device session themselves, right around the five-minute mark. In three separate runs across two days it landed at 303.9, 304.1 and 304.2 seconds after frames started flowing — so repeatable that in the last run we posted the predicted kill time five minutes in advance, and the log line landed within one second of it. Heat rides the same window on a curve nearly as repeatable: the glasses' thermal state (visible in logcat) steps up around the two-minute mark — that's when the wearer's phone shows Meta's own overheating notice — and again around 3:20. The hotter the glasses when the cut lands, the rougher the exit: our one pre-heated run also took the Bluetooth link down for a couple of minutes, where cool runs ended the session and nothing else.

And no — an app can't dodge this by tidying up its own stream early. We have many runs' worth of scar tissue here: closing the stream from software is the same "trying to be clever" path from above, with the same punishments. On these glasses, the reliable ways a stream pauses or closes are the wearer's two gestures — and the platform's own clock and thermostat. The stream's lifetime simply isn't yours.

So the SDK treats the five-minute cut exactly like a hold on the temple: the session ends with the same SESSION_ENDED_BY_DEVICE your hold-handling already covers, and the next camera call re-arms everything automatically — a couple of seconds end-to-end, no app restart, verified in-process on hardware. Same posture as the button: observe, respond, recover. Never assume a stream you armed six minutes ago is still there.

Making a hardware gesture testable in a browser

The uncomfortable part: if this only manifests on physical glasses, most developers meet it for the first time in production, on a user's face.

So the Extentos simulator grew the whole mechanism. The simulator runs the same SDK code as real hardware with only the transport swapped — so when we gave the browser a capture button, the paused behavior came from the same shared gate that runs on the glasses. The sim page now shows the glasses with a marker on the right temple: tap it, and your app — running in an emulator, connected over a WebSocket — gets the identical StreamPaused error, byte for byte. Hold it and the stream stops. The capture LED in the sim tracks the privacy light. A recording paused mid-clip skips footage precisely the way the hardware does (we verified the sim's clip against a stopwatch: an eight-second take with a three-second pause delivers a four-second clip).

Agents get the same power headlessly: an MCP tool presses the button, so an AI coding agent can pause your camera mid-test and assert that your app says the right thing — before you ever put the glasses on.

The takeaway

If you're building for camera-equipped smart glasses, budget for this early: the wearer can pause or kill your camera stream at any moment, and that path deserves the same polish as your happy path. The full developer treatment — every signal your app observes, handling patterns, and the simulator workflow — lives in the capture button guide.