4 Commits

Include renames

Author	SHA1	Message	Date
FreeTLab	66a19525bd	fix(alarm): defer the Dart fade-in until the native handoff confirms ... The native service and the Flutter player each ran their own 5%-to- target fade-in, and both could drive audible volume at the handoff, producing a jump or ramp reset. The Dart ramp now starts exactly once from the handoff-confirmation path: the player still pre-starts at 5%, and _confirmarAudioFlutterListo() starts the ramp in a finally block so it runs whether the native confirmation succeeds or fails — the alarm can never stay stuck at 5% if the native side is already gone. Work unit 3/3 of alarm-volume-ramp-restore (fade-in dedup).	2026-07-11 09:57:06 +02:00
FreeTLab	acd903d9a8	feat(alarm): make the ring immune to device media volume ... The alarm's steady-state audio runs on the Flutter media-stream player after the native handoff, so device volume 0 silenced it entirely. The ring now forces STREAM_MUSIC to an audible reference: Dart requests the override before pre-starting alarm audio (fallback WAV included), Kotlin captures the current volume once and restores it idempotently on every exit path (dismiss, snooze, dispose), with a native best-effort backstop in service teardown. The backstop is handoff-aware via PluriWaveAlarmService.flutterOwnsRing: confirmFlutterAudio marks the handoff before triggering the native stop, so the backstop cannot restore the volume mid-ring right as the Flutter player takes over (that would re-silence the alarm at volume 0). The flag resets at every ring start; Flutter process death after handoff remains a documented best-effort gap. The alarm's perceived loudness keeps ramping 5% to the configured volume through the player as before; normal radio playback and call ducking never touch the override. Work unit 2/3 of alarm-volume-ramp-restore (ring volume override).	2026-07-11 09:15:37 +02:00
FreeTLab	43f61d7c21	docs(openspec): cancel alarm FGS slice, the alarm service type never existed ... Apply-stage SDK verification (javap on android-34/35/36 platform jars plus api-versions.xml) proved FOREGROUND_SERVICE_TYPE_ALARM and the FOREGROUND_SERVICE_ALARM permission are fictional constants. The existing mediaPlayback|systemExempted declaration is the documented correct pattern for an alarm app holding exact-alarm permissions, so slice 1 ships no code and root cause B is withdrawn. Spec, design, and tasks amended with the evidence; volume-override and fade-dedup slices proceed unaffected.	2026-07-11 01:22:18 +02:00
FreeTLab	747738d20a	docs(openspec): add SDD artifact trails for bt-device-identity and alarm-volume-ramp-restore ... In-progress artifact sets from the current SDD cycles: exploration, proposal, spec, design, tasks, and verify reports as produced so far. Also drops a leftover working copy of eq-device-disconnect-revert whose contents were already committed under changes/archive/.	2026-07-11 00:56:22 +02:00