Crash reports
Hi guys, I have a crash report that affects just one user and always occurs in exactly the same place. Other players with the same build, same HMD are playing fine. As far as I have been able to work out the issue is related to UI Widgets but even this i am not certain of. Does anybody have any idea what's going on here and how to debug and fix it? This is the report summary and then the stack trace... oculus:native_crash:SIGSEGV:libUE4.so::FSlateRHIRenderingPolicy::BuildRenderingBuffers(sanitized)::$_21::operator()(sanitized) const Thread 10669\ #00 pc 000000000008c438 /apex/com.android.runtime/lib64/bionic/libc.so (memcpy_aarch64_simd+248) (BreakpadBuildId: 5cc6b9f35ce196db1de51b94b123688b0)\ #01 pc 0000000008abc378 libUE4.so (FSlateRHIRenderingPolicy::BuildRenderingBuffers(FRHICommandListImmediate&, FSlateBatchData&)::$_21::operator()(FRHICommandListImmediate&) const + 0x98) (BreakpadBuildId: 3e5160afb0844a0e3b5777981db217330)\ #02 pc 0000000007829a94 libUE4.so (FRHICommandListExecutor::ExecuteInner_DoExecute(FRHICommandListBase&)+168) (BreakpadBuildId: 3e5160afb0844a0e3b5777981db217330)\ #03 pc 000000000784bba8 libUE4.so (FExecuteRHIThreadTask::DoTask(ENamedThreads::Type, TRefCountPtr<FGraphEvent> const&)+164) (BreakpadBuildId: 3e5160afb0844a0e3b5777981db217330)\ #04 pc 000000000784b980 libUE4.so (TGraphTask<FExecuteRHIThreadTask>::ExecuteTask(TArray<FBaseGraphTask, TSizedDefaultAllocator<32> >&, ENamedThreads::Type)+52) (BreakpadBuildId: 3e5160afb0844a0e3b5777981db217330)\ #05 pc 0000000006e3ca18 libUE4.so (FNamedTaskThread::ProcessTasksNamedThread(int, bool)+244) (BreakpadBuildId: 3e5160afb0844a0e3b5777981db217330)\ #06 pc 0000000006e3c598 libUE4.so (FNamedTaskThread::ProcessTasksUntilQuit(int)+108) (BreakpadBuildId: 3e5160afb0844a0e3b5777981db217330)\ #07 pc 0000000007889144 libUE4.so (FRHIThread::Run()+72) (BreakpadBuildId: 3e5160afb0844a0e3b5777981db217330)\ #08 pc 0000000006eb1a6c libUE4.so (FRunnableThreadPThread::Run()+96) (BreakpadBuildId: 3e5160afb0844a0e3b5777981db217330)\ #09 pc 0000000006e3b0f0 libUE4.so (FRunnableThreadPThread::_ThreadProc(void)+68) (BreakpadBuildId: 3e5160afb0844a0e3b5777981db217330)\ #10 pc 00000000000fd0ec /apex/com.android.runtime/lib64/bionic/libc.so (pthread_start(void*) [bionic/libc/bionic/pthread_create.cpp:382 + 0x4]) (BreakpadBuildId: 5cc6b9f35ce196db1de51b94b123688b0)\ #11 pc 0000000000094fb0 /apex/com.android.runtime/lib64/bionic/libc.so (__start_thread [bionic/libc/bionic/clone.cpp:53 + 0x4]) (BreakpadBuildId: 5cc6b9f35ce196db1de51b94b123688b0) 2026 Meta28Views0likes1CommentApp Key Error
I have a few apps I'd been working on which are on my developer account which are all based off of the same project - due to this I've managed to use the same app key across a few projects (silly, I know). Would this potentially be causing a problem I have with achievements / leaderboards? One of the apps works fine, however another app doesn't seem to register any achievements or leaderboards. If so, is it easy to change the app key over? Unfortunately the one I'm having issues with is the one that I'm actually looking to release! For reference I'm using a slightly modified 4.27 Oculus UE Build.45Views0likes1CommentQuest 3 v203 forces 6DoF Headset Tracking when launching an app, but I need to use 3DoF
Hi everyone, I am developing a UE5 application for Meta Quest 3. My use case requires the headset to work in 3DoF , I need to disable Headset Tracking / motion tracking in the Quest system settings, because the application is used in a moving environment where 6DoF positional tracking is not stable. However, on the latest Quest system version v203, when I disable Headset Tracking and then launch my app, the system shows a prompt asking me to enable Headset Tracking / 6DoF. If I choose not to enable it, the application closes and cannot continue. I have already tried adding the following to the final AndroidManifest.xml: <uses-feature android:name="android.hardware.vr.headtracking" android:required="false" android:version="1" /> I confirmed that this entry exists in the final APK Manifest, but the Quest system still forces me to enable Headset Tracking when launching the app. My questions are: 1. Is there an official way in Unreal Engine / Meta XR to allow a Quest app to launch when Headset Tracking is disabled? 2. Is there an Unreal equivalent of Unity’s “Allow Optional 3DoF Head Tracking” setting? 3. Is this forced 6DoF prompt a system-level behavior in the latest Quest v203 firmware? 4. Can an app disable or bypass this prompt, or is it impossible from the application side? My target device is Meta Quest 3, running the latest system version v203. Any official guidance or workaround would be appreciated. Thank you.45Views0likes1Comment[UE5.6 / Quest 3] CONTEXTUAL_BOUNDARYLESS_APP breaks app launch — how to disable Guardian?
Hi everyone, I'm developing a VR app for a museum/art exhibition using Unreal Engine 5.6, targeting Meta Quest 3. The experience is fully passive (no controllers, no room-scale movement), so I need to completely suppress the Guardian boundary system. What I tried: Following the suggestion in this thread (https://communityforums.atmeta.com/discussions/dev-unreal/disable-guardian-at-runtime-in-mixed-reality-apps-unreal/1186665), I added this flag to my AndroidManifest via ManifestRequirementsOverride.txt: <uses-feature android:name="com.oculus.feature.CONTEXTUAL_BOUNDARYLESS_APP" android:required="true" /> Results: -Quest 2 + UE5.0 → works perfectly, Guardian suppressed -Quest 3 + UE5.6 → app gets stuck on Unreal splash screen and never launches Without this manifest flag the app runs fine on Quest 3. As soon as I add it, it freezes on splash. I also tried enabling the boundaryless/passthrough options inside the Meta XR Plugin settings in UE5.6. The headset shows the message "Boundary may be inactive in this app", which sounds promising — but then immediately after, it prompts the user to set up a stationary boundary anyway, completely defeating the purpose. Questions: Is `CONTEXTUAL_BOUNDARYLESS_APP` deprecated on Quest 3? Is there a replacement flag? Has anyone successfully suppressed Guardian on Quest 3 with a recent UE5 version? Any help appreciated, Thanks.37Views0likes1Comment[UE5.6 / Quest 3] CONTEXTUAL_BOUNDARYLESS_APP breaks app launch — how to disable Guardian?
Hi, I'm working on a VR app for a museum exhibition with Unreal Engine 5.6 on Quest 3. The experience is passive, no controllers needed, so I'm trying to disable Guardian completely. I found that adding CONTEXTUAL_BOUNDARYLESS_APP to the manifest worked fine on Quest 2 with UE5.0, but on Quest 3 the app just freezes on the Unreal splash screen and never starts. If I remove that line everything works again. I also tried the boundaryless settings inside the Meta XR Plugin. The headset shows "Boundary may be inactive in this app" but then immediately asks the user to set up a stationary boundary anyway. Has anyone managed to fully suppress Guardian on Quest 3 with UE5.6? Is that manifest flag deprecated on Quest 3? Any alternative approach via Blueprint or C++? Thanks!29Views0likes1CommentMetaXRInteraction missing Ray visuals for ISDKControllers, but ISDKHands working as intended.
I recently upgraded to the version 1.81.0 of MetaXRInteraction on the Oculus Unreal engine fork. Version 5.6.1 And the controller components don't have ray visuals when interacting with menus. The functionality works, I can click, and elements change when hovered, but it's hard to aim. What's weird, is that the ISDKHand components, do have proper ray visuals. (Expect for the right reticle not getting blue when pinching) I am not sure what is broken, or how to get this working. All parameters are defaults. And I only turn off/on the Ray and Grab components (for both ISDK Hands and ISDK Controllers) when the user selects a hand preference in settings using the Set Active function. Video demonstrating the issue. https://drive.google.com/file/d/1GZB-dCXpaxryZP92I9jXAnZO34Lg9WHP/view?usp=sharing Thanks!122Views0likes3CommentsMeta Interaction SDK Version Mismatch in UE 5.7.4 (Requires MetaXR 1.233.0 but found 1.201.0)
I am currently working on a VR project using Unreal Engine 5.7.4 and am running into a version mismatch error between the Meta Interaction SDK and the Meta XR Plugin. The Issue: Upon launching the editor, I receive the following warning: “Meta Interaction SDK version '1.201.0' (v201) requires MetaXR Version '1.233.0' (v201) but found '1.201.0' (v169). Mismatched versions may result in unexpected behavior.” Current Setup: Engine Version: Unreal Engine 5.7.4 (Epic Games Launcher) Meta Interaction SDK: Version 1.201.0 Meta XR Plugin: Version 1.201.0 (reported as v169 by the engine/plugin) Despite both plugins showing as Version 1.201.0 in the Unreal Engine Plugins window, the Interaction SDK specifically requests Version 1.233.0 of the Meta XR plugin to maintain compatibility. Troubleshooting Steps Taken: Verified that both plugins are enabled in the Installed > Virtual Reality section. Updated DefaultBuildSettings to BuildSettingsVersion.V6 and IncludeOrderVersion to EngineIncludeOrderVersion.Latest in my .Target.cs files to ensure they align with UE 5.7 requirements. Attempted to find a standalone download for Meta XR 1.233.0, but the current Meta developer downloads page appears to package them differently. Any help or guidance on how to resolve this version discrepancy so I can utilize the Interaction SDK features safely would be greatly appreciated. Thank you!167Views1like1Comment[New navigator update] No app icon and name
Hi! My Quest 3 recently updated itself to newer OS with reworked navigator. The issue is, that the exact same app (literally the same .apk file) now shows default icon and no name in the taskbar. Previously there was a logo and correct name. FYI this is fully proprietary, in-house only app. It isn't on marketplace nor it ever will be as it's our internal tool. It's just bad UX for us so I want to fix that. Also it never shows on the installed apps list, only in hidden "Untrusted sources" - can I overcome that without using marketplace? I use UE5, and those are values i set (that worked perfectly fine before but after the update they don't) DefaultEngine.ini PackageName ApplicationDisplayName VersionDisplayName DefaultGame.ini ProjectID ProjectName Description CompanyName I would like to kindly ask for you support on this matter. Best regards!130Views2likes1CommentUpdated Meta Horizon Link app to 85.0.0.239.552 and now USB Link breaks within a min or so.
Everything was working fine for months but after updating to 85.0.0.239.552, my USB link is broken. After a min or so, the video craps out. Images below, video attached. This is not while playing games or dev'ing in Unreal or Unity. This is simply connecting my headset and going into PC link via USB-C cable. I simply go into PC link, wait about a min, and it craps out. After this happens, I can exit out of Link. When I disconnect and reconnect the USB cable, the headset registers the connect and pops up the USB debug window. But if I go to Quick Settings, the Link button says no PC is connected. Link functionality is broken. The ONLY way to reset Link is to restart the headset. Then I can go back into PC Link, wait a min or so, and then it craps out again. This has completely stopped all development on my project.431Views3likes5CommentsConflicting Information in the Horizon OS SBC (Shader Binary Cache) Documentation?
In the documentation regarding building a shader binary cache per-platform (link) the documentation states: Using this feature, once one user starts the app and manually builds the SBC, all other users with the same device and software (Horizon OS, graphics driver, and app) will be able to avoid the shader generation process by downloading a copy of a pre-computed SBC. However, later on the same page, it states there is an automation in place to launch the apps and perform scripted prewarming logic if requested. The system automatically identifies and processes Oculus OS builds and app versions that require shader cache assets. It generates and uploads these assets to the store backend and automatically installs them during an app install or update. Does this feature support both of those setups? If I am not scripting any custom warmup logic, will shader binary caches still be shared between users with identical setups? IE, if I simply play the release candidate on the target OS version/hardware, will my SBC be automatically uploaded, or are SBCs only distributed when a scripted warmup sequence is present? Few details are provided regarding SBCs from other users being uploaded, so I'm curious if this is an inaccuracy or not. Thanks, excited to see features like this in Horizon OS. Very important for first time user experience.69Views0likes1Comment