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>
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>
Android's WebView ships no Web Notifications API, so window.Notification
was undefined, mc-webui detected that and greyed its toggle out as
"Unavailable". The app also declared no POST_NOTIFICATIONS and created no
channel, so it never even appeared in Android's notification settings.
A shim injected at document start puts window.Notification back and
forwards it to a @JavascriptInterface bridge that posts through Android's
NotificationManager. mc-webui itself is untouched - the page keeps using
the standard API.
- onPageStarted is early enough: mc-webui reads the permission on
DOMContentLoaded, a whole parse and script pass later
- web permission states map onto Android's, with
shouldShowRequestPermissionRationale separating "ask again" from
"blocked for good" after a refusal
- tags replace notifications the way the web API expects; a tap returns to
the running app (singleTop) and fires the page's onclick
- notifications only arrive while the process is alive, same as the PWA
versionCode 2 / versionName 1.1. Verified: debug and release both build
clean (lintVitalRelease included), shim and drawable land in the APK, and
the shim's contract is covered by a Node harness against a fake bridge.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The wrapper is what users sideload, so its source belongs next to the APK -
they can read what they install, or build it themselves.
Behaviour fixes on the way in (APK rebuild pending):
- The saved server address survives. Back on the first page and connection
errors used to delete it, so a stray tap or a moment without signal meant
typing the address again; the form now opens pre-filled and only a save
replaces what is stored. Back at the top level asks: exit, change server,
or cancel
- QR scanning works: the page's camera request is mirrored to an Android
permission request (CAMERA, on an https instance - getUserMedia needs a
secure context, as in any browser)
- Downloads work: a DownloadListener hands database backups and other files
to DownloadManager, which puts them in the phone's Downloads folder
- Links to other hosts and non-http schemes open in the system browser, so
a URL in a message no longer navigates the app away from the instance
- Rotating the screen no longer reloads the page
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
