FreeTLab/pluriwave
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(openspec): cancel alarm FGS slice, the alarm service type never existed
Build & Deploy PluriWave / Análisis de código (push) Successful in 34s
Details
Build & Deploy PluriWave / Build APK + AAB release (push) Successful in 1m43s
Details

Browse Source 
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.
This commit is contained in:
FreeTLab
2026-07-11 01:22:18 +02:00
parent 39693ce995
commit 43f61d7c21
3 changed files with 27 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files
openspec/changes/alarm-volume-ramp-restore/design.md
+14
View File
@@ -1,5 +1,19 @@
# Design: Alarm Volume Ramp & Device-Volume Immunity
> **SLICE 1 CANCELLED — CORRECTION (2026-07-11, apply-stage SDK verification).**
> The first two Architecture Decisions below are built on constants that DO NOT EXIST in the
> Android SDK: `FOREGROUND_SERVICE_TYPE_ALARM` and `android.permission.FOREGROUND_SERVICE_ALARM`
> are fictional (verified via `javap -constants` on the local android-34/35/36 platform jars and a
> full `api-versions.xml` sweep — 13 real FGS types, no alarm variant; constants are additive, so
> absence in 36 rules out 34/35). The existing `mediaPlayback|systemExempted` declaration is the
> documented correct pattern for an alarm-clock app holding exact-alarm permissions starting an FGS
> from an AlarmManager broadcast, and the prior `app-quality-and-native-alarms` deviation
> (T-S1-03/04) that kept it was right. Slice 1 ships NO code change. Root Cause B from the
> exploration is withdrawn; the user-visible bug is fully attributed to Root Cause A (media-stream
> steady state), addressed by Slices 2 and 3, which are independent and unaffected.
> Evidence trail: engram `sdd/alarm-volume-ramp-restore/apply-progress` (#2332) and project
> discovery `android/fgs-alarm-type-nonexistent` (#2333).
## Technical Approach
Three independent, rollback-isolated slices realizing proposal #2302. Kotlin owns the manifest fix and a new ring-scoped `STREAM_MUSIC` override (no Flutter volume plugin exists; `MainActivity` already owns the audio channels). Dart drives lifecycle: it invokes override at ring start and restore from the already-centralized exit points. The existing 5%->`alarma.volumen` Dart player ramp is kept; only the audible fade-in *driver* is deduped at handoff. Normal radio playback and `ServicioAudioSession` ducking (S3-R1) are never touched — the override fires only while a ring is active. Kotlin is code-inspection + mandatory on-device QA (flutter build forbidden); Dart follows strict TDD.