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.

docs/requirements/srs.md

@@ -3,7 +3,7 @@
 **Product name:** Chanora
 **Document type:** SRS / Software Requirements Specification
 **ASPICE process alignment:** SWE.1 Software Requirements Analysis
-**Version:** 0.9.2
+**Version:** 0.9.8
 **Status:** Baseline Candidate
 **Source baseline:** `chanora_SysDes_ASPICE_SYS3_v0.5.md`
 **Architecture baseline:** Flutter + Rust Core + `tsclientlib` protocol adapter
@@ -2434,14 +2434,15 @@ This section extends the ASPICE SWE.1 Software Requirements Specification. The s
 - Source SysDes: SysDes-134
 - Verification method: Release Inspection
 
-**SRS-187**: The software shall define Android API 24 as the minimum Android runtime baseline unless approved platform constraints raise the minimum version.
+**SRS-187**: The software shall define Android API 28 (Android 9.0) as the minimum Android runtime baseline, per DEC-004 (Accepted 2026-05-14, which raised the original API 24 recommendation to API 28). The minimum may be raised further only if Flutter, plugin, audio, or platform constraints require it; it shall not be lowered without a superseding accepted decision.
 
 - Status: Baseline Candidate
 - Type: Software Platform Requirement
 - Stage: P0 / MVP
 - Allocated to: Android Build Configuration, Platform Adapter
 - Source SysDes: SysDes-135
-- Verification method: Platform Test
+- Verification method: Platform Test, Release Inspection
+- Change record: 0.9.6 (2026-05-17) updated minimum Android API from 24 to 28 to align with DEC-004 and the reconciled SysRS-288 wording. ID preserved.
 
 **SRS-188**: The Android release build process shall target the Android API level required by Google Play on the upload date.
 
@@ -2623,6 +2624,30 @@ This section extends the ASPICE SWE.1 Software Requirements Specification. The s
 - Source SysDes: SysDes-150
 - Verification method: Functional Test, UI Review
 
+**SRS-208**: The Chanora Android client shall engage the Android in-call audio mode (for example via `AudioManager.setMode(MODE_IN_COMMUNICATION)` or an equivalent platform routing-assist mechanism) no later than the moment a voice session becomes connected, so that microphone gain, output routing, echo handling, and Bluetooth SCO behaviour follow Android's voice-communication path rather than the media path. The client shall release the in-call mode (restoring the prior audio mode) when the last active voice session ends.
+
+- Status: Baseline Candidate
+- Type: Platform Behavioural Requirement
+- Stage: P0 / MVP
+- Allocated to: Audio (Android), Platform Adapter (Android)
+- Source SysDes: SysDes-152 (Android in-call audio mode subsystem allocation, primary), SysDes-135 (Android platform baseline, secondary/context)
+- Verification method: Android Integration Test, Audio Test
+- Acceptance criteria: On Android, audio-mode transitions to in-communication on first voice-session connect and reverts on last voice-session disconnect; behaviour is observable via platform audio diagnostics and produces voice-path routing for SCO/built-in mic.
+- Analysis: Feasible via the existing Platform Adapter (Android) boundary and JNI call into `AudioManager`. Verification intent (SWE.6): demonstrate audio-mode entry/exit transitions are bound to voice session lifecycle, not to UI screen lifecycle.
+- Unresolved assumptions: None at SRS layer. Upstream SysDes derivation now anchored at SysDes-152 (with SysDes-135 retained as platform-baseline context).
+
+**SRS-209**: The Chanora Android client shall request the runtime microphone permission (`RECORD_AUDIO`) at or before voice session activation, and shall not begin microphone capture without that permission having been granted. If the permission is denied, revoked, or not yet decided, the client shall fail safe to listen-only operation (output stream remains available consistent with SRS-204) and shall surface a user-visible path to grant the permission before retrying transmit.
+
+- Status: Baseline Candidate
+- Type: Platform Behavioural Requirement / Privacy
+- Stage: P0 / MVP
+- Allocated to: Platform Adapter (Android), Audio, Flutter UI
+- Source SysDes: SysDes-153 (Android RECORD_AUDIO runtime permission acquisition flow, primary), SysDes-135 (Android platform baseline, secondary/context)
+- Verification method: Android Integration Test, UI Test, Privacy Review
+- Acceptance criteria: Permission prompt occurs no later than the user's first transmit attempt within a voice session; denial keeps the session alive in listen-only mode (`capture_active = false`, `transmit_active = false`, output stream open per SRS-204); UI exposes a non-blocking path to re-request or open system settings to grant the permission.
+- Analysis: Feasible via existing platform permission adapter (SRS-108) and the audio engine's split `capture_active` / `transmit_active` states (SRS-201). Verification intent (SWE.6): demonstrate that listen-only is a first-class flow on denial and that no microphone capture is started prior to grant.
+- Unresolved assumptions: None at SRS layer. Upstream SysDes derivation now anchored at SysDes-153 (with SysDes-135 retained as platform-baseline context); reuses the general permission obligation already captured in SRS-027 / SRS-108.
+
 ## 17. Updated SRS to SysDes Coverage Statement
 
 | SysDes Range | SRS Coverage |
