ab3554b746dbbada555a6846a8f5b3125fed7108
83
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
8a71bc237f |
feat: restaurar los grupos de favoritos al importar y recordar la lista del coche
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. |
||
|
|
8e155cc0ac |
fix: cumplir las guias de calidad de Android Auto y localizar el arbol del coche
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. |
||
|
|
575ba793ae |
fix: corregir ecualizador desincronizado, musica local en Android Auto y bloqueo del paywall
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.
|
||
|
|
4ca2813267 |
feat(ecualizador): include equalizer on/off toggle in export/import
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. |
||
|
|
2e15d05431 |
fix(ads): force test ad units in release during closed testing
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. |
||
|
|
9cfa5ac17d |
fix(iap): address code review defects in freemium/IAP change
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] |
||
|
|
aa0b242374 |
feat(iap): add freemium unlock via one-time in-app purchase
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. |
||
|
|
d754e28ddf |
fix(audio): keep local skips local, and stop a failed station blanking Auto
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.
|
||
|
|
f01c0911f7 |
fix(auto): guard shipped resources, walk favourite groups when skipping
History review requested by the owner: when and why did the Android Auto UI stop working. ANSWER: 31 July, commit |
||
|
|
3398d02a43 |
fix(auto): keep the service alive through interruptions, restore local music
Four car reports, two root causes.
1. Local music vanished from the Android Auto menu. Self-inflicted, by
|
||
|
|
a6cdf0e72c |
fix(auto): advertise the transport actions Android for Cars requires
Reported: on the Android Auto playback screen the play/pause button stays
on PLAY while audio is audibly playing, and "it used to work, in the
latest versions it doesn't".
Previous rounds looked for a regression in this repo's audio commits and
found none: every playbackState.add site publishes playing:true with a
ready processingState, and AudioService.getPlaybackState maps that to
STATE_PLAYING. That search was aimed at the wrong thing.
The Android for Cars guide ("Enable playback control") is explicit:
"Android Auto and AAOS display playback controls based on the actions
that are enabled in the PlaybackStateCompat object. By default, your app
must support the following actions: ACTION_PLAY, ACTION_PAUSE,
ACTION_STOP, ACTION_PLAY_FROM_MEDIA_ID, ACTION_PLAY_FROM_SEARCH."
systemActions has carried only `seek` + `stop` since
|
||
|
|
80538900db |
fix(alarmas,auto): guard the last unguarded snooze path, surface car progress
Continuation of |
||
|
|
7054a4c871 |
fix(alarmas,auto): guard the native snooze anchor, surface the EQ in the car
Three reported issues, two fixed and one instrumented. 1. Posponer left the alarm snoozed ~1444 minutes (24h04m). Traced end to end in Kotlin. onAlarmFired runs from the receiver BEFORE the ringing notification exists, and persists snoozeOriginMillis = null plus a triggerAtMillis already advanced to TOMORROW by computeNextTriggerMillis. snooze() then anchored on `spec.snoozeOriginMillis ?: spec.triggerAtMillis` and picked up tomorrow. The existing clamp could not catch it: it only rescues anchors in the PAST, so an anchor +24h out sails through. The countdown text is honest -- ceilMinutes(snoozeUntil - now) over Dart's own template -- the corrupt value is snoozeUntil. With N=5 and a tap at T+1min the arithmetic lands on 1444 exactly. This is the defect |
||
|
|
f2f706b342 |
fix(auto): restore the equalizer toggle and list the user's own presets
Two Android Auto regressions reported from the car. 1. The on/off equalizer action disappeared from the playback screen. That was self-inflicted: commit |
||
|
|
cacd3ece57 |
fix(audio): keep custom actions out of the media notification controls
The equalizer toggle appended to the transport controls was aborting the whole notification. controls feeds BOTH the phone notification and the car playback screen, and AudioService.setState walks every control through createCustomAction (AudioService.java:513-520) BEFORE reaching mediaSession.setPlaybackState (:552) and enterPlayingState (:559) -- the only place the notification is ever posted. createCustomAction resolves the icon by name via getIdentifier (:415-420), which returns 0 on a miss, and passes it to PlaybackStateCompat.CustomAction.Builder, which throws on a 0 icon or an empty label. That throw aborts setState, so the media session is never published: no shade widget, no lock-screen controls, not even the small status-bar icon. ExoPlayer runs independently so audio keeps playing, and until asyncError got a subscriber the exception was dropped silently. Nothing is lost in the car: the Ecualizador browse folder already lists Desactivar plus every preset by name, which is Auto's own idiom for choosing among options. |
||
|
|
6da3e69f7e |
fix(audio): stop emitting a transient idle during a source change
Root cause of the disappearing media notification, and it is self-inflicted
on EVERY Android version — no plugin patch involved.
`audio_service`'s `_observePlaybackState` (audio_service.dart:1131-1136) calls
`AudioService._stop()` on ANY transition into `idle` from a non-idle state.
That reaches `stopService()` -> `deactivateMediaSession()` ->
`notificationManager.cancel(NOTIFICATION_ID)`. The notification is re-posted
at exactly one place, `internalStartForeground()`, reachable only from the
`!wasPlaying && playing` edge in `setState()`, and its FIRST statement is
`ContextCompat.startForegroundService(...)` — which on API 31+ throws
`ForegroundServiceStartNotAllowedException` whenever the process is not in a
foreground state.
Every station change walked straight into that. `_cambiarFuente` pushes
`loading`, then `_recrearPlayer` disposes the old `AudioPlayer` and builds a
FRESH one; a fresh player's first `playerStateStream` event is always `idle`,
and the listener forwarded it verbatim. So `loading -> idle` tore the
foreground service down mid-source-change, and recovery depended on the
following `playing: true` edge restarting it. Screen off, lock screen, or an
Android Auto / Bluetooth-initiated start is precisely where the platform
refuses that restart: audio keeps playing, the notification never returns.
That is exactly what the user reports.
The mapping decision moves out of the private `_mapProcState` into a pure
top-level `mapearEstadoProceso(proc, {required bool cambiandoFuente})`, so the
one line that decides whether the foreground service dies is unit-testable
without instantiating the handler (which needs MethodChannels). It is
byte-for-byte identical to the old switch in every case except `idle` while a
source change is in flight, which now maps to `loading`. The test asserts the
full ProcessingState x cambiandoFuente matrix against a literal transcription
of the previous mapping, and asserts both directions explicitly: a real stop
still yields `idle`, a source-change idle yields `loading`, and `idle` is the
only case where the two branches differ at all.
The only risk this introduces is a `_cambiandoFuente` stuck at `true`: a real
user stop would be masked away from `idle`, the service would never stop, and
the notification would become unkillable. So the flag is cleared by four
independent mechanisms rather than one audited path:
- a `finally` around the whole body of `_cambiarFuente`, which covers normal
completion, BOTH `revision != _revisionFuente` early returns, every
`rethrow` out of a catch clause, and any non-`Exception` `Error` that none
of the three clauses matches;
- eagerly at the top of each of the three catch clauses — needed on top of
the `finally` because `_gestionarErrorReproduccion` calls `_player.stop()`
WITHOUT awaiting it, so that `idle` could otherwise land while the mask
was still up;
- right after `setUrl` resolves, before anything below can await, since the
fresh player's transient `idle` is already behind us at that point;
- at the start of `stop()` — before `_player.stop()` — and at the start of
`_gestionarErrorReproduccion`, which makes the invariant total: the flag
is `false` before every single `_player.stop()` call in this class.
`stop()` matters most: `BaseAudioHandler.stop()` is empty, so the handler
never pushes `idle` itself — teardown is driven entirely by the player's
emission. A stop landing while a station change was still in flight would
otherwise be masked and the notification would survive the stop.
Audited: two `_player.stop()` call sites exist and both are preceded by a
clear; `_recrearPlayer` has exactly one caller and it is guarded; the old
player cannot emit during `_recrearPlayer` because its subscriptions are
cancelled first.
|
||
|
|
b0271fa953 |
feat(audio): log AudioService.asyncError instead of swallowing it
`AudioService.asyncError` had ZERO subscribers app-wide. The plugin funnels
every asynchronous failure of its own observers into that stream and nowhere
else — `_observePlaybackState`, `_observeMediaItem` and `_observeQueue` each
wrap their whole body in `catch (e) { _asyncError.add(e); }`, and the artwork
path uses `.catchError(_asyncError.add)` — and a `PublishSubject` with no
listeners simply drops what it is given. The platform-side exception behind
"the media playback notification disappeared" was therefore being discarded
without a single log line, which is why that report arrives with no evidence
attached.
`observarErroresAudio` is a pure, injectable seam in `arranque_audio.dart`
(stream in, logger callback out), matching the seam convention this codebase
already uses for `esperarArranqueAudio`, `decidirAvanceCola` and
`debeReaplicarEcualizador`: the unit tests exercise the wiring with a plain
`StreamController`, never the real plugin. The default logger emits one
`[PluriWave]`-prefixed `developer.log` line at `level: 900`, the same level
and prefix `servicio_audio.dart` already uses, so one logcat filter catches
both.
Wired from `lib/main.dart`, not from `arranque_audio.dart`: main.dart is the
module that genuinely owns handler lifecycle — it is the only caller of
`AudioService.init`, `registrarHandler` and `ServicioAudioSession`, and both
the on-time and the degraded/timeout startup branches converge on its
`conectarHandler` closure. `arranque_audio.dart` owns only the timeout race
and the degraded loading shell; it never creates or registers a handler
(`alListo` is injected into it from main.dart), so it has no lifecycle to
hang a subscription on. Subscribing happens before `AudioService.init` — the
getter only touches a static subject — so nothing reported during the
MediaBrowser handshake is missed, and one subscription covers both paths.
The subscription is cancellable and its `cancel` is registered into the
handler via `registrarLimpiezaArranque`, mirroring the existing
`registrarHandler` / `registrarFuenteNavegacion` / `registrarFuenteMusicaLocal`
registration convention. `onTaskRemoved` — the only handler teardown in this
app — runs it, so the subscription cannot outlive what it instruments. The
dependency points bootstrap -> service, so `servicio_audio.dart` never has to
import the bootstrap module or the plugin's static stream.
Zero behaviour change: nothing but log output is added.
|
||
|
|
b09d644a2c | merge: incorporate main's safearea/auto-order/vacaciones fixes | ||
|
|
015a20a823 |
feat(tutorial): add 9-screen help/tutorial carousel
Add PantallaTutorialAyuda, a PageView-based carousel covering saved
stations/groups, per-station equalizer, recording, adaptive alarms,
Android Auto favorites, auto-reconnect, snooze duration, custom
stations, and a closing summary with a "watch it again" reminder.
ServicioTutorialAyuda persists a one-time seen flag so the carousel
shows once via mostrarSiProcede, independent of entry point; the
final page's CTA label depends on the primerArranque constructor
parameter ("Empezar a escuchar" vs "Cerrar").
Translate the new copy into all 13 supported locales and update
helpSubtitle to describe the new entry point.
|
||
|
|
cfd8bc9e6a |
fix(auto): preserve phone-chosen station order in Android Auto folders
Android Auto's Favoritos/Todas/Mis emisoras folders always re-sorted by a hardcoded quality criterion in ConstructorArbolAuto.hijos/hijosGrupo, discarding whatever order the caller passed in. EstadoRadio now pushes already-ordered snapshots (listaFavoritosManual for Favoritos, and the ordenListas-sorted populares/emisorasCustom getters for Todas/Mis emisoras, re-pushed immediately on cambiarOrdenListas), and hijos/ hijosGrupo stop re-sorting so that order survives into the car. |
||
|
|
a8dca83cd9 |
feat(alarmas): surface the three native scheduling failures in Dart
Completes the bridge the native side already exposed. AlarmScheduler and PluriWaveAlarmService record a pre-notice that could not be armed, a refused foreground-service start, and a per-alarm reschedule that failed after a reboot -- but nothing read them, so all three still ended at logcat. EstadoAlarmas now drains them at startup and turns each into a per-alarm exception, which the card already knows how to mark. An alarm that never reached the OS stops looking identical to one that did. The read is deliberately tolerant: a failure to read is logged and swallowed, never surfaced as an alarm error, so a diagnostics gap cannot masquerade as a scheduling problem. |
||
|
|
47d0b8a053 |
feat(alarmas): record and clear per-alarm scheduling failures
Adds ServicioAlarmas.registrarFalloProgramacion/limpiarFalloProgramacion, persisting a scheduling-reliability failure through the same ExcepcionAlarma model saltarProxima already uses. Only one failure record is kept per alarm (latest attempt wins) and skipNext entries for any alarm are never touched. EstadoAlarmas wiring follows next. |
||
|
|
88bd251eba |
fix(alarmas): scope schedule-skip exceptions to skipNext only
ExcepcionAlarma._esValida matched ANY exception tipo against an occurrence, treating it as a user skip. Only the 'skipNext' tipo existed until now, but the next commits reuse the same model to record scheduling-reliability failures per alarm (so the alarms list can surface them via ultimaExcepcionPara) -- without this guard, a recorded failure would be silently treated as if the user asked to skip that occurrence, corrupting scheduling. Adds tipo constants to ExcepcionAlarma for the upcoming failure kinds. |
||
|
|
3f80291e78 |
feat(auto): equalizer folder in the browse tree, one toggle on playback
On-device feedback: two identical icons on the car's now-playing screen, one of which looked dead. It worked -- but head units render custom actions icon-first, so cycling six presets behind one static glyph was invisible. A monochrome icon cannot encode which of six presets is active. Android Auto separates the idioms deliberately: custom actions for stateless toggles, browsable lists for choosing among options. - Playback screen keeps one action: equalizer on/off, state-aware icons - New Ecualizador folder lists Desactivar plus the six presets by name, active one marked - The preset-cycling action and its drawable are removed Supersedes the redesign's no-equalizer-folder rule, which predated knowing custom actions do not surface state in a car. # Conflicts: # lib/l10n/app_ar.arb # lib/l10n/app_bn.arb # lib/l10n/app_de.arb # lib/l10n/app_en.arb # lib/l10n/app_es.arb # lib/l10n/app_fr.arb # lib/l10n/app_hi.arb # lib/l10n/app_id.arb # lib/l10n/app_it.arb # lib/l10n/app_ja.arb # lib/l10n/app_pt.arb # lib/l10n/app_ru.arb # lib/l10n/app_zh.arb |
||
|
|
f19666508d |
fix(auto): remove the preset-cycling custom action, superseded by folder
The equalizer's preset-cycling custom action (eq_preset_siguiente) and its ic_auto_eq_preset drawable are no longer needed now that the "Ecualizador" folder lists all six presets directly: the folder replaces what the cycle action did, and this frees a scarce Android Auto custom action slot. The on/off toggle is now the equalizer's only custom action. |
||
|
|
8423ccdd0c |
feat(auto): add an Ecualizador browsable folder with preset selection
On-device feedback showed the equalizer's preset-cycling custom action
looked dead: many head units render custom actions icon-first, and a
monochrome icon cannot legibly encode "which of six presets" the way a
browsable list's text rows can.
This adds an "Ecualizador" folder to the car's browse tree, listing
"Desactivar" first, then the six factory presets by name, with the
currently-active one marked. Selecting a preset routes through the same
playFromMediaId seam every other browse-tree leaf already uses; picking
a preset while the equalizer is off turns it on and applies that preset.
Supersedes the earlier "no equalizer folder" rule (commit
|
||
|
|
049ab78acb |
feat(alarmas): replace one-line reliability button with full diagnostics screen
Surface all six DiagnosticoAlarmasAndroid fields instead of three: the battery-optimization exemption and native pending-alarm count were already collected but silently dropped by the old widget. Each failing signal now offers a "Fix this" action that opens the right system settings screen (exact alarms, notifications, full-screen intent, battery optimization), guarded by SDK level and never crashing when a ROM lacks that screen. Manufacturers known for aggressive background killing (Xiaomi/Redmi/POCO, Huawei, Oppo, Vivo, OnePlus, Samsung) get an honest explanation that Autostart must be enabled manually, since there is no API to detect or grant it. Notifications now deep-links straight to ACTION_APP_NOTIFICATION_SETTINGS via a new openNotificationSettings native method, instead of reusing the runtime permission popup meant for first-time alarm creation. New copy is added to all 13 ARB locales with real per-language translations (not Spanish copies), verified by the ARB parity and anti-copy tests plus the corruption scanner. |
||
|
|
ef9705a30e |
feat(alarmas): add pure diagnostic mapping and autostart-guidance logic
DiagnosticoAlarmasAndroid already collected six raw reliability fields but only three ever reached the UI. Add a pure-Dart mapping that turns the raw snapshot into five ordered signals with a clear ok/needs- attention state (exact alarms, notifications, full-screen intent, battery-optimization exemption, native pending-alarm count), plus a manufacturer check for vendors known to require manually enabling Autostart (Xiaomi/Redmi/POCO, Huawei, Oppo, Vivo, OnePlus, Samsung), since there is no public API to detect or grant that setting. |
||
|
|
25405564ee |
fix(auto): give the equalizer actions distinct, state-aware icons
On a car head unit the custom actions render icon-first, so two actions sharing ic_stat_pluriwave were indistinguishable and the toggle gave no sign of whether the equalizer was on. Each action now has its own drawable, and the toggle swaps between ic_auto_eq_on and ic_auto_eq_off so its state is legible at a glance. |
||
|
|
491585ad12 |
fix(eq): re-apply the equalizer after an audio-focus interruption
The equalizer stopped applying after another app interrupted audio (e.g. a navigation app's voice prompt): play a station with EQ working, let the prompt speak, resume -- the audio sounds flat until the station is re-tapped. debeReaplicarEcualizador only re-attaches the equalizer when the native player session id actually changes. A short transient interruption keeps the SAME session (no id rotation), so that trigger never fires, while Android's AudioEffect framework can let a higher-priority client silently disable this app's effect instance in the meantime. Add reaplicarEcualizador() to ObjetivoAudioInterrumpible, implemented as a thin delegate to the existing _activarEcualizador() (already the correct idempotent setEnabled + re-push-gains path). ServicioAudioSession calls it on resume-from-pause (after reanudar()) and on un-duck (after setAtenuado(false)) -- additive to the existing session-id trigger, not a replacement. The method takes no argument, so it can only re-assert whatever enabled/disabled state the handler already holds -- an interruption cycle with the equalizer OFF stays OFF. |
||
|
|
9eff760462 |
feat(auto): equalizer enable/disable and preset cycling from the car
Expose the equalizer's on/off toggle and preset choice as PlaybackStateCompat
custom actions on the now-playing screen. The redesign's removal of the
in-car equalizer FOLDER from the browse tree stays as-is (
|
||
|
|
1b0bea5492 |
fix(auto): fall back to on-brand artwork when a station or track has none
Stations and tracks with no artwork showed empty tiles in the car. The browse tree's itemEmisora/_itemLocal already fell back to the rotating station_art_* drawable via artUriPara/artUriLocal, but the "now playing" MediaItem built when actually playing something (car tap, phone-initiated play, folder-queue advance, direct local-track tap) did not, so the car's now-playing screen still went blank. Reuse the SAME artUriPara/artUriLocal fallback (already the project's one selection scheme, mirroring PluriStationArtFallback) at every "now playing" construction site: reproducirPorMediaId, ServicioAudio.reproducir (now via the extracted, unit-tested mediaItemParaEmisora), construirMediaItemColaLocal and reproducirPistaLocal. Guard the reverse direction too: emisoraDesdeMediaItem (extracted from the handler's private method, now unit-tested) only reflects artUri back into Emisora.favicon when it passes faviconUsable, so the phone UI's CachedNetworkImage widgets never attempt a doomed fetch of the car's android.resource:// fallback URI -- they keep falling back to PluriStationArtFallback exactly as before. |
||
|
|
6822432a51 |
feat(auto): play a local-music folder's subfolders recursively too
totalPistas counted only DIRECT audio children, so "Reproducir carpeta"/ "Aleatorio" were hidden for a folder that contains only subfolders, and playing a folder queued only its direct tracks. Add a bounded recursive walk (pistasRecursivas) that collects every track beneath a folder, depth-first, sorted by name at each level. Bounded on two independent axes to keep a single tap's native SAF round-trips and in-memory list size predictable on a deep or wide library: - depth: 4 levels below the tapped folder (profundidadMaximaRecursivaLocal) - count: 500 tracks total (limitePistasRecursivasLocal) The folder-play/shuffle actions are now offered whenever the recursive count is > 0, and "Reproducir carpeta"/"Aleatorio" queue everything found, not just direct children. |
||
|
|
eea8ec31e6 |
fix(auto): sort local-music subfolders before files
itemsLocales sorted a folder's children by name only, mixing directories and files. A subfolder whose name sorted after enough tracks (e.g. "Live" behind 80 numbered tracks) landed on a later "Más..." page, making it unreachable without paging through every track first. Sort directories before files, then by name within each group -- the standard file-browser convention. Subfolders now always land on page 0. |
||
|
|
2959941485 | fix(bienvenida): wire the welcome screen into the first-launch flow | ||
|
|
c9fe0ad651 |
feat(eq): restyle equalizer screen and add custom presets
Restyle the Ecualizador settings screen to the new visual language while keeping the equalizer at 5 bands (spike-resolved, Engram id 2498 - band count is device-reported via just_audio's AndroidEqualizer, not app-chosen; the approved mockup's 7 sliders would silently no-op on typical hardware). - Restyle EcualizadorWidget in place: strip its internal title + preset chip row (the pushed screen's header now carries the title), add a habilitado parameter that greys/disables every slider when EQ is off. Widen PresetsEcualizadorWidget additively (personalizados param) so custom presets can join the chip row without a second implementation. - Add servicio_presets_personalizados.dart (new file, own SharedPreferences key eq_custom_presets_v1) for custom EQ preset persistence - kept out of servicio_ecualizador.dart, which has an empty-git-diff success criterion for this change. preset_ecualizador.dart is unchanged: a custom preset is just a PresetEcualizador with a user-supplied name. - Extend EstadoEcualizador with presetsPersonalizados, guardarPresetPersonalizado (validates non-empty name), eliminarPresetPersonalizado. The load is a new explicit cargarPresetsPersonalizados(), deliberately NOT folded into cargarPersistido(): that method is exercised ~30 times by estado_ecualizador_test.dart (protected, must stay unmodified) via Fakes only, with no SharedPreferences awareness in that file. - Build out the Ecualizador screen body: base-vs-per-station explainer banner, a "Salida activa" row surfaced on the main screen (previously Advanced-only), an "Emisoras con ajuste propio" drill-down sourced from the existing presetsPorEmisora map, and a "Guardar como preset" action. New coverage lives in new files rather than touching the three protected EQ test files: ecualizador_widget_test.dart (component-level, did not exist before this commit), servicio_presets_personalizados_test.dart, and estado_ecualizador_presets_personalizados_test.dart. servicio_ecualizador.dart, servicio_audio.dart and the three protected EQ test files keep an empty git diff. Full suite: 713/713 green (2 skipped, unchanged), up from 682. size:exception - realized 1,954 changed lines (25 files, plus this docs update) against the 400-550 forecast: lib/ + ARB alone is ~650 lines, near the top of the forecast band by itself since this WU also had to build out a screen body WU3a only stubbed; the rest is 4 test files (675 lines) and 11 new ARB keys regenerating 13 lib/l10n/gen files (~546 lines) - the same pattern every prior work unit in this branch has hit. Not splittable: WU14 reuses this unit's editor component by exact runtime type and cannot begin until this lands as a whole. |
||
|
|
c6f16c81b5 |
feat(paises): add country browser and extract shared radio transport
Extracts ServicioRadio's transport loop (server discovery, host rotation, bounded retries, User-Agent, timeout, status check, json.decode, sticky-host bookkeeping) out of `_get` into a new `_getJson(path, params) -> Future<List<dynamic>>` helper, moved as one block with no logic edits. `_get` is reimplemented on top, still owning every station-specific concern: `lastcheckok: '1'`, `Emisora.fromApi` + the empty-uuid/url filter, and the `_compararCalidad` quality sort. `_getJson` is deliberately sort-agnostic and filter-agnostic so a non-station endpoint can reuse the resilience behaviour without inheriting station-only semantics. Non-negotiable ordering followed per design ADR-4: new test/servicios/servicio_radio_transporte_test.dart characterises all 8 existing station calls (7 via `_get` plus `registrarClick`, which builds its own URI) against the UNMODIFIED `_get` first - green by construction - pinning path, lastcheckok=1, hidebroken=true, a non-empty User-Agent, exact order/reverse/limit/offset, and the exact returned UUID sequence from a fixture with deliberately shuffled bitrate/clickcount/votes. That last assertion is what makes the extraction safe: a sort that silently sank into transport would pass every other check. Re-running the same file after the extraction is byte-identical green. test/servicios/servicio_radio_test.dart is untouched by this work unit - its passing unmodified is itself a signal that transport wasn't disturbed. The 6 pre-existing `order: bitrate` occurrences (obtenerPopulares, buscarPorNombre, buscarPorPais, buscarPorIdioma, buscarPorTag, buscar) are untouched - a deliberate server-side quality bias deciding which stations return within `limit`, unrelated to and never to be confused with the user-facing "Ordenar" control, which stays entirely client-side via the existing OrdenEmisoras (Engram reference/radio-browser-sort-order). Behaviour delta, accepted per ADR-4, not a regression: moving `_servidorActual` bookkeeping into `_getJson` means a successful `/json/countries` call now warms the sticky host for subsequent station calls too - one shared warm mirror per instance, desirable, not per-call-type state. Adds the Paises browser over the verified `/json/countries` contract (Engram reference/radio-browser-countries-endpoint): new lib/modelos/pais_radio.dart (`PaisRadio.fromApi` parses `stationcount` via `int.tryParse` since the API returns it as a JSON string, not an int - an `as int` cast would throw), `obtenerPaises()` sends neither `lastcheckok` nor `order` (the screen sorts client-side by name; the API's raw byte order isn't proper collation for any locale this app ships), and inherits `hidebroken=true` from the unchanged `_uri` (desirable here too, since the endpoint's own default is false). `EstadoBusqueda` gains `paises`/`cargandoPaises`/`cargarPaises()` with an in-memory cache guard so re-entering the screen never refetches. New PantallaPaises (lib/pantallas/pantalla_paises.dart): a "Tus idiomas" shortlist (one representative country per the app's 13 supported locales, matched against the fetched list - the proposal/spec name this section but don't specify its derivation) above the full alphabetical list, each entry showing its parsed station count. Reachable from Buscar's discovery landing state via a new entry row, added now rather than left dangling per this file's own forward-reference comment (and the WU15/WU15b lesson: a fully-tested but unreachable screen is a real defect, not a follow-up). New ARB keys (en/es only, matching this change's established precedent): countriesScreenTitle, countriesYourLanguagesTitle, countriesAllTitle, radioCountriesError. Tests: 631 -> 649 (2 skipped, unchanged). flutter analyze unchanged at 1 pre-existing info. grep confirms `countrycodes` appears nowhere in lib/. |
||
|
|
589fc54580 | feat(grabaciones): add recordings library screen | ||
|
|
2403da3c2e |
refactor(auto): drop the in-car equalizer, keep EQ on the phone
The car tree carried a whole equalizer feature: an `Ecualizador` root folder with the six factory presets, a browsable `Personalizado` folder, five band folders and thirteen gain leaves each, plus the media-id namespaces, routing predicates, persistence-targeting and children-changed plumbing that fed them. Equalization is a phone task; the driver should not be tuning 5 bands from a car screen. Removed: the `eq_preset:`/`eq_banda:`/`eq_gain:` namespaces and their predicates and parsers, the `ecualizador`/`eq_custom` folder ids and their getChildren branches, itemPresetEq/presetsEq/itemEqPersonalizado/bandasEq/ gananciasBandaEq, resolverPresetEq, presetPersonalizadoEfectivo, dispositivoDestinoEq, debeAplicarPrincipalAhora/debeAplicarSeleccionAhora, aplicarPresetPorMediaId, aplicarGananciaPorMediaId, and in the handler the playFromMediaId branches, _presetPersonalizadoAuto, _dispositivoActivoAuto, _dispositivoDestinoEqAuto and the subscribeToChildren/_hijosSubjects notification machinery that existed only to refresh band titles after a gain tap. Deliberately KEPT: automatic per-device EQ. Reaching the car still applies that device's preset, because that lives in EstadoEcualizador and the output-device detection, not in this tree — it works with Android Auto or without it. Configuring is what moves to the phone; applying stays automatic. Also kept: the `eq_preset_*_v1` SharedPreferences keys in ServicioEcualizador, which share a name with the deleted media-id prefix by coincidence only and hold the phone's own presets. The root folder set goes from five entries to four (three without local music); its test now asserts no equalizer folder is offered at all, so a reintroduction has to be deliberate. |
||
|
|
9b8209ac93 |
fix(radio): discover live API mirrors instead of hardcoding dead ones
Two of the three Radio Browser hosts this client shipped no longer resolve.
The retry loop rotates de1 -> nl1 -> at1, so once the first attempt failed
for any transient reason the remaining two were guaranteed to fail as well:
the retries meant to add resilience had become a dead end, and a single blip
surfaced as "No connection to the radio API" with a healthy API and a healthy
network. The live mirror list confirms only one server remains:
[{"ip":"91.98.4.78","name":"de1.api.radio-browser.info"},
{"ip":"2a01:4f8:1c1d:699::1","name":"de1.api.radio-browser.info"}]
The API docs say exactly what this code was doing wrong: "Never use a direct
link to a single new server. It is much better to get a list of the servers",
pointing clients at all.api.radio-browser.info to enumerate what exists.
Seed with that round-robin host plus de1, then resolve the real list from
/json/servers once per instance and rotate over that. Discovery shares one
in-flight request across concurrent callers, because the home screen loads
two lists at once through Future.wait, and any failure silently leaves the
seed list in place — it still contains a working host, so a failed discovery
must never be worse than not trying. Explicitly injected servers disable
discovery so callers can still pin a mirror.
Build the User-Agent from the running package too. The API asks clients to
identify themselves, and this header claimed PluriWave/0.1.0 while the app
shipped 1.1.x. A literal cannot stay correct here — CI bumps the version on
every single release — so read it via package_info_plus, already a dependency
used in three other places. If package info is unavailable the product name
goes out alone rather than a made-up version, and resolution never throws: a
header must not be able to fail a request.
|
||
|
|
4042cf5ffd |
fix(eq): stop the phone's FM sink from posing as the active output
Regression from the previous commit. Ranking every AudioDeviceInfo type this
build does not name individually ABOVE the built-in speaker was meant to let
a car stereo on LE Audio or an automotive bus win. It also promoted the
internal sinks a phone exposes permanently: on the Xiaomi test device
AudioManager reports TYPE_FM (14) as an output, so getActiveAudioDevice
picked it over the real speaker with nothing connected at all. Confirmed on
device:
audio_devices.onListen -> {id=other:14:4, type=14, name=2412DPC0AG}
It then reached Dart under an `other:14:4` id whose type is neither the base
speaker nor a known one, slipped past the collision guard and had a preset
row persisted for it -- reinstating the exact symptom this series set out to
kill: a permanent green active-output dot on a device that was not connected.
Replace the deny-by-omission ranking with an explicit allow list of outputs a
user actually connects. The built-in speaker sits below all of them and above
everything else, so any sink that physically exists but is never where media
plays (TYPE_FM, TYPE_BUILTIN_SPEAKER_SAFE, telephony, remote submix) can no
longer be selected. A one-time purge clears the `other:` rows the bad build
persisted; genuine ones re-register on their next connection.
Fix the USB type constant while here: TYPE_USB_HEADSET is 22, not 14, and 14
is TYPE_FM. The Kotlin USB branch hardcoded 14 and the Dart type table
mirrored the same mistake, so the two cancelled out for real USB headsets
while making a phone's own FM sink decode as USB audio. Both now use 22.
Verified with javap against android.jar (android-36) rather than trusting the
comment that introduced the error.
|
||
|
|
39ead7bea4 |
fix(eq): stop the phone speaker from impersonating a Bluetooth device
deviceToMap handed the builtin_speaker id to EVERY output type its `when` did not name. A car stereo on LE Audio (TYPE_BLE_HEADSET) or an automotive bus (TYPE_BUS) therefore arrived in Dart under the phone speaker's own id, carrying a type that maps to `desconocido` -- which slipped past the type-only esBase guard and persisted a device entry keyed builtin_speaker. From that moment on, every playback through the phone's own speaker matched that entry, so the green active-output dot stayed pinned to whatever the user had renamed it to (a car, in the reported case) whether or not anything was connected. The dot was never wrong; the row was poisoned. Give unnamed output types their own `other:<type>:<address>` id namespace, and match esBase by id as well as by type so no future native regression can re-create the collision. A guarded one-time migration purges what the collision already persisted from all three device-keyed maps. Fix the ranking too: builtin_speaker sat inside the priority list as a peer, so any type absent from that list sorted BELOW the always-present speaker and could never win. The speaker is now the explicit last resort, externally connected outputs outrank it, and virtual or call-only sinks (earpiece, telephony, remote submix, SCO) are ranked below it so they can never be reported as where music is playing. Route every AudioDeviceInfo.getAddress read through a version-guarded helper. It is API 28 with minSdk 24, and two pre-existing unguarded calls in this same method were latent NoSuchMethodError crashes on Android 7-8.1. Android lint for :app goes from 8 errors to 6. Also lets the user manage the list, which is how they recover from a bad entry without waiting for a release: a remove action clears a device's preset, name and matrix entries, unnamed rows show their transport and address tail instead of a raw bt_a2dp:AA:BB:... id, and the green dot finally carries a tooltip and a semantics label saying what it means. Device QA pending for wired and USB outputs: no jack or adapter available to exercise those paths. Their detection is unchanged by this commit. |
||
|
|
1e33a79724 |
fix(recordings): open the recordings folder from the system file manager
The recordings live in app-private storage (<data>/app_flutter/grabaciones), which the Android sandbox forbids any other app from reading, so no ACTION_VIEW on a file:// or FileProvider URI could ever open it. On top of that, viewDirectory built an EMPTY candidate list for that path: directoryDocumentUri returned null (path outside external storage) and FileProvider.getUriForFile threw because pluriwave_file_paths.xml never covered app_flutter. The loop never ran, so both entry points -- the radio recorder and Settings -- always showed "could not open the folder". Publish the folder as a browsable storage root via RecordingsDocumentsProvider instead. The files never leave private storage; the document framework asks us for them one document at a time, and the user can browse, copy out, rename and delete straight from the file manager. The root follows a user-configured path and falls back to the default recordings directory. Its title reuses the already-translated recordingsFolderTitle, so no new literal is introduced in any of the 13 locales. Also fixes "open last recording", broken by the same missing FileProvider root, and replaces Intent.createChooser with a bare startActivity in the candidate loop: a chooser never throws when nothing can handle the intent, so the first candidate always "succeeded" and the fallback chain never ran. Device QA pending -- the provider is driven entirely by the platform's document framework, so no unit test covers it. Each candidate logs its own name under file_actions.viewDirectory for logcat triage. |
||
|
|
d0abe32eef |
fix(audio): survive audio_service init hang on Android Auto cold start
AudioService.init has no internal timeout and an unhandled onConnectionSuspended case in its MediaBrowser self-bind; under bind contention with the car's connection it can hang forever, so runApp never ran (black car screen, white phone UI until process kill). Race init against an 8s timeout without ever re-calling it: on timeout run a bootstrap app that waits on the same future, wires the handler exactly once when it resolves, reports errors via FlutterError, and swaps to the real app. Auto browse sources now register before the init await since they take no handler dependency. |
||
|
|
29f7d54e85 |
fix(alarm): fail-safe alarm system overhaul (SDD alarm-system-overhaul, slice A)
Root-cause fix for the unstoppable-alarm incident (alarm rang 15 minutes, only uninstall silenced it) plus systematic hardening of every stop path. Native (Kotlin): - Verified stop: stopActiveAlarm now derives its result from the real post-teardown state (companion instance + synchronous stopEverything + activeRingingId check) instead of reporting unconditional success. - Atomic teardown: every stop path (stop action, notification button, snooze, missed, onDestroy, startForeground failure) funnels through one stopEverything() covering audio, wakelock, notification, foreground state and firing-record cleanup; player.release() guarded. - Bounded ringing: 10-minute auto-silence armed via AlarmManager fires a FIRED->MISSED transition with a localized missed-alarm notification; repeating alarms keep their native rearm, deleted alarms never produce ghost MISSED notifications. - Durable firing record with onStartCommand re-validation (resurrection guard) and boot-time stale cleanup; firing records cleared on every refuse/mismatch/cancel path. - New notification-only dismissal channel (dismissAlarmNotificationOnly) so UI-level dedup can never kill a live ring's audio. Flutter (Dart): - Stop/disable/edit/delete of a ringing alarm always attempt to silence it; on native-query failure the stop falls back toward silence via the id-scoped legacy stop. - Verified-stop results surface failures: the ringing screen keeps dismiss-by-design on success, but on a verified failure it stays up with a persistent force-stop banner (guarded against double-dismiss) and auto-dismisses if the ring ends externally (missed/notification). - Missed events sync alarm bookkeeping without opening the ringing UI. - 4 new l10n keys translated across all 13 locales (ARB guard green). 550 tests green, analyzer clean. Reviewed in 3 adversarial 4-lens rounds (2 deterministic + 1 refuter-corroborated critical fixed); formal gentle-ai receipt waived by maintainer authorization (correction scope legitimately exceeded the frozen genesis paths). On-device QA checklist in openspec/changes/alarm-system-overhaul/tasks.md pending before archive. |
||
|
|
163ff69f7a |
feat(eq): android auto custom equalizer and robust device detection
- MainActivity: onListen re-emits the current active device and registers the audio device callback idempotently, so recreated activities resync instead of freezing the active-device id on a disconnected device. - servicio_dispositivo_audio: resubscribir() re-opens the event channel; estado_ecualizador exposes refrescarDispositivoActual() with an in-flight guard, invoked on app resume and when opening advanced EQ options, clearing stale green-dot device selections. - navegacion_auto/servicio_audio: new 'Personalizado' browse tree in Android Auto (5 band folders, 13 gain steps each) applied live via setBanda; preset and gain taps persist at device level when multi-device EQ is active and respect station/matrix overrides, with apply-before-persist ordering and children-changed notifications. - l10n: regenerate stale generated localizations; add rxdart as direct dependency for the subscribeToChildren override. |
||
|
|
dfd40ca937 |
feat(auto): queue playback and shuffle for local music folders [size:exception]
Adds "Reproducir carpeta" (sequential) and "Reproducir aleatorio" (Fisher-Yates over the name-sorted order) as folder-scoped playable actions, with auto-advance on track completion and skip next/prev. Isolation from live radio is structural, not disciplinary: the public playMediaItem always clears the local queue on any call, and a new private _encolarCambioFuente is the only path that can advance within it. _cambiarFuente, ControladorReconexion, and the reconnect error path are untouched -- confirmed by a byte-for-byte empty diff on all 4 pre-existing radio/reconnect regression suites, independently re-run before and after (21/21 both times). Handler wiring itself is static-review-only (PluriWaveAudioHandler can't be unit-instantiated); the isolation/advance/race-guard decision logic is extracted into cola_local.dart's pure functions, which are fully unit-tested. |
||
|
|
352eb9fc37 |
feat(auto): real metadata, quality sort and name buckets for local music [size:exception]
Local tracks now show embedded title/artist/album art (via native MediaMetadataRetriever, cached through the existing FileProvider) instead of the raw filename, falling back gracefully when a file has no usable tags. Adds two navigable entry points per folder: sort by audio quality (bitrate, capped at 150 tracks per folder to bound worst-case latency) and alphabetical name buckets -- the closest realistic form of "filtering" given Android Auto has no text-search UI in this integration. Metadata resolves only for the page actually being browsed (same slice-cheap-then-map discipline as the paging change), backed by a flat 256-entry LRU session cache that survives across pages. No new permission, no new pub dependency, no l10n changes (car-tree labels stay hardcoded Spanish, matching every existing label in the tree). |
||
|
|
725169cd31 |
feat(auto): page local-music folders instead of truncating at 50 [size:exception]
Folders over the 50-item cap now show a "Mas..." item that reveals the next page on tap, instead of silently dropping the rest. Paging slices the cheap raw list before building any MediaItem, so items beyond the requested page are never resolved (art, title) -- proven by a call-count test. Also swaps the raw SAF content:// URI shown in settings for a parsed, human-readable folder name with a localized fallback across all 13 locales. servicio_audio.dart is untouched; this stays entirely within the local-music tree/dispatch layer. |
||
|
|
6ae7e378c4 |
feat(auto): browse and play local music folders in Android Auto [size:exception]
Phase 1: pick a device folder via SAF (persisted grant, no new permission), browse its nested subfolders/tracks as a 5th Android Auto root folder (hidden until configured), and play tracks through the existing pipeline (EQ, art rotation, cold-start-safe source). No metadata/sort/filter/shuffle yet -- filename is the title, generic rotating art is the placeholder; deferred to a follow-up phase. Adds a new pluriwave/file_actions native method (listAudioChildren) and an onActivityResult override in MainActivity for the SAF folder picker -- both static-review-only, no Android build available here. |