android: the falcon on the launcher — a real adaptive icon, with the monochrome layer

The phone has been wearing tauri's logo. `tauri android init` writes the
generated project's `res/` from its own template and never reads
`src-tauri/icons/android/`, which has carried the falcon since 50afa6a, and the
detour build runs cargo and Gradle directly — so nothing ever copied it across:
the two dominant colours in the packaged `mipmap-xxxhdpi/ic_launcher.png` are
`#24c8db` and `#ffc131`, tauri's own brand cyan and amber. `src-tauri/android/res/`
is the app module's res now, tracked, and `build.sh` and `dev.sh` copy the whole
tree into `gen/android` before Gradle, because that project is regenerated and
gitignored and an asset that only lives there is an asset that disappears.

It is a real adaptive icon: the kit's foreground and its **monochrome** layer at
five densities, the legacy mipmaps under it, and the background as one
`#FF05080B` colour resource rather than five identical flat PNGs, so the gradient
being mocked separately replaces one file. The kit's own XML could not ship — it
points every layer at `@drawable/` while shipping them as PNGs under `mipmap-*`,
and in the generated project two of those three references resolve to Android
Studio's template robot rather than failing — so the overlay's XML says
`@mipmap/` and `@color/`, and its colour file takes the same name tauri's does,
because two files declaring one colour is a hard aapt2 error.

Losing the copy would be silent — the APK still builds, still installs, and wears
the old logo with nothing in the log — so `verify-icon.sh` opens every APK both
scripts make and reads the resources back out: the two `mipmap-anydpi-v26` XMLs
present, and four PNG names at five densities byte for byte from the overlay. A
release APK keeps neither the bytes nor the names — AGP re-encodes every PNG and
shortens every resource path — so that path asks `aapt2 dump resources` what each
name points at and compares pixel dimensions instead; 72×72 at hdpi still tells
the kit's icon from tauri's 49×49. No walk step: a launcher icon is not reachable
from inside the app, and the masking and the themed layer want a minute with the
phone's home screen.

ANDROID.md

@@ -30,6 +30,7 @@ implements is `research/mobile-mockup/` (gitignored; see its README).
 | `src-tauri/tauri.android.conf.json` | merged over `tauri.conf.json` on Android: one window at `mobile.html`, no desktop resources, `minSdkVersion` 26 |
 | `src-tauri/gen/android/` | the generated Gradle project (`npx tauri android init`); `minSdk = 26`. Gitignored |
 | `src-tauri/android/build.sh`, `deploy.sh` | the detour build (below) and build → install → launch → screenshot |