@@ -2632,6 +2657,91 @@ This section extends the ASPICE SWE.1 Software Requirements Specification. The s
 | SysDes-142 through SysDes-148 | Covered by `SRS-195` through `SRS-203` |
 | SysDes-149 through SysDes-151 | Covered by `SRS-204` through `SRS-207` |
 
+## 18. Android Audio Backend (P0)
+
+This subsection groups the Android voice-audio-backend software requirements derived to support the platform-adapter decision to host Android voice capture and playback through a dedicated low-latency native audio backend (mirroring the iOS voice-processing precedent already represented in the codebase for the iOS path). These requirements close the historical gap in which the Android voice path was carried by a generic desktop-style default backend and the hardware acoustic-echo / noise-suppression / automatic-gain effects were silently not engaged. They are sourced strictly from SysDes (per the SRS layering policy) and additionally cite the upstream SysRS items they help satisfy.
+
+**SRS-210**: The Chanora Android voice audio path shall achieve a round-trip mouth-to-ear ("glass-to-glass") latency of at most 150 ms on Android devices that support AAudio low-latency performance mode, and at most 250 ms on Android devices that do not support low-latency performance mode. For the purpose of this requirement, an Android device is considered to "support AAudio low-latency performance mode" if and only if (a) the client requested `AAUDIO_PERFORMANCE_MODE_LOW_LATENCY` on both the input and output streams at stream-open time, and (b) the AAudio stream returned by the platform reports `getPerformanceMode() == AAUDIO_PERFORMANCE_MODE_LOW_LATENCY` after the stream is opened. Devices that downgrade the returned performance mode to `NONE` or `POWER_SAVING` fall under the 250 ms bound.
+
+- Status: Baseline Candidate
+- Type: Platform Behavioural Requirement / Performance
+- Stage: P0 / MVP
+- Allocated to: Audio (Android), Platform Adapter (Android)
+- Source SysDes: SysDes-154 (Android voice audio backend subsystem — AAudio low-latency performance-mode path with platform-reported observability, primary), SysDes-135 (Android platform baseline, secondary/context)
+- Verification method: Android Integration Test, Audio Test, Loopback Latency Measurement
+- Acceptance criteria: On at least one reference Android device that returns `AAUDIO_PERFORMANCE_MODE_LOW_LATENCY` for the opened streams, instrumented loopback latency (mouth-to-ear, full duplex through the voice engine) does not exceed 150 ms at the 95th percentile across a 60-second measurement window; on at least one reference device that does not, the same measurement does not exceed 250 ms at the 95th percentile.
+- Analysis: Feasible on API 28+ (per SRS-187 / DEC-004) using AAudio low-latency streams, which is one of the platform-recommended paths called out by SysRS-055. The latency tiering reflects the well-understood split between devices that expose the fast mixer / low-latency capture path and devices that do not. Verification intent (SWE.6): demonstrate that the chosen native-audio backend on Android opens streams in low-latency mode where the device permits it, and that the measured round-trip latency falls under the tier appropriate to the reported `getPerformanceMode()`.
+- Unresolved assumptions: The exact reference-device matrix (which physical handsets define the "supports low-latency" tier vs the fallback tier) should be ratified by the verification owner. The 150 / 250 ms numeric targets are derived from SysRS-055's "production audio integration" intent and are not yet stated numerically at the SysRS layer; if SysRS owners wish to ratify a numeric mouth-to-ear bound, the values here should be considered the SRS-layer derivation and would update accordingly.
+
+**SRS-211**: The Chanora Android voice-capture path shall request the platform "voice communication" input preset where the operating system exposes one, so that the OS-side capture chain (gain shaping, far-end suppression, microphone selection) is the voice-optimised chain rather than the music/media chain. On Android the client shall request `AAUDIO_INPUT_PRESET_VOICE_COMMUNICATION` as the primary preset, and shall fall back to `AAUDIO_INPUT_PRESET_VOICE_PERFORMANCE` if the primary preset is not honoured by the device. This mirrors the precedent on iOS, where the voice-capture path is hosted on the platform voice-processing audio unit (`VoiceProcessingIO`); the Android requirement is the platform-analogous obligation, not a port of iOS code.
+
+- Status: Baseline Candidate
+- Type: Platform Behavioural Requirement
+- Stage: P0 / MVP
+- Allocated to: Audio (Android), Platform Adapter (Android)
+- Source SysDes: SysDes-154 (Android voice audio backend subsystem — voice-communication input preset on the capture stream, primary), SysDes-135 (Android platform baseline, secondary/context)
+- Verification method: Android Integration Test, Audio Test
+- Acceptance criteria: On stream open, the Android voice-capture stream is constructed with input preset = `VOICE_COMMUNICATION`; if the device's AAudio stack reports that the preset was not honoured (or stream open fails specifically due to the preset), the client retries with `VOICE_PERFORMANCE`; the active preset is observable via audio diagnostics. The output-stream usage / content-type obligations are covered separately by SRS-213.
+- Analysis: Feasible on API 28+ AAudio (covered by SRS-187). The iOS analogue (voice-processing audio unit) is already realised in the codebase, so the platform-symmetric obligation is well-founded. Verification intent (SWE.6): demonstrate that the input preset is set at stream-construction time, not after stream start, and that the fallback path is taken only on documented preset-rejection conditions.
+- Unresolved assumptions: None at SRS layer.
+
+**SRS-212**: Where the Android device exposes the hardware voice-audio effect APIs `AcousticEchoCanceler`, `NoiseSuppressor`, and `AutomaticGainControl`, the Chanora Android client shall engage each available effect on the active microphone capture session (via the platform `audioSession`-id attachment API or the AAudio effect-attachment equivalent) at or before the moment voice capture is started. Where one or more of these hardware effects is not available on the device, the client shall fall back to the equivalent software processing already provided by the cross-platform audio engine, and shall not silently leave that processing disabled. This requirement explicitly closes the prior no-op gap in which the Android path acknowledged the request to engage hardware effects but did not in fact engage them.
+
+- Status: Baseline Candidate
+- Type: Platform Behavioural Requirement
+- Stage: P0 / MVP
+- Allocated to: Audio (Android), Platform Adapter (Android), Audio Engine
+- Source SysDes: SysDes-154 (Android voice audio backend subsystem — engagement of platform hardware voice-audio effects with documented software fallback, primary), SysDes-135 (Android platform baseline, secondary/context)
+- Verification method: Android Integration Test, Audio Test
+- Acceptance criteria: For each of `AcousticEchoCanceler`, `NoiseSuppressor`, `AutomaticGainControl`: on devices where `isAvailable()` is true, the effect is constructed against the capture session id, enabled before the first capture callback delivers samples, and reports `getEnabled() == true` for the duration of the capture session; on devices where the effect is not available, the audio engine's software equivalent is engaged for the same duration. The fall-back decision is recorded in sanitised audio diagnostics.
+- Analysis: Feasible via the Android `android.media.audiofx` effect APIs bound to the capture session id surfaced by the native backend. Verification intent (SWE.6): demonstrate via instrumented test that, on at least one device where hardware AEC is reported available, hardware AEC is engaged; and on at least one device where it is not, the software AEC path in the cross-platform engine is engaged. The "silent no-op" prior behaviour is explicitly excluded.
+- Unresolved assumptions: None at SRS layer. SRS-208 (Android in-call audio mode) remains the routing-mode obligation; this requirement is the effects-engagement obligation and is complementary, not duplicative.
+
+**SRS-213**: The Chanora Android voice-output stream shall declare `AAUDIO_USAGE_VOICE_COMMUNICATION` and `AAUDIO_CONTENT_TYPE_SPEECH` at stream construction so that the Android audio policy engine routes the stream under the voice-communication routing rules that engage when `MODE_IN_COMMUNICATION` is active (per SRS-208), including correct Bluetooth SCO routing, earpiece-vs-speaker selection, and ducking behaviour against media.
+
+- Status: Baseline Candidate
+- Type: Platform Behavioural Requirement
+- Stage: P0 / MVP
+- Allocated to: Audio (Android), Platform Adapter (Android)
+- Source SysDes: SysDes-154 (Android voice audio backend subsystem — voice-communication usage and content-type declarations on the output stream, primary), SysDes-152 (Android in-call audio mode subsystem — output usage is the precondition for in-call-mode routing, secondary), SysDes-135 (Android platform baseline, secondary/context)
+- Verification method: Android Integration Test, Audio Test
+- Acceptance criteria: The opened AAudio output stream reports usage = `VOICE_COMMUNICATION` and content type = `SPEECH`; with `MODE_IN_COMMUNICATION` engaged (per SRS-208), playback routes to the in-call output device (earpiece / SCO / wired headset) and does not route to the media output device.
+- Analysis: Feasible on API 28+ AAudio. The combination is the platform-documented way to opt the stream into the voice routing path and is the playback-side counterpart of SRS-211's capture-side preset selection. Verification intent (SWE.6): demonstrate routing differs from a media-usage stream under `MODE_IN_COMMUNICATION`.
+- Unresolved assumptions: None at SRS layer.
+
+**SRS-214**: The Chanora Android voice input and output streams shall request `AAUDIO_SHARING_MODE_EXCLUSIVE` on a best-effort basis at stream construction, and shall gracefully fall back to `AAUDIO_SHARING_MODE_SHARED` when the platform denies exclusive access (for example because another application holds an exclusive stream or because shared media playback is active). The fall-back shall not be reported as a fatal error to the user and shall not prevent voice session establishment; it shall be recorded in sanitised audio diagnostics so that the achieved sharing mode is observable for SRS-210 latency analysis.
+
+- Status: Baseline Candidate
+- Type: Platform Behavioural Requirement
+- Stage: P0 / MVP
+- Allocated to: Audio (Android), Platform Adapter (Android)
+- Source SysDes: SysDes-154 (Android voice audio backend subsystem — best-effort exclusive sharing-mode policy with graceful shared fallback, primary), SysDes-135 (Android platform baseline, secondary/context)
+- Verification method: Android Integration Test, Audio Test
+- Acceptance criteria: On stream open the client requests `EXCLUSIVE`; on devices that grant it, `getSharingMode()` reports `EXCLUSIVE`; on devices or device states that deny it, the client opens with `SHARED` instead and the voice session proceeds; the achieved sharing mode appears in sanitised audio diagnostics for both the input and the output stream.
+- Analysis: Feasible on API 28+ AAudio. Exclusive mode is the documented path to the lowest-latency tier on devices that expose a fast capture/playback path; making the request best-effort avoids regressing the user's ability to join a voice session when another exclusive stream is active. Verification intent (SWE.6): demonstrate both the granted and denied paths and that neither blocks voice session establishment.
+- Unresolved assumptions: None at SRS layer.
+
+**SRS-215**: The Chanora Android client shall maintain active microphone capture while the application is backgrounded by hosting voice transmission inside an Android foreground service whose manifest declares `foregroundServiceType="microphone"`. This formalises at the SRS layer the platform-required hosting model under which background microphone capture is permitted on Android 9+ (API 28+) and is the software-requirement counterpart of the existing foreground-service obligation captured in SRS-111.
+
+- Status: Baseline Candidate
+- Type: Platform Behavioural Requirement
+- Stage: P0 / MVP
+- Allocated to: Platform Adapter (Android), Audio (Android), Android Manifest
+- Source SysDes: SysDes-154 (Android voice audio backend subsystem — lifecycle binding to the Android microphone-typed foreground service for background voice capture, primary), SysDes-135 (Android platform baseline, secondary/context)
+- Verification method: Android Integration Test, Manifest Review
+- Acceptance criteria: With the application backgrounded and a voice session active in transmit-capable state, microphone capture continues to deliver frames to the audio engine; the hosting Android service is observable via `dumpsys activity services` (or equivalent platform diagnostics) as a foreground service of type `microphone`; the manifest declares `foregroundServiceType="microphone"` on the hosting service component.
+- Analysis: Feasible on API 28+ per SRS-187 / DEC-004; the foreground-service-type attribute is the platform's documented mechanism for declaring background microphone use. Verification intent (SWE.6): demonstrate that the foreground service is started before background microphone capture begins, and that capture stops if the foreground service is not granted.
+- Unresolved assumptions: None at SRS layer. SRS-111 remains the higher-level foreground-service obligation; this requirement narrows it to the microphone-typed variant required by the voice transmission path.
+
+## 19. Updated SRS to SysDes Coverage Statement (Android Audio Backend)
+
+| SysDes Range | SRS Coverage |
+|---|---|
+| SysDes-152 (Android in-call audio mode subsystem) | Primary anchor for `SRS-208`; additionally cited as a secondary anchor by `SRS-213` (output-stream usage/content-type is the precondition for in-call-mode routing). |
+| SysDes-153 (Android RECORD_AUDIO runtime permission acquisition flow) | Primary anchor for `SRS-209`. |
+| SysDes-154 (Android voice audio backend subsystem) | Primary anchor for `SRS-210` (AAudio low-latency performance-mode latency tiering), `SRS-211` (voice-communication input preset with `VOICE_PERFORMANCE` fallback), `SRS-212` (hardware AEC/NS/AGC engagement with software fallback), `SRS-213` (voice-communication output usage/content-type), `SRS-214` (best-effort exclusive sharing mode with shared fallback), and `SRS-215` (microphone-typed foreground-service-hosted background capture). |
+| SysDes-135 (Android platform baseline) | Retained as the secondary/context anchor on `SRS-208` through `SRS-215` (the eight Android voice-audio SRS items conceptually rest on the Android platform baseline as their platform context, but no longer take SysDes-135 as the primary derivation). Upstream SysRS items addressed across the eight items are SysRS-055, SysRS-217, SysRS-288, SysRS-305, and SysRS-306. |
+
 
 ## Baseline Candidate 0.9.1 Update
 
