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.

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.