meta-wearables-dat-android

### Environment MWDAT SDK: 0.7 Device: Samsung Galaxy S23, Android 14 ### Brief Camera feed (from MWDAT API) and microphone feed (using BT) dont work well together. ### Description When activating HFP/SCO ( + persistent ) alongside an active MWDAT camera stream, the session drops every few minutes with: Stream error: CRITICAL_STREAM_ERROR DeviceSession error: SESSION_ENDED_BY_DEVICE The session reconnects but the error recurs. Camera-only works fine; the issue only appears when the mic is active simultaneously. Please refer to #130 for further description about the issue.

Environment SDK version: 0.7.0 (AARs: mwdat-core, mwdat-camera, mwdat-display) Device: Meta Ray-Ban Display glasses (developer mode enabled) App package: com.scentvault.app Application ID: 1511527103955249 Companion phone: Android (Samsung Galaxy S25 Ultra) Meta AI app: up to date Glasses firmware: current Problem never fires. After succeeds, the display stays permanently in state. The session itself is healthy — fires correctly, camera and other capabilities work, and returns successfully. Only the display state transition from → never occurs. What we've tried Added and to as documented Tried immediately after and during state — both fail silently (consistent with docs that is only valid in ) Unregister → re-register cycle via the SDK Tried voice commands ("Hey Meta, open ScentVault") — confirmed this is not the correct invocation path for DAT display apps Registered app in Wearables Developer Center, created release channel, published version to alpha channel Confirmed DAT Wearables App and Meta AI app are up to date on glasses Suspected cause Based on issues #115 and #116, this appears to be a server-side authorization issue where the glasses-side list does not include our Application ID, so remains and the display session is never authorized on the device side. Request As seen in issue #99, some developers have been unblocked by a manual server-side authorization push from the Meta team. Requesting the same for Application ID 1511527103955249 on our registered glasses/device. Happy to provide any additional diagnostic info (device serial, logs, etc.) if needed. References: #99, #115, #116

Environment mwdat SDK: 0.7.0 (mwdat-core + mwdat-camera) — camera only (uses addStream; does not use the Display capability) Glasses: Ray-Ban Meta (camera-only), firmware 125.1 (release build 125.0.0.253.402) Meta AI app: 278.0.0.16.167 Registration: release channel, production APPLICATION_ID / CLIENT_TOKEN (registered in Wearables Developer Center) Trigger: only the DAM_ENABLED manifest value differs between the two runs — explicitly true vs explicitly false. Everything else (code, device, channel, credentials) is identical. Steps to reproduce 1. Start a camera stream (createSession → session.start() → addStream(VideoQuality.MEDIUM, 24fps)). Streaming works. 2. Fold the glasses during streaming → BT socket severed (bt socket closed, read return: -1). 3. Unfold / wear the glasses again, wait a few seconds. 4. Retry the stream (createSession → addStream). Actual — DAM_ENABLED=true: Never recovers. BT transport reconnects but the socket is never opened: Device linkState stays DISCONNECTED (the device remains in Wearables.devices), createSession() → NO_ELIGIBLE_DEVICE. App restart required. Recovers — DAM_ENABLED=false (same hardware / channel / credentials): Stream resumes after the app retries (no process restart). Questions 1. For a camera-only app on a non-Display device (Ray-Ban Meta), is DAM (DAM_ENABLED=true) expected to prevent link-lease re-acquisition after a transport severance (fold)? 2. In the DAM flow, is there a supported way to recover in-app (without process restart) after such a severance — e.g. an API to re-acquire the link lease? 3. Is DAM_ENABLED=false a supported long-term choice for camera-only apps? (Concern: in 0.8+, a missing key defaults to true, so this would silently regress on SDK upgrade.)