@@ -2659,3 +2769,12 @@ This section extends the ASPICE SWE.1 Software Requirements Specification. The s
 | Version | Date | Description |
 |---|---|---|
 | 0.9.5 | 2026-05-15 | Added v1 audio + PTT lifecycle software requirements SRS-204 through SRS-207 sourced from SysDes-149..151: bridge surface drops `start_audio` / `stop_audio` and adds `voice_join(channel_id)` / `voice_leave()`, audio engine opens streams on first voice-channel join and closes on last leave with output independent of mic-permission state, `TransmitMode` enum (`Ptt` default, `Continuous`, reserved `VoiceActivity` per DEC-030) persisted per identity, `release_tail_ms` (default 200, range 0–500) gate on the `true → false` transition of `transmit_active` with re-press cancellation, Voice Bar hard-mute override of `transmit_active`. Strict layered sourcing preserved (`SRS -> SysDes` only). |
+
+
+## Baseline Candidate 0.9.6 Update
+
+| Version | Date | Description |
+|---|---|---|
+| 0.9.8 | 2026-05-18 | Retargeted the `Source SysDes` field on SRS-208, SRS-209, and SRS-210 through SRS-215 from the generic SysDes-135 (Android platform baseline) to the dedicated Android voice-audio derivation items authored by the system-architecture owner: SysDes-152 (Android in-call audio mode subsystem) is now the primary anchor for SRS-208; SysDes-153 (Android RECORD_AUDIO runtime permission acquisition flow as Permission/Voice subsystem partitioning) is now the primary anchor for SRS-209; SysDes-154 (Android voice audio backend subsystem — AAudio low-latency path, voice-communication usage/preset, hardware-effects engagement with software fallback, sharing-mode policy, FGS-hosted background mic lifecycle) is now the primary anchor for SRS-210 (latency), SRS-211 (input preset), SRS-212 (hardware AEC/NS/AGC), SRS-213 (output usage/content-type), SRS-214 (sharing mode), and SRS-215 (microphone-typed foreground service). SRS-213 additionally retains SysDes-152 as a secondary anchor because the output-stream usage is the precondition for in-call-mode routing. SysDes-135 is retained on all eight items as the secondary/context anchor (platform-baseline relationship). Section 19 coverage table updated. Strict layered sourcing preserved (`SRS -> SysDes` only). No technical or behavioural content of SRS-208 through SRS-215 was modified; this is a surgical retargeting of the `Source SysDes` field only. |
+| 0.9.7 | 2026-05-18 | Added Android Audio Backend (P0) section 18 hosting SRS-210 through SRS-215 to support the platform-adapter decision to host Android voice capture/playback on a dedicated low-latency native audio backend (mirroring the iOS voice-processing-audio-unit precedent). SRS-210 sets numeric mouth-to-ear latency targets (≤150 ms on devices that return `AAUDIO_PERFORMANCE_MODE_LOW_LATENCY`, ≤250 ms otherwise). SRS-211 mandates `AAUDIO_INPUT_PRESET_VOICE_COMMUNICATION` with `VOICE_PERFORMANCE` fallback. SRS-212 mandates engagement of hardware `AcousticEchoCanceler` / `NoiseSuppressor` / `AutomaticGainControl` on the capture session id with software-AEC fallback (closes the prior silent no-op). SRS-213 mandates `AAUDIO_USAGE_VOICE_COMMUNICATION` + `AAUDIO_CONTENT_TYPE_SPEECH` on output. SRS-214 mandates best-effort `AAUDIO_SHARING_MODE_EXCLUSIVE` with `SHARED` fallback. SRS-215 mandates microphone-typed foreground-service hosting (`foregroundServiceType="microphone"`) for backgrounded voice transmission. Added section 19 coverage statement. Strict SRS→SysDes sourcing preserved: `Source SysDes` traces via SysDes-135 (Android platform baseline) pending a SysDes revision that introduces a dedicated derivation item for the Android voice audio backend; SysRS-055, SysRS-217, SysRS-288, SysRS-305 are cited as the upstream SysRS obligations addressed. |
+| 0.9.6 | 2026-05-17 | Propagated SysRS reconciliation (Wave 1.5) into SRS for P0 Android. SRS-187 minimum Android API raised from 24 to 28 per DEC-004 (ID preserved, change record added). SRS-188 verified consistent with SysRS-289 (Google Play upload-date target SDK); no rewrite required. SRS-111 (Android foreground service for active voice session), SRS-119 (Android AAB release build), and SRS-163 (Android back-navigation intent) reviewed and left unchanged — text remains unambiguous and P0/P1 scope is intact. Added SRS-208 (Android in-call audio mode engaged on voice-session connect, released on last disconnect — addresses SysRS-305) and SRS-209 (explicit `RECORD_AUDIO` runtime permission acquisition at or before voice-session activation, fail-safe to listen-only on denial — addresses SysRS-306). Strict layered sourcing preserved (`SRS -> SysDes` only); `Source SysDes` for SRS-208/209 traces via SysDes-135 pending a SysDes revision that introduces dedicated derivation items for SysRS-305/306. |

