docs(p0): SysRS/SysDes/SRS/SAD/SDD/Verification + traceability for Android P0 reconciliation

Full P0 Android documentation chain:

- SysRS: API 24 → API 28 reconciliation per DEC-004 (SysRS-288);
  add SysRS-305 (Android in-call audio mode), SysRS-306
  (RECORD_AUDIO runtime timing).
- SysDes: SysDes-152 (in-call audio mode subsystem), SysDes-153
  (RECORD_AUDIO permission flow), SysDes-154 (Android voice audio
  backend), SysDes-155 (macOS runtime baseline).
- SRS: SRS-187 → API 28; add SRS-208 (in-call audio mode), SRS-209
  (RECORD_AUDIO + listen-only fallback), SRS-210..215 (Android voice
  audio backend latency/preset/AEC/usage/sharing/foreground service);
  retarget SysDes anchors from generic SysDes-135 to SysDes-152/153/154.
- SAD: SAD-063 refreshed (API 28); add SAD-084 (audio mode
  controller), SAD-085 (permission adapter with listen-only),
  SAD-086 (foreground service), SAD-087 (macOS runtime baseline);
  formalize cross-cutting + platform-specific allocation pattern
  in §24.1.
- SDD: expand SDD-028 (BackIntentService); refresh SDD-073 (build
  config); add SDD-105 (JNI bootstrap), SDD-106 (permission
  requester), SDD-107 (foreground service), SDD-108 (audio mode
  controller), SDD-109 (AAB pipeline), SDD-110 (PTT capability),
  SDD-111..116 (Android voice audio backend), SDD-118 (Android
  bridge build automation), SDD-119 (iOS/macOS bridge build
  automation back-fill).
- Verification: create android-p0-acceptance.md TC-1..TC-18; add
  SWE4-UV-040..052, SWE5-IV-016..026, SWE6-SV-018..030,
  SYS4-SIV-015 strengthened + SYS4-SIV-017/018.
- Governance: traceability matrix v0.9.9 with end-to-end chain
  closure; DEC-032 documents the temporary abiFilters reduction to
  arm64-v8a only and its restore-by gate.

