coinosv3.git/static, branch master

Android 1.14 (code 15) APK: UnifiedPush only without Play Services, built and signed on lap from 90bc4d3 (76:64:83:AB…). sha256 58a5c4787efbb52d3b34924e51ede844c3b17d8e20b5fc6524e24fd59f5bdfc1.

2026-10-13T06:51:32Z

Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01KPw21NEpWeTGu6swVASmBt

Android 1.13 (code 14) APK: sticky-immersive, built and signed on lap from bcf5f54 (the key assetlinks.json names: 76:64:83:AB…). sha256 63dac2e8b5b6b3d2d4b1f0fe4d73daa3c4c42b23bd11c81ba0d47da483efa26c.

2026-10-13T06:29:31Z

Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01KPw21NEpWeTGu6swVASmBt

Android 1.11 (code 12): 1.9's per-theme system-bar colours, rebuilt to sit above a 1.10 test build. The navigation buttons stay white on white on Android 17 / Chrome 154 whatever the app asks for: the TWA's Custom Tab window ignores the navigation-bar colour (plain Chrome tabs are fine), reported to Chromium

2026-10-09T16:30:07Z

Co-Authored-By: Claude Opus 5.5 Claude-Session: https://claude.ai/code/session_01MgAFLnkF7KrdhuyCLMNgtL

PWA maskable icon is the inner mark on white, like the native app's adaptive icon: it was a copy of the full logo, so Chrome's home-screen Coinos showed an extra outer ring

2026-10-09T05:26:44Z

Co-Authored-By: Claude Opus 5.5

Setup wizard: a cover behind the avatar — twelve nature covers (self-hosted, Unsplash) cycled with arrows or a swipe, or upload your own; untouched, each pubkey gets its own default, published as the kind-0 banner beside the punk

2026-10-07T20:25:49Z

Co-Authored-By: Claude Opus 5.5

The Android app's system bars follow the system theme, and the page's theme colour follows the app's.

2026-09-28T06:58:44Z

One dark colour for both bars gave white navigation icons over a light page under gesture navigation. The wrapper (1.9, versionCode 10) now uses the page background in light mode and the dark theme colour in dark mode, for the status bar and the navigation bar alike. The page updates its theme-color meta when its own theme is applied, so a PWA's status bar and the wrapper's follow the same switch. Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_01VhUKyXKtsJ67QAFfb7QR9D

Public Sans, the coinos.io face, across the app.

2026-09-27T22:07:30Z

One variable-weight woff2 each for upright and italic (41 KB + 45 KB, OFL), shipped with the build and precached by the service worker; the system stack paints first and stays when the file never arrives. Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_01VhUKyXKtsJ67QAFfb7QR9D

End to end over the real network, and the advice now fits the app it's in.

2026-09-13T00:06:14Z

A push sent to ntfy.sh reached a killed app on a real phone: 17:02:21.259 ntfy.sh → the phone's ntfy → broadcast to io.coinos.webview 17:02:21.308 app process started (it had been killed) 17:02:21.458 wake: job started 17:02:22.926 wake: finishing (page said so) — 1.7s, and "You were paid" One thing that took two goes: `adb shell am force-stop` marks a package STOPPED, and Android delivers no broadcasts to a stopped package unless the sender sets FLAG_INCLUDE_STOPPED_PACKAGES — which `am broadcast` does and a real distributor rightly doesn't. The first attempt looked like a failure and was a test artefact; `am kill`, which is what Android itself does to a backgrounded app, delivers fine. And the WebView build can now say something useful about push. It was inheriting the browser's line — "your browser has no push service, try Firefox" — which is nonsense inside a WebView that IS the app. It asks the host what's actually there and says: install a push app like ntfy (nothing installed), or wait a moment and reopen (a distributor that hasn't answered yet). Payments and messages still arrive whenever coinos is open, which is the part that matters most to someone reading an apology. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_019mrt228Upn9nNCwGixzSLx

Proven on a phone: woken from a cold stop in four seconds.

2026-09-12T22:52:54Z

The whole chain, on real hardware, with the shipping APK installed: am broadcast → PushReceiver → expedited job → off-screen WebView → v3.coinos.io/?wake= → the wallet restored from its vault → CoinosHost.done() 15:49:52.341 schedule -> 1 15:49:52.390 job started (49ms later) 15:49:56.602 finishing (page said so) Four and a bit seconds from a force-stopped app to the page reporting it had dealt with the payload — not the timeout, the page. A notify payload raised the right notification too ("You were paid", "New message"), and the wallet it woke was one imported into the WebView build minutes earlier, restored from the vault in a process that had been killed. The payload no longer goes to logcat. It carries the user's push, and anything with ADB can read that. Unproven, and the one link I couldn't close here: the distributor handshake. There's no UnifiedPush distributor on this phone, so every push above was a broadcast I sent by hand — which is exactly what a distributor sends, but it isn't the same as watching ntfy do it. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_019mrt228Upn9nNCwGixzSLx

The wake had to be a job, not a foreground service — Android says so.

2026-09-12T22:47:56Z

Tested on a real phone, and the first attempt didn't work at all: Background started FGS: Disallowed [... code:DENIED ...] startForegroundService() not allowed due to mAllowStartForeground false Android 12 forbids starting a foreground service from a broadcast receiver. An expedited job is the sanctioned replacement — it runs promptly from the background and needs no notification of its own to apologise for existing — so WakeService is now WakeJob, and the notification is decided by what arrived rather than by whether we could wake: a payment or a message is news either way, a wallet-connect request the wallet answers by itself is not. Two more things the phone found. A job with a connectivity constraint needs ACCESS_NETWORK_STATE, or schedule() throws and nothing runs at all. And a wake with nothing to answer used to hold a WebView open for the full thirty seconds — a locked wallet, no wallet on the device, or no NWC connections all end the job immediately now. Also a bug worth naming: ctx carried `wakeDone` by shorthand, which captured the binding while it was still undefined (ctx is built before it's defined). The page could never say it had finished, so every wake ran its full timeout. It reads through a closure now, like its neighbour. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_019mrt228Upn9nNCwGixzSLx