Skip to main content
Reiz04
New Participant
July 27, 2026
Question

Quest 3 battery drain: self-restart leaves display on but blank, 96% to 2% in 5h

TL;DR — After my Quest 3 restarts itself on a schedule, it comes back with the display powered on but nothing rendered. Put it on and you see a black screen; you have to press the power button off and on to get an image. Because nothing renders, nothing ever requests sleep, and it burns around 950 mA until the battery is dead. Three occurrences, including one after a factory reset. Has anyone else hit this, and is there any way to stop the scheduled reboot job?

DEVICE

Quest 3, build UP1A.231005.007.A1, Android 14. Battery is essentially new: 31 charge cycles, 4892 mAh full-charge capacity, health reported GOOD.

WHAT HAPPENED

Headset untouched in a bag at 96%. Wi-Fi off, auto-wake off, auto-update off, sleep timeout 15 seconds.

13:36:39 — com.oculus.horizon/com.oculus.auth.control.RebootJobService runs for 10 seconds, then com.oculus.nux.ota calls PowerManagerService.reboot() with reason "nux"

13:36:53 — reboots

13:37:00 — proximity correctly reports PROX_OFF, so the system knows it is not being worn

13:37:04 — VR Power Manager transitions STANDBY to SLEEP

13:37:10 — Android turns the display ON at 78% brightness, six seconds after the VR runtime already went to sleep

13:37 to 18:25 — 4 hours 48 minutes with zero VRPM transitions, zero sleep requests, zero camera frames, display on throughout

18:25 — I put it on, see black. Power off, power on, image returns immediately.

WHY IT NEVER SLEEPS

PowerManagerService logs screenOffTimeout=86400000

Setting screen_off_timeout = 86400000, which is 24 hours

Setting sleep_timeout = -1, which is never

Android's own timeouts are effectively disabled by design, because the VR power manager owns sleep. But it entered SLEEP before the display came on, so it had no transition left to make and never issued a sleep request. Nothing catches this state.

THE DRAIN

From healthd, sampled every 10 seconds for the entire window:

battery l=81 v=4073 t=41.0 h=2 st=3 c=-666886 fc=4892000 cc=31

Sustained -700 to -1120 mA, peaking at 47 C inside a closed bag. Normal standby on this same headset the previous day was 166 mAh over 24 hours 50 minutes, about 6.7 mA. That is roughly 140 times higher.

WHAT I RULED OUT

Proximity sensor is fine. PROX_OFF at 13:37:00, PROX_ON when I put it on at 18:25:51, PROX_OFF when I removed it at 18:26:08, all correct. Calibration loaded normally and hmd_disable_prox_sensor is false. One millisecond after the 18:26:08 event the VR Power Manager correctly went RUNNING to STANDBY, with auto-wake still disabled, so the sensor-to-sleep path works.

Display hardware is fine. The DSI PHYs, controllers and panel all probe successfully, and the panel re-initialises perfectly on a manual power cycle.

No crashes. There are no system_server_crash or system_app_crash entries in dropbox.

Not an update. Wi-Fi was off, wifi_on = 0. No OTA package was staged, update_engine had no payload, and the device booted from the same slot, slot_suffix = "_a". NuxOtaService ran for 31 milliseconds and was killed 10 minutes later as an empty process. Disabling automatic updates therefore does not prevent this reboot.

Factory reset did not help. This is the third occurrence.

WORKAROUND

After any self-restart, press the power button to turn the display off and back on once. That resyncs both state machines and the image returns. Two seconds of work, but you have to know it restarted, and mine was in a bag.

QUESTIONS

1. Has anyone else seen the headset return from a self-restart with a lit but blank display?

2. Is there any way to disable or reschedule auth.control.RebootJobService? It reboots with no network and nothing to install.

3. Is there a reason screen_off_timeout is 24 hours with no shorter fallback for when the VR runtime is not driving the display?

I have submitted an in-headset bug report with full logs and diagnostics attached.

1 reply

steve40
Honored Contributor
July 28, 2026

I have submitted an in-headset bug report with full logs and diagnostics attached.