24 Commits

Include renames

Author	SHA1	Message	Date
FreeTLab	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.	2026-09-04 13:26:00 +02:00
FreeTLab	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.	2026-09-04 13:26:00 +02:00
FreeTLab	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.	2026-09-04 13:26:00 +02:00
FreeTLab	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.	2026-08-10 20:37:07 +02:00
FreeTLab	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 2540556, "give the equalizer actions distinct, state-aware icons". 9eff760 (31-07) androidIcon: 'drawable/ic_stat_pluriwave' -> in the APK 2540556 (31-07) androidIcon: 'drawable/ic_auto_eq_on' -> NEVER in it That commit swapped a drawable that shipped for two that the stale CI resource cache never included. From that moment getResourceId returned 0, PlaybackStateCompat.CustomAction.Builder threw, and the throw aborted AudioService.setState before the session was published -- so every Android Auto symptom chased since is one line of that commit. The bitter part is that 2540556 was itself a fix for a report about two identical icons. Three changes. 1. CI guard. The build now unzips the release APK and fails if a drawable resolved by NAME at runtime is missing. Resolution by name cannot fail at compile time -- it fails in the car, silently, with id 0. This class of bug shipped undetected for a week; it cannot ship again. 2. Skipping stations now walks the favourites GROUP first, as requested: group -> all favourites -> my stations -> catalogue. Two deliberate exclusions, both tested: `sinAsignarId` is the ABSENCE of a group, not a group, so those walk all favourites; and a one-member group falls through too, or both buttons would be dead ends. The group is read from the FAVOURITE record, never from the playing station -- that one is rebuilt by emisoraDesdeMediaItem, which carries no group id and would always report "unfiled". 3. Diagnostics on the station skip. It was reported as doing nothing for radio, and every early return in that method is silent: an empty list and a single-entry list look identical from outside. The log now names which one fired, so the next capture answers it instead of another hypothesis. Tests: 1161 -> 1165.	2026-08-07 11:38:27 +02:00
FreeTLab	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 c1afe72 yesterday. That commit moved registrarFuenteNavegacion above every await to keep a headless engine from dying before it ran -- but left registrarFuenteMusicaLocal below `await SharedPreferences.getInstance()`. The root menu decides whether to offer "Música Local" with `fuenteLocal != null && await fuenteLocal.hayCarpetaConfigurada()`, so the car could now get a root response in the window between the two registrations, find a null source, and be told there is no local music. Android Auto caches the browse root, so it stayed missing for the whole session. Before the reorder both registrations sat together after the await and the window did not exist. FuenteMusicaLocalAutoImpl never needed prefs to be CONSTRUCTED -- it resolves them lazily per call, the same convention ServicioAlarmas uses -- so it now registers beside the station source, above every await, and the window is gone rather than narrowed. 2. PluriWave disappeared from the Auto pane mid-drive, the playback screen sat frozen, and the equalizer was lost on every navigation prompt. One cause for all three. androidWillPauseWhenDucked: true made audio_session translate Android's AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK into a full PAUSE. In a car that fires constantly: every navigation instruction, every speed-camera warning, every voice assistant. And a pause publishes playing:false, which AudioService.setState turns into exitPlayingState() and, with androidStopForegroundOnPause: true, into stopForeground(...). The plugin's own doc for that flag says what follows: "while in this lower priority state, the operating system will also be able to kill your service at any time to reclaim resources". A killed service is a media session that vanishes from the car pane -- and another media app takes the slot. Now the app ducks instead of pausing, so playing stays true and session, notification and pane all survive an interruption; and the service stays foreground even on a real pause, so a genuine one is not a death sentence either. androidNotificationOngoing goes to false because the plugin asserts it implies stopForegroundOnPause, and nothing is lost: a foreground service already forces the notification to be ongoing. A real, non-duckable focus loss (a phone call) still pauses and still auto-resumes -- asserted, so the duck change cannot silently turn a call into a station playing over it. 3. Previous/next on the car playback screen, for stations too. skipToPrevious/skipToNext are now advertised unconditionally, since Android Auto only draws those buttons when the app declares support. They are no longer inert without a local queue: they walk the narrowest list the current station belongs to -- favourites, then my stations, then the catalogue -- wrapping at both ends, because a button that goes dead at the end of a list reads as broken on a screen with no visible list position. Matching is by uuid so a refreshed snapshot still resolves, and a station in no list leaves playback untouched. The equalizer toggle still fits alongside them: prev/next take their two reserved slots and the equalizer claims the remaining custom-action room because construirControlesTransporte places it before MediaControl.stop. The phone notification is deliberately untouched: `controls` still gates skip on an active queue, so nativeActions and androidCompactActionIndices are byte-identical. Only systemActions changed, and only the car reads those. Tests: 1146 -> 1158.	2026-08-06 19:49:57 +02:00
FreeTLab	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 e9d1f67, the first commit of the project -- git log -S confirms it was never once edited. So the required actions have never been advertised, and no audio commit can explain a change in behaviour. Android Auto ships as its own app and updates itself, which is how a working screen breaks with a clean repo history. That fits the report better than any commit here does. The phone notification was never affected: it builds its play/pause button from `controls`, not from these bits, which is exactly why the symptom is car-only. Skip actions stay conditional on an active queue on purpose -- the same guide notes Auto reserves the prev/next slots for them and gives the space to custom actions when the app does not support them, and that is the space the equalizer toggle needs. ACTION_PLAY_FROM_SEARCH is now implemented rather than merely claimed: advertising it unimplemented would have the car's assistant accept "play Radio X" and silently do nothing. emisoraParaBusqueda ranks exact name, then prefix, then substring, then country, accent- and case-insensitive because voice transcription rarely gets diacritics right; favourites are searched first so they win a name tie, and a miss plays nothing rather than something arbitrary. Still a hypothesis for the play/pause symptom, not a confirmed fix -- it is documentation-backed and cheap, but only a head unit can confirm it. Tests: 1132 -> 1141.	2026-08-06 01:28:42 +02:00
FreeTLab	80538900db	fix(alarmas,auto): guard the last unguarded snooze path, surface car progress ... Continuation of 7054a4c: the native anchor guard alone did not fix the reported ~1444-minute snooze, because Dart runs AFTERWARDS on the pre-notice path and had no guard at all. 1. Snooze from the pre-notice notification, root cause. app.dart dispatches AFTER the receiver's postponeNext already ran and after startActivity, and EstadoAlarmas.posponerProximaDesdePreaviso took whatever occurrence it was handed on faith, then persisted and rescheduled from it -- the last snooze path in the codebase with no occurrence guard. The occurrence itself is not trustworthy either: app.dart falls back to alarma.proximaEjecucion when the native event carries none, and that field can already point at tomorrow. _ocurrenciaSonando is generalized into _ocurrenciaValida with a caller- supplied forward allowance and an externally-proposed occurrence that still has to survive the same check. The pre-notice path gets a ventanaPreaviso (30 min, matching AlarmScheduler.PRE_NOTICE_MILLIS) -- unlike the ringing-screen guard, this occurrence legitimately has not happened yet, which is exactly why the existing helper could not just be reused here. Also heals state already poisoned by the missing guard: a snoozeHasta parked past a 3-hour ceiling (posponerEjecucion clamps to 120 minutes, so anything beyond that is corruption, not a long real snooze) is dropped on recalculation. Without it, an alarm poisoned on a build before this fix keeps reporting tomorrow after updating, and the user reasonably concludes nothing changed. 2. Android Auto: no progress bar or time labels on a local track. updatePosition was never set anywhere in the handler, so it sat at its Duration.zero default while copyWith refreshed updateTime to now on every push -- the car was told "position 0, as of right now" on every event, a bar pinned at the start regardless of what was actually playing. Now set from _player.position on both the player-state and buffered-position listeners (the latter ticks ~2/s, which is what keeps the car's bar smooth between player-state events). Also stream the MediaItem's duration once the source reports it -- Auto draws no bar at all without one, and radio streams correctly keep reporting none (live audio has no length). 3. Android Auto: drop the Ecualizador browsable folder. Owner decision after driving with it: a browsable six-preset list is more interaction than a driver wants, and on/off from all three player views (already fixed in 7054a4c to win the custom-action slot) is the only equalizer control that belongs in the car. Preset selection stays on the phone. This lands back on the redesign mockup's original rule ("sin carpeta de ecualizador"), now for a road-tested reason. getChildren keeps answering the folder's id transitionally, since a head unit can have the old tree cached for a session or two. The two "raiz always includes/ends with Ecualizador" tests are replaced, not regressed -- same move the codebase already made once in the other direction for the same folder. Tests: 1127 -> 1132.	2026-08-05 23:07:10 +02:00
FreeTLab	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 cacd3ec removed it on the theory that a custom action in `controls` aborts `AudioService.setState` and kills the media notification. Reading the plugin source refutes it. setState (AudioService.java:513-520) SPLITS the list -- a control carrying a customAction goes to `customActions` (PlaybackStateCompat, i.e. the car), everything else becomes a NotificationCompat.Action in `nativeActions` (the phone notification). The two never mix. And the throw the theory depended on cannot happen here: ic_auto_eq_on/ic_auto_eq_off both exist under res/drawable, and the labels are non-empty in all 13 locales. The notification outage was already fixed by abc6b47 (transient idle on a source change, which setState turns into a full stop() at :557). The action is back, with both state-aware icons. The real invariant -- a custom action's icon must resolve and its label must be non-empty -- is now a test that reads res/drawable and fails on a missing file, instead of a comment claiming custom actions are forbidden outright. 2. The Ecualizador folder never listed the user's saved presets. itemsEcualizadorAuto iterated PresetEcualizador.presets, so only the six factory presets appeared -- the user's own were unreachable from the car, the surface where a preset picker matters most. They now arrive through a registered read function (same seam as stations and local music, re-read per browse so a preset saved on the phone shows up without an app restart). presetsEcualizadorAuto is the single source of truth for the ordered universe, used to BUILD the items and to RESOLVE a tap, so the folder cannot show an item that resolution then refuses -- which is what the factory-only default in seleccionarPresetEqPorMediaId would have caused. A custom preset whose name collides with a factory one is dropped: the media id is the raw name, so it could only ever resolve to the factory entry, and an item that applies a preset other than the one it names is worse than an absent one. Tests: 1108 -> 1120.	2026-08-03 21:32:09 +02:00
FreeTLab	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.	2026-08-01 11:26:24 +02:00
FreeTLab	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 2403da3), which predated this feedback -- see decision auto/ecualizador-diseno. The preset-cycling custom action still coexists with the folder in this commit; it is removed in the next one.	2026-07-31 19:11:01 +02:00
FreeTLab	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.	2026-07-31 00:47:26 +02:00
FreeTLab	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.	2026-07-31 00:43:20 +02:00
FreeTLab	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.	2026-07-31 00:38:39 +02:00
FreeTLab	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.	2026-07-27 15:50:24 +02:00
Javier Bautista Fernández	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.	2026-07-22 10:26:02 +02:00
FreeTLab	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.	2026-07-20 01:08:15 +02:00
FreeTLab	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).	2026-07-19 23:52:08 +02:00
FreeTLab	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.	2026-07-19 22:14:05 +02:00
FreeTLab	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.	2026-07-19 20:30:50 +02:00
FreeTLab	90cd232ad2	feat(auto): expose EQ presets as a browsable Android Auto folder ... Adds an Ecualizador folder listing the 6 fixed presets; selecting one applies and persists it through the existing headless-safe seam without touching playback or the now-playing media item.	2026-07-19 14:12:39 +02:00
FreeTLab	f368bcc777	feat(auto): surface favorite groups as Android Auto sub-folders ... Favoritos now renders non-empty custom groups as grupo:<id> sub-folders (hidden when empty) with ungrouped stations left as direct leaves, reusing the existing hijos() path so the zero-groups case stays byte-identical to today's flat list.	2026-07-19 13:42:25 +02:00
FreeTLab	c193650cc4	fix(auto): fall back to brand art and surface quality on dead/missing favicons ... Android Auto no longer copies the launcher icon as placeholder art; it rotates through the same 4 on-brand station_art assets the phone UI already uses, keyed by the same per-station hash for visual parity. Malformed or unusable favicon URLs (including a Dart Uri quirk where 'http://' reports hasAuthority=true with an empty host) now fail the validity gate instead of being handed to the OS media browser as-is. Browsable items also show codec/bitrate as a subtitle when known.	2026-07-19 13:06:18 +02:00
Javier Bautista Fernández	35bb180612	feat(auto): browsable Android Auto media tree with play-by-id [size:exception] ... Expose PluriWave to Android Auto (projected) as a media app: - Declare car media support (automotive_app_desc.xml + manifest meta-data) so Android Auto discovers the existing MediaBrowserService. - New navegacion_auto.dart: ConstructorArbolAuto builds the browse tree (Favoritos / Todas las emisoras / Mis emisoras, 50-item cap, stable emisora:<id> media ids), reproducirPorMediaId routes a car tap to the existing playMediaItem pipeline, FuenteEmisorasAutoLocal serves the tree cold-start-safe (local favorites/custom stations before Flutter UI runs). - PluriWaveAudioHandler overrides getChildren/getMediaItem/playFromMediaId as thin delegations; playback pipeline untouched. - EstadoRadio pushes live station snapshots to the browse source and reconciles the selected station when playback starts from the car. - Every playable item ships title + artUri; stations without logo fall back to a bundled default art (android.resource://). Tests: 52/52 green (10 new navegacion_auto, 2 new estado_radio, plus audio safety-net suites). Handler overrides and native XML are static-review-only (no Android build env). Size exception approved for a single reviewable commit.	2026-07-16 16:28:44 +02:00