coinosv3.git/static/graphene.apk, branch master

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

A reply can carry a picture, and the WebView build has a name you can say.

2026-09-12T22:37:48Z

The reply box gets the same paperclip the post composer has: one uploader now, handing the URL to whichever draft asked for it, and the reply's own imeta tag describing what it carries. And the UnifiedPush build is graphene.apk — what people will actually call it, and short enough to read down a phone line. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_019mrt228Upn9nNCwGixzSLx