Event-Based Push Notifications Not Being Received on Mobile Devices
We are experiencing inconsistent delivery of push notifications to mobile devices through the Meta Horizon app. We created an event-based push notification and it has already been approved. The notification is configured to launch a specific destination within the app when tapped. After it got approved, we used the request ID to trigger the push notification from our server to our active users, the response shows "success": true, but the delivery appears unreliable. Occasionally, the notification is successfully received on our test user account, but in most cases no push notification is delivered. The request itself appears to complete successfully, so there is no obvious indication of failure from the API response. To isolate the issue, we tested with a single test user account and manually triggered the requests multiple times. The behavior remains inconsistent—sometimes the push notification arrives, but most of the time it does not. We would like to understand: Are there any rate limits or throttling rules for sending push notifications through the Meta servers? Is there a limit on the number of users per request or the frequency of requests? Are there any recommended retry mechanisms or delivery guarantees we should implement? Are there any logs or diagnostics available to verify whether the notification was accepted and processed by Meta’s push service? Any guidance on troubleshooting or best practices for reliable push notification delivery would be greatly appreciated.
Quest 3 Constant Restart Loop, Need full OTA firmware
Hello I have a quest 3 sistem which I use constantly, it started failing and went into a constant restart loop, and the factory reset does not work, The bootloader works and the ADB sideload works, recovery is possible but I need the Full OTA Firmware to fix it. I need to find where to download it. Thank you
USB: Input-Only Microphone Should Not Mute Built-in Speakers, Technical Analysis & Proposed Fix
When any USB-C audio device is connected to Quest 3 — even an input-only microphone with no speaker/DAC capability — Meta Horizon OS routes ALL audio (both input AND output) to the USB-C port and mutes the built-in headset speakers. This contradicts standard Android AOSP behavior and blocks legitimate professional use cases. The Problem Many professional VR applications need external microphone input (for speech recognition, recording, or communication) while maintaining audio output through the built-in speakers. Examples include therapeutic VR, education, accessibility, content creation, live streaming, and enterprise training. We purchased a USB-C gooseneck microphone that is input-only (no speaker, no DAC, isSink=false). On standard Android devices, connecting this mic only affects audio input — speakers continue working. On Quest 3, the built-in speakers are immediately muted, even though the USB device has zero output capability. What We've Tried (Everything Fails) 1. usb_audio_automatic_routing_disabled=1 (ADB): Does not selectively disable routing — prevents the USB device from registering with AudioService entirely (UsbAlsaManager.selectAlsaDevice() returns early), so setPreferredDevice() cannot find the mic at all. 2. AudioManager.setCommunicationDevice(builtInSpeaker) (API 31+): Only affects USAGE_VOICE_COMMUNICATION streams, not media/game audio. Unity uses FMOD → AAudio (native C layer), which routes through USAGE_GAME — unaffected. 3. AudioTrack.setPreferredDevice(builtInSpeaker): Would require intercepting the engine's internal audio output at the native layer — not feasible, and Quest 3's audio HAL may override it anyway. 4. "External Microphone" toggle (Settings > Advanced, v64+): Enables USB mic recognition only. Does NOT provide split input/output routing. 5. Input-only USB mic (isSource=true, isSink=false): Expected AOSP-compliant behavior (only input rerouted). Built-in speakers are still muted. Root Cause Analysis — AOSP vs. Meta Horizon OS In upstream AOSP, UsbAlsaManager.java checks actual device capabilities via USB Audio Class descriptors: // AOSP: frameworks/base/services/usb/java/com/android/server/usb/UsbAlsaManager.java private void selectAlsaDevice(UsbAlsaDevice alsaDevice) { UsbDescriptorParser parser = alsaDevice.getParser(); if (parser.hasOutput()) { // Only register OUTPUT if USB device has playback capability alsaDevice.startOutput(); } if (parser.hasInput()) { // Only register INPUT if USB device has capture capability alsaDevice.startInput(); } } The AOSP AudioPolicyManager then only reroutes streams matching registered capabilities. An input-only device never triggers checkOutputsForDevice(), so speakers remain active. Meta's Horizon OS overrides this separation. The most likely cause: // Probable Meta override (simplified): void AudioPolicyManager::onNewUsbDevice(audio_devices_t device) { // Does not check if device has output capability setDeviceConnectionState(AUDIO_DEVICE_OUT_SPEAKER, AUDIO_POLICY_DEVICE_STATE_UNAVAILABLE); setDeviceConnectionState(AUDIO_DEVICE_OUT_USB_DEVICE, AUDIO_POLICY_DEVICE_STATE_AVAILABLE); } Proposed Fix Check the USB device's Audio Class descriptors before modifying output routing: void AudioPolicyManager::onNewUsbDevice(const sp<UsbAlsaDevice>& device) { if (device->hasCapture()) { setDeviceConnectionState(AUDIO_DEVICE_IN_USB_DEVICE, AUDIO_POLICY_DEVICE_STATE_AVAILABLE); } if (device->hasPlayback()) { // Route output to USB ONLY if device has output capability setDeviceConnectionState(AUDIO_DEVICE_OUT_USB_DEVICE, AUDIO_POLICY_DEVICE_STATE_AVAILABLE); } // If !hasPlayback(): leave built-in speaker routing UNCHANGED } This is a single conditional check in the audio policy layer. It requires zero UI changes and simply aligns Quest 3 with upstream AOSP behavior. Additional Solutions (If a Broader Fix is Planned) - User-facing setting: Add "Audio Output" under Settings > Sound with options "Headset Speakers" / "USB-C" / "Automatic", independent of input routing. - Developer API: Allow applications to call setPreferredDevice() with routing respected for all audio usages (not just USAGE_VOICE_COMMUNICATION). Impact The Quest 3 hardware is fully capable — speakers and USB operate on independent audio paths. This is purely a software routing policy that could be resolved with a minimal code change. The fix would unblock every developer building applications that need external audio input while maintaining speaker output. Happy to provide dumpsys audio output or USB device descriptors to help diagnose the exact policy override. Related: A similar request was posted on the archived forum: "Request for Enhanced Audio Routing Controls with External Microphones on Meta Quest" (jrb-vr, October 2024) — which received no response.Stuck in Verification Loop - Cannot Create App for WhatsApp API
Hello, I am stuck in a verification loop when trying to create a new app for the WhatsApp Business API. My Goal: To create a "Business" type app to integrate with the WhatsApp Business Platform. The Problem: Every time I click "Create App" on the developers.facebook.com dashboard, I am redirected to the "Verify Your Account" page (see attached screenshot), even though my account is already fully verified. What I have already done: My account has 2-Factor Authentication (2FA) enabled. My phone number is fully verified in the main Meta Accounts Center. I have tried this in multiple browsers (Chrome, Firefox) and in InPrivate/Incognito mode. The verification for my credit card also fails. I was able to successfully create a developer organization ("Umiya Agro Digital") through the Meta Quest developer dashboard (developer.oculus.com), so my account is recognized as a developer account on that new system. However, the developers.facebook.com platform does not recognize this and keeps forcing me into this broken registration flow. I cannot proceed. Please advise.
Quest System Keyboard Input Box is gone on the new GameActivity entry point Unity 6
Hello, We are encountering a significant issue with system keyboard on Meta Quest builds using Unity 6. The Problem Forced Entry Point: Unity 6 now defaults to the GameActivity application entry point. When we attempt to use the older Activity entry point (required for the previous keyboard system), the application crashes on startup, forcing us to use GameActivity. Missing Input Box: The GameActivity entry point uses the GameActivity Jetpack library, which has removed the on-screen input box that traditionally appears above the system keyboard. For mobile apps, this is a clean design, but in Meta Quest VR, this causes a major UX problem. The UX Issue on Meta Quest Since the Quest system keyboard is visually separate and detached from the in-game UI, users lose all visual confirmation of what they are typing. The visible input box on the system keyboard is necessary in VR to show the user the text they are actively entering. The Constraint Migrating our entire project to a custom virtual keyboard is not feasible due to the complexity of supporting multiple languages and character sets. Our Question Is there an official or known way to restore the input box feature on the system keyboard, as it existed with the old "Activity" entry point, while still using the required GameActivity in Unity 6? Any guidance on modifying the GameActivity bridge or another low-level fix would be greatly appreciated. Thank you!
DistanceGrabUseInteractable?
Hi, This is definitely a pretty basic question relating to the Meta Interaction SDK for Unity. I've managed to get a HandGrabUseInteractable linked to a HandGrabinteractable via a SecondaryInteractionFilter. However, I also have a DistanceHandGrabInteractable on that object, linked to its own HandGrabUseInteractable linked to the same delegate as the first. When I grab the object without distance grab, my script calls BeginUse, EndUse, and ComputeUseStrength properly. When I grab with distance, it does not, as far as I can tell - I am working on Mac and the simulator was not working with this scenario at all, so I have to port the APK to my quest each time I want to test. That takes away a bit of my debugging capabilities. I thought perhaps this was an issue with having multiple HandGrabUseInteractables, but when I removed the duplicate and made the object only have DistanceHandGrabInteractable and one HandGrabUseInteractable, it still did not work. I also wondered if perhaps HandGrabUseInteractable only supports the HandGrabInteractable, and not other HandGrabInteractables? But peeking at the package code and reading the SecondaryInteractionFilter docs seemed to suggest either HandGrabInteractable or DistanceHandGrabInteractable should work, so long as all references are piped correctly. What am I doing wrong? How can I link my DistanceHandGrabInteractable to a HandGrabUseInteractable? Will I need to make my own DistanceGrabUseInteractable script, perhaps using the existing HandGrabUseInteractable as a base? Thanks for the help
Accessibility Feature Request: Conversation Focus Mode for Ray-Ban Meta Display Glasses
Hi everyone! I’m a Ray-Ban Meta display glasses user who is hard of hearing and wears hearing aids daily. I’d love to see a conversation focus mode added that prioritizes voices directly in front of the wearer and reduces background noise. In busy environments, this would make a big difference for hearing-aid users and others who rely on clearer speech in real time. If this type of accessibility feature is ever developed, I would absolutely love the ability to have it added to my glasses and would be happy to provide feedback or participate in any beta or user-testing opportunities. I’ve also submitted this through support channels, but wanted to share here in case the team is gathering feedback.
