Volume control

Fission

Product

▾

Setup

›

›

Volume control crosses into host policy. Some platforms let apps adjust system streams; others only let an app control its own media element or expose hardware buttons outside app control.

This reference is for the exact API shape. If you are wiring the feature into an app for the first time, start with the Volume control guide, then return here when you need operation names, request types, provider contracts, or platform configuration details.

Public API

Item	Value
Effect helper or entrypoint	ctx.effects.volume()
Provider trait or host contract	VolumeHost
Test provider or test entrypoint	MemoryVolumeHost
Primary request types	VolumeStream / VolumeSetRequest / VolumeAdjustRequest
Primary success types	VolumeLevel
Error type	VolumeError
CLI value	volume-control

Operations

Method or operation	Purpose	Request	Success
get_level	Read one host volume stream.	VolumeStream	VolumeLevel
set_level	Set a stream level and optional mute state.	VolumeSetRequest	VolumeLevel
adjust_level	Increase or decrease a stream relative to its current level.	VolumeAdjustRequest	VolumeLevel

Provider contract

Register a VolumeHost with .with_volume_host(...). Use MemoryVolumeHost in tests. Providers should clamp or reject invalid levels and return unsupported where the target cannot expose system volume.

Providers should return typed errors for unsupported operations, denied permissions, unavailable hardware, cancellation, timeouts, and platform policy restrictions. Silent success is not acceptable because reducers need a truthful result to update state and explain what happened.

Platform configuration

The CLI adds Android MODIFY_AUDIO_SETTINGS. iOS does not expose broad app-controlled system volume. Desktop providers can map to mixer APIs when appropriate, but packaged apps may have store policy constraints.

When a CLI value exists, fission add-capability <value> --project-dir . records the capability in fission.toml and updates generated target files where Fission can do that deterministically. Android generated configuration lives in platforms/android/AndroidManifest.xml. iOS generated configuration lives in platforms/ios/Info.plist and platforms/ios/Entitlements.plist when entitlements are required. Desktop package metadata is reviewed during packaging because Windows, macOS, and Linux use different permission and distribution systems.

Runtime behavior

Capability calls are queued from reducers through ctx.effects. The active shell resolves the request with the registered provider and then dispatches the configured success or error action. Missing providers should produce typed unsupported errors. Packaging mistakes usually show up as denied permissions, missing entitlements, missing route registration, or provider-specific failures.

•

Volume control guide

•

Capability matrix

•

Platform capabilities reference