FreeTLab
b294b287c7
The live eventosAlarma stream and the one-shot obtenerEventoInicial() both read the same native fire event on cold start, so the same alarm id can reach _mostrarAlarmaSonando twice within the same tick. The second, duplicate delivery correctly detected an alarm was already active and hit the "ignored" branch — but that branch unconditionally called ocultarNotificacionAlarma, whose native handler (dismissAlarmNotification) unconditionally stops PluriWaveAlarmService for that id. Confirmed via on-device logcat: the duplicate's stop landed ~180ms after the ring-scoped media-volume override was captured and ~2.3s before the real native-to-Flutter handoff, so flutterOwnsRing was still false and the teardown backstop restored the device's original volume immediately. The Flutter/radio player kept ringing regardless (it starts independently of the native service), now anchored to whatever volume the device happened to be at — explaining both "ignores the configured ramp" and "plays at the device's own volume." The ignored branch now only hides the notification when the duplicate carries a genuinely different alarm id than the one already ringing; a duplicate of the SAME ring's own event is now a pure no-op.