VModal Smart Glass SDK: Live Video Streaming from Android-Connected Smart Glasses

What the SDK Does and Who Needs It

Smart glasses applications face a specific media problem: the camera on a wearable device is not the same as the camera on a phone. Meta smart glasses use the Meta Device Application Toolkit (DAT) to manage the capture lifecycle, and coordinating DAT with Android MediaCodec, encoded video queuing, and a live transport protocol while also building the user experience is enough complexity to derail a product timeline.

The VModal smart glass SDK exists to own that pipeline. The host app calls into a Kotlin API; the SDK takes responsibility for everything from Meta DAT capture through H.264 encoding, MPEG-TS muxing, and SRT transport to the remote ingest endpoint. The app keeps the camera permission flow, the user interface, and the authentication logic. The SDK keeps the encoding and transport details invisible.

The target use cases listed in the README include remote expert support, hands-free field work, live training and inspection, and AR/VR companion experiences. A production streaming scenario is also listed, with the SDK providing bounded queues, backpressure signals, and typed failure modes that a field diagnostic screen or support workflow can observe. The last push was on 2026-09-13.

The Two-Layer Architecture: Kotlin Client and Rust Core

The SDK separates concerns between two components. The Kotlin client handles the public API surface, Meta DAT integration, camera coordination with Android MediaCodec, coroutine-based state management, and event propagation. The Rust media core handles the encoded-media queue, H.264 normalization, MPEG-TS muxing, SRT transport, reconnect behavior, and transport metrics.

This split is deliberate. Bounded queues and GOP-aware backpressure live in the Rust layer, which means a weak network does not cause unbounded memory growth in the Android process. The SRT reconnect logic uses configurable delays, jitter, and timeouts. When a stream target expires or is rejected, a LiveStreamTargetProvider interface can fetch a fresh destination while the app presents a single coherent stream lifecycle to the user.

From the host app's perspective, none of the JNI handles or SRT socket state is visible. The Activity interacts only with SmartGlassClient. The Rust layer is accessible through JNI but that boundary is not part of the public API.

The project builds with two Gradle flavors. The offline flavor runs lint and JVM tests without Meta artifacts or device credentials, allowing CI validation without hardware. The meta flavor targets real devices and requires the Meta Wearables DAT dependencies.

Backend Integration and Credential Boundaries

The SDK does not manage account-level streaming credentials. Instead, the design requires a backend endpoint that validates the authenticated app user and returns a short-lived LiveStreamTarget containing the SRT connection details. The app briefly holds those SRT fields to initiate the stream but should not log or persist the stream ID or passphrase.

This boundary keeps provider credentials (Cloudflare Stream keys, live platform API tokens) on the server rather than in the APK. The README states explicitly that account-level credentials should never appear in the app. The backend issues a lease; the SDK uses it.

The SmartGlassClient is designed to be instantiated exactly once per active capture owner. Running a competing camera session while SmartGlassClient is active is prohibited. The README production checklist also requires a foreground service when streaming may continue while the app is backgrounded.

The client.metrics API exposes connection health, queue pressure, and transport behavior. The README notes this is intended for a developer panel, a field diagnostic screen, or a support workflow rather than general display to end users.

Hardware and Environment Prerequisites

The SDK requires Android API level 31 or higher, JDK 17, and Android compile SDK version 36. Meta smart glasses integration requires a compatible Meta smart-glasses registration and a Meta Wearables DAT setup; the README lists this as a hard prerequisite and not something the SDK handles.

The repository includes an Android simulator example in examples/00_simulator that walks through installing an Android 14 AVD and exercising the Meta Mock Device Kit without physical glasses. This allows teams to develop and test the Kotlin integration before hardware is available.

The full SDK quickstart and build commands are documented in docs_sdk/readme.md rather than inline in the main README. The main README describes the architecture and directs developers to that document for the actual build steps and Kotlin integration walkthrough.

A note on scope: the README explicitly distinguishes this SDK from the VModal Android SDK. This package handles live camera streaming from glasses to an ingest endpoint. Video upload, indexing, and multimodal search require the separate VModal Android SDK.

Failure Modes and Cases Where This SDK Is the Wrong Choice

The SDK is built around a single transport: SRT to a live ingest endpoint. Teams that need RTMP, WebRTC, or HLS output from smart glasses will not find that here. The README makes no mention of alternative transport protocols.

The dependency on Meta DAT means the SDK is currently exclusive to Meta smart glasses. A team that needs to support multiple smart-glass hardware platforms would need to replace the Kotlin capture layer entirely; the Rust media core could theoretically be reused, but the Meta-specific parts are not abstracted into a pluggable interface based on what the README describes.

The repository has no GitHub releases and no license file. The absence of a license is a significant constraint: without an explicit grant of rights, the default copyright law applies, which means the code cannot be used, distributed, or modified without permission from the copyright holder. The README points to VModal developer resources at v-modal.com but the licensing situation is not documented in the repository.

For teams streaming from a phone camera rather than wearables, there is no advantage to this SDK over standard Android streaming libraries. The value is in the Meta DAT integration and the bounded-queue SRT transport stack, both of which are irrelevant without wearable hardware.

ExoPlayer and WebRTC as Ecosystem Alternatives

For Android live streaming without smart-glass constraints, ExoPlayer (now part of Media3) and WebRTC-based solutions are the standard alternatives. ExoPlayer handles camera capture and HLS or DASH output with a large community and extensive documentation. WebRTC provides low-latency bidirectional streaming with browser interop.

The VModal SDK occupies a narrower niche than either of those: Meta DAT capture plus SRT transport plus a bounded-queue media core. Neither ExoPlayer nor WebRTC integrates with Meta DAT, and neither ships with the GOP-aware backpressure model the VModal Rust core provides. The comparison is not about raw streaming capability but about whether the wearable-specific capture and encoding pipeline is the part you want to own.

Editorial conclusion

The VModal smart glass SDK is the right starting point for Android teams building live-streaming experiences on Meta smart glasses who want to hand the media pipeline to a library and focus on their product layer. It is the wrong fit for teams that need video upload and indexing rather than live streaming (the README explicitly redirects that use case to the separate VModal Android SDK), or for teams that need full source availability (no license file is present in the repository). Before integrating, verify that your target device supports the Meta Wearables DAT and that your backend can mint short-lived SRT stream targets, since both are hard dependencies.

Frequently asked questions

Official sources

1. Issues
2. README
3. v-modal/vmodal_sdk_smartglass on GitHub