RFD 1082: A companion APK relays face weights past Chrome’s own gap
Problem
Chrome on Android XR does not grant WebXR’s expression-tracking feature, so XRFrame.expressions never reaches the web app inside an immersive session, and a VRM avatar’s face cannot follow the user’s own face in AR or VR through Chrome alone. This gap is specific to Android XR’s own Chrome build; a headset whose browser grants expression-tracking needs no bridge at all.
Decision
A companion APK, com.weftspun.xrfacebridge, runs native face tracking (Jetpack XR, with OpenXR’s XR_ANDROID_face_tracking as a parallel path per RFD 1096), then POSTs face JSON to the dev PC over LAN while the user is inside Chrome WebXR. Chrome loads this project’s own URL with ?nativeFaceRelay=1, and applies the relayed weights through the same code path native WebView injection already uses. This is a development-time workflow; production would need real WebXR expressions, a hosted relay, or a native immersive host instead.
See DETAILS.md for the end-to-end data flow, the implementation status table, the platform constraints, and the test steps.