Trace: full chain SysRS → SysDes → SRS → SAD → SDD → Code → Verification.
This commit is contained in:
EdisonJwa
2026-05-18 12:48:28 +08:00
parent 4c19410556
commit 5aa51c310f
13 changed files with 2487 additions and 17 deletions
+70 -2
View File
@@ -3,7 +3,7 @@
**Product name:** Chanora
**Document type:** SysDes / System Architectural Design
**Process alignment:** Automotive SPICE SYS.3 System Architectural Design
**Version:** 0.9.2
**Version:** 0.9.7
**Status:** Baseline Candidate
**Input baseline:** Chanora SysRS v0.6
**Target application type:** Cross-platform voice client application system
@@ -2888,9 +2888,61 @@ This SysDes version covers all known SysRS requirements from `SysRS-001` through
- ASPICE SYS.3 alignment: Element behaviour
- Allocated SysRS: SysRS-304
**SysDes-152**: The system architecture shall allocate engagement of the Android voice-communication audio mode (for example `AudioManager.setMode(MODE_IN_COMMUNICATION)` or an equivalent platform routing-assist mechanism) to the Android Platform Adapter as a dedicated in-call audio mode subsystem responsibility. The Android Platform Adapter shall (a) take a snapshot of the prior `AudioManager` mode before the first active voice session enters the connected state, (b) engage voice-communication mode no later than the moment the voice session becomes connected, (c) hold the mode for the full duration of any active voice session through refcount-composable enter/exit semantics so that overlapping or rapidly cycling sessions do not prematurely drop the mode, and (d) restore the snapshotted prior mode when the last active voice session ends. This is the system-architectural partitioning between the cross-platform Audio Subsystem (which owns capture/playback streams and codec) and the Android Platform Adapter (which owns the platform audio policy mode). This SysDes item is the proper anchor for the Android in-call audio mode software requirement.
- Status: Baseline Candidate
- Type: Subsystem Element / Platform Allocation
- Stage: P0 / MVP
- Allocated to: Android Platform Adapter, Audio Subsystem (consumer)
- Downstream artifact: SRS, SAD, SDD, Verification
- Verification method: Integration Test, System Test
- Verification owner: Audio / Platform QA, Android Owner
- ASPICE SYS.3 alignment: Static architecture, dynamic architecture, element allocation
- Allocated SysRS: SysRS-305
- Notes: Refines the Android platform baseline anchored by SysDes-135 (Android minimum runtime / Play target SDK policy); SysDes-135 remains the platform-baseline context item and is not in conflict with this element-allocation derivation. Consistent with SysDes-021 (OS services allocation) and SysDes-032 (Platform Adapter Layer).
**SysDes-153**: The system architecture shall allocate Android runtime microphone permission (`RECORD_AUDIO`) acquisition and denial-handling to the Android Platform Adapter as the system-design partitioning between the Permission Subsystem and the Voice Subsystem. The Android Platform Adapter shall (a) own the runtime permission request flow and surface a typed permission-state signal to the Rust Core, (b) ensure that the permission acquisition attempt occurs at or before voice session activation so that the cross-platform Audio Subsystem never opens an input capture stream without a granted permission, (c) provide a listen-only fallback path when the permission is denied, revoked, or not yet decided, in which the output stream lifecycle (per SysDes-150) is preserved and the transmit gate remains closed, and (d) expose a user-facing re-request entry point for granting the permission and retrying transmit. The Voice Subsystem and Audio Subsystem shall consume only the typed permission-state signal and shall not call platform permission APIs directly. This SysDes item is the proper anchor for the Android RECORD_AUDIO timing software requirement.
- Status: Baseline Candidate
- Type: Subsystem Element / Platform Allocation
- Stage: P0 / MVP
- Allocated to: Android Platform Adapter, Permission Subsystem, Audio Subsystem (consumer), Voice Subsystem (consumer), Flutter UI (re-request affordance)
- Downstream artifact: SRS, SAD, SDD, Verification
- Verification method: Integration Test, System Test
- Verification owner: Audio / Platform QA, Android Owner
- ASPICE SYS.3 alignment: Static architecture, element allocation, interface design
- Allocated SysRS: SysRS-306
- Notes: Additive to the platform-baseline anchor SysDes-135 and to the general OS-permission allocation in SysDes-021 / SysDes-059 (IF-014 Permission Interface). Consistent with SysDes-150 listen-only path (output stream independent of microphone permission). Inherits but does not duplicate the general microphone-permission obligation traced through SysRS-055.
**SysDes-154**: The system architecture shall allocate the Android voice audio backend as a dedicated subsystem owned by the Android Platform Adapter and exposed to the cross-platform Audio Subsystem (SE-13) through a trait-based backend abstraction, mirroring the platform-backend pattern already established on iOS (the `coreaudio-rs` / `VoiceProcessingIO` voice-audio path). The Android voice audio backend subsystem shall encapsulate (a) low-latency duplex voice capture and playback via the AAudio low-latency performance-mode path with platform-reported performance-mode observability for downstream latency budget evaluation, (b) voice-communication usage and content-type declarations on the output stream and a voice-communication input-preset selection on the capture stream so that Android's audio policy engine routes the streams under the voice-communication rules engaged by the in-call mode element (SysDes-152), (c) engagement of available platform hardware voice-audio effects (acoustic echo canceller, noise suppressor, automatic gain control) against the active capture session with documented fallback to the cross-platform software processing in the Audio Subsystem (SysDes-137 / SysDes-138) when a given hardware effect is unavailable, (d) a sharing-mode policy that requests exclusive sharing on a best-effort basis with graceful fallback to shared sharing recorded in sanitised audio diagnostics rather than surfaced as a user-facing fatal error, and (e) a lifecycle binding to the Android foreground service of microphone type so that background voice capture is hosted under the platform-required foreground-service model. The Audio Subsystem consumes the backend through the trait abstraction only and shall not depend on AAudio types directly. This SysDes item is the proper anchor for the Android voice audio backend software requirements (latency, input preset, hardware effects, output usage/content-type, sharing mode, foreground-service-hosted background capture).
- Status: Baseline Candidate
- Type: Subsystem Element / Platform Allocation
- Stage: P0 / MVP
- Allocated to: Android Platform Adapter (owner), Audio Subsystem (consumer through trait), Platform Adapter Layer, Diagnostics (sharing-mode telemetry)
- Downstream artifact: SRS, SAD, SDD, Verification
- Verification method: Integration Test, System Test, Audio Test
- Verification owner: Audio / Platform QA, Android Owner
- ASPICE SYS.3 alignment: Static architecture, dynamic architecture, element allocation, interface design, architecture analysis
- Allocated SysRS: SysRS-055, SysRS-305
- Notes: Refines the Android platform baseline anchored by SysDes-135 (Android minimum runtime / Play target SDK policy); SysDes-135 remains the platform-baseline context item and is unchanged. Trait-based platform backend pattern is shared with the iOS voice-audio path (`VoiceProcessingIO` via `coreaudio-rs`) but is not a code port. Composes with SysDes-152 (in-call mode), SysDes-153 (permission acquisition), SysDes-137 / SysDes-138 (audio processing default policy and platform-native preference with isolated fallback), SysDes-144 (`capture_active` / `transmit_active` split), SysDes-150 (audio engine lifecycle bound to voice-channel membership), and the foreground-service obligation already represented at the system level (SysRS-055, SysRS-111 chain).
**SysDes-155**: The system architecture shall allocate the macOS runtime baseline as a dedicated platform-baseline element parallel to SysDes-133 (iOS) and SysDes-135 (Android), covering (a) the macOS deployment-target policy as a single-source-of-truth system-design concern owned by the macOS Build Configuration and consumed identically by the Flutter macOS runner and the Rust `chanora_bridge` native dependency (the canonical declaration site is the CocoaPods podspec at `apps/chanora_flutter/macos/chanora_bridge.podspec`, which is the location to be cited by downstream SRS/SAD/SDD; the numeric value itself is an implementation detail and is not embedded in this SysDes item), (b) a universal-binary packaging policy under which the Rust cdylib shall be produced for both `arm64` and `x86_64` host slices and combined via `lipo` into a single fat Mach-O binary so that one packaged macOS application supports Apple Silicon and Intel hosts without per-architecture artefacts, (c) the macOS `.framework` `Versions/A` bundle layout convention (versioned bundle directory with `Current` symlink, `Resources/Info.plist`, and the binary at `Versions/A/<FrameworkName>`) as the system-level packaging shape for the native bridge so that it is loadable by the Flutter macOS runner and is acceptable to codesigning and notarisation, and (d) CocoaPods podspec integration as the auto-build mechanism that drives the Rust cdylib build, the universal-binary `lipo` step, and the `.framework` assembly during a `pod install` / Flutter macOS build, so that the macOS build pipeline has a single, declarative entry point. This SysDes item is the proper macOS platform-baseline anchor for SAD-087 and for SRS items that allocate macOS-runtime responsibility, replacing any "open follow-up" SysDes placeholder previously carried by SAD-087.
- Status: Baseline Candidate
- Type: Platform Architecture Decision
- Stage: P0 / MVP
- Allocated to: macOS Build Configuration (owner), Platform Adapter Layer (macOS Platform Services), Release / Operations (Release Pipeline), Verification
- Downstream artifact: SRS, SAD, SDD, Verification
- Verification method: Review, Platform Test (macOS), Release Inspection
- Verification owner: macOS Owner / Release Manager
- ASPICE SYS.3 alignment: Static architecture, architecture constraints, element allocation, consistency
- Allocated SysRS: SysRS-002, SysRS-050, SysRS-193
- Notes: Parallel in role to SysDes-133 (iOS runtime baseline) and SysDes-135 (Android runtime baseline); neither SysDes-133 nor SysDes-135 is modified by this item. Source SysRS selection: SysRS-002 anchors the multi-platform obligation that explicitly enumerates macOS as a target client platform, SysRS-050 anchors the macOS runtime environment obligation for native desktop integration, and SysRS-193 anchors the signed/notarized macOS build obligation that the `.framework` `Versions/A` layout and universal-binary policy must satisfy in the release pipeline. No macOS-specific deployment-target or universal-binary SysRS item currently exists; if a finer-grained macOS minimum-runtime SysRS item is required (analogous to SysRS-286 for iOS and SysRS-288 for Android), the systems-requirements owner should consider authoring it in a follow-up — this SysDes item is structured so that such a future SysRS item can be added to `Allocated SysRS` without restructuring the element. SysDes-155 cites the podspec file path only and does not embed its current deployment-target value; the value itself remains owned by the Build Configuration subsystem.
## 17. Updated SysRS Coverage Statement
This SysDes version covers all known SysRS requirements from `SysRS-001` through `SysRS-304`.
This SysDes version covers all known SysRS requirements from `SysRS-001` through `SysRS-306`.
| SysRS Range | SysDes Coverage |
|---|---|
@@ -2898,6 +2950,8 @@ This SysDes version covers all known SysRS requirements from `SysRS-001` through
| SysRS-286 through SysRS-295 | Covered by `SysDes-133` through `SysDes-141` |
| SysRS-296 through SysRS-302 | Covered by `SysDes-142` through `SysDes-148` |
| SysRS-303 through SysRS-304 | Covered by `SysDes-149` through `SysDes-151` |
| SysRS-305 through SysRS-306 | Covered by `SysDes-152` through `SysDes-154` (with SysDes-154 additionally refining SysRS-055 for the Android voice audio backend) |
| SysRS-002 / SysRS-050 / SysRS-193 (macOS platform-baseline slice) | Additionally refined by `SysDes-155` (macOS runtime baseline, parallel to SysDes-133 / SysDes-135) |
## Baseline Candidate 0.9.1 Update
@@ -2926,3 +2980,17 @@ This SysDes version covers all known SysRS requirements from `SysRS-001` through
| Version | Date | Description |
|---|---|---|
| 0.9.5 | 2026-05-15 | Added v1 audio + PTT lifecycle allocation SysDes-149 through SysDes-151 sourced from SysRS-303 / SysRS-304: `TransmitMode` enum element (`Ptt` / `Continuous` / reserved `VoiceActivity` per DEC-030) at the audio + bridge + UI boundary, audio engine lifecycle bound to voice-channel membership with no manual start affordance and a listen-only path independent of mic permission, hard-mute override element, and the release-tail timer adapter (default 200 ms, range 0500 ms) on `transmit_active`. Strict layered sourcing preserved (`SysDes -> SysRS` only). |
## Baseline Candidate 0.9.6 Update
| Version | Date | Description |
|---|---|---|
| 0.9.6 | 2026-05-18 | Added dedicated Android voice-audio element allocations SysDes-152 (Android in-call audio mode subsystem, source SysRS-305), SysDes-153 (Android RECORD_AUDIO runtime permission acquisition flow as system-design partitioning between Permission Subsystem and Voice Subsystem, source SysRS-306), and SysDes-154 (Android voice audio backend subsystem: trait-based platform backend mirroring the iOS `VoiceProcessingIO` pattern, AAudio low-latency path, voice-communication usage/preset, hardware effects engagement, sharing-mode policy, FGS-hosted background mic lifecycle; source SysRS-055 + SysRS-305). SysDes-135 remains the Android platform-baseline context item and is unchanged. These derivations are the proper SysDes anchors for SRS-208, SRS-209, and SRS-210..215, which currently cite SysDes-135 generically and shall be retargeted by the software-requirements owner in a follow-up pass. Strict layered sourcing preserved (`SysDes -> SysRS` only). |
## Baseline Candidate 0.9.7 Update
| Version | Date | Description |
|---|---|---|
| 0.9.7 | 2026-05-18 | Added dedicated macOS runtime baseline element allocation SysDes-155, parallel in role to SysDes-133 (iOS runtime baseline) and SysDes-135 (Android runtime baseline). SysDes-155 anchors the macOS deployment-target policy as a single-source-of-truth concern (citing the podspec file path `apps/chanora_flutter/macos/chanora_bridge.podspec` without embedding its value), the universal-binary (`lipo`'d `arm64` + `x86_64`) packaging policy, the `.framework` `Versions/A` bundle layout convention, and CocoaPods podspec integration as the auto-build mechanism for the Rust cdylib. Allocated to macOS Build Configuration, Platform Adapter Layer (macOS Platform Services), Release Pipeline, and Verification. Source SysRS: SysRS-002 (multi-platform target client platforms including macOS), SysRS-050 (macOS runtime environment / native desktop window integration), SysRS-193 (signed/notarized macOS builds). SysDes-155 is the proper SysDes anchor for SAD-087 and for downstream SRS items that allocate macOS-runtime responsibility, and is the recommended retarget for SAD-087's previously-open Source SysDes follow-up. SysDes-133 and SysDes-135 are unchanged. Strict layered sourcing preserved (`SysDes -> SysRS` only). Follow-up recommendation: systems-requirements owner may consider authoring a finer-grained macOS minimum-runtime SysRS item parallel to SysRS-286 (iOS) and SysRS-288 (Android); SysDes-155 is structured so that such a future SysRS item can be added to its `Allocated SysRS` list without restructuring the element. |