Arquitectura de alarmas con pantalla apagada

Diagnóstico

El flujo anterior hacía que Android recibiese la alarma con AlarmManager, pero el sonido real dependía de que se abriese MainActivity y de que Flutter llegase a pintar PantallaAlarmaSonando. Con pantalla apagada, Doze o restricciones del fabricante, ese arranque de UI puede retrasarse hasta que el usuario enciende la pantalla.

Decisión

La alarma debe sonar desde Android nativo en cuanto llega ACTION_FIRE. Flutter pasa a ser la interfaz de control para detener, posponer y hacer handoff a la radio de la app, pero no el único origen del sonido.

Flujo recomendado

AlarmScheduler programa la alarma con setAlarmClock y fallback exact/inexact.
PluriWaveAlarmReceiver recibe ACTION_FIRE.
El receiver arranca PluriWaveAlarmService como foreground service.
El servicio toma un PARTIAL_WAKE_LOCK, muestra notificación foreground y reproduce audio con USAGE_ALARM.
La UI Flutter se abre por full-screen intent si Android lo permite.
Al detener/posponer desde Flutter, se manda comando nativo para parar el servicio.

Referencias

Android alarms: https://developer.android.com/develop/background-work/services/alarms
Foreground service restrictions: https://developer.android.com/develop/background-work/services/fgs/restrictions-bg-start
AOSP DeskClock AlarmService: https://android.googlesource.com/platform/packages/apps/DeskClock/+/ac260c0096605526f772af7eec73d6a51dc6de32/src/com/android/deskclock/alarms/AlarmService.java

Notas

El audio local interno es el fallback más fiable para pantalla apagada.
La radio remota puede fallar por red, DNS, TLS o timeout; por eso debe existir fallback interno.
Si un fabricante bloquea incluso servicios arrancados desde alarma, habrá que guiar al usuario con permisos de batería/autostart.

1.8 KiB Raw Blame History