+| `src-tauri/android/res/` | the app module's own Android resources, tracked: the adaptive launcher icon, its monochrome layer, the legacy mipmaps and the one colour the background is. `build.sh` and `dev.sh` copy the whole tree into `gen/android/app/src/main/res/` before Gradle; `verify-icon.sh` reads it back out of the APK |
 | `src-tauri/src/android_glue.rs` | `JNI_OnLoad`: hands the JavaVM and app Context to `ndk-context` (cpal's AAudio backend needs it; tao 0.35 never fills it) |
 | `src-tauri/src/updater_mobile.rs` | the updater's stand-in on mobile (`#[cfg(mobile)] #[path]`) |
 | `src-tauri/src/lyric_align_stub.rs`, `vocal_sep_stub.rs` | stand-ins off Windows for the two Windows ML modules |
@@ -1284,6 +1285,8 @@ cargo build --lib -p app --target aarch64-linux-android --features tauri/custom-
 # 1. strip the library's debug info (607 MB → 50 MB; the debug packaging keeps symbols)
 cp target/aarch64-linux-android/debug/libapp_lib.so src-tauri/gen/android/app/src/main/jniLibs/arm64-v8a/
 "%LOCALAPPDATA%\Android\Sdk\ndk\28.2.13676358\toolchains\llvm\prebuilt\windows-x86_64\bin\llvm-strip.exe" --strip-debug src-tauri/gen/android/app/src/main/jniLibs/arm64-v8a/libapp_lib.so
+# 1b. the app's own resources, over the generated project's (the launcher icon)
+cp -r src-tauri/android/res/. src-tauri/gen/android/app/src/main/res/
 # 2. package with Gradle, skipping the task that would redo the symlink
 cd src-tauri/gen/android && ./gradlew.bat assembleArm64Debug -x rustBuildArm64Debug
 ```
@@ -1477,6 +1480,98 @@ A command that has been renamed answers `No command <name> found for plugin
 <class>`, which lands in logcat rather than on screen:
 `adb logcat --pid=$(adb shell pidof com.soulstream.app)`.
 
+## The launcher icon
+
+Until this round the phone wore **tauri's** logo. `tauri android init` writes
+the generated project's `res/` from its own template and never reads
+`src-tauri/icons/android/` — which has carried the falcon since `50afa6a`
+— and the detour build runs cargo and Gradle directly, so nothing ever
+copied it across. The two dominant colours in
+`gen/android/app/src/main/res/mipmap-xxxhdpi/ic_launcher.png` were `#24c8db`
+and `#ffc131`: tauri's brand cyan and tauri's brand amber.
+
+`src-tauri/android/res/` is the app module's res, tracked, and `build.sh` and
+`dev.sh` copy the whole tree into the generated project before Gradle runs.
+It carries:
+
+- `mipmap-anydpi-v26/ic_launcher.xml` and `ic_launcher_round.xml` — the
+  adaptive icon: a foreground, a background, and a **monochrome** layer, which
+  is what Android 13's themed icons need and what tauri's generator has never
+  made;
+- `mipmap-{m,h,xh,xxh,xxxh}dpi/` — `ic_launcher_foreground.png` and
+  `ic_launcher_monochrome.png` (108–432 px) from the kit's
+  `android/adaptive/res/`, and the legacy `ic_launcher.png` /
+  `ic_launcher_round.png` (48–192 px) from its `android/legacy/`;
+- `values/ic_launcher_background.xml` — `#FF05080B`, the brand's night.
+
+Three things about it are not obvious.
+
+**The kit's own adaptive XML does not compile here.** Its
+`android/adaptive/res/mipmap-anydpi-v26/*.xml` points every layer at
+`@drawable/…`, and the kit ships those layers as PNGs under `mipmap-*` with
+no `drawable-*` directory anywhere. That is worse than a missing resource:
+the generated project still carries Android Studio's template vectors at
+`drawable/ic_launcher_background.xml` and
+`drawable-v24/ic_launcher_foreground.xml`, so two of the three references
+resolve — to the green robot — and only `@drawable/ic_launcher_monochrome`
+fails the build. The overlay's XML says `@mipmap/` for the two image layers
+and `@color/` for the background instead.
+
+**The background is one colour resource, not five identical flat PNGs.**
+A richer gradient is being mocked separately; when it is approved it replaces
+one file, and the three XML references do not move.
+
+**The colour file is named `ic_launcher_background.xml` on purpose.**
+`src-tauri/icons/android/values/ic_launcher_background.xml` declares the same
+resource name (`#fff`), and two files in one `values/` directory declaring
+one colour is a hard aapt2 error — `resource 'color/ic_launcher_background'
+has a conflicting value`. Sharing the filename means the overlay overwrites
+it rather than colliding with it, if a future `npx tauri android init` ever
+copies it in.
+
+That leaves `src-tauri/icons/android/` a second, stale copy of these same
+resource names: white background, no monochrome, hdpi at 49×49. Nothing on
+Android reads it while the build is the detour — but `npx tauri icon` writes
+it, and it should be brought to the kit before anyone builds through the CLI.
+
+### Checking it
+
+`verify-icon.sh` opens the APK `build.sh` has just made and reads the
+resources back out. It checks the overlay's own two XMLs first, before the APK
+is opened — a `<monochrome>` layer that a later edit drops is a failure too —
+and then reads the APK, debug and release differently, because AGP hands them
+to aapt2 differently:
+
+- **debug** — the packaging default for a debuggable build type is
+  `--no-crunch`, so every entry *is* the file on disk. Both
+  `res/mipmap-anydpi-v26/*.xml` must be in the APK, and all four PNG names at
+  all five densities must be byte for byte the overlay's.
+- **release** (`--crunched`) — aapt2 re-encodes every PNG, *and* AGP's
+  resource optimization (`OptimizeResourcesTask` → `SHORTEN_RESOURCE_PATHS`)
+  renames the lot: an APK optimized here had no `res/mipmap-…` entry left at
+  all, only `res/Ag.png`. Neither the bytes nor the names survive, so the
+  check asks `aapt2 dump resources` what each name points at and compares the
+  pixel dimensions of whatever that is — 72×72 at hdpi still separates the
+  kit's legacy icon from tauri's 49×49. If the resource *names* have been
+  collapsed as well (that comes with resource shrinking, which this project
+  does not turn on), it says the icon is unchecked rather than claiming a
+  failure it cannot see.
+
+Both `build.sh` and `dev.sh` call it, so no APK this repo makes can quietly go
+back to the old artwork. It costs about a second and a half on the 107 MB
+debug APK.
+
+What it cannot check is what the icon looks like. `deploy.sh`'s `px-1.png` is
+a screenshot of the app five seconds after launch; the launcher is not in it.
+The one thing that may now differ there is the Android 12+ system splash,
+which is drawn from the launcher icon — if a cold start ever runs past those
+five seconds, that splash is the falcon on `#05080B` rather than tauri's mark.
+**Adaptive masking and the monochrome layer can only be judged from the
+phone's home screen**, which is a minute with the Pixel: the icon under the
+launcher's mask, in the app drawer, in recents and in another app's share
+sheet — and then Wallpaper & style → Themed icons on, to see the monochrome
+layer take the wallpaper's colour.
+
 ## Verifying
 
 ```bash