On Meta Horizon OS v2.6, Quest 3 apps in Shared Mode occasionally get stuck on the system loading screen (three animating dots) during cold launch. Despite the app running normally underneath with 72 FPS, proper XR session state progression, receiving controller input and audio, and submitting frames, the layers are never presented. The issue is caused by a race condition in the vr runtime service foreground app handshake, specifically with OnForegroundVrAppClient initially firing with pid 0 before compositor client registration. This results in InterstitialManager being stuck with pid 0 and renderingEnabled 0, preventing interstitial teardown. The issue reproduces across multiple apps with different Unity versions and Android entry points, but resume launches succeed as they receive a real pid immediately.
The Meta Quest 3 headset fails to establish a PCVR connection via Link after updating to version 2.6. Despite the Meta Quest Developer Hub recognizing the connected headset, the device gets stuck on the connection screen and cannot transition to PCVR mode. The physical connection is successfully established and detected, but the PCVR handshake or session initialization process does not complete, thereby preventing the testing of Unity projects through Link.
The feedback requests that Quest 2 Touch controllers be supported as an optional input device on newer Quest headsets, such as Quest 3, in addition to native controllers. This would enable developers to test cross-generation controller compatibility and ensure consistent input layouts for games originally designed for Quest 2 controllers, allowing them to verify input behavior across controller generations without needing multiple headset SKUs.
On Meta Quest 3S, approximately 50% of cold launches in Shared Mode (Quest for Business) result in the app being killed due to a shell focus-arbitration race condition. This occurs when the KioskDuiActivity overlay auto-closes via "System Defined Closure," triggering competing VisibilityRequestController requests. Specifically, TravelToHome (priority 55) takes precedence over ReturnFromImmersiveApp (priority 50), causing the app process to be killed with signal 9. Notably, subsequent launches with the same overlay/close sequence succeed without triggering TravelToHome. The race condition happens within 170ms of the panel closure event.
The Meta Quest 2 is unable to establish a PC Link connection via a USB 3.0 cable. The PC does not detect the headset, and the Quest 2 incorrectly identifies the cable as "charging only", despite the cable being capable of data transfer. The cable is also not functioning for charging. This issue suggests a USB enumeration or handshake failure between the Quest 2 and the host PC, potentially due to cable compatibility, USB port configuration, or Link software detection issues.
The MCP Tools reference documentation page for IWSDK AI is experiencing a rendering issue, resulting in garbled or duplicated text, specifically displaying "ecs_stepecs_step". This suggests a content corruption or rendering problem on the page, despite users finding the page helpful overall.
A device is not being detected in Meta Link despite being successfully recognized in Meta Developer Hub. The device connection works for Developer Hub, but it fails to enumerate or appear in Meta Link. This suggests a potential issue with Meta Link's device detection or enumeration process, which is distinct from hardware or general USB/ADB connectivity problems. The issue prevents users from utilizing Meta Link functionality.
The Unity IAP/Add-ons documentation lacks code examples for implementing a freemium model with in-app purchase to unlock full app functionality. Specifically, developers are unable to find guidance on how to offer a free limited preview version with an option to purchase the full app through the store. The documentation does not provide information on what code is required to enable this common monetization pattern, making it difficult for developers to implement it.
The Quest 3S standalone device reports support for the XR_EXT_user_presence extension but fails to deliver a negative event (XrEventDataUserPresenceChangedEXT with isUserPresent=XR_FALSE) when the HMD is removed. Specifically, when the headset is removed for 5-15 seconds, no raw false event, Unity Input System edge transition, or HMDUnmounted callback is triggered. The session remains focused, and upon remounting, the first visible content is VR without a false->true event pair. Positional tracking loss is correctly detected via OVRPlugin.positionTracked and OVRManager.TrackingLost. This issue occurs with the following configuration: Quest 3S (panther), Horizon OS build 3697600027800610, Android 14/API 34, Unity 6000.0.60f1, com.unity.xr.openxr 1.16.1, com.unity.xr.meta-openxr 2.4.0, and com.meta.xr.sdk.core 78.0.0.
The developer is requesting an API for Horizon OS on standalone Meta Quest devices to allow application-generated audio to be injected into the system microphone path or mixed with user voice input. Currently, there is no SDK or API that supports this functionality. The existing workaround of playing audio through the speaker and capturing it with the microphone results in echo, feedback, and poor quality. The proposed solution is a user-authorized virtual microphone or a controlled audio injection API. This feature is needed for various use cases, including text-to-speech accessibility, voice modification, AI voice applications, and soundboards for social VR experiences.