# Pixel 11 Pro stuck LED 1.0.9

Date: 2026-08-27
Repository: Pixel HiLight-shizuku-led-fix
Slug: stuck-led-1-0-9
Owner:

## Problem

Pixel 11 Pro users report that one HiLight LED can remain physically lit after an animated
notification expires even though Android reports every light black and no session remains. The
v1.0.8 black sequence is therefore not a reliable physical-clear signal. Before this work, the app
could also reconnect to an old Shizuku daemon and collapsed framework acceptance, shadowing, failure,
and retry exhaustion into success-shaped status.

## Goals

- Guarantee that 1.0.9 starts a uniquely identifiable renderer on Shizuku, ADB, and root.
- Make every clear attempt and terminal outcome truthful and privacy-safe to export.
- Run exactly one bounded recovery cycle for each accepted visible-to-dark transition.
- Preserve Android call and Gemini ownership while dark.
- Provide a signed-build-compatible LED recovery lab for affected Pixel 11 Pro testing.
- Validate software and ownership regressions on the maintainer's connected Pixel 11 Pro XL.

## Non-Goals

- Claiming physical efficacy from the non-reproducing Pixel 11 Pro XL.
- Automatically shipping a visible RGB scrub without affected Pixel 11 Pro evidence.
- Reverse-engineering or modifying Google's vendor light HAL.
- Publishing, committing, or pushing a release in this implementation pass.

## Implemented Candidate

The 1.0.9 candidate is app version code 10. Every transport reports renderer contract 1,
implementation revision 4, status schema 6, and clear algorithm 1. Shizuku v12 or newer peeks at an
existing user-service version before binding, then uses composite service version 1004 and validates
the full identity before replaying visible/current state. A mismatch may receive only a minimal safe
idle document while the app removes and rebinds it once. Other transports stay fenced until the
rejected binder is known to be disconnected. ADB and root report the same contract and are rejected
as stale until restarted from the current APK.

v1.0.8 already sent alpha-black → canonical black before closing the normal render session. v1.0.9
retains that step, waits after the final write, releases the normal session, then opens three fresh
priority `-1000` sessions and repeats the black-only sequence. The same three-pass cycle runs before
renderer readiness and is available through **Retry LED cleanup** only while HiLight is off and idle.
Automatic cycles are armed by the first attempted visible output, even if the Binder write fails, so
duplicate disabled documents cannot create unbounded retries. A temporary dark frame in the same
animation configuration closes only its normal session and preserves that cycle; expiry, master-off,
source/configuration changes, and an always-dark configuration run the terminal recovery once. A
reserved stop attempt and bounded close retries remain available for shutdown. No recovery path asks
RGB channels to emit light.

Status distinguishes receipt, render-thread settlement, and release; handoff requires the matching
released revision, no open session, terminal cleanup, and a stopped privacy observer. ADB reset uses
a constrained helper-process pattern; root additionally validates the exact PID, owner, and command
line. Both terminate cooperatively so a current helper's shutdown hook can run `Engine.stop()` before
exit. Each ADB/root launch requires a valid explicit renderer instance ID and acquires a singleton
process lock before `Engine` starts; synchronous startup cleanup can take roughly 2–3 seconds.

After the source's exact process or binder exit is proven, the app sends the new/current renderer a
fully disabled one-shot cleanup request and waits for that exact request to be accepted and for its
revision to become terminal, closed, and released before replaying desired output. If a fresh current
bridge instance heartbeat appears while no handoff or root transition is active, the app retargets
and re-pushes saved current state once with `arm=false`. A restarted helper therefore does not remain
dark or restart the auto-off clock. These are software/framework sequencing guarantees, not physical
LED proof. The renderer independently caps ambient output at five minutes.

**Copy LED diagnostics** exports only allowlisted build, transport, renderer identity, session,
cleanup, and revision fields. Cleanup results distinguish Binder acceptance, effective framework
readback, shadowing, I/O failure, completion without physical verification, and exhaustion. None of
those results observes photons.

## Validation Layers

- Host tests: renderer contract, stale-service fence, clear readback/outcomes, retry exhaustion,
  duplicate-idle coalescing, stop reserve, manual retry, and released-revision handoff.
- Build gates: `:app:testDebugUnitTest :app:assembleDebug :app:lintDebug`, standalone helper DEX, and
  `git diff --check`.
- Pixel 11 Pro XL: install/upgrade, identity 1/r4/schema6/clear1, Shizuku service 1004, repeated
  expiry/master-off, zero idle sessions, one visible session, and call/Gemini hand-back. Because this
  device does not reproduce the latch, these checks are regression evidence only.
- Pixel 11 Pro: the physical release gate below.

## Affected-device release gate

Use a Pixel 11 Pro that has reproduced the problem; a clean Pro XL run cannot qualify the fix.

1. While the phone is still on signed v1.0.8, use the reporter's known reproduction and run three
   Wave plus three Breathe notification expiries. The device qualifies as affected if at least two
   trials leave a physical LED latched; extend the baseline to ten trials and record each outcome.
2. Leave the final baseline latch in place. Do not reboot, clear app data, or manually restart the
   renderer. Install the signed 1.0.9 candidate as an update and reopen HiLight. This exercises both
   old-renderer rejection and startup cleanup against a real latch. Record whether the LED clears by
   observation, then copy LED diagnostics. Confirm app code 10, renderer revision 4, status schema 6,
   clear algorithm 1, and service 1004 for Shizuku. Stop if the identity differs.
3. Run 10 Wave plus 10 Breathe expiries with the candidate. After every expiry, record physical LED
   state and confirm `cleanup.terminal=true` and `session.open=false`. Also verify a call or Gemini can
   use the array while HiLight is dark.
4. If any candidate trial latches, do not reboot or restart the renderer. Record the visible LED,
   colour, and time; copy diagnostics; tap **Retry LED cleanup**; wait for terminal cleanup and a
   closed session; then record whether the physical LED cleared. Framework readback is not physical
   observation, and any candidate latch fails the zero-latch release gate even if manual retry clears
   it.
5. Repeat on two independently baseline-qualified Pixel 11 Pro devices, preferably one Shizuku and
   one ADB. Both upgrade-startup latches must clear and all 40 candidate expiries must finish with zero
   physical latches and no framework session leak before widening distribution beyond targeted testing.
6. Before calling the issue eliminated, collect a seven-day soak from three affected reporters with
   at least 100 total expiries and zero stuck LEDs. Attach copied diagnostics, never notification
   content or full logcat.

Until that gate passes, 1.0.9 is suitable for targeted testing, but its black-only sequence is a
mitigation candidate rather than a proven physical fix.

## Risks

- Hidden API behavior or vendor arbitration may differ from AOSP; readback is framework-only.
- Cleanup settle waits briefly hold the engine lock; regression-test animation cadence and handoff.
- A visible recovery stimulus may flash or suppress a system effect if its priority is raised.
- Remote reporter results are invalid unless app/renderer identities match the tested build.

## Remaining Question

- Which invisible/visible stimulus clears the latch on a baseline-qualified Pixel 11 Pro?