Show controller batteries under the game menu, and let the guide LED follow them

[trexx]

Summary

Battery state was already collected for every supported pad but only ever forwarded to the host. Two additions, plus two pre-existing faults fixed on the way.

Battery label. While any level of the in-game menu is up, a small end-aligned line along the bottom of the screen lists every controller's battery by host player number:

Controller 1: 75%  ·  Controller 2: 50%, charging  ·  Controller 3: wired

• New Android-free ControllerBatteries store (one slot per player number, synchronized), fed by both existing battery paths in ControllerHandler; Game formats it.
• The menu is a chain of AlertDialogs whose onDismiss fires for a parent after its child has opened, so a DialogChain token decides which dismissal is the last one and hides the label.
• The dialog's dim stays; the text uses the primary colour so it reads through it.

"Battery level" guide LED. A fifth value of the Xbox button brightness setting. The guide LED is monochrome, so it steps through the presets — full = Bright, medium = Normal, low = Dim — and slow-blinks at critical. A battery-less cabled pad goes Bright.

• GuideButtonLed holds every LED constant and the ladder on the Java side, where it is tested; the native side only applies what it is handed and refuses a pattern outside enum LedMode.
• Native: Controller::setLed() stores the command and sends it once the device has started; startDevice() applies whatever is stored through the same applyLed(), so the frame is built in one place. ledBrightness loses its const (and the comment that justified it) and gains a pattern, both std::atomic against the startThread fallback. New JNI entry setLedNative (JII)Z.

Fixed on the way:

• A GIP pad's first status packet usually lands before its first input report — which is what assigns its player number — so its first battery report went to the host as player 0. Now held on the context until the number is assigned.
• On the cabled path, a status arriving before the Java object existed armed the driver's change filter with nobody listening, so Java heard nothing until the battery actually moved. The filter now stays unarmed until a report is delivered; MS-GIPUSB 2.2.9 has the pad repeat status every second for its first ten seconds.

Pad-audio menu numbering. The submenu counted GIP pads by their position in the driver's list, which disagreed with the label and the host whenever the Shield controller or a Bluetooth pad held a slot. It now names pads by the host's player number (GameMenuLayout.padNumber(), tested), reading "Unused controller" for a pad that has not sent input yet, and keeping positional numbers only when multi-controller is off (every pad is player 0 there). Numbering is still assigned on first input, deliberately: assigning at deviceAdded() was considered and dropped because LiSendControllerArrivalEvent() returns -2 until the stream's input channel exists and nothing re-sends it, so a pad attached at launch would be announced into the void.

Latency and performance impact

None on any per-frame path. Battery writes happen at battery-change frequency on driver threads; the label is built once per menu level on the UI thread while the decoder is already stalled behind the dialog, and is a child View of the window rather than a layer (§14); the LED sends one GIP frame per level change on the driver's read thread, deduplicated against charge-only changes.

Applies to

Label: all pads on both boxes (Shield controller via sceManager; Bluetooth pads via API-31 BatteryState, so Homatics only; GIP pads on both). LED: GIP pads this app drives, on both boxes.

Test plan

• ./gradlew testDebugUnitTest — 366 tests, 0 failures (62 new/updated: ControllerBatteriesTest, DialogChainTest, GuideButtonLedTest, PreferenceConfigurationTest, GameMenuLayoutTest)
• ./gradlew assembleRelease lintRelease — both ABIs build; the 2 lint warnings are pre-existing (UsbDriverService, Profiler)
• On device: HARDWARE_TESTING.md §31 — in particular whether a pad honours LED_BLINK_SLOW at all, which Table 42 leaves open, and that the label is legible under the dialog's dim

🤖 Generated with Claude Code