SoulStream

3 Commits

Include renames

Author SHA1 Message Date

Author	SHA1	Message	Date
KeelrLeek	da4abeb8c9	android: the launcher's ground is the desktop's, not a flat colour under it The icon round left the adaptive background as one `#FF05080B` and a note that a gradient was being mocked. The mock settles it: the falcon covers about a quarter of a circle-masked tile, so the ground is three quarters of what anyone sees, and concept 04's glow survives every mask — the visible top-left corner goes from `#05080B` to `#0E3543`. So `@color/ic_launcher_background` becomes `@drawable/ic_launcher_ground`, a vector carrying the desktop icon's own linear surface and the radial glow over it, every number `src-tauri/icons/icon.svg`'s multiplied by 108/1024 and nothing else. The colour resource stays where it is, unreferenced, because its filename is the only thing stopping tauri's own `#fff` from colliding with it. A vector and not five PNGs on evidence. The kit's glow has a uniform scale, so the SVG ellipse is a circle and its rotation is a no-op, which is exactly what `android:type="radial"` can carry; two numbers there and no vector could have said it. The linear axis is 51.1° off horizontal, which rules out a `<layer-list>` of shapes as well, whose angle must be a multiple of 45. It was compiled and linked with the SDK's own aapt2 over the real merged res tree and every stop read back out of the APK. The name is `ic_launcher_ground` and not `ic_launcher_background` on purpose: the generated project still carries Android Studio's template drawable of that name, so under the other name an overlay copy that failed would silently link the green robot — under this one it is a hard link error, which was tested too. `verify-icon.sh` follows the layer. It does not ask whether the file is in the APK; it asks what the adaptive icon's `<background>` resolves to, through the resource table, in both build types, and then reads concept 04's six stops back out of what it found — which catches a stale APK as well as a lost overlay. Passing on a debug APK and on one put through `--shorten-resource-paths`, failing on a stale one, and saying NOT CHECKED rather than guessing when aapt2 is absent. What none of it can see is a pixel: banding on the OLED, the glow's weight under the Pixel's mask and how the falcon reads on a lit ground are a launcher screenshot on the phone, and ANDROID.md says so instead of implying the check covers it. One slot the ground reaches is not the launcher at all. `MediaHub.appIcon()` draws whatever `getApplicationIcon()` returns into a 512 px bitmap and hands it to the lock-screen card as the large icon for any track whose cover has not been decoded yet, so the card and the shade carry this ground as well — the quickest place for Kyle to look at it, and the only reader of the launcher icon inside the app. The walk reads that card's title and the session's playback state and never its icon, so no step changes meaning. The Android 12+ splash very likely changes as well, and the other way from what the docs' one-line version of the rule suggests: the platform drops an adaptive background only when it is a single colour close to `windowSplashScreenBackground`, which round 44's flat `#05080B` was, so the falcon has been drawing there alone and enlarged; a gradient is not one colour, so it is kept and the whole icon is drawn. Likely, not proven — that one is a screenshot too.	2026-09-15 07:22:02 -05:00
KeelrLeek	d42645d2a0	android: the icon where it moves — the glyph, the lock screen and a splash that is not white Both notification glyphs are the same falcon now, the logo kit's monochrome path verbatim inside a group that re-frames it for a 24dp box — the playback card's and the transfers notice's, because a note beside an arrow does not read as one app, and the transfers one keeps the tray bar it always had so the falcon dives into it. The fill stays white on transparent: the shade composites a small icon from its alpha channel alone and tints it itself, so a coloured export would arrive as a white blob. The lock screen falls back to the app's own icon instead of a grey hole. `MediaHub.art` is null from the moment a track changes until the frontend has finished decoding its cover, and null forever for a track with none, so `appIcon()` decodes the launcher icon ONCE — through the PackageManager, because a library module's R has no `ic_launcher` — and hands it to both the card and `METADATA_KEY_ALBUM_ART`. The app manifest lives in gitignored `gen/` and declares no category, so the media-session plugin's own library manifest contributes `android:appCategory="audio"` through the merger, and a `Theme.App.Starting` on the brand ground replaces Android 12+'s white flash — in `values-v31` and `values-night-v31` both, because the qualifier order puts night mode ahead of platform version and a splash written only into `values-v31` is silently ignored on a dark-mode phone. The walk gains `media-card`: after the session block, the card is still posted on the `playback` channel with the playing track's title on it, and `media-keys` below it still gets the transport back — which is what a drawable the shade cannot inflate would actually break. The glyph itself and the splash are screenshots; `dumpsys notification` prints a resource id and never a pixel, and the splash is gone before the walk's first frame.	2026-09-15 07:22:01 -05:00
KeelrLeek	4ebc38d5f3	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.	2026-09-15 07:22:00 -05:00

da4abeb8c9

android: the launcher's ground is the desktop's, not a flat colour under it

The icon round left the adaptive background as one `#FF05080B` and a note that
a gradient was being mocked. The mock settles it: the falcon covers about a
quarter of a circle-masked tile, so the ground is three quarters of what
anyone sees, and concept 04's glow survives every mask — the visible top-left
corner goes from `#05080B` to `#0E3543`. So `@color/ic_launcher_background`
becomes `@drawable/ic_launcher_ground`, a vector carrying the desktop icon's
own linear surface and the radial glow over it, every number
`src-tauri/icons/icon.svg`'s multiplied by 108/1024 and nothing else. The
colour resource stays where it is, unreferenced, because its filename is the
only thing stopping tauri's own `#fff` from colliding with it.

A vector and not five PNGs on evidence. The kit's glow has a uniform scale, so
the SVG ellipse is a circle and its rotation is a no-op, which is exactly what
`android:type="radial"` can carry; two numbers there and no vector could have
said it. The linear axis is 51.1° off horizontal, which rules out a
`<layer-list>` of shapes as well, whose angle must be a multiple of 45. It was
compiled and linked with the SDK's own aapt2 over the real merged res tree and
every stop read back out of the APK. The name is `ic_launcher_ground` and not
`ic_launcher_background` on purpose: the generated project still carries
Android Studio's template drawable of that name, so under the other name an
overlay copy that failed would silently link the green robot — under this one
it is a hard link error, which was tested too.

`verify-icon.sh` follows the layer. It does not ask whether the file is in the
APK; it asks what the adaptive icon's `<background>` resolves to, through the
resource table, in both build types, and then reads concept 04's six stops back
out of what it found — which catches a stale APK as well as a lost overlay.
Passing on a debug APK and on one put through `--shorten-resource-paths`,
failing on a stale one, and saying NOT CHECKED rather than guessing when aapt2
is absent. What none of it can see is a pixel: banding on the OLED, the glow's
weight under the Pixel's mask and how the falcon reads on a lit ground are a
launcher screenshot on the phone, and ANDROID.md says so instead of implying
the check covers it.

One slot the ground reaches is not the launcher at all. `MediaHub.appIcon()`
draws whatever `getApplicationIcon()` returns into a 512 px bitmap and hands
it to the lock-screen card as the large icon for any track whose cover has
not been decoded yet, so the card and the shade carry this ground as well —
the quickest place for Kyle to look at it, and the only reader of the
launcher icon inside the app. The walk reads that card's title and the
session's playback state and never its icon, so no step changes meaning. The
Android 12+ splash very likely changes as well, and the other way from what
the docs' one-line version of the rule suggests: the platform drops an
adaptive background only when it is a single colour close to
`windowSplashScreenBackground`, which round 44's flat `#05080B` was, so the
falcon has been drawing there alone and enlarged; a gradient is not one
colour, so it is kept and the whole icon is drawn. Likely, not proven — that
one is a screenshot too.

2026-09-15 07:22:02 -05:00

KeelrLeek

d42645d2a0

android: the icon where it moves — the glyph, the lock screen and a splash that is not white

Both notification glyphs are the same falcon now, the logo kit's monochrome
path verbatim inside a group that re-frames it for a 24dp box — the playback
card's and the transfers notice's, because a note beside an arrow does not
read as one app, and the transfers one keeps the tray bar it always had so
the falcon dives into it. The fill stays white on transparent: the shade
composites a small icon from its alpha channel alone and tints it itself, so
a coloured export would arrive as a white blob.

The lock screen falls back to the app's own icon instead of a grey hole.
`MediaHub.art` is null from the moment a track changes until the frontend has
finished decoding its cover, and null forever for a track with none, so
`appIcon()` decodes the launcher icon ONCE — through the PackageManager,
because a library module's R has no `ic_launcher` — and hands it to both the
card and `METADATA_KEY_ALBUM_ART`. The app manifest lives in gitignored
`gen/` and declares no category, so the media-session plugin's own library
manifest contributes `android:appCategory="audio"` through the merger, and a
`Theme.App.Starting` on the brand ground replaces Android 12+'s white flash —
in `values-v31` and `values-night-v31` both, because the qualifier order puts
night mode ahead of platform version and a splash written only into
`values-v31` is silently ignored on a dark-mode phone.

The walk gains `media-card`: after the session block, the card is still
posted on the `playback` channel with the playing track's title on it, and
`media-keys` below it still gets the transport back — which is what a
drawable the shade cannot inflate would actually break. The glyph itself and
the splash are screenshots; `dumpsys notification` prints a resource id and
never a pixel, and the splash is gone before the walk's first frame.

2026-09-15 07:22:01 -05:00

KeelrLeek

4ebc38d5f3

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.

2026-09-15 07:22:00 -05:00