ci(size): TV APK size baseline is stale — the gate now fails every PR that builds TV

[ucguy4u]

The TV leg of build-android fails the APK size guardrail on PRs that do not change TV size at all.

Measurement

• Gate reading on fix: Pixel 9 QA pass — chat dead end, silent playlist failure, forced portrait, red suites #1362: tv | app-arm64-v8a-release.apk | 31.80 MB | budget 35.00 MB | baseline 29.63 MB | +7.31% | FAIL: exceeds 5% baseline increase
• Built origin/main (678446b3) locally with the exact CI flags (--release --target=lib/main_tv.dart --target-platform=android-arm64 --dart-define=APP_VARIANT=tv --dart-define=APP_PLATFORM=androidTv --tree-shake-icons --split-debug-info --obfuscate): 31.80 MB, the same figure.

So main itself is 7.31% over the recorded baseline. The PR is size-neutral; the gate is measuring accumulated growth on main and charging it to whichever PR runs next. Every PR that builds the TV variant fails this check until the baseline moves.

Why the baseline never caught up

.github/apk-size-baselines.tsv says "This file is updated automatically after successful main builds", but its last content change was 18200609 (shell/TV/Coins composition unification). The update-apk-size-baselines job reports skipping on PR runs, and it cannot run after a main build that fails this same gate — so once main drifts past 5%, the refresh path is unreachable and the gate stays red for everyone.

Current recorded baselines:

component	baseline	budget
full	453201577 B (432.2 MB)	35 MB
tv	31071323 B (29.63 MB)	35 MB
coins	20745001 B (19.78 MB)	25 MB

(The full row is also worth a look — a 432 MB baseline against a 35 MB budget column reads like the budget is not being applied to that component.)

Decisions needed from the release owner

1. Where did the 2.2 MB go? Absorbing it into the baseline accepts it permanently. It may be legitimate (TV gained features since 18200609) or a regression worth reverting; it should be attributed before it is accepted.
2. Refresh the baseline to main's measured size once (1) is answered, in a commit that cites the measurement.
3. Break the deadlock so this cannot recur: let the baseline refresh run on main even when the delta check fails (report-only on main, enforcing on PRs), or allow an explicit labelled override on a PR that intends to move the baseline.

Not fixing this in #1362, because bumping a size guardrail permanently accepts growth that PR did not cause.

[ucguy4u]

Attributed and fixed in #1366 — no baseline change needed.

The accumulated 2.2 MB was non-target-ABI native libs from plugin AARs. --target-platform=android-arm64 filters only Flutter's own libflutter.so/libapp.so; libs delivered inside a plugin AAR (sqlite3_flutter_libs) keep every ABI they were published with, so the arm64-only TV APK was carrying:

 1.48 MB  lib/x86_64/libsqlite3.so
 1.45 MB  lib/armeabi-v7a/libsqlite3.so
 0.17 MB  libdartjni.so + libdatastore_shared_counter.so, both extra ABIs

Excluding non-target ABIs in packaging.jniLibs takes the TV release from 31.80 MB to 28.62 MB — back under the 29.63 MB baseline, so the gate passes on the recorded number rather than a raised one. full and coins use the same single-ABI CI flags and get the same cut.

Points 1 and 2 of this issue are answered by that. Point 3 — the refresh deadlock, where a main build that fails this gate can never update the baseline it failed against — is still worth fixing on its own, since the next genuine growth will reproduce the same stuck state.

[ucguy4u]

Measured the full row while doing release-mode qualification, since it looked wrong in the original report.

Built the phone flavor from merged main with the exact CI full-profile flags: 80.93 MB (arm64, tree-shaken, obfuscated). The recorded baseline for that component is 453201577 bytes = 432.2 MB, with a 35 MB value in the budget column.

So the full row is not just stale — it is measuring a different artifact shape than CI now produces (a fat/multi-ABI or unobfuscated build), and at 432 MB no plausible regression could ever trip its 5% delta. enforceReleaseBudget is false for that profile, so the 35 MB budget column is inert too. Net effect: the full app currently ships with no size guardrail in either dimension.

Once #1366 and #1368 land, the first main build will record 80.93-ish MB for full and the delta gate becomes meaningful there for the first time. Worth a deliberate look at that first refreshed baseline rather than letting a 432 MB → 81 MB correction land unnoticed.

[ucguy4u]

Status update on the remaining half of this issue, since it turns out to be blocked on main's CI rather than on a decision.

Resolved: the TV overrun was non-target-ABI plugin libs (#1366), which took TV from 31.80 MB to 28.63 MB — back under the recorded 29.63 MB baseline, so the gate passes on the number already in the file. The refresh deadlock is fixed by #1368.

Still open: the full row reads 453201577 bytes (432.2 MB) against an artifact that actually measures 80.93 MB when built with the CI flags (--release --target-platform=android-arm64 --tree-shake-icons --split-debug-info --obfuscate). With enforceReleaseBudget: false on that profile, the 35 MB budget column is inert too, so the full app has no size guardrail in either dimension — it could grow five-fold without tripping the 5% delta.

Why it has not self-corrected: update-apk-size-baselines has needs: [build-android] and only runs on push to main. Main's CI has been failing, so the job never runs and the file stays frozen at the values recorded in 18200609:

• run 30547730339 (13:37) — analyze: failure
• run 30550973082 (14:17, after fix(ci): stop analysing patrol suites that cannot resolve #1378 and refactor(coins): move CoinVaultModule into the package it registers #1380 merged) — analyze: failure again

That second failure is not the analyzer. It is exit 123 from the job's "Check formatting" step: three files landed unformatted on main (airo_lan_sync_service.dart, mobile_actions_screen.dart, remote_agent_skill_installer.dart). #1381 fixes that.

So the sequence to close this issue is: land #1381 → main CI goes green → the baseline job runs for the first time since 18200609 → full drops from 432 MB to its real ~81 MB. That correction is large enough to be worth a deliberate look when it lands rather than letting it pass unnoticed, which is the point I raised earlier.