logan
867ced8c81
On Android the hardware keys are the volume control and the framework mixes our stream against the device level, so a second control inside the app moves something the user already moved. Where that is true the player's level sits at maximum, SetVolume / ChangeVolume / MuteToggle are refused, and nothing persists a level nobody chose: restore remembers the stored value instead of applying it, and saveState writes that same value back rather than recording the synthetic maximum. Mute is in that list because it is a level of zero by another name -- and because with no control rendered it would be the one state on such a platform the user could not get out of. The predicate is named after the capability rather than the platform, because that is what makes it testable. Only platformOwnsVolume is behind a build tag, in two files that declare nothing else; everything else is decided against Player.systemVolume, a field a test sets either way. That is mediacontrols' split, with androidpayload.go's reasoning for keeping the contract out of a tagged file, and the tagged pair is covered by a source sweep since no tier here compiles both halves. SetDuck is deliberately untouched: it applies its attenuation by re-applying the *user's* level through setVolumeLocked, so pinning that level to maximum leaves the offset arithmetic exactly as it was. It is the only thing that may still move the output on such a platform, and TestSystemVolumeStillDucks is that property rather than a comment.
12 lines
354 B
Go
12 lines
354 B
Go
//go:build android
|
|
|
|
package player
|
|
|
|
// platformOwnsVolume is true on Android: volume is the device's, set
|
|
// with the hardware keys, and `mediacontrols`' Android handler
|
|
// implements no volume callback for the same reason.
|
|
//
|
|
// See systemvolume.go for why this constant is the whole of what a
|
|
// build tag decides here.
|
|
const platformOwnsVolume = true
|