[Bug]: HiLight's settings doesn't respect the Privileged access method #1372

Activity

1. Celestial04

   assigned

   sameerasw

   on Oct 13, 2026
2. Celestial04

   added

   bugSomething isn't workingSomething isn't working

   on Oct 13, 2026
3. Celestial04

   changed the title [-][Bug]: HiLight settings doesn't respect the Privileged access method[/-] [+][Bug]: HiLight's settings doesn't respect the Privileged access method[/+] on Oct 13, 2026
4. jawzf commented on Oct 14, 2026

   

   jawzf

   on Oct 14, 2026

   Contributor

   More actions

   Thanks for the report. This is currently expected behaviour rather than a regression, but it's a fair gap.

   Hilight drives the LEDs through the system lights service (ILightsManager), which needs CONTROL_DEVICE_LIGHTS. That permission is signature|privileged, so it can't be granted to the app with pm grant. Shizuku and Porter work because they hand Essentials a binder running as the shell user, which already holds it. Root mode in Essentials only runs su -c shell commands, so there's no binder to call the lights service through. That's why HilightLights.isModeSupported() only accepts Shizuku and Porter, and why "Try it" does nothing in Root mode.

   Workaround for now: if you start Shizuku (it can run as root), set Privileged access to Shizuku or Auto and Hilight will work.

   Possible fixes:

   1. In Root mode, fall back to Shizuku's binder when Shizuku is running, and make the status text clearer when it isn't.
   2. Proper root support via libsu's RootService: a small service running as uid 0 that makes the ILightsManager calls (getLights, openSession, setLightStates, closeSession) over a tiny AIDL interface, with HilightLights picking the Shizuku or root path.

   @sameerasw would you be open to option 2? It adds the libsu dependency, so I wanted to check before opening a PR. Happy to do option 1 on its own if you'd rather not.

   👍React with 👍1Reacted by celestial04
5. sameerasw commented on Oct 14, 2026

   

   sameerasw

   on Oct 14, 2026

   Owner

   More actions

   Thanks for the report. This is currently expected behaviour rather than a regression, but it's a fair gap.

   Hilight drives the LEDs through the system lights service (ILightsManager), which needs CONTROL_DEVICE_LIGHTS. That permission is signature|privileged, so it can't be granted to the app with pm grant. Shizuku and Porter work because they hand Essentials a binder running as the shell user, which already holds it. Root mode in Essentials only runs su -c shell commands, so there's no binder to call the lights service through. That's why HilightLights.isModeSupported() only accepts Shizuku and Porter, and why "Try it" does nothing in Root mode.

   Workaround for now: if you start Shizuku (it can run as root), set Privileged access to Shizuku or Auto and Hilight will work.

   Possible fixes:

   1. In Root mode, fall back to Shizuku's binder when Shizuku is running, and make the status text clearer when it isn't.
   2. Proper root support via libsu's RootService: a small service running as uid 0 that makes the ILightsManager calls (getLights, openSession, setLightStates, closeSession) over a tiny AIDL interface, with HilightLights picking the Shizuku or root path.

   @sameerasw would you be open to option 2? It adds the libsu dependency, so I wanted to check before opening a PR. Happy to do option 1 on its own if you'd rather not.

   I am fine but we do need some external proper testing with this as we don't got rooted devices to test.
6. jawzf commented on Oct 14, 2026

   

   jawzf

   on Oct 14, 2026

   Contributor

   More actions

   I totally agree. We especially need rooted Pixel 11 devices. Unless @Celestial04 you are willing to help me with the testing?