docs/requirements/sysrs.md

@@ -1849,7 +1849,7 @@ This section converts the baseline product decisions into auditable system-level
 - Priority: P0
 - Verification: Release Inspection
 
-**SysRS-288**: The Chanora Android application shall support Android API 24 or later as the minimum runtime baseline unless Flutter, plugin, audio, or platform constraints require raising the minimum version.
+**SysRS-288**: The Chanora Android application shall support Android API 28 (Android 9.0) or later as the minimum runtime baseline, per DEC-004 (Accepted 2026-05-14, which raised the original API 24 recommendation to API 28). The minimum may be raised further only if Flutter, plugin, audio, or platform constraints require it; it shall not be lowered without a superseding accepted decision.
 
 - Priority: P0
 - Verification: Review, Platform Test
@@ -1934,6 +1934,16 @@ This section converts the baseline product decisions into auditable system-level
 - Priority: P0
 - Verification: Functional Test, UX Review
 
+**SysRS-305**: When the Chanora Android application has an active voice session connected, the system shall engage the Android in-call audio mode (for example via `AudioManager.setMode(MODE_IN_COMMUNICATION)` or an equivalent platform routing-assist mechanism) so that microphone gain, output routing, echo handling, and Bluetooth SCO behaviour follow Android's voice-communication path rather than the media path. The in-call mode shall be entered no later than the moment the voice session becomes connected and shall be released when the last active voice session ends. Back-fills the v0.9.8 product-decision-register entry that recorded `AudioManager.setMode(MODE_IN_COMMUNICATION)` engagement via JNI without prior SysRS coverage.
+
+- Priority: P0
+- Verification: Platform Test (Android), Audio Test
+
+**SysRS-306**: The Chanora Android application shall acquire the Android runtime microphone permission (`RECORD_AUDIO`) at or before the point of voice session activation, and shall not begin microphone capture without that permission having been granted by the user. If the permission is denied, revoked, or not yet decided, the application shall remain functional in listen-only mode (consistent with SysRS-303) and shall surface a user-facing path to grant the permission before retrying transmit. This requirement is additive to the general permission obligation in SysRS-055 and makes the runtime-acquisition timing explicit.
+
+- Priority: P0
+- Verification: Platform Test (Android), Functional Test
+
 
 ## 32. Change History Addendum
 
