4 Commits

Include renames

Author	SHA1	Message	Date
FreeTLab	3449e2cb79	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-08-31 14:34:49 +02:00
FreeTLab	1d5332453f	fix(audio): make the audio diagnostics visible in release builds ... Every diagnostic line in the audio path used `dart:developer`'s `log()`. That function writes to the VM service, which a RELEASE build does not have — so in the only build that ever runs in a car, all eleven of them went nowhere. `debugPrint`/`print` do reach logcat in release; `log()` does not. That includes the two channels built specifically to end the guessing: - `registrarErrorAudioService`, which subscribes to `AudioService.asyncError` so the plugin's swallowed platform exceptions stop vanishing (b0271fa). It moved them from a dropped PublishSubject to a dropped log call. - `_trazarEstadoPublicado`, the published-state trace added in 7054a4c to settle why the car's play button never becomes pause. So "no evidence" was never a quiet app. It was an app writing its evidence somewhere release builds discard. Several rounds of hypotheses were argued without data that the app was already producing. All eleven now use `debugPrint` with a `[PluriWave][Tag]` prefix, so one filter catches the audio path and the existing alarm lines together: adb logcat | grep PluriWave No behaviour changes. Tests: 1158, unchanged.	2026-08-06 21:48:20 +02:00
FreeTLab	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.	2026-08-01 19:15:53 +02:00
FreeTLab	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.	2026-07-25 13:43:40 +02:00