Initialize the Android SDK

You create one ExtentosGlasses instance and hold it for the life of your app's glasses session. There is no required Application subclass and no static singleton to register — you call a factory and keep the handle.

Create the instance

import com.extentos.glasses.core.ExtentosGlasses
import com.extentos.glasses.core.ExtentosConfig
import com.extentos.glasses.core.ExtentosEnvironment

val glasses = ExtentosGlasses.create(
    ExtentosConfig(
        applicationContext = applicationContext,
        environment = if (BuildConfig.DEBUG) {
            ExtentosEnvironment.DEVELOPMENT
        } else {
            ExtentosEnvironment.PRODUCTION
        },
    )
)

ExtentosGlasses.create(config: ExtentosConfig = ExtentosConfig()): ExtentosGlasses is the only entry point — the constructor is internal, so always go through create(). Calling it with no argument (ExtentosGlasses.create()) is valid and uses all defaults.

A natural home for the handle is a ViewModel or a small holder scoped to your app's lifetime; create it once and reuse it. When you're done, call glasses.shutdown() (a suspend function) — see Lifecycle.

ExtentosConfig

Every field is defaulted, so the config is as small as you need it.

Set environment = PRODUCTION for production builds. It defaults to DEVELOPMENT so that installDebug builds never pollute production analytics. If you ship a release build still on DEVELOPMENT, its events land in the dev backend, not your production bucket. The BuildConfig.DEBUG pattern above is the canonical way to wire it. (As a safety net the SDK also reconciles the declared environment against an on-device classifier and downgrades a mismatched PRODUCTION debug build with a warning — but declare it correctly rather than relying on that.)

Transport choice

sealed interface TransportChoice {
    data object Auto : TransportChoice          // default — resolves at runtime
    data object SystemAudio : TransportChoice    // mic + speaker over OS Bluetooth; no vendor SDK
    data object RealMeta : TransportChoice       // force real glasses via Meta DAT
    sealed interface Simulated : TransportChoice {
        data object Local : Simulated            // in-process mock, no network
        data class Browser(val url: String? = null) : Simulated  // browser simulator
    }
}

Auto is almost always right. In order: the browser simulator when a session URL is baked in or set in the environment; then real glasses when a vendor module claims a bonded device; then — only when you set ExtentosConfig.debug = true, which is a config field defaulting to false, not your BuildConfig.DEBUG build type — the dev pairing screen; and otherwise SystemAudio, mic and speaker over whatever the OS has routed, which keeps a voice app working with no vendor SDK at all. A vendor claim beats the pairing screen, so a debug build with bonded glasses still goes to hardware. See Runtime internals for the full resolution order and its caveats.

Reading which transport you got

ExtentosGlasses exposes the resolution outcome directly — useful after an upgrade, or to confirm a release build reached real hardware rather than the audio baseline:

Log.i("app", "transport=${glasses.transportChosen} (${glasses.selectionSource})")

A camera app that reads SYSTEM_AUDIO here got there for one of three reasons: com.extentos:glasses-meta isn't on the classpath, no Meta glasses are bonded to the phone, or BLUETOOTH_CONNECT wasn't granted before create(...). Check them in that order.

The sub-client surface

ExtentosGlasses exposes typed sub-clients as properties. You call capabilities through them:

val photo = glasses.camera.capturePhoto()
glasses.audio.transcriptions().collect { transcript -> /* ... */ }

Handle results with ExtentosResult

Lifecycle and capability operations return ExtentosResult<S, F> instead of throwing. It is a sealed interface with two cases:

import com.extentos.glasses.core.ExtentosResult

when (val r = glasses.camera.capturePhoto()) {
    is ExtentosResult.Ok  -> usePhoto(r.value)
    is ExtentosResult.Err -> handleFailure(r.error)
}

The failure side carries concrete, per-operation variants — capturePhoto() / captureVideo() return a CaptureError (NotConnected, PermissionDenied, ThermalCritical, HingesClosed, CoexistenceBlocked, StreamPaused, DisabledByUser, PlatformError — all eight, or your when won't be exhaustive); connect() returns a ConnectError (NoDeviceAvailable, PermissionDenied, PairingFailed, RegistrationRequired, TransportFailure); recordDiscrete() / speak() return an AudioError. See Errors for the full set.

Do not wrap these in runCatching. They never throw, so runCatching would only catch unrelated exceptions and silently hide the typed failure. Pattern-match the result instead.

Helpers if you don't want a full when:

val value = glasses.camera.capturePhoto().valueOrNull()   // S? — null on failure
val error = result.errorOrNull()                          // F? — null on success
val mapped = result.map { it.uri }                        // transform the success
val chained = result.flatMap { upload(it) }               // chain another result

Next: Lifecycle covers shutdown, the foreground service, and process death; Threading covers the coroutine/Flow model.

Related