@@ -1960,3 +1970,10 @@ This section converts the baseline product decisions into auditable system-level
 | Version | Date | Description |
 |---|---|---|
 | 0.9.5 | 2026-05-15 | Added v1 audio + PTT lifecycle requirements SysRS-303 and SysRS-304 capturing the no-manual-start audio engine bound to voice-channel membership, the v1 transmit-mode set (`Ptt` default + `Continuous`, with `VoiceActivity` reserved per DEC-030), the listen-only flow (output independent of mic permission), the hard-mute override, and the 200 ms (0–500 ms) PTT release tail for word-boundary anti-clipping. |
+
+
+## Baseline Candidate 0.9.9 Update
+
+| Version | Date | Description |
+|---|---|---|
+| 0.9.9 | 2026-05-17 | Reconciled SysRS-288 with DEC-004 (Accepted 2026-05-14): Android minimum runtime baseline raised from API 24 to API 28 (Android 9.0); rationale and decision citation added in-line. Verified SysRS-055, SysRS-161, SysRS-195, SysRS-217, and SysRS-289 remain consistent with DEC-004 (no API-level text in any of these; no rewrite required). Added SysRS-305 (Android in-call audio mode engagement during active voice session — back-fills the v0.9.8 product-decision-register `AudioManager.setMode(MODE_IN_COMMUNICATION)` entry) and SysRS-306 (explicit Android runtime microphone permission acquisition at or before voice session activation, additive to SysRS-055). |