Reportado desde el uso real: desde el movil el ecualizador va bien, pero el
boton de Android Auto a veces no hace nada y a veces suena como si se aplicara
una doble ecualizacion.
El preset del handler nunca se sembraba desde disco
`_presetActual` arrancaba en `flat` a fuego. registrarHandler sembraba el flag
de encendido pero no el preset, asi que en un motor donde la interfaz del
telefono nunca corrio -- el que arranca Android Auto -- el toggle del coche
aplicaba `flat`, o lo que hubiera quedado, en vez del preset del usuario. Es la
misma clase de fallo que ya se corrigio para el flag: aquel recibio un puerto
headless y el preset se quedo fuera. Ahora tiene el suyo, con la misma forma:
opcional, el fallo se traza y cae al valor por defecto, nunca propaga.
La siembra respeta un preset ya elegido por EstadoEcualizador, que es mas rico
que la clave principal, para que la lectura de disco en vuelo no lo pise.
El efecto se habilitaba antes de escribir las ganancias
La ruta era setEnabled -> setEnabled -> ganancias: `aplicarPreset` volvia a
llamar a setEnabled por su cuenta. Entre la habilitacion y la escritura sonaban
las ganancias anteriores, y ese hueco es lo que se percibia como doble
ecualizacion. Ahora una funcion pura devuelve los pasos en orden y ambas rutas
la recorren: ganancias primero, habilitacion despues.
Las ganancias NO se resetean al apagar, y es deliberado: setEnabled(false)
puentea el efecto sin liberarlo ni limpiar sus niveles, y la ruta de encendido
los reescribe enteros antes de habilitar, asi que no queda ninguna ventana de
ganancia rancia que un reset pudiera cerrar.
El boton desaparecia en cada cambio de emisora
`_recrearPlayer` bajaba `_eqDisponible` sin republicar controles, asi que cada
cambio de emisora emitia al menos un estado sin la accion de EQ. Peor: las
llamadas nativas estan detras de ese flag, de modo que un toggle en esa ventana
cambiaba el icono sin tocar el audio. Ahora el unico que lo escribe es
`_activarEcualizador`.
Mantenerlo optimista exigia quitar de la ruta del toggle el `await
_eq.parameters`, que es un Completer que solo se completa cuando el reproductor
se engancha: esperarlo dejaba el boton pendiente durante toda la carga, y para
siempre si la carga fallaba. Se cachean los parametros al activarse.
Los fallos nativos dejan de ser mudos
El `catch (_) {}` ocultaba que la llamada nativa habia fallado y dejaba el icono
afirmando un estado que el audio no tenia. Ahora se traza, y un fallo al
habilitar revierte el flag, republica los controles y no persiste.
EstadoEcualizador adopta lo que el motor acepto en vez de asumir que su peticion
prospero: sin eso, el telefono escribia en disco un valor que el handler acababa
de rechazar, reabriendo la divergencia que el dueño unico habia cerrado.
Suite completa: 1515 pasan, 2 omitidos. flutter analyze mantiene los 5 avisos
preexistentes.
Desde el 29-08 ningun build de main volvio a aparecer en builds.freetimelab.es,
y nada avisaba: el job salia verde porque el scp subia correctamente, solo que a
una ruta que el indexador no lee.
El portal indexa DOS niveles, <app>/<version>/<ficheros>. La solucion anterior
metia la rama como TERCER nivel (pluriwave/main/v1.3.3/), asi que sus ficheros
quedaban fuera del indice: 39 versiones listadas, ninguna con "main", ninguna
con los codigos 158, 159 ni 160. Encima el echo del propio paso tenia "pluriwave"
escrito a fuego y anunciaba la carpeta antigua, congelada desde el +157, que es
justo donde se miraba al no encontrar nada.
Ahora la rama va en el NOMBRE DE LA APP, que es lo que el portal si entiende.
PRO conserva la entrada limpia "pluriwave" y main tiene la suya, igual que ya
conviven radar-foral y radar-foral-android. Se cumple el objetivo original -- que
el build de desarrollo no aparezca como ultima version de release -- sin romper
el indexado. La ruta impresa se deriva de la misma variable, para que no puedan
volver a desincronizarse.
Se alinea tambien el arreglo del secreto de Google Play que ya esta en PRO: el
paso se omite con un aviso en vez de hacer `exit 1`, y el mensaje de Telegram
deja de afirmar que se publico algo que no se publico. main nunca ejecuta esos
pasos, pero mantener un unico workflow evita conflictos en cada trasvase entre
ramas.
Dos fallos reportados desde el uso real en el coche.
Los grupos de favoritos no volvian al importar
La exportacion nunca estuvo rota: los grupos viajaban desde siempre y la
asignacion de cada emisora va dentro de cada favorito como grupo_id. El fallo
estaba solo al importar. La restauracion reutilizaba ServicioFavoritos.agregar,
que fuerza "sin asignar" a proposito, porque una emisora recien marcada como
favorita no tiene grupo. Correcto para esa ruta, destructivo como primitiva de
restauracion: los grupos volvian vacios y todo aterrizaba en Sin asignar. Se
separa la ruta de restaurar, que respeta el grupo_id del backup y su orden.
Ningun test lo detectaba porque el doble de pruebas era infiel: el fake
conservaba el grupo que la implementacion real destruia, y no tenia
restaurarGrupo, asi que esa ruta estaba sin cubrir. Los tests existentes lo
esquivaban pasando siempre una lista de grupos vacia. Se corrige el doble.
No hace falta subir la version del formato: el envoltorio ya llevaba todo.
El coche perdia la lista al reconectar
El contexto de reproduccion vivia solo en memoria, y el motor que arranca
Android Auto es un proceso nuevo sin interfaz ni EstadoRadio, asi que al
reconectar se reproducia la ultima emisora sin saber a que lista pertenecia y
siguiente/anterior no hacian nada hasta entrar a favoritos a mano. Ahora se
persiste el TIPO de contexto y, cuando aplica, el id del grupo, y se resuelve
contra las listas vivas en cada salto: si el grupo cambia de contenido entre
sesiones, el coche ve lo actual y no una foto vieja.
Cadena de repliegue, decidida por el propietario:
grupo vivo con la emisora dentro -> se recorre el grupo
grupo vivo sin la emisora -> se permanece en el grupo, primera
grupo vivo pero vacio -> se ensancha a favoritos
grupo borrado -> favoritos
sin favoritos -> comportamiento actual
Honrar un grupo de una sola emisora exigia levantar dos barreras, no una:
el resolutor y el propio _saltarEmisora, que se negaba a nombrar un grupo con
menos de dos miembros. emisoraVecina queda intacta: su contrato de no saltar a
ciegas es deliberado y se usa desde mas sitios, asi que el caso de "la emisora
se salio del grupo" se trata en el flujo del salto.
La puerta de entitlement no cambia: un conductor sin premium sigue recorriendo
solo el conjunto gratuito, y un contexto congelado mientras pagaba se descarta
en vez de recorrerse.
Suite completa: 1501 pasan, 2 omitidos. flutter analyze mantiene los 5 avisos
preexistentes.
Google Play devolvio "Approved with Issues" en el codigo 157: "clicking on
stop button makes the entire app useless", citado contra las Android for Cars
App Quality Guidelines. La causa no era el boton de parar.
Maquina de estados del transporte
_cambiarFuente publicaba mediaItem y loading ANTES de su primer await y solo
comprobaba su revision despues de que _recrearPlayer retornase. Los cambios de
fuente se encolan incrementando la revision al encolar, no al ejecutar, asi
que tocar una emisora, tocar otra antes de que cargue y pulsar Stop dejaba que
las entradas obsoletas reescribieran loading sobre el idle que stop() acababa
de publicar. Estado final: loading para siempre sobre una sesion que
audio_service ya habia desactivado. Ahora la guarda de revision es la primera
sentencia del metodo.
pause() no invalidaba una carga en vuelo, asi que la emisora arrancaba igual
despues de pulsar pausa; se revalida la intencion antes de llamar a play().
Se anade un suelo de estado que cierra cualquier loading o buffering sin carga
viva, exento cuando el reproductor ya entrego audio y solo esta rebufferando,
para no convertir un tunel en un error. El presupuesto hasta el primer mensaje
baja a menos de diez segundos y los reintentos ya no borran el mensaje visible.
Tier gratuito en el coche
El arbol devolvia una unica fila no reproducible para cualquier carpeta cuando
no habia premium, y un revisor con instalacion limpia siempre es tier
gratuito. Ademas skipToNext, skipToPrevious, playFromSearch y playFromMediaId
retornaban en silencio. La raiz gratuita pasa a ofrecer una sola carpeta con
emisoras reales y reproducibles, compiladas en el binario para que existan en
frio, y la puerta de entitlement acota contenido en vez de bloquear acciones.
Se elimina la fila "Funcion Premium". Una consulta de voz vacia arranca la
ultima emisora, que fallaba tambien a los clientes de pago.
Localizacion
El locale del handler solo lo fijaba un widget que el motor headless nunca
construye, asi que todo error del coche salia en castellano. Se resuelve desde
el locale de plataforma. Se traducen las once etiquetas del arbol que estaban
a fuego y se retira la convencion que lo justificaba. Un test nuevo falla si
vuelve a aparecer texto visible fuera del sistema de traduccion.
Suite completa: 1455 pasan, 2 omitidos. Los mecanismos se verificaron por
mutacion: borrar cada uno pone la suite en rojo. flutter analyze mantiene los
5 avisos preexistentes.
Tres fallos reportados en uso real, con sus causas raiz verificadas en codigo.
1. Ecualizador: el estado no tenia dueño unico
El handler arrancaba con `_ecualizadorActivo = true` a fuego. El valor
persistido solo llegaba por EstadoEcualizador.cargarPersistido(), alcanzable
unicamente desde el arbol de widgets, que un arranque headless de Android Auto
nunca construye. Resultado: el coche reproducia con el EQ forzado a ON mientras
disco e interfaz decian OFF.
Ahora registrarHandler siembra el flag desde disco en todos los motores y
setEcualizadorActivo persiste por su cuenta, asi que un toggle desde el coche o
la notificacion sobrevive sin EstadoEcualizador. _resincronizarConHandler pasa
a ser adopcion pura de interfaz.
Ademas mapearGananciaNativa enviaba 0 dB al punto MEDIO del rango nativo. Con
un getBandLevelRange() asimetrico, un preset plano metia varios dB de boost
real: la causa del "suena muy alto con el boton apagado". Reescrito para
escalar cada lado contra su propio extremo, de modo que 0 dB es siempre 0.
El dispatch de customAction no tenia ningun test. Se extrae decidirToggleEq y
se cubre contra el handler real. El efecto nativo se re-asierta al reactivarse
el reproductor, porque AudioEffect.setEnabled de just_audio es un no-op
mientras la plataforma esta desacoplada.
2. Musica Local no aparecia en el arbol de Android Auto
hayCarpetaConfigurada() consultaba MethodChannel('pluriwave/file_actions'),
registrado solo en MainActivity.configureFlutterEngine. Sin Activity no hay
handler, invokeMethod lanza MissingPluginException y el catch la confundia con
"permiso revocado", omitiendo el nodo. No dependia del entitlement.
La logica SAF sale a packages/pluriwave_file_actions, un paquete plugin local.
El motor headless que crea audio_service ejecuta GeneratedPluginRegistrant en
su constructor, asi que el canal queda registrado en ambos motores. Repuntar el
manifest a una subclase de AudioService no era viable: AudioServicePlugin
enlaza por ComponentName explicito y la app perderia el audio.
EstadoCarpetaLocal de tres valores separa "sin carpeta" de "canal no
disponible"; la raiz decide por la URI persistida y el subarbol muestra un item
explicativo en vez de una carpeta vacia. La invalidacion del arbol cacheado se
dispara al reanudar con el coche ya suscrito; el guardia anterior miraba
View.maybeOf, que bajo runApp siempre existe, por lo que se gastaba en el
arranque headless y no volvia a dispararse.
3. El paywall bloqueaba las compras
restorePurchases() de in_app_purchase_android emite siempre, y con lista vacia
si no hay nada que restaurar. El `if (compras.isEmpty) return;` se la tragaba,
noEncontrada nunca se emitia y la rama que limpia _compraEnCurso estaba muerta
en produccion. Como comprar y restaurar comparten ese flag, un usuario sin
compras que pulsaba restaurar se quedaba sin poder comprar.
Suite completa: 1366 pasan, 2 omitidos. 17 tests nuevos, todos nacidos rojos y
verificados por mutacion. flutter analyze mantiene los 5 avisos preexistentes.
Three related fixes to the release plumbing:
- Only PRO bumps the semver now. main was bumping its patch on every push,
so it raced permanently ahead of the branch that actually ships (main hit
1.3.3 while PRO sat at 1.3.0), buried release artifacts under a dev branch
on the portal, and made every main<->PRO merge conflict on pubspec.yaml.
The build number still advances on every branch, since Play requires it to
be monotonic across the whole app.
- The [version set] marker is now searched across every commit the push
introduced, not just the tip. A plain 'git pull' inserts a merge commit
with no marker, which silently dropped a pinned name and turned 1.3.0
into 1.3.1.
- Artifacts land in a per-branch folder so the portal stops interleaving
development and release builds.
Every build of a given semver was published as `pluriwave-v1.3.0.aab` into
the same folder, so main and PRO overwrote each other and three different
builds became indistinguishable once downloaded — the browser saves them as
"(1)", "(2)" and the version code is only visible by unzipping the bundle.
That cost two rejected uploads to Play Console for reusing a version code.
Artifacts are now `pluriwave-<branch>-v<semver>+<build>.<ext>", which
identifies itself weeks later and outside this repo.
Three fixes that all came out of on-device testing:
- e57f7bb restores alarms after a backup import. The import wrote the JSON
to prefs but EstadoAlarmas never re-read it, so imported alarms were
invisible, were overwritten by the next edit, and were never scheduled
natively — they would not have rung.
- a2bed18 makes the premium sheet dismissible (close button, 'not now',
back gesture) and replaces the bare title with the five concrete things
the purchase unlocks. A purchase sheet with no way out is a Play policy
risk, not just bad UX.
- 4ca2813 closes the last export gap: the equalizer on/off toggle now
travels with the backup (schema v4, additive; an old backup without the
field leaves the current toggle untouched).
The backup envelope carried favorites, EQ presets, alarms and the
multi-device toggle but not EstadoEcualizador's own on/off flag, so
restoring a backup on another device silently kept that device's
existing toggle state instead of the source device's.
Bumps the backup schema to v4 (additive over v3): the flag is only
written when explicitly provided, so old exports stay at v2/v3.
Importing an old backup without the field leaves the current toggle
untouched rather than defaulting it. Applying the imported value
reuses EstadoEcualizador.cambiarActivo so it persists and pushes to
the live audio engine exactly like a manual toggle.
The premium sheet had no close affordance or way to defer, and its
copy only said "Función Premium" without stating what it unlocks.
Adds a header close (X) button and a "not now" secondary action so
dismissal is never harder than purchasing, and replaces the bare
title with a concrete, honest breakdown of the 5 things premium
unlocks (no ads, Android Auto, station recording, alarm vacation
ranges, unlimited alarms) plus the one-time-purchase framing. The
phone equalizer is never listed, since it stays free for everyone.
New l10n keys added to all 13 locales.
Importing a backup wrote the alarm/vacation/exception block straight to
SharedPreferences but never told EstadoAlarmas about it, so the UI kept
showing the pre-import alarms, a later edit could persist that stale
state back over the imported one, and imported alarms were never
(re)scheduled with the Android native layer. The backup screen now
calls EstadoAlarmas.cargarPersistidasSinRecalcular() followed by
refrescarProgramacion() after a successful import, extracted into a
directly-testable aplicarImportacionConfig() function.
The test hardcoded 4-18 August 2026, which was in the future when it was
written and is now in the past. The pill only renders for the active or
next range, so the assertion started failing purely because the calendar
moved on — the production code was never wrong.
Anchor the range on next month (days 4-18, so it never straddles a month
boundary) and assert against rangoFechasCorto, the same pure formatter the
widget uses, so the test checks that the pill is rendered rather than
restating the formatter's own output.
main had drifted behind PRO by the whole 1.3.0 line: the freemium/IAP
feature, the code-review fixes, the real AdMob ids, the equalizer
cross-surface resync and the closed-testing ad switch all shipped through
PRO only. This reconciles main so day-to-day work no longer branches from
a stale base.
# Conflicts:
# pubspec.yaml
Brings in two independent fixes that both need to reach testers:
- e9f47d4 resyncs EstadoEcualizador with car/notification-initiated changes
and closes the persistence gap that lost them on restart.
- 2e15d05 forces Google test ad units in release builds while
usarAnunciosDePruebaEnRelease is true, so no tester can generate invalid
traffic against the AdMob account during closed testing.
[version set] keeps the 1.3.0 name; CI advances the build number.
Closed-testing human testers cannot be registered as AdMob test
devices, so release builds serving real ad units risked invalid
traffic against an AdMob account that currently earns essentially
nothing. Add usarAnunciosDePruebaEnRelease, a single boolean switch
defaulted to true, that keeps bannerAdUnitId/interstitialAdUnitId on
Google's official test ids even in kReleaseMode. Flipping it to false
is the only change needed to go live. AndroidManifest's AdMob
application id is untouched, as it only initializes the SDK.
A toggle from the Android Auto notification or a preset picked from the
car's EQ folder mutated PluriWaveAudioHandler state directly, leaving
EstadoEcualizador (and therefore the phone UI) unaware and never
persisting the change, so it was lost on the next app restart.
Forward the handler's ecualizadorActivo flag through ServicioAudio and,
mirroring EstadoRadio's existing playFromMediaId resync, diff it plus
presetActual against the cached values on every estadoStream tick,
adopting and persisting a divergence via ServicioEcualizador.
Play Console already holds version code 152 (name 1.3.0, uploaded 16 Aug),
so the bundle this pipeline produced was rejected as a duplicate code.
This empty commit re-triggers the build. The bump step advances the code to
153 (the first free one) while [version set] keeps the 1.3.0 version name,
which is the release name this freemium/IAP work is shipping under.
Fixes 9 of 10 review findings (10th requires a manual Play Console
step, no code change):
1. app.dart/banner_anuncio_superior.dart: move the top SafeArea inside
BannerAnuncioSuperior so it only reserves status-bar height when an
ad actually renders, restoring edge-to-edge layout for premium and
free-unloaded users.
2. servicio_anuncios.dart: bound every interstitial await (load,
presentation, and the injected implementation itself) with
injectable timeouts so a callback that never fires can no longer
hang a caller.
3. estado_entitlement.dart/hoja_premium.dart: expose a typed
resultadoUsuario signal for purchase/restore failures and
restore-found-nothing, with dedicated localized messages
(compraError, restauracionSinCompras) across all 13 locales --
never the raw developer/exception string.
4. main.dart/servicio_consentimiento.dart: add a GDPR/UMP consent flow
(ConsentInformation/ConsentForm) that gates Mobile Ads SDK init on
canRequestAds(); premium users never see a consent form; failures
degrade to no ads instead of crashing or blocking startup.
6. servicio_anuncios.dart: track real ad presentation
(onAdShowedFullScreenContent) so a failed-to-show interstitial no
longer consumes a session cap slot.
7. banner_anuncio_superior.dart: add an explicit load-attempted guard
so repeated didChangeDependencies (e.g. entitlement notifyListeners
during a purchase) can only ever trigger one banner load attempt.
8. servicio_anuncios.dart: make esPremium a required constructor
parameter, matching the hardened contract already applied to
EstadoAlarmas/EstadoGrabacion/EstadoRadio.
9. hoja_premium.dart: add a dedicated premiumActivo localized string
instead of reusing the equalizer's equalizerActive translation,
across all 13 locales.
All fixes implemented RED-first (failing test before production
code). Full suite: 1261 passed, 2 pre-existing skips, 0 failures.
flutter analyze: 5 pre-existing issues only, 0 new.
[version set]
App id always uses the real value (SDK init only, no ad-serving risk).
Banner/interstitial pick the real unit id in release builds and Google's
test unit id everywhere else, so debug/profile builds can never serve
(or accidentally tap) a real ad.
EstadoAlarmas, EstadoGrabacion and EstadoRadio defaulted `esPremium` to
`() => true`, so any construction site that forgot to wire entitlement
compiled fine and silently ran ungated — failing OPEN to premium and
disabling the paywall with no test able to catch it.
The parameter is now required with no default. Production wiring in
app.dart was already correct and is unchanged; the 184 pre-existing test
call sites now pass `() => true` explicitly, which is exactly the old
implicit default, so every assertion is untouched.
EstadoRadio has no gate of its own but constructs EstadoGrabacion, so it
inherits the same contract.
The one test that existed to pin the old default is renamed to describe
what it still covers (the premium path through iniciar() with no
duracion); its assertions are unchanged.
Adds a permanent, non-consumable premium unlock (EstadoEntitlement +
PuertoCompras/ServicioComprasPlayBilling) that removes ads and unlocks
alarm vacations, alarms past a 5-alarm free cap, recording start, and
full Android Auto browsing. The phone equalizer stays free for everyone.
- Entitlement is prefs-backed (compra_premium_v1), fail-open, and
resolvable headlessly via esPremiumPersistido() for the Android Auto
audio handler, which registers before runApp.
- Android Auto reduced mode keeps the real root folder labels for free
users; browsing into any of them (and playFromMediaId/playFromSearch/
skipToNext/skipToPrevious) is blocked at the getChildren/servicio_audio
choke points, with a locked "Función Premium" item as the backstop.
Current-station play/pause/stop stays untouched. A free -> premium
transition actively invalidates the head unit's cached browse tree.
- Ads (top banner + capped interstitial before adding a station or an
alarm) are gated behind entitlement via ServicioAnuncios, using
official Google test ad unit IDs pending AdMob provisioning.
- Alarm cap UX shows an explanatory message with a secondary unlock
action rather than a bare paywall jump; existing data is grandfathered.
- 4 new localization keys translated across all 13 supported locales.
Co-located tests use strict TDD (RED test before implementation) for
every new pure-logic unit; full existing suite passes unchanged.
Three reported suspicions. Two confirmed by reading, one not.
1. CONFIRMED, self-inflicted. Playing a song from the phone and pressing
NEXT jumped to a radio station.
3398d02 taught skipToNext/skipToPrevious to fall back to station skipping
when there is no local queue, so the car's buttons would not be dead for
radio. But queue-less does not mean radio: tapping ONE track goes through
reproducirPistaLocal, which never builds a queue -- only folder playback
sets _colaLocal. That is exactly why the report said "at least the first
time".
emisoraActual cannot tell them apart either: _cambiarFuente fills it in for
every source, so a local MP3 arrives as an Emisora whose url is its
content:// document URI. The media id's scheme is the real discriminator,
the same test that already keeps the recorder off local files. A local
track now skips nowhere, which is the correct behaviour for a single item.
2. CONFIRMED mechanism. A failed station made the app disappear from the
Android Auto pane.
The error path published STATE_ERROR and then cleared everything:
`emisoraActual = null; mediaItem.add(null)`. That leaves the session in an
error state with no metadata at all, and Auto drops a session with nothing
to show -- reported as "if a station fails it seems to crash, and going to
1/3 it fails".
Both are kept now. Nothing outside servicio_audio.dart consumes mediaItem
(verified), so the phone is unaffected, and the car gains two things: the
screen can still name the station that failed instead of going blank, and
previous/next stay usable, so a driver can skip out of a dead station
instead of being stranded -- _saltarEmisora needs emisoraActual to know
where it is in the list. The error state itself is unchanged.
3. NOT CONFIRMED. A local track occasionally jumping to another one mid-play.
An advance requires a genuine `completed` from just_audio, so either the
player reports the end early -- plausible for a content:// SAF source,
whose duration is not always exact -- or something else moved the track.
Reading the code cannot separate those, so nothing was changed on a guess.
The advance now logs the decision with the processing state, position and
duration that caused it, so the next occurrence arrives with its reason
attached.
Tests: 1192 -> 1195.
Audit of the same failure family as the shrunk drawables: references by
NAME that nothing validates at compile time.
The whole onboarding and release-notes feature had never shipped. Reading
the installed APK: ZERO entries under assets/content/, while
assets/icons/alarmas/* was present. pubspec declared `assets/content/`, and
Flutter does not recurse -- naming a directory includes the files sitting
directly in it, never its subdirectories. Every content file lives in one
(onboarding/, updates/<locale>/), so none of them were packaged.
On the device that surfaced on every single launch:
Unable to load asset: "assets/content/onboarding/en.md"
with the file plainly present on disk. That is why it never looked like a
packaging problem. The tell was already in the pubspec: assets/icons/alarmas/
is listed explicitly, so the rule was known once and not applied here.
All 14 content directories are now declared: onboarding/ plus updates/ for
each of the 13 locales.
The guard is a test that loads every file under assets/content/ through
rootBundle, because that is the only thing that proves an asset is declared
and will ship. A test asserting File.existsSync would have stayed green
through all of this -- the files were never missing, only unpackaged. Run
against the unfixed pubspec it fails 26 of 27; with the fix it passes.
Tests: 1165 -> 1192.
Root cause found, and it is not the stale build cache I claimed earlier.
flutter clean was good hygiene and changed nothing here, because nothing
was cached: the resources were being deliberately removed.
Flutter's own Gradle plugin enables shrinking on every release build --
FlutterPlugin.kt, `releaseBuildType.isMinifyEnabled = true` and
`isShrinkResources = true` -- no matter what app/build.gradle.kts says. The
shrinker keeps what it can see referenced, and it cannot see
`MediaControl.custom(androidIcon: 'drawable/ic_auto_eq_on')`: that is a
string inside Dart, resolved at runtime through getIdentifier. So both
equalizer icons were stripped from every release APK ever built.
The evidence that pins it, from the APK pulled off the device:
ic_stat_pluriwave present <- referenced as R.drawable from Kotlin,
4 call sites in the alarm notifications
ic_auto_eq_on absent <- named only in a Dart string
ic_auto_eq_off absent <- named only in a Dart string
Same folder, same file shape, same commit range. The only difference is
whether a real R.drawable reference exists, which is exactly what the
shrinker looks for.
The consequence was never a blank button. getResourceId returns 0 for an
unresolvable name, PlaybackStateCompat.CustomAction.Builder throws on a 0
icon, and that throw aborts AudioService.setState before the media session
is activated -- so Android Auto held a frozen, inactive session. Dead
playback screen, play that never became pause, the app losing its pane to
any app with a live session, audio playing "as if it were not the app".
One shrunk file, four symptoms, since 31 July (2540556).
Two protections, because they fail differently:
- res/raw/keep.xml with tools:keep is the official mechanism for
dynamically resolved resources and is what actually binds the shrinker;
- RecursosResueltosPorNombre.kt gives them genuine R.drawable references,
the same thing that kept ic_stat_pluriwave alive all along.
station_art_* are kept too. They are reached the same way, through
android.resource:// URIs built in Dart, and survived only by luck.
Tests: 1165, unchanged -- this is a build-configuration fix, and no Dart
test can see it. The CI resource guard is what verifies it now.
The previous guard reported "Drawables en el APK: (ninguno)" for a 105MB
release APK. Zero drawables is impossible -- AndroidX alone contributes
dozens -- so the check was wrong, not the build. Release APKs shorten and
rename resource file paths, so `res/drawable/...` simply is not how they
are stored there. The 45MB base.apk taken off the device kept readable
paths because it came from an AAB through bundletool; the CI builds a fat
APK through a different pipeline. Same app, different layout.
Resource NAMES survive in resources.arsc regardless of path shortening, so
that is what gets inspected now.
And the guard checks itself before judging. It looks for a sentinel
resource known to be present (station_art_nova); if the sentinel is not
found, the inspection method is unreliable and the step says so instead of
declaring anything absent. This guard has already lied once, reporting
ic_stat_pluriwave missing when it was verified present, and that lie was
about to send us hunting a build problem that did not exist. A check with
no way to detect its own failure has no business failing a build.
Verified before pushing, all three extracted verbatim from the parsed YAML
and run against real inputs:
1. real 45MB base.apk -> sentinel found, ic_stat_pluriwave OK,
ic_auto_eq_on/off missing, exit 1
2. APK absent -> reports the path and lists what is there,
exit 1, no resource accusations
3. zip without arsc -> "inspection impossible", exit 1 (checked
without a pipe, so the code is the script's)
Scenario 3 is the one the old guard got wrong: it turned an inspection
failure into three false "FALTA" lines.
FreeTLab
ShanaiaBot