Samsung Galaxy Glasses Are Real: What Android Developers Need to Build for the First Consumer Android XR Device

Samsung just announced Galaxy Glasses at Unpacked in London — and this one is different from the usual "coming soon" XR hardware tease. These ship this fall, they run Android XR with Gemini built in, and they're the first consumer product where everything you've been reading about in the Jetpack XR SDK has an actual device behind it. If you build Android apps and haven't thought seriously about this platform yet, today is a good day to start.

I've already covered the Jetpack XR SDK reaching beta01 with its breaking changes and Developer Preview 4 of the ARCore layer. This post is different: it's about what the Galaxy Glasses hardware actually constrains and enables, and what that means for how you think about building for this platform — especially when the 2026 device has no display.

The Hardware Story: Phone-Tethered, No Display, Gemini as the Interface

The 2026 Galaxy Glasses are audio-only. There is no display, no waveguide, no AR overlay. The UI is Gemini — it talks to you through bone-conduction speakers, it hears you through the microphones, and the 12MP camera gives it something to look at. All the actual processing runs on your paired phone. The glasses themselves run a Snapdragon AR1 class chip that's essentially a radio and sensor bus — it doesn't do inference locally.

That phone-tethered constraint is the most important developer detail. Everything your app does runs on the user's Android phone, proxied to the glasses frame via Bluetooth. The glasses aren't a compute platform; they're a sensory input/output peripheral. The comparison that makes more sense than a headset is a smartwatch with a better camera and no screen.

A second model — currently in Samsung's roadmap for 2027 — does add a micro-LED display and will be where spatial UI patterns from the Jetpack XR SDK's scene and panel APIs become genuinely relevant. For this year, though, display-era thinking doesn't apply.

One Codebase, Three Form Factors — At Runtime, Not Compile Time

Here's the thing the Android XR SDK documentation makes clear but doesn't always emphasize enough: you're not building a "glasses app" or a "headset app." You're building an Android XR app that expresses different capability tiers depending on what the runtime tells it about the connected device.

The same codebase is intended to run on:

