The VolumeShaper is used to apply a volume
envelope to an AudioTrack or a MediaPlayer.
Test: CTS
Bug: 30920125
Bug: 31015569
Change-Id: If8b4bed29760aa3bd15a4b54cae60e40b4f518ee
An AudioPlaybackConfiguration contains an IPlayer
interface for system control of a player. It is not
exposed to non-system signature components.
AudioService, through PlaybackActivityMonitor, is monitoring
the death of the IPlayer so the matching player can get
unregistered in case it meets its maker.
Test: use vendor/google_toolbox/team/audio/cmds/ClPlaybackActivity
Bug: 30258418
Change-Id: Ibf3bceba91882ff16bffbf1219c55a1f89ccb13f
AudioService keeps track of status of implementations of PlayerBase.
AudioService's PlaybackActivityMonitor maintains a list of
playback configurations for each PlayerBase, and a list
of clients that want to receive updates about the playback.
Playback activity clients can query the playback configuration
of the system through AudioManager, or register a callback
for updates. For clients with MODIFY_AUDIO_ROUTING permission
(system), the playback configurations contain more information
about each player (player type, uid, pid, state), and can see
all players, not just the "active" ones. The act of stripping
off data about the players that is not supposed to be seen
by non-system clients, is referred to as "anonymization". It
is implemented in system server, so no system data is ever
sent to playback activity clients without system permission.
More information about the AudioPlaybackConfiguration is
available in the SystemApi (uid, pid, player type, player state).
Test: run cts -m CtsMediaTestCases -t android.media.cts.AudioPlaybackConfigurationTest
Bug: 30955183
Change-Id: I85997594c0378216419f5f0fdaa0714996fd3573
Deprecate methods where stream types are not used for
volume control operations.
Add a warning in the logs about the use of stream
types to encourage migration to audio attributes.
Since STREAM_ACCESSIBILITY is added in O for the
volume of a11y audio, throw an exception when
trying to use it for playback.
Test: make offline-sdk-docs
Bug: 30955183
Change-Id: I7fcf79f1de68f217a9b19561aa1325ade169dfcf
Modified the signature of the abstract volume methods so
it is clear at the subclass level whether the volume
command is for a mute or a volume control.
Changed the implementations in the subclasses
accordingly.
Removed appOps handling inside SoundPool and made it
inherit from PlayerBase.
Moved handling of the camera sound restriction from
SoundPool to PlayerBase.
Added support in SoundPool native implementation for
muting, as each player has its own volume.
Test: play a long file with SoundPool and enter DnD mode
Bug: 30955183
Bug: 28249605
Change-Id: I0fcd7480f9a455c06aa4f7092486f5c65bc9d7db
Order the playback restriction checks from the most likely
restriction to the least likely.
Bug 30073948
Change-Id: I6431d15a2ed8b5831f937eab8db940d942082b0e
Make sure that camera shutter sound is played in
total silence DND mode when enforced by country
regulation.
Bug: 29973005
Change-Id: I208f7ae5b07777eac48597f68feae6358999b2c3
Actually, this implementation is more what we want for ephemeral
apps. I am realizing the two are not really the same thing. :(
For this implementation, we now keep track of how long a uid has
been in the background, and after a certain amount of time
(currently 1 minute) we mark it as "idle". Any packages associated
with that uid are then no longer allowed to run in the background.
This means, until the app next goes in the foreground:
- No manifest broadcast receivers in the app will execute.
- No services can be started (binding services is still okay,
as this is outside dependencies on the app that should still
be represented).
- All alarms for the app are cancelled and no more can be set.
- All jobs for the app are cancelled and no more can be scheduled.
- All syncs for the app are cancelled and no more can be requested.
Change-Id: If53714ca4beed35faf2e89f916ce9eaaabd9290d
Fix performance regression in SoundPool by not checking SoundPool
can play audio everytime it's about to play.
Instead check for permission in constructor and register a listener
for changes on OP_PLAY_AUDIO.
Bug 20018833
Change-Id: I4e7a633d23b98653a149681d18a387cd560efe4d
Playback restrictions can be lifted with the correct flag,
FLAG_BYPASS_INTERRUPTION_POLICY, but this flag is for the
system only. As such, it must be read by querying "all
the flags" with AudioAttributes.getAllFlags() which is a
system API which returns all the system flags. getFlags()
only returns the public SDK flags.
Bug 19407114
Change-Id: I22dadfaf5d1b48b3c0754e1e6af00b734d790fec
Running in a configuration without audio service is not fully tested.
Remove the configuration option for now. Also remove unused delegation
layer in SoundPool.
Bug: 19891112
Change-Id: I47be0e32d54b8ef8fa25cf47b85eacf8a4969500
- New @hidden @SystemApi FLAG_BYPASS_INTERRUPTION_POLICY, request
to ignore any current audio restrictions, such as zen mode
content-based notification filtering.
- Wire up FLAG_BYPASS_INTERRUPTION_POLICY to the existing
audio restriction checks in the framework.
- New @hidden @SystemApi FLAG_BYPASS_MUTE, request to play
audibly, even if the underlying stream is muted.
- Wiring up to audio framework TBD.
- Use both of these new flags on the inline volume slider
controls used in Settings, ensuring playback is heard
regardless of the current device filter state.
Bug: 19407114
Change-Id: I3d44394931592ccbc1b61ddd9a4d1cc984da17cc
Complete javadoc for android.media.SoundPool.Builder to document
what the default values are.
Bug 17059255
Change-Id: I966e9ed00ed75a78c9b4741b7f68bae996442cdf
Add support for building a SoundPool instance and specify
the AudioAttributes.
Remove SRC quality which was never implemented, while leaving
room for supporting it later through the Builder pattern.
Remove stream types.
Update AudioService's use of SoundPool to the new scheme.
Change-Id: Ie51e4008684e5ba25f9b7368098e4f20266a15c7
- Add new audio restriction layer to app-ops. Restrictions add
additional constraints to audio operations at a stream-level.
Restrictions do not affect the persistable state, and are purely
additive: that is, they can only impose additional contstraints, not
enable something that has already been disabled. Restrictions
also support a whitelisted set of exempt package names.
- Add new audio stream-level checks to app-ops.
- Implement a provisional OP_PLAY_AUDIO suppression to three
java entry points MediaPlayer, AudioTrack, & SoundPool.
- Enhance vibrator api to take stream information as an optional
hint - the constants correspond to AudioManager stream types.
OP_VIBRATE now supports the stream-level restriction check.
- Simplify Vibrator subclasses by adding default implementations
for two .vibrate calls.
- Migrate NoMan's zen-mode control to use the new app-ops
stream-level restriction mechanism.
Change-Id: Ifae8952647202f728cf1c73e881452660c704678
For storing pointers, long is used in media classes,
as native pointers can be 64-bit.
In addition, some minor changes have been done
to conform with standard JNI practice (e.g. use
of jint instead of int in JNI function prototypes)
Change-Id: Idc4ca0124d03df7f9cef412488abafd020e5e774
Signed-off-by: Ashok Bhat <ashok.bhat@arm.com>
Signed-off-by: Marcus Oakland <marcus.oakland@arm.com>
Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
SystemServer is currently a monolithic class that brings up key system
services. This change is the first phase of refactoring it to be more
configurable. Specifically, it adds a set of on/off switches used to control
startup of individual services. Future plans include finer grained controls
and a more explicit and consistent startup sequence for these services.
Change-Id: I7299f5ce7d7b74a34eb56dffb788366fbc058532
Add combined channel APIs setVolume to AudioTrack, MediaPlayer, and
SoundPool to make later migration easier, and encourage apps to use
that API. The new APIs are @hide for now.
Change-Id: I0c87bfdbff4f4292259fa33e65f67badbafd270b
The problem can occur if a sample is started at the same time as the last AudioTrack callback
for a playing sample is called. At this time, allocateChannel() can be called concurrently with moveToFront()
which can cause an entry in mChannels being used by moveToFront() to be erased temporarily by allocateChannel().
The fix consists in making sure that the SoundPool mutex is held whenever play(), stop() or done() are called.
In addition, other potential weaknesses have been removed by making sure that the channel mutex is held while
starting, stopping and processing the AudioTrack call back.
To that purpose, a mechanism similar to the channel restart method is implemented to avoid stopping channels
from the AudioTrack call back but do it from the restart thread instead.
The sound effects SounPool management in AudioService has also been improved to make sure that the samples have
been loaded when a playback request is received and also to immediately release the SoundPool when the effects are
unloaded without waiting for the GC to occur.
The SoundPool.java class was modified to allow the use of a looper attached to the thread in which the sample
loaded listener is running and not to the thread in which the SoundPool is created.
The maximum number of samples that can be loaded in a SoundPool lifetime as been increased from 255 to 65535.
Change-Id: I368a3bdfda4239f807f857c3e97b70f6b31b0af3
