coinosv3.git/android/app/build.gradle, branch master

Android 1.14 (code 15): UnifiedPush only where web push can't reach the app. isolabellart asked why Coinos opens a prompt inside ntfy: every launch of the TWA asked whatever UnifiedPush distributor was installed for an endpoint (and asked for notification permission for it), Play Services or not. UnifiedPush is there for phones without Google Play Services (GrapheneOS and the like); with Play Services, web push reaches Chrome — and so the TWA — through Google already, and asking ntfy too only put up its prompt (and would bring every notification twice). The TWA now asks a distributor only when Play Services isn't installed and enabled (Push.playServices; its package named in the manifest's queries for Android 11+), or when it already holds an endpoint — whoever has one has been through the prompt and may be counting on it. The WebView builds (webview, fdroid) are unchanged: web push never reaches a WebView, so UnifiedPush is their only way in either way.

2026-10-13T06:51:13Z

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

Android 1.13 (code 14): the app runs immersive. Adam doesn't want Chrome's "v3.coinos.io – To exit full screen, drag from the top and touch the back button", which Chrome shows whenever a page enters its full screen and a page can't turn off. The TWA now launches in sticky-immersive display mode (android-browser-helper's DISPLAY_MODE): the status and navigation bars are hidden, and a swipe in from an edge shows them for a moment. The page — in display-mode fullscreen, which installedApp() counts — fills the screen with the pager without ever asking for the browser's full screen. A Custom Tab's window is the browser's, so the page can't switch this on and off: it's the whole app. Thread clips and YouTube still ask for the browser's full screen, and so still get the notice. 1.12 (code 13) was published without its APK committed here; this sits above it.

2026-10-13T06:28:40Z

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

Dark mode: your own chat bubbles are a gray (#343a44, light text) instead of the white accent, which glared among the dark bubbles. Android 1.12 (code 13): the TWA no longer names a navigation-bar colour — the helper library always passed one (white when the manifest named none), and Chrome 154's Custom Tab window paints that bar white anyway while the buttons follow the colour asked for, so the colour extras are stripped from the launch intent (both schemes) and the bar is left to the browser and the system. Untested on a device yet; not published.

2026-10-09T16:46:29Z

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

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

README rewritten for today's coinos v3; build switches are COINOS_* (HAL_* still accepted); silent-payment leftovers removed

2026-10-06T05:35:56Z

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

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

Android: no Google dependency-metadata block in the APK; 1.8 (code 9).

2026-09-17T21:41:37Z

F-Droid's APK check refuses the Play-only dependency-metadata signing block AGP adds by default. Off for every flavor. Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_01JuwQqNWtDJcxPWtEm9134z

F-Droid: fastlane metadata in-repo, text lockfile, version 1.7 (code 8).

2026-09-17T21:33:40Z

From the fdroiddata review and its pipeline: store text (summary, description, icon, changelogs) belongs in fastlane/ here rather than in the recipe; the category is "Wallet"; the scanner strips committed APKs by itself, so the two scandelete entries go; and bun.lockb is a binary the scanner flags — replaced by Bun's text lockfile (bun.lock, same pinned versions). A new tag is needed for the new tree, so 1.7. Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_01JuwQqNWtDJcxPWtEm9134z

Android: a reproducible F-Droid flavor with the web app bundled inside.

2026-09-17T15:19:41Z

The Android builds so far were shells around the live site: a verified APK proved nothing about the code that ran. The new `fdroid` flavor (io.coinos.fdroid) shares the WebView shell and carries the built web app in its assets. The page still lives at the v3.coinos.io origin — same storage, links and gift URLs — but every file under it is answered from the APK (Assets.java); only the site's live API paths reach the network, and the bundled page registers no service worker (HAL_NO_SW=1). Two clean unsigned builds give the same APK. COINOS_UNSIGNED=1 builds without the keystore; Bun is pinned via packageManager; the Gradle wrapper properties pin 8.12. fdroid/io.coinos.fdroid.yml is the fdroiddata recipe (checksum-pinned Bun in sudo, prebuild web build, scandelete, our signing key allowed for the Binaries match) and docs/REPRODUCIBLE.md the how-to. Verified on a phone: the bundled build cold-starts in airplane mode. Co-Authored-By: Claude Fable 5.1 Claude-Session: https://claude.ai/code/session_01JuwQqNWtDJcxPWtEm9134z

A second Android build that can wake the wallet, because it holds it.

2026-09-12T17:32:01Z

The TWA can't. Chrome renders the site, so the wallet's keys live in Chrome's storage for its own origin, and nothing outside Chrome can reach them — a UnifiedPush message could raise a notification and no more. On a phone with Google Play Services none of this matters; without it, background answering was simply unavailable. So: a second flavour, io.coinos.webview, "Coinos (UnifiedPush)". The wallet runs in a WebView this app owns, which means a push can start it off-screen and let it answer for itself. WakeService loads it with ?wake= into the same storage the visible app uses, the page subscribes and answers whatever the payload was about, then calls CoinosHost.done() so the service stops — capped at 25 seconds from the page and 30 from the service, because nothing here is allowed to sit in the background costing battery. Its foreground notification says what it's doing rather than apologising for existing. The WebView carries what the wallet actually needs: DOM storage and IndexedDB, the camera for the QR scanner (granted only once Android has granted it to us), a file chooser for attaching pictures, and links to anywhere but coinos.io handed to a real browser. The trade is named in the code and worth naming here: a separate app is a separate wallet. Its storage is its own, so signing in there is signing in again. That's why this is a second build rather than a replacement — the TWA is untouched, still the better browser for anyone whose phone has push. The shared push receiver now asks the system for whatever front door this build has, and asks a per-flavour Wake class whether the wallet can be woken at all — no flavour checks in the middle of it. Both APKs build and ship: coinos.apk as before, coinos-unifiedpush.apk beside it. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_019mrt228Upn9nNCwGixzSLx