HTC VIVE Eagle (preview)

HTC VIVE Eagle is the fourth vendor Extentos targets, and it is the one where the vendor ships a simulator. HTC's ViveGlassSimulator implements the very same ViveGlassClient interface as the real kit, so the Extentos transport is driven end to end by HTC's own binary with only the substrate simulated. That is a stronger position than a vendor with no hardware to buy and no emulator to stand in for it — and it is still not hardware verification.

This page is the honest status: what runs, what has never run, and the two things HTC controls that no amount of code on our side can resolve.

TL;DR

• Built and simulator-proven on Android: connect, photo, video frames, a muxed MP4 clip, the microphone stream, transcription and speech — 8/8 against HTC's own simulator binary.
• Publishes as com.extentos:glasses-htc — the module and its publishing config are done, and the artifact goes to Maven Central with the next release cut, alongside the rest of the SDK. It is our transport code only: HTC's SDK is not inside it and never will be, because HTC publishes no licence permitting redistribution, so you install theirs from HTC.
• Never run on hardware. Eagle was Asia-only until HTC announced US availability from September 2026, so nobody on our side could buy one.
• HTC must register your app. There is no self-serve route, and an unregistered app does not error — it silently fails to connect. Extentos turns that silence into a typed ConnectError.RegistrationRequired.
• Both platforms are simulator-proven — 8/8 against HTC's own simulator on each. iOS ships as a separate swift-glasses-htc package so existing swift-glasses consumers are untouched, and that isolation is verified: swift-glasses still builds with no HTC framework present anywhere.
• Testable today: vive_eagle is selectable in the simulator, so an app's behaviour under a second camera-and-audio vendor is verifiable now.
• Meta is unaffected. A Meta-only app never inherits any of this — HTC's binary must never reach com.extentos:glasses.

Extentos support

The same eleven rows appear on every vendor page, in the same order, so vendors can be compared directly rather than by reading differently-shaped tables. Depth specific to this vendor follows below.

Beyond the spine

Detail with no counterpart on other vendors, kept separate so the table above stays comparable.

What Eagle breaks that Meta does not

Three assumptions a Meta-shaped app makes quietly.

Failure is silent, not loud. An app HTC has not registered does not throw and does not crash — the connection simply never completes. This is the single most likely thing you will hit, and it is why the transport turns ERROR_UNREGISTER_APP into a typed ConnectError.RegistrationRequired rather than letting it read as a timeout.

Barge-in does not work. cancelSpeak is the primitive an assistant uses to stop talking when the wearer starts. HTC exposes no way to stop an utterance, so on Eagle it is a no-op. If your voice loop depends on interrupting playback, it degrades here — design the turn-taking so that waiting out a long utterance is not the only escape.

Two privacy behaviours are enforced in hardware, with no API and no reason code. The camera auto-disables when the glasses are not worn or the capture LED is covered, and connecting throws GlassesNotWornException if they are not on the wearer. Neither is something your app can detect in advance or work around; both are states to handle, not bugs to fix.

Adding it

Neither platform is scaffolded by generateConnectionModule, and that is deliberate: the steps that decide whether this works at all are HTC's to grant, not ours to generate.

Android

Three steps.

1. Install HTC's SDK into your mavenLocal. HTC ships it as a .7z containing a file-based Maven repository, from their download page — free, no sign-in, no approval. Extract it and install com.htc.viveglass.sdk:viveglass_client and :viveglass_simulator into ~/.m2/repository. There is no remote repository to point Gradle at, and we cannot mirror one for you.

2. Let Gradle see it, scoped to HTC's group alone — in settings.gradle.kts:

dependencyResolutionManagement {
    repositories {
        mavenLocal {
            content { includeGroup("com.htc.viveglass.sdk") }
        }
        google()
        mavenCentral()
    }
}

3. Add the module.

dependencies {
    implementation("com.extentos:glasses-htc:2.7.0")
}

It self-registers through androidx.startup, so adding the module is the integration. TransportChoice.Auto resolves to it once Eagle is the connected device, and your handler code does not change — the same glasses.camera.capturePhoto() and glasses.audio.transcriptions() you write for Meta.

iOS

Two steps, plus the same HTC registration.

1. Install HTC's SDK. Same archive, different half — run scripts/install-viveglass-sdk-ios.sh from the swift-glasses-htc package, which fetches HTC's .7z and stages ViveGlassKit.xcframework and ViveGlassSimulator.xcframework into Artifacts/. HTC nests .7z inside .7z on iOS, so you need a 7-Zip tool (brew install sevenzip).

2. Add the package and register it.

// Package.swift
.package(url: "https://github.com/extentos/swift-glasses-htc", from: "2.7.0"),

// in your App's init, before Extentos.create(...)
import GlassesHtc

ExtentosHtc.register()

Android's module self-registers through androidx.startup, so adding it is the integration there. iOS has no equivalent — nothing runs a library's code before the app's — so registration is one explicit call. Handler code is identical to Meta's on both platforms.

Why the module is separate

Meta's transport lives in com.extentos:glasses-meta because Meta's artifacts sit behind a credentialed repository. HTC's lives in com.extentos:glasses-htc for a sharper reason: their binary has no stated licence, so it must never become something a Meta customer inherits by depending on com.extentos:glasses. A voice-only app, or a Meta app, pulls none of it and needs nothing from HTC.

The same boundary is why the artifact we publish contains our code and not theirs.

Related