android: the handoff — the pending rounds, the pipeline, and what is unverified

Everything written this session that has not been through the device: rounds 43
to 48 (each patch adversarially verified, 43's transient-notice expectation
fixed), a partial round 49, the pipeline scripts, the Android Auto design and
the icon comparison mock. Also the two harness changes that were never A/B'd —
adaptive waits, which may only shorten a declared wait and never lengthen it,
and a ship that runs the mock walk and the deploy at the same time. The A/B and
its 255-step baseline are in handoff/tools; main stays at what the phone has
actually walked.

handoff/rounds/ins-r44-doc-section.txt

@@ -0,0 +1,91 @@
+## 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.