Bug: Native crashes not reported as REASON_CRASH_NATIVE in ApplicationExitInfo
## Issue summary On Quest 2 (Horizon OS, build `UP1A.231005.007.A1`, Android 14), native app crashes are not surfaced correctly through the `ApplicationExitInfo` API. A full tombstone is written to disk by `debuggerd`, but the framework fails to associate it with the process exit, so `ApplicationExitInfo` reports the wrong reason and no trace. This breaks any crash-reporting SDK that relies on `ApplicationExitInfo.REASON_CRASH_NATIVE` + `getTraceInputStream()` (e.g. the Sentry Android SDK, and AOSP's own documented native-crash flow). ## Observed behavior `debuggerd` handles the crash and writes a valid tombstone to `/data/tombstones/`: ``` F libc : Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0 in tid 26718 (GameThread), pid 26590 F DEBUG : Diagnostic-Collection-Type: Tombstone Proto F DEBUG : pid: 26590, tid: 26718, name: GameThread >>> [redacted package name] < ``` `NativeTombstoneManager` then rejects the tombstone because of non-standard filenames: ``` W NativeTombstoneManager: unexpected tombstone name: /data/tombstones/tombstone_09.lock.pb W NativeTombstoneManager: unexpected tombstone name: /data/tombstones/tombstone_09.pb.lock.pb ``` These `.lock.pb` / `.pb.lock.pb` names do not match AOSP's expected `tombstone_NN[.pb]` pattern. (Horizon OS is creating `tombstone_NN.lock` and `tombstone_NN.pb.lock` lock files in the tombstone directory, which the manager mis-parses.) The crash is routed to a custom DropBox tag instead of the standard one, and the framework cannot determine the exit reason: ``` I DropBoxManagerService : add tag=SYSTEM_TOMBSTONE_PROTO_WITH_HEADERS I ActivityTaskManager : captureExitReasonForRootTask: unknown app exit reason, defaulting to crash ``` The resulting `ApplicationExitInfo` record is wrong: ``` dumpsys activity exit-info [redacted package name]: reason=2 (SIGNALED) subreason=0 (UNKNOWN) status=11 ... trace=null ``` It should be `reason=5 (REASON_CRASH_NATIVE)` with a non-null `getTraceInputStream()`. ## Expected behavior A native crash (SIGSEGV) that produces a tombstone should be recorded in `ApplicationExitInfo` as `REASON_CRASH_NATIVE` with the tombstone available via `getTraceInputStream()`, matching AOSP and stock Android devices. ## Impact Crash-reporting SDKs cannot retrieve native crash traces on Quest at all. `/data/tombstones/` is system-owned and unreadable from the app sandbox, so `ApplicationExitInfo` is the only sanctioned path, and it returns no usable data. The tombstone data exists on disk but is inaccessible to apps. **Reproducibility:** 100% on Quest 2 (`UP1A.231005.007.A1`). The same app build on a stock Android phone correctly reports `REASON_CRASH_NATIVE` with a trace. ## Repro steps 1. Install an app that triggers a native SIGSEGV (null deref on a worker thread). 2. Crash it, then relaunch. 3. Run `adb shell dumpsys activity exit-info` → most recent entry is `reason=2 (SIGNALED) trace=null` instead of `reason=5 (CRASH_NATIVE)`. 4. In `adb bugreport`, see the `NativeTombstoneManager: unexpected tombstone name` warnings, while the tombstone file itself exists in `/data/tombstones/`.How do I access the meta quest device name or id
Hi! Hopefully someone has solved this problem - I'm looking to log some information to a cloud database and I need to access and log the device Id. The ID I'm looking for isn't accessed via "SystemInfo.deviceUniqueIdentifier", nor is it SystemInfo.deviceModel, deviceName, or deviceType. The ID I'm looking for is the same ID that shows up in the Meta Horizon Managed Services devices list. It's a 14 digit device Id like "1WMHH6666V0335". I'm looking to access this Id in Unity. Can someone tell me what property I'm looking for? I think this might be the SERIAL number. Thanks for your time!
Quest standby breaks OVRCanvasMeshRenderer punch-hole UI tracking. Timewarp offset on wake-up.
Hello everyone, I'm currently facing a persistent issue regarding OVRCanvasMeshRenderer in my Unity project for Meta Quest. The setup: Engine: Unity (using Universal Render Pipeline) SDK: Meta XR All-in-One Version 201 Unity: 6.0 (6000.0.63f1) Features: Using Meta's punch-hole / underlay technology to render high-quality UI over the scene via OVRCanvasMeshRenderer. The problem: Everything works perfectly when launching the app. However, if the user puts the Meta Quest headset into standby/sleep mode and then wakes it up to resume the application, the UI canvas suffers from a noticeable positional offset (displacement). It seems like the projection matrices or the underlying render textures do not resynchronize correctly with the updated tracking data when the application regains focus. The Canvas appears detached or lags behind the head movement. What I've tried: Disabling and re-enabling the OVRCanvasMeshRenderer component upon OnApplicationFocus(true) / OnApplicationPause(false). Introducing a small delay (WaitForSecondsRealtime) before re-enabling to let the tracking stabilize. Forcing an OVRManager.display.RecenterPose(). The displacement still occurs or requires a hard restart of the app to fix completely. Has anyone encountered this specific bug with OVRCanvasMeshRenderer or Any OVR features after standby? Is there a known workaround or a specific lifecycle method we should call to force-refresh Meta's punch-hole rendering system upon resume? Thanks in advance for your help!
Question regarding prerequisites for Cloud Backup
Hey everyone, I was looking into some specifics regarding savesystems with quest and have a question, perhaps someone can clear things up for me. So I understand Meta has moved away from a cloud storage API to use Androids automatic cloud backup system. I wanted to test that out with a Unity app I made. From what can see there are mutliple steps that need to be setup for sure: - In the App created on the meta developer dashboard, cloud storage must be activated - The User (in this case myself) must have cloud backup enabled on the headset itself Those 2 seem quite certain. Now there's one third thing that I'm trying to find out: OculusProjectConfig.asset and it's "disableBackup" flag. This will set the resulting Manifests allowBackup flag from what I gather, but not 100% sure even on this I had written a large paragraph trying to explain what got me confused, but I'll ratehr just ask outright: Is it a necessity to also make sure that the allowBackup flag in the final AndroidManifest is set to true? ThxBroken Quest 3S Cameras
My Meta Quest 3S (SN: 340YC10G8N0PVR) has suffered a total hardware failure. The device is stuck on a permanent Black Screen, and the controllers have entered an Infinite Rumble loop that does not stop. I have already performed the 'Last Resort' Factory Reset, but the hardware remains unresponsive. The Tracking Service has failed entirely, and even the Gaze Dot has disappeared from the display. I have also attempted to boot from both Slot A and Slot B, but the 'Blind Setup' wall persists due to the physical failure of the tracking cameras. Since a full system wipe (Factory Reset) did not resolve the issue, this is clearly a hardware-level defect. I am requesting an immediate warranty replacement to Meta so I can restore my data and return to the Metaverse.technical issues
hello i am a game creator and i need help i have the when i try to load into my game it just doesnt let me get in its stuck at the loading part i didint add any loading screens just straight into the game and it just doesnt get in please help this is just killing my motivation i had this in all of my projects
