Releases: uraniam9/lune-bridge
Release list
Lune Bridge 2.0.3 - update notices
The panel now tells you when there is a newer release.
2.0.2 fixed a bug that could leave a lock screen too dark to read, and the people who needed that fix had no way of knowing it existed. That is most of the way to not having shipped it at all.
The panel now shows the new version, links its release notes, and has a Skip button for when you have heard enough about that particular one.
What it does with the network
This needed deciding rather than defaulting, because the argument for this module is that it stays out of your way.
- It runs when you open the panel, never from the daemon. Nothing here talks to the internet while you are asleep.
- The answer is cached on your device for twelve hours, so opening the panel repeatedly does not mean repeatedly asking GitHub.
- It fetches one static file from this repo. It sends no identifiers of its own: no device ID, no install ID, nothing about your phone. Nothing is recorded anywhere except on your phone.
lunectl update offstops it permanently.lunectl updateruns it by hand whenever you want.
A reply that does not parse as the feed is thrown away rather than believed, so a captive portal login page cannot turn into "you are out of date".
Android 9+ and Magisk 20.4+ / KernelSU / APatch; Android 12+ for dimming.
Lune Bridge 2.0.2 - lock screen fix
If you are locked out right now
Hold Volume Down through the boot animation to get into Android's safe mode, which disables every root module for that boot. From there, update the module or remove it. If you have a custom recovery, deleting /data/adb/modules/lune_bridge works too.
What went wrong
At boot the module works out what your framework still clamps, by writing a value and reading back what actually got stored. It then puts your old value back.
When the setting had never been written on that device there was no old value to put back, and instead of clearing the key it left its own test value sitting there: Extra Dim strength at 95, warm floor at 1700K.
If Extra Dim or Night Light was already switched on, that took effect on the next boot. The screen came up at roughly a twentieth of its normal light, or deep amber, on a lock screen you then could not read well enough to unlock. Everything in the module behaved exactly as designed, and the phone was unusable.
Fixed
- The probe now clears a key it found empty instead of leaving a value behind. Two tests cover both branches, and both fail against the old code.
- The boot probe no longer runs on every boot. What it measures only changes when the ROM or the module changes, so it is keyed on both and skipped otherwise. Writing display settings every boot is what turned one mistake into something that happened forever rather than once.
lunectl probestill re-runs it on demand.
Worth saying plainly
The failed-boot guard did not catch this and could not have. It watches for a boot that never finishes, and these boots finished fine. The screen was just unreadable afterwards. That gap is mine and I am thinking about the right answer to it.
Reported independently by two people on two different root managers within a day. That is the only reason it was obvious this was the module rather than something device-specific, so thank you to both.
Android 9+ and Magisk 20.4+ / KernelSU / APatch; Android 12+ for dimming.
Lune Bridge 2.0.1
Fixes from a day of actually using it on a phone rather than reading it.
Do Not Disturb ignored its own preference while quiet mode was running
In both directions. Switching it on mid-quiet did nothing until the next entry, which for an overnight window is the following night. Switching it off left DND on, with the only control for it now reading "off" and quietctl reset the only way out.
Both faults had the same shape: a preference read at one moment to decide something that happens at another. Quiet mode now records that it was the one that turned DND on and acts on that record, so the preference takes effect when you change it. DND you switched on yourself is still left alone.
The manual quiet toggle lost to the scheduler
Inside quiet hours the next tick re-applied whatever the window said, so switching quiet mode off by hand lasted about twenty seconds. A manual tap is now an override that holds until the window's own answer changes, which is the next window edge. Setting a new schedule clears it.
Setting a schedule looked like it tripped something unrelated
A window containing the current time starts quiet mode there and then. That is the point of a schedule, but nothing said so. It does now. The custom pickers also stopped looking like they had applied when they had not: Set marks itself while holding something unsaved, and the card says plainly that presets apply on tap while custom waits for Set.
Also
- A gated PWM knee explains itself when tapped. It was
disabled, and a disabled control swallows the event, so the explanation never fired and the knee read as broken rather than off-limits. - Buttons in rows and lists clear 42px instead of being sized for a mouse.
- An app both quieted and allowed through now says which way that resolves, including the case where the
notifylever makes the allow do nothing at all. - Quiet hours keep the times typed into them when the schedule is switched off.
- Press and hold anywhere on the panel for two seconds to reset. The reset button is the way back from a screen too dark to read, which is exactly when it cannot be found.
- Warmth Off says so when warmth is already off.
- The SonoLune card dismisses per tab and lists what each suite offers. Labs is linked from the bottom of the Display tab.
- Report a bug, Request a feature and Share my PWM knee in About, opening the issue forms directly.
Upgrading from a build older than 2.0.0
The module id changed at 2.0.0, from lune_display_bridge to lune_bridge. Magisk and KernelSU key modules by id, so an older build is not replaced by this one. It stays installed alongside, and its copies of lunectl and quietctl in /system/bin may be the ones you get on the command line.
su -c "ls -d /data/adb/modules/lune_*"
If lune_display_bridge is listed, remove it.
117 unit tests, 110 QA checks. Android 9+ and Magisk 20.4+ / KernelSU / APatch; Android 12+ for dimming.
Lune Bridge 2.0.0
Adds the Quiet Field suite. The module is now called Lune Bridge rather
than Lune Display Bridge, since it is no longer only about the display. The
module id is unchanged, so this is an in-place upgrade.
No Xposed, anywhere. The original concept for Quiet Field assumed LSPosed
hooks would be needed. They are not. Everything below is appops and
cmd notification - documented interfaces that survive ROM updates and behave
the same on a Pixel and on a heavily skinned OEM build.
- Per-app levers via appops:
wake_lock,turn_screen_on,
use_full_screen_intent,vibrate,post_notification. Availability is
probed per device rather than inferred from the SDK number. - Quiet windows on a schedule, including windows that cross midnight. Do Not
Disturb is set to priority, not total silence, so alarms still fire. - Per-app Do Not Disturb bypass, so the people who matter still get through.
- Opt-in re-engagement watcher that snoozes notifications matching a pattern
list, and only for apps you explicitly added. Ships 27 starter patterns.
Honest about its two costs: it polls, so matches flash briefly first, and
polling uses battery. quietctlCLI, and a Quiet Field tab in the WebUI with an app picker.- Scheduler cadence scales with use - an hour when nothing is configured, a
minute during quiet hours - so the display-only user pays nothing for it. uninstall.shnow lifts every appop it set. An app left onignoreafter
the module is gone would stay broken with nothing left to explain why.- 89 tests, up from 38. New coverage for overnight windows, the
08/09
octal parsing trap, lever mapping, and a check that no shipped pattern
matches an ordinary message.
Fixed a latent bug where conf_get/cap_get/qconf_get referenced an unbound
$2 when called without a default. Harmless under Android's shell, caught by
the stricter test harness.
Install: flash LuneBridge-v2.0.0.zip in Magisk, KernelSU or APatch, then
reboot. Needs Android 9 or newer; Android 12+ for dimming below the panel
minimum.
Run su -c lunectl status afterwards. It reports honestly whether the overlay
took effect on your ROM rather than assuming it did, so you will know in one
command instead of wondering.