meta-dat-android-api-atlas

Maps and audits the Meta Wearables Device Access Toolkit Android API surface with pinned Maven artifacts and evidence levels.

Updated Sep 6, 2026
One-click install
npx skills add https://github.com/shotcowboystyle/meta-wearables-ops-plugin --skill meta-dat-android-api-atlas-shotcowboystyle
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: meta-dat-android-api-atlas
Source: https://github.com/shotcowboystyle/meta-wearables-ops-plugin/tree/main/.agent/skills/meta-dat-android-api-atlas
Command: npx skills add https://github.com/shotcowboystyle/meta-wearables-ops-plugin --skill meta-dat-android-api-atlas-shotcowboystyle

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Android developers integrating Meta smart glasses cannot trust that a Kotlin symbol mentioned in docs, AGENTS.md files, or samples actually exists in the resolved Maven artifact, and 0.9 migrations silently break camera, Display, and DatResult code. This Skill audits the public Meta Wearables Device Access Toolkit Android API surface against exact Gradle/Maven coordinates so implementation decisions rest on verified artifacts rather than prose. ## Core Features & Use Cases - Artifact-pinned API mapping: Verifies the four public artifact lanes (mwdat-core, mwdat-camera, mwdat-display, mwdat-mockdevice) and maps routes from Wearables.initialize through registration, sessions, Flows, and typed DatResult failures. - 0.9 migration auditing: Resolves Session/DeviceSession naming conflicts, camera addStream consolidation, Java-visible DatResult, Display builder changes, and DAM_ENABLED traps against the selected artifact. - Evidence-level separation: Keeps source, compile, mock, connected, physical, signed, release-channel, and production proof distinct so no claim overreaches its evidence. - Use Case: When asked to add camera streaming to an Android glasses app, produce an atlas row with the exact com.meta.wearable artifact version, confirmed Camera.stream signature, compile gate, phone fallback, and the physical-device evidence still required. ## Quick Start Audit the Meta DAT Android API surface for camera and Display support in my app targeting mwdat 0.9 and list confirmed symbols with their evidence levels.

Frequently Asked Questions about meta-dat-android-api-atlas

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I verify Meta Wearables DAT Android API symbols before implementing?

Resolve the exact com.meta.wearable Maven artifact versions for mwdat-core, mwdat-camera, mwdat-display, and mwdat-mockdevice, then confirm each symbol against the generated API reference for that release. Never treat AGENTS.md prose, samples, or llms.txt output as proof a Kotlin symbol compiles.

What changed in the Meta DAT Android 0.9 migration?

Key 0.9 changes include camera consolidation from addStream/removeStream to addCamera/Camera.stream/Camera.stop/removeCamera, DatResult becoming a Java-visible reference type, new Display buttonGroup and local Bitmap image paths, and removal of DisplayComponent and VideoScope. DAM is always enabled, making the DAM_ENABLED manifest key obsolete.

Does the Android DAT SDK support glasses microphone audio?

The official Android sample uses the phone's AudioRecord, which is not an observed glasses HFP microphone route. Treat glasses audio routing as a separate task requiring explicit audio profile, consent, route observation, and physical-device evidence.

Can MockDevice tests prove physical glasses functionality?

No. MockDevice provides deterministic registration, permissions, lifecycle, and phone/file media testing, but offers no radio, optics, HFP audio, thermal, or firmware proof. Keep mock evidence strictly separate from connected-device and physical evidence.

How should Gen 3 Meta glasses be mapped in the Android SDK?

Do not map Gen 3 to META_GLASSES, RAYBAN_META, Display, or any enum without a current official mapping and named runtime evidence. Mark Gen 3 entries as to-verify until an official source confirms the mapping; Gen 2 mappings require source or runtime evidence as well.