• A full XR headset (Galaxy XR, Google's own headset when it ships)
• Display glasses — the 2027 Galaxy Glasses model, AR spatial panels, the works
• Audio-only glasses — the 2026 Galaxy Glasses, where you have camera, mics, and speakers but no display

The SDK surfaces capabilities at runtime through the session API rather than requiring you to branch in your manifest or maintain separate codepaths. You query what's available — does this device have a display? Can it render a spatial panel? Is the Gemini Live API available? — and scale your experience accordingly. On a headset you build a scene. On audio glasses you build a conversational agent that lives inside Gemini.

This is the same principle as responsive layout on Compose, just applied to an entirely different dimension of device capability. The discipline is the same: don't hardcode assumptions about the device, query the runtime, and express the appropriate experience for what's actually there.

The Actual App Model for Audio-Only Glasses: Gemini Live API

If there's no display, what does your app actually do on Galaxy Glasses? The answer is: your app provides context and capabilities that Gemini uses when the user talks to it through the glasses.

The primary integration path is the Gemini Live API, surfaced through Firebase AI Logic. Unlike a standard generate request — prompt in, text out — the Live API maintains a persistent bidirectional session that handles both audio input and output natively. You don't wire up ASR separately, you don't call TTS separately, you don't manage turn-taking. The session handles it.

// Initialize a live model via Firebase AI Logic
val firebaseAI = Firebase.ai(backend = GenerativeBackend.googleAI())
val model = firebaseAI.liveModel(
    modelName = "gemini-2.0-flash-live-001",
    generationConfig = liveGenerationConfig {
        responseModality = ResponseModality.AUDIO
    }
)

// Start a session — this is the persistent connection
val session = model.connect()

// Send audio input (from glasses mic, captured on the phone)
session.sendAudio(audioBytes)

// Receive audio output (played back through glasses speakers)
session.receiveAudio { audioChunk ->
    audioPlayer.play(audioChunk)
}

The glasses microphone captures audio and the phone processes it, sends it to Gemini via the Live API, gets audio back, and plays it through the glasses speakers. From the user's perspective they asked Gemini a question and got an answer through their glasses. From the developer's perspective they set up a LiveSession and wired the audio I/O.

FunctionDeclaration: how your app's logic surfaces to Gemini

The more interesting part is what you give Gemini to work with. The Live API supports function calling — you declare the capabilities your app exposes, Gemini calls them on the user's behalf when relevant, and the results come back into the conversation.

val searchNotes = FunctionDeclaration(
    name = "searchNotes",
    description = "Search the user's saved notes by keyword",
    parameters = Schema.obj {
        put("query", Schema.string("The search term"))
    }
)

val session = model.connect(
    requestOverride = liveConnectConfig {
        tools = listOf(Tool(functionDeclarations = listOf(searchNotes)))
    }
)

// Handle Gemini calling your function
session.receive { message ->
    message.toolCall?.functionCalls?.forEach { call ->
        if (call.name == "searchNotes") {
            val query = call.args?.get("query")?.asText()
            val results = notesRepo.search(query ?: "")
            session.sendToolResponse(call.id, results.toJson())
        }
    }
}

This is the same pattern as AppFunctions but at the session level rather than the system level. Your notes app exposes searchNotes, your navigation app exposes getDirections, your media app exposes playArtist. Gemini calls whichever one makes sense based on what the user said. The user doesn't know or care which app handled it — they just got an answer through their glasses.

The Camera: More Context, Not a Camera App

The 12MP camera on Galaxy Glasses is primarily there to give Gemini visual context, not to let users take photos (though it can do that too). Real-time translation, object identification, reading signs or menus, identifying plants or landmarks — these are all Gemini vision tasks that happen because the camera feed is available as part of the Live API session.

From a developer perspective, passing camera frames into the Live session is straightforward:

// Send a camera frame for Gemini to analyze
session.sendImage(
    imageBitmap = cameraFrame,
    mimeType = "image/jpeg"
)

// Or send inline in text with context
session.sendText(
    "What does the text in this image say?",
    inlineData = listOf(InlineData(cameraFrame, "image/jpeg"))
)

This is the same Firebase AI Logic multimodal API you'd use for a standard generate call, just running inside a live session. If you've already integrated Gemini's vision capabilities in your phone app, the glasses version is mostly a question of routing the right image source.

What Should You Actually Build — or Not Build — Right Now?

Five years building Android apps across Nodat, Musist, Samachar, and HailUp has made me pretty allergic to shipping for a platform that doesn't exist yet. Galaxy Glasses changed that calculus: they're real hardware, with real software, shipping this fall. But "build for it now" and "ship for it now" are different things.

Things worth building now

• Gemini Live API integration on your existing app. If your app has data that's useful in conversational form — notes, tasks, media playback, navigation, shopping lists — declare it as FunctionDeclarations. This benefits your phone app through assistant integration today and shows up on Galaxy Glasses automatically when the user's phone is paired.
• Audio UX for your app's core actions. Think through what your app's top 5–10 user actions would sound like as Gemini responses. "You have 3 unread high-priority notes" is different from a visual badge count. The discipline of designing for no display is useful even if you never ship a glasses-specific experience.
• AppFunctions declarations. The overlap between AppFunctions (system-level AI agent surface) and Gemini Live function calling is intentional and convergent. What you expose via @AppFunction shows up in both contexts. Do it once, get both.

Things to wait on

• Spatial UI (panels, scenes, 3D objects). The 2026 device has no display. None of the SpatialPanel, SpatialGltfModel, or scene APIs from the XR SDK do anything on this hardware. Wait for the 2027 display model before building screen-based spatial UI.
• Glasses-specific companion apps. Samsung will have a companion app. Trying to build a parallel companion before the hardware is in developer hands — with real APIs, real latency numbers, and real hardware constraints — is mostly a waste of time. Get an actual device first.
• Hardcoded audio-only assumptions. The XR platform will have display devices. Build with the capability-query pattern from the start so your code doesn't rot the moment a display device exists.

The Bigger Picture

Galaxy Glasses matter for a reason that goes beyond the device itself: they're the moment the Android XR platform stops being hypothetical. The SDK reaching beta01, the emulator improvements, the ARCore stable APIs, the Jetpack Compose for XR components — those were all preparing for a device that had no shipping date. Now it has one.

For the developer who's been watching this space: the window to get comfortable with the Gemini Live API, function calling patterns, and the XR capability model before consumer hardware ships is roughly now until fall. That's not a lot of time, but it's enough to understand the programming model, prototype something real in your app's domain, and not be starting from zero when users with Galaxy Glasses ask why your app doesn't do anything interesting on their new glasses.

The iPhone moment this isn't — audio-only AI glasses are a genuinely new interaction model that will take time to find its killer use cases. But the platform is real, the SDK is beta, the hardware is shipping, and the developers who understand it six months from now will be the ones who were playing with it six months ago. The foundation work is done. There's no excuse for not knowing how this platform works anymore.