A channel used to have two settings: every message or nothing. Now it has
three - muted, every message, or a named profile of rules (mentions me,
message contains, sender contains; any or all must match). A channel on a
profile counts only matching messages: the unread badge, the navbar bell,
the app-icon badge and the browser/Android notification all follow the same
rule. Direct messages are untouched.
- app/notify_profiles.py: rule matching (case- and diacritic-insensitive,
same table as the chat filter), validation, storage in app_settings
- read_status.notify_profile column, written together with is_muted so a
mute never leaves a profile behind; migration added
- /api/notification-profiles CRUD, PUT /api/channels/<i>/notifications;
/api/read_status and /api/messages/updates report channel_notify_profiles,
the latter counts a profiled channel's unread through the profile
- Manage Channels: the bell opens a menu (Off / Every message / profiles /
Manage profiles...) instead of toggling; profiled rows get a green badge
- Settings > Notifications: profile list with in-use counts and an editor
- app.js evaluates the same rules for socket-delivered messages, and a
state version guard stops an in-flight poll from undoing a fresh
mute/favorite/profile change
- i18n en/pl (43 keys), docs (user guide, architecture, whatsnew), tests
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Built from 8b5ed4c and run for five hours on a Galaxy S20 FE: 115 wake ticks,
two of which found the socket dead and put it back, and notifications still
arriving at the end. The previous upload predates the wake, so the checksum in
the docs pointed at a build that still went silent after an hour.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Measured on a Galaxy S20 FE with the service running: the app process, the
service and the WebView's own renderer process all stayed alive for an hour and
a half, and the page still stopped after 56 minutes. Notifications were posted
correctly from 11:29 to 12:25 - 45 of them, traced through the PendingIntent
each one creates - and then nothing, while the server went on emitting messages
at 12:28:46, 12:28:53 and 12:29:12. The server saw the client time out at
12:29:52 and no reconnection was attempted for the next 29 minutes, although
socket.io retries forever by default. Delivery came back only when the activity
was resumed.
Ruled out with evidence rather than reasoning: Doze (the phone was charging and
only reached full at 13:05), Wi-Fi (wpa_supplicant heartbeats every 10s, no
drop), Samsung's Freecess freezer (it froze a dozen other apps by name that
afternoon and never this one - the foreground service did its job), a killed
renderer or app process (neither appears in any kill line), and socket.io giving
up (reconnectionAttempts defaults to Infinity).
What is left is that Chromium suspends the work of a hidden page. A foreground
service buys the process; it does not make Chromium run the page inside it. That
gap is not something the Stage B plan knew about.
So the service now nudges the page every two minutes. evaluateJavascript is the
lever: injected script does not queue behind the throttled timers the page's own
setTimeout calls sit in. The script re-opens the socket if it has died, which is
what mc-webui would have done a second later had its timers been running, and it
reads mc-webui's own chatSocket rather than anything added for this, so it works
against whichever server version the user typed in.
The wake logs one line every two minutes under the McPageWake tag. That is
deliberate: it is the only way to tell "the page answered" from "the page never
ran the script" after the fact, which is exactly what the next measurement has
to distinguish.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Built from 9adb98d and verified on a Galaxy S20 FE: installs over the Play
build as an update, keeps the saved address, and the foreground service starts
and stops with the notification toggle.
The Play row in docs/android-app.md deliberately stays at 2.0 - the Store still
serves that until the release passes review.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Found on a real device: after Change server, Back did not offer the leave
prompt but reversed into the previous server's pages, leaving the app showing
one instance while it was set to another. The address form is reached through
Back, so switching twice was enough to get there.
The behaviour predates the recent-servers list, but that list is what turns
switching servers into an everyday action rather than a once-a-year one.
Only a deliberate choice of server clears the history - typed in, picked from
the list, or restored at startup. Following a notification into a conversation
still goes back the way it came.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Closes the last open [CLAUDE] item in the Play release plan. The section only
covered the .apk in this repository; the app has been on Google Play since
2026-09-05 and the two have to go out together or they drift apart. Adds what
Play needs on top - an .aab rather than an .apk, a versionCode that has not been
used, release notes per listing language, and the declaration a foreground
service always triggers - plus the promote-from-library shortcut that made the
first production review take hours instead of days.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Two changes to the Android wrapper, shipping together as app version 2.1
(versionCode 6).
Notifications stopped arriving a few minutes after the app was backgrounded,
and no setting on the phone could prevent it: Android freezes a process with
nothing in the foreground, and a frozen process runs no JavaScript and holds
no socket. MeshWatchService is a foreground service of type remoteMessaging
that does no work of its own - it exists so Android leaves the process alone.
Every notification is still built by the mc-webui page, so mutes, blocked
senders, channel names, translations and deep links stay in one place rather
than being duplicated in Kotlin.
The service follows mc-webui's own notification toggle, read from localStorage
by the shim rather than asked of the page, because the wrapper connects to
whichever server its user typed in - very often an older mc-webui. The shim
also wraps Storage.prototype.setItem, since localStorage fires no event in the
document that wrote it. Android's own switches have the last word, so a revoked
permission or a silenced channel stops the service too.
setRendererPriorityPolicy goes with it: the page renders in a process of its
own, and WebView waives that process's priority once the view stops being
visible, so a service saving only the host process would still lose the
renderer under memory pressure.
Separately, the address screen now lists the servers reached before, so running
more than one instance no longer means retyping the whole address to switch.
Only addresses that answered are listed, which keeps typos out.
Also replaces the deprecated setDecorFitsSystemWindows with enableEdgeToEdge,
which is what Play Console has been flagging twice. Its default navigation-bar
scrim is overridden, or it would paint over the strip the wrapper colours to
match the page below Android 10.
Docs, the privacy policy (both languages) and the app-vs-PWA comparison are
updated: three of them said the app ran nothing in the background.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The wrapper was published to the Play Store today, so three places that told
readers it was not distributed there are now wrong: the Android guide, the
user guide and the README.
Each now leads with the Store and keeps the .apk as the deliberate second
route, with the fact that matters to existing users stated where they will
look for it: both builds carry the same signing key, so installing from Play
updates a repository build in place and keeps the server address.
Historical whatsnew entries are left as written; the change is announced in a
new Unreleased entry instead.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
--global writes to the config of whoever runs it, so a user updating with sudo was still prompted after applying the fix. Confirmed by a user on Raspberry Pi OS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
--global writes to the config of whoever runs it, so a user updating with sudo was still prompted after applying the fix. Confirmed by a user on Raspberry Pi OS.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
GitHub's HTTP/2 front end began answering the anonymous git-upload-pack
POST with 401 for the git 2.39 / libcurl 7.88 build that ships with
Debian 12. Git reads any 401 as a credential request, so update.sh sat
on "Username for 'https://github.com':" against a public repo, on every
server at once, with nothing changed locally.
Pull with http.version=HTTP/1.1, which GitHub still serves anonymously,
and set GIT_TERMINAL_PROMPT=0 so a genuine auth failure errors out
instead of blocking on stdin forever. Documented in troubleshooting,
README and whatsnew, including the one-off git config for installs too
old to carry the fix.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both are copies of files already in the untracked .claude/ directory --
AGENTS.md of .claude/CLAUDE.md, .agents/skills/ of .claude/skills/ --
written by the agent tooling, not by hand. They were never tracked, and
a `git add -A` sweeping them into an unrelated commit is exactly what
this prevents.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Expanding a Settings section fired one `get` per field, each a full mesh
round-trip. Seven questions to a repeater four hops away, answered one at
a time, to change the one field you came for -- and often a batch that
timed out halfway and left the section blank.
Nothing is read until asked for now:
- every field has its own read button beside the control (same row, so
no extra line per field), and `Read all fields` at the top of the
section still does the whole batch
- GET /settings takes an optional `fields=` subset so a single field is a
single round-trip; the section still defines the order
- reads are queued client-side. The device already serializes CLI traffic
behind one lock, so parallel requests would only tie up server threads
waiting for it
- values are remembered per repeater in localStorage, so a section opens
with the last readings instead of empty boxes. A remembered value is a
usable baseline -- Apply writes an absolute value, so editing from a
stale reading still sets what was typed -- and is marked with a clock
per field plus a note at the foot of the section saying when it was
read. Apply and unsupported replies update the cache too
- a failed read no longer wipes what is on screen: the remembered value
stays, still editable, still marked
- field hints moved from a text block under the control into an info icon
by the field name (the pattern the app's own Settings modal uses), and
every field has one now instead of the 9 that did
Verified against a live repeater from the local container: expanding all
8 sections makes 0 requests, a single-field read sends exactly
`?section=advanced&fields=rxdelay`, the value survives a reload from cache
with the stale note, and Apply still round-trips (dutycycle rewritten to
its own value).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Settings -> Advanced carried txdelay and direct.txdelay but not rxdelay,
which CommonCLI has had all along for every repeater and room server
(get + set, float 0-20, 0 = off by default). Reaching it needed a raw
CLI command.
It is a distinct mechanism from the tx delays: calcRxDelay staggers the
repeating of flood packets by packet score, so a strong copy repeats
sooner and a marginal one waits and drops the repeat as a duplicate.
Adds the field to _REPEATER_SETTINGS_FIELDS and SETTINGS_SECTIONS (the
two lists must stay mirrored) plus en/pl labels and help. `af` stays out
on purpose: dutycycle replaced it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The path list is a retry order, so the same route twice means retrying a
route that has just failed while a genuinely different one waits. Both
editors (contact info and My Repeaters) POST to the same endpoint, so the
guard sits there: adding or editing a path onto a route the contact
already has is refused with 409 duplicate_path, and the modal stays open.
Paths are now normalized to lowercase on write and existing duplicates are
collapsed on startup (keeping the primary copy), which lets a unique index
back the check. The index is created in the migration rather than
schema.sql, which runs before duplicates are removed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
With a real list loaded, the "N neighbours" counter shared the toolbar
row and pushed the kebab button onto a second line — on a 360 px phone
the four controls already fill the row on their own. The counter now sits
on its own line under the toolbar, where it reads as a caption for the
table, and the buttons keep a fixed position whether the list has loaded
or not. Verified one-line at 320/360/390/412 px.
Also trims the name column to 32vw on narrow screens: at 40vw a list of
25 neighbours with minute-and-second ages pushed the SNR column out of
the table's scroll box. The full name is in the detail dialog.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Covers the kebab menu and the detail dialog in the user guide, the two
new API entries in architecture.md, and a What's New entry under
Unreleased.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Neighbours pane could only read the repeater's list. The standard
MeshCore app offers two more commands from its overflow menu, and there
was no way to reach either from here:
- `discover.neighbors` — repeater-firmware only, so a node type that does
not have it answers with an error we surface verbatim rather than
reporting a success
- `neighbor.remove <prefix>`, with an empty prefix clearing the whole list
Remove-all deliberately gets its own endpoint instead of going through
/cli: the firmware matches `neighbor.remove ` on all 16 bytes including
the trailing space, and the CLI endpoint strips the command, so the
console cannot express it at all. The prefix is validated as hex of even
length — the firmware derives the byte count as len/2 and would silently
match a wider set than asked for.
Both actions are admin-only (the list itself needs only a login) and live
behind a kebab menu next to Refresh, which keeps the header on one line
on a phone once the Refresh label is dropped below `sm`.
Single removal goes through a detail dialog opened by selecting a row or
a map marker, rather than a trash icon per row: that row already
truncates names at 390px, and a delete button at the edge of a scrolling
list is the easiest thing in the panel to mis-tap. The dialog doubles as
somewhere to show the pubkey prefix, SNR, last-heard time and position,
which the list has no room for; guests see it without the button.
Also caps the name column at 40vw and scrolls the table in its own box,
so a long neighbour name no longer drags the whole page sideways.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Interface tab carried data-demo-lock as a whole, which greyed out the
sidebar layout breakpoint along with the toast settings. The breakpoint is
localStorage — per browser, invisible to every other visitor — so it belongs
with theme, notification permission and the quick-access bar, all of which
were already allowed. The toast settings are server-side and shared, so the
lock moves onto the uiSettingsForm that owns them.
Audited every other locked region against the localStorage key list: this was
the only per-browser control caught by a lock. Notifications, theme, FAB
placement/size/position and the sidebar breakpoint are now the complete set of
preferences a demo visitor may change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
whatsnew.md went in with the fix; architecture.md and troubleshooting.md
did not.
- architecture.md: new section on why one impossible coordinate blanks a
whole map (Leaflet clamps latitude, not longitude), the four places the
check is applied, and why a corrupted `type` is logged rather than
normalised. app/geo.py and geo-utils.js added to the file tree
- troubleshooting.md: user-facing entry for the blank map and the
world-spanning route, naming the two log lines that identify the
offending adverts, and saying plainly that updating is enough
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A tester's cached-contacts map came up empty and Path Analyzer drew routes
across the globe. Two of his 2131 cached contacts carried garbage positions
from corrupted adverts - lat 1642 / lon -323 and lat 309 / lon -1768.
Leaflet clamps latitude when projecting but not longitude, so fitBounds()
spanned 1797 degrees, dropped to zoom 0 and centred on lon -870; all 2273
real markers were rendered several world-widths outside the viewport.
Reproduced against his DB: zoom 0, bounds -1431..-309. The device-only view
was fine because both bad rows are cache-only.
Four layers, so no single miss can blank a map again:
- app/geo.py: one definition of a usable coordinate, applied on write in
Database.upsert_contact() so the cache stops storing garbage, and on API
output so a cache poisoned by an older build heals itself with no
migration. Corrupted advert types (61, 126, 152, 210 seen in the wild)
are logged but kept raw - they already render as UNKNOWN.
- static/js/geo-utils.js: hasValidGps()/withValidGps()/fitMapToPoints()
replace eight copies of the same check across six files. Path Analyzer
had a looser variant that also accepted lon == 0, which put nodes off
west Africa and stretched routes across the map; it now shares the rule.
- Per-marker try/catch and a bounds validity check, so an entry that still
slips through costs its own pin rather than the whole map.
Verified against the tester's DB in a container: cached map 2273 markers,
lon span 1797 -> 19 degrees, centred on Poland; the route that drew the
world-spanning line (msg 29499, token 72AF) now renders as a real
Krakow-Kielce path with the bad hop left unresolved. Live local instance
regression-checked on all five map pages. tests/test_geo.py: 43 passed;
full suite 290 passed, 2 pre-existing failures unrelated to this change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The cherry-pick that replayed them over the 2.12.0 release boundary put both
sections' bullets in the closed 2.12.0 section, which had already been tagged
and published. The 2.12.0 section is now byte-identical to v2.12.0 again.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A notification said "New: 1 channel" and nothing more, because
sendBrowserNotification() was driven by badge-counter deltas and never saw a
message. The socket payload has carried the sender, the text and the channel
all along.
Channel messages now notify as "<channel>" / "<sender>: <text>", DMs as
"<sender>" / "<text>", each conversation on its own tag so one cannot bury
another, and repeats on the same tag collapse with a count in the title.
Notifications carry a deep link in options.data.url; a tap resolves it in place
when the page is already up, and the wrapper hands it to the Intent so a cold
start lands there too. Channel links are new (/?channel=<idx>); DM links reuse
the conversation parameter /dm already accepted.
Two faults that made notifications look unreliable while the app was awake:
- A message on the channel last left on screen never notified at all. A channel
now counts as open only while the document is visible.
- The first checkAndNotify() compared against zeroed baselines, so a page
loading in the background announced its whole backlog as new ("New: 492
channels"). The first pass now only takes the measurement.
The count-only notification stays as the fallback for messages the socket never
delivered; the socket path advances its baselines so the same message is not
announced twice.
dm.js's checkDmNotifications() is removed rather than updated: dm.html never
loads app.js, so its areNotificationsEnabled() guard returned on the first line
in every context it ran in, and it would now be a second, vaguer alert for a
message app.js already announces in full.
Verified against the local container with a Playwright harness (14 checks):
content, collapsing, mute and own-message suppression, taps on a running page,
cold starts on both link kinds, and no stray count-only alerts.
Background delivery on Android is a separate, architectural problem and is
untouched here - the wrapper still has no foreground service, so a frozen
process still stops notifications altogether.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
"Sync clock" under My Repeaters sent the firmware's `clock sync`, which
sets the repeater RTC from the CLI packet's sender_timestamp. The
companion overwrites that field with its own RTC before transmitting
("Use node's RTC instead of app timestamp", companion_radio/MyMesh.cpp),
so the button copied the node's drift onto the repeater instead of the
server's time — observed as a repeater set 56 minutes slow. Send
`time <epoch>` instead: the value travels in the command text, taken
straight from the host clock and untouched in between.
The node's own clock is now checked on connect and hourly, and set from
the host whenever it has drifted more than 30s. It is only ever set by
hand today, so it free-runs: the local test device was 16 hours behind.
CMD_SET_DEVICE_TIME is refused when it would move a clock backwards, so
a fast-running device is logged loudly rather than retried in silence.
Also name the timezone wherever a clock is printed. The Status row
renders in the browser's zone, the console in the container's, and
repeaters answer their own `clock` in UTC — three unlabelled renderings
of the same instant, which is what made this look like chaos rather
than drift.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
On phone-sized screens the floating column overlapped the message
composer and its bottom button landed on top of send, so tapping send
hit the FAB instead. Enough testers reported it to make clear the
default was wrong rather than their aim.
isFabHidden() now treats a missing key as hidden, so only an explicit
'false' shows the bar. The storage key and its meaning are unchanged,
which keeps every browser that already made a choice on that choice:
the new default reaches only browsers that never touched the setting.
The checkbox is inverted to match — "Show Quick Access buttons",
unticked by default — because a negatively phrased toggle that ships
ticked reads as a double negative. Renamed settHideFab -> settShowFab
and the two translation keys with it, en and pl both updated.
With the bar off, applyItemPlacements() already routes every item to
the main menu, verified in a real browser: filter, search, DMs,
contacts and settings are all reachable under the hamburger, the send
button is unobstructed, the choice survives a reload, and a browser
holding 'false' keeps the bar.
Not covered: the direct-message screen has its own FAB container that
does not read this setting. Hiding it there would strand the DM filter
and settings, which have no menu equivalent, so it stays visible for
now and is called out in whatsnew.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
A message containing an apostrophe followed by angle brackets — e.g. a bot
answering "Type 'channel <name>' for a description" — tore the action row
below it apart: the apostrophe closed the single-quoted onclick attribute,
the '<' ended the <button> tag, and the remainder ("...")' title="Quote">)
landed on the page as visible text, with reply and quote dead.
JSON.stringify() produced a valid JS literal but was spliced into markup
raw. jsArg() wraps it in escapeHtmlAttribute(), so quotes and brackets
survive as entities and the JS parser sees the literal only after the HTML
parser decodes the attribute. Applied to the quote/edit buttons in channel
chat and DM, and to the sender-name handlers (reply, map, block) that had
the same defect for a name containing an apostrophe.
Verified in a browser against the local container: all ten test messages
now render six clean buttons with no stray text, and quoting '<>' fills the
composer correctly.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
console.html and logs.html are always-dark terminal pages that
deliberately do not load theme.css, so the var(--text-secondary) the
notice asked for resolved to nothing there and the text fell back to
Bootstrap's near-black body colour — roughly 1:1 against the navy
background, i.e. invisible.
Fixed twice over. Every colour in the demo CSS now carries a fallback,
so a page without theme.css degrades to a readable light notice instead
of to nothing — that closes the whole class of bug rather than this one
instance. And console.html restyles the notice in its own palette,
alongside the other hardcoded colours it already owns.
Measured contrast: console 12.22:1, light theme 7.76:1, dark theme
5.71:1 (WCAG AA for small text is 4.5:1).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mc-webui has no login, which is fine on a LAN and not fine once the
address is handed to testers: they assume the node is theirs and rename
it, and the console is right there for anyone curious enough to type
into it.
MC_DEMO=true refuses everything that reconfigures the radio, destroys
data, reaches other people's repeaters, rebuilds the containers,
publishes to an external broker, or hands out a secret. Reading and
sending messages keep working, so the instance is still worth visiting.
The guard is default-deny: an api_bp.before_request hook refuses every
non-GET unless it is on a short allowlist, so an endpoint added later is
locked without touching this module. That mattered — six mutating
endpoints already had no frontend caller and would never have made a
hand-written blacklist. A small read denylist covers the GETs that leak
(repeater passwords, backup download, capture download, /api/logs),
which the write guard never sees.
Two paths bypass the HTTP layer and are closed separately: the console
is a Socket.IO event, not a route, so it is checked against a read-only
command set; the log viewer is refused at the connect handshake.
Access is kept two ways. MC_DEMO_TRUSTED_NETS unlocks by CIDR, and
MC_DEMO_UNLOCK_CODE unlocks by a code typed once in Settings and held in
an HMAC cookie for 30 days — stateless, and deliberately not Flask's
session, whose SECRET_KEY is a hardcoded public constant.
The trap the network list walks into: published through a tunnel, every
visitor arrives from the tunnel's address, and if the tunnel runs on the
LAN then trusting the LAN unlocks the instance for the whole internet.
An address arriving with a proxy header is therefore not matched unless
MC_TRUST_PROXY is on, and startup logs report the resulting shape.
Frontend is advisory only: demo-lock.js loads from _head_i18n.html so it
reaches all eight entry points including the six iframes, greys out
[data-demo-lock] rather than hiding it (the instance exists to show the
app off), re-applies via MutationObserver for JS-rendered buttons, and
turns any 403 demo_locked into a toast.
Verified on the local container: the rename, reboot, updater, vacuum,
cleanup and the leaky GETs all 403; sending, read markers and ordinary
reads pass; `set name` is refused over the console socket while `infos`
still answers; unlock/lock round-trips. 86 new unit tests, en/pl at 100%.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The wrapper sources moved to targetSdk 36 and versionName 2.0, but the
`.apk` shipped from this repository was still the 1.3 build, so the
download table described a file that no longer matched the code beside it.
Replaces the published binary and the figures that identify it: 5.2 MB,
version 2.0, and a new SHA-256. Verified before committing - apksigner
reports the APK as signed by the same certificate as every release before
it (SHA-256 425857b3...9bd230), so it installs as an update rather than
forcing a reinstall, and aapt2 confirms versionCode 5 against targetSdk 36.
Also adds the release notes for both Android changes in this cycle.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The system bar strips took their colour from the page only when a page
finished loading or the app came back to the foreground. mc-webui switches
its theme by flipping data-theme on the document element - no reload, no
trip through onResume - so switching to the dark theme left a white strip
under the status bar until the app was restarted.
A MutationObserver on that attribute closes the gap. It lives entirely on
this side, so mc-webui still needs no changes, and it reports twice: once
immediately and once after 300 ms, because the theme change animates and
an immediate read catches a colour mid-transition.
The callback arrives through a second, separate JavaScript bridge rather
than an extra method on the notification one. That bridge is deliberately
minimal, and a one-way "here is a colour" channel has no business sharing
a surface with notification permissions.
Verified on a real device: the strips now follow the theme both ways
without leaving the app.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Google Play requires every listing to link a publicly reachable privacy
policy, whether or not the app collects anything. This one is served from
the repository itself, so its history is public alongside the code it
describes.
English and Polish on one page, self-contained and theme-aware like
contact-management.html. The content is drawn from what the app actually
does: nothing reaches the developer, and what stays on the phone is the
server address, the per-host HTTP credentials, the notification-prompt
flag and the WebView's own cache - each listed with the reason it exists.
Permissions get the same treatment, one row each.
docs/.nojekyll is not optional here. GitHub Pages runs Jekyll by default
and docs/architecture.md contains brace syntax Liquid tries to interpret,
which would fail the build and take the policy URL down with it. Serving
the folder as static files avoids the whole class of problem.
Rendering checked in Chrome at 390px and 1000px, light and dark: no
horizontal overflow, tables fit without sideways scrolling.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Google Play rejects anything below targetSdk 36 submitted after
2026-08-31, so the wrapper had to move off 34 before it can be published
at all.
The toolchain came along for the ride: AGP 8.2.0 -> 8.13.2, Gradle
8.7 -> 8.14.3, Kotlin 1.9.22 -> 2.2.21, and the AndroidX libraries to the
newest releases that still build against Android 16. The very newest ones
(core-ktx 1.19) want AGP 9.1 and compileSdk 37, which is a DSL migration
of its own and buys nothing here.
Targeting 36 means the system draws behind the status and navigation bars
with no way to opt out, so the padding that used to arrive for free is now
applied by hand - system bars, display cutout and the keyboard, all on the
root. Padding the root leaves strips of its background behind the bars,
and a white strip above a dark mc-webui theme reads as a bug, so the page
is asked for its own background colour after every load and the strips are
painted to match, with the bar icons flipped to stay readable.
Verified from the CLI: assembleDebug, assembleRelease and bundleRelease
all pass, and aapt2 confirms targetSdk 36 with the permission set
unchanged. Still needs a look on a real Android 15/16 device.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
