Skip to content

v0.2.0 — Audio session management

Choose a tag to compare

View all tags
@SteliyanH SteliyanH released this 27 Aug 11:35
· 23 commits to main since this release
v0.2.0
7c009ca
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Closes a defect that was live in every consumer of the kadr family.

The bug

Nothing in the family touched AVAudioSession — not kadr, not kadr-ui, not the reference app. So a host got whatever session it happened to be in, which for a fresh app is .soloAmbient.

That category obeys the ring/silent switch. A user mutes their phone, opens a video editor, and the preview is silent with nothing on screen explaining why. Video playback is expected to ignore that switch, which is why every video app you have used does.

Two more consequences of having no session at all: an interruption stopped playback and nothing resumed it, and starting a preview stopped the user's music without anyone deciding it should.

try AudioSession.configure(.preview)   // audible with the phone muted
try AudioSession.activate()            // when the preview appears
try AudioSession.deactivate()          // lets their music resume

Design

AudioSessionPolicy is a separate type from AudioSession — the policy carries the decisions, the session applies them. That split is the only reason this has coverage: AVAudioSession cannot be exercised off a device, and CI runs on macOS where the framework does not exist.

Configuration and activation are separate calls. Activation takes audio focus, so a host that activates at launch silences the user's music for as long as the app is open.

deactivate notifies others by default, so a paused music app resumes.

interruptions carries the system's shouldResume flag rather than swallowing it — ignoring it is how an app talks over a phone call.

8 → 16 tests.

Assets 2
Loading