The previous commit made build.yml unparseable and no job ran at all:
yaml: line 183: could not find expected ':'
A `run: |` block is a YAML literal scalar, so every line has to keep the
block's indentation. The python3 fallback I added used a heredoc whose
body sat at column 0, which terminates the scalar -- YAML then tried to
read `import zipfile, sys` as a mapping and gave up. Worse than a broken
check: a broken pipeline.
The fallback is gone rather than re-indented. unzip is present on this
runner, a second code path existed only to guard against a case that was
never observed, and its only contribution was an escaping hazard inside
YAML inside shell.
Verified before pushing this time, which is the actual lesson:
- build.yml now parses (yaml.safe_load), 6 + 15 steps;
- the guard's `run` script was extracted from the parsed YAML and executed
verbatim against the real 45MB base.apk pulled off the device. It prints
the drawable inventory, reports ic_stat_pluriwave OK and ic_auto_eq_on /
ic_auto_eq_off missing, and exits 1 -- matching an independent zipfile
inspection of the same file.
Two commits in a row shipped a CI change that had never been run. Both
were caught by the user rather than by me.
The guard added in the previous commit reported all three drawables as
missing on its first run, including ic_stat_pluriwave -- which is
verifiably present: it was read out of the base.apk pulled off the device
byte by byte. The step also finished in 0s, so it never opened the file at
all. Either the APK is not at the assumed path on this runner or unzip is
unavailable, and the failing pipeline silently produced an empty listing
that every grep then "failed" against.
A guard that lies is worse than no guard: it sends you hunting ghosts,
which is exactly the failure mode this whole episode has been about.
It now verifies its own preconditions before judging anything:
- the APK must exist, and if it does not the step prints where the APKs
actually are (find over build/app/outputs) instead of guessing;
- it needs unzip or python3, and says so plainly if neither is there;
- an empty listing is treated as "inspection unreliable", not as
"everything is missing";
- it dumps the real res/drawable inventory before the verdict, so a
future failure is readable without another round trip.
Matching is now exact (grep -qx) rather than substring.
The logic was run locally against the real 45MB base.apk taken off the
device: ic_stat_pluriwave OK, ic_auto_eq_on and ic_auto_eq_off missing --
which is precisely what an independent zipfile inspection of the same APK
reported yesterday. The check agrees with reality before shipping.
History review requested by the owner: when and why did the Android Auto
UI stop working.
ANSWER: 31 July, commit 2540556, "give the equalizer actions distinct,
state-aware icons".
9eff760 (31-07) androidIcon: 'drawable/ic_stat_pluriwave' -> in the APK
2540556 (31-07) androidIcon: 'drawable/ic_auto_eq_on' -> NEVER in it
That commit swapped a drawable that shipped for two that the stale CI
resource cache never included. From that moment getResourceId returned 0,
PlaybackStateCompat.CustomAction.Builder threw, and the throw aborted
AudioService.setState before the session was published -- so every Android
Auto symptom chased since is one line of that commit. The bitter part is
that 2540556 was itself a fix for a report about two identical icons.
Three changes.
1. CI guard. The build now unzips the release APK and fails if a drawable
resolved by NAME at runtime is missing. Resolution by name cannot fail at
compile time -- it fails in the car, silently, with id 0. This class of
bug shipped undetected for a week; it cannot ship again.
2. Skipping stations now walks the favourites GROUP first, as requested:
group -> all favourites -> my stations -> catalogue. Two deliberate
exclusions, both tested: `sinAsignarId` is the ABSENCE of a group, not a
group, so those walk all favourites; and a one-member group falls through
too, or both buttons would be dead ends. The group is read from the
FAVOURITE record, never from the playing station -- that one is rebuilt by
emisoraDesdeMediaItem, which carries no group id and would always report
"unfiled".
3. Diagnostics on the station skip. It was reported as doing nothing for
radio, and every early return in that method is silent: an empty list and
a single-entry list look identical from outside. The log now names which
one fired, so the next capture answers it instead of another hypothesis.
Tests: 1161 -> 1165.
The equalizer drawables were never in the shipped binary. Verified by
pulling base.apk off the device and reading it:
res/drawable/ic_stat_pluriwave.xml PRESENT (added 02-07)
res/drawable/ic_auto_eq_on.xml ABSENT (added 31-07, 2540556)
res/drawable/ic_auto_eq_off.xml ABSENT
Neither as a zip entry nor as a name in resources.arsc. Both files are in
git with content and on disk; the older sibling in the same folder is in
the APK. The difference is when they were added.
This runner is self-hosted and the workflow never cleaned, so build/
survives between runs and Gradle's incremental resource merge went stale:
resources present when the cache was built kept working, resources added
afterwards silently never made it in.
The cost was weeks of wrong diagnosis. getResourceId returned 0 for that
icon, PlaybackStateCompat.CustomAction.Builder throws on a 0 icon, and
that throw aborts AudioService.setState BEFORE mediaSession.setActive --
so Android Auto held a frozen, inactive session. On the device that
surfaced as a dead playback screen, a play button that never became
pause, PluriWave losing its pane to whichever app did have an active
session, and audio that played "as if it were not the app". One cause,
four symptoms.
Dart changes always shipped because Dart is recompiled every build, which
is exactly why this hid for so long: every fix appeared to land and
nothing behaved differently.
flutter clean costs build time. It buys the guarantee that what is in git
is what is in the binary, which this project just spent weeks not having.
Adds tool/check_arb_placeholder_corruption.py, a static check that flags
literal "?" glued to an ICU placeholder brace in any lib/l10n/app_*.arb
value that has a placeholders metadata block. This is the exact corruption
shape fixed in the previous commit; flutter analyze doesn't catch it since
the JSON/ICU stays syntactically valid. Wired as a CI step before
flutter analyze so it fails fast.
Also audited lib/l10n/app_localizations_ext.dart (hand-maintained weekday/
month/date-sentence maps, not covered by ARB tooling): all 22 locale maps
have the full 13/13 keys with no corruption or leftover English — no
changes needed there.
The app is stable, so mark this as the 1.0.0 milestone. The CI bump step
now honors a [version set] marker: when present it ships the pinned semver
as-is and only advances the build number (Play requires it monotonic),
instead of the automatic patch bump that cannot cross the 0.x -> 1.0.0
boundary. Normal commits keep auto-incrementing the patch (1.0.1, 1.0.2, ...).
- Remove complex Python wrapper that caused timeout issues
- Use direct flutter test with --concurrency=1 --timeout=60s
- Simplify cleanup with pkill instead of Python loop
- Increase timeout from 4m to 15m (tests take ~10s but CI overhead is high)
FreeTLab
Javier Bautista Fernández