* Add AudioSystem.FOR_VIBRATE_RINGING mode to match the native layer
AUDIO_POLICY_FORCE_FOR_VIBRATE_RINGING force mode
* Switch to this mode when Bluetooth SCO is connected
* Modify AudioService.muteRingerModeStreams() method to not mute ringer
volume when Bluetooth SCO is ON. Also, when ringer is unmuted, mirror
speaker ringtone volume on Bluetooth SCO ringer
Bug: 72647074
Test: Call phone in vibration mode and hear ringtone on HFP enabled
headset, verify that ringtone is only played through headset.
Then disconnect headset and call again to verify that ringtone
does not play through phone speaker in vibration mode.
Change-Id: I7d642020710c085f0e1f27c750c74b0e2fb57398
Adds additional documentation that clarifies how to set up CryptoInfo
objects for CENC 2016 decryption schemes, in particular for the case of
HLS SAMPLE-AES Audio.
Bug: 62503021
Test: make docs
Change-Id: Ia21ef62a4144e7b41b0216ba0b968ff6c52d0297
It only runs when the screen is on.
Test: manual, invoking gesture with different system settings
Bug: 75252670
Change-Id: I934d0bbb0a9fffecf34ebaadf77f3e1241d4faf7
The service is meant to replace the PendingIntent based API. Once all
users of the PendingIntent based API switched the PendingIntent based API
will be removed.
To have as little as possible impact on the whole SoundTrigger framework
the RemoteSoundTriggerDetectionService class implements the same
interface as the PendingIntent based class. Hence the exising code has
very little change. Further once the old code can be removed the amount
of changed (and added) code is limited.
The RemoteSoundTriggerDetectionService -> SoundTriggerDetectionService
is a vanilla as possible service implementation. The special behaviors
are:
- The system holds a wakelock while service operations are in progress
and the service is bound as foreground. Hence the service can e.g.
listen to the microphone.
- Service operations have a certain amount of time they are allowed to
run. Once every operation is either finished or the the operation
exceeded the allotted time, the system calls onStopOperation for each
still pending operation. This is a similar model as for the commonly
used JobService.
Please note that if the time allowed for an operation is 15s and
op1 was run as 0si, and op1 was run at 5s, the service is allowed to run
until 20s. Hence _both_ onStopOperations will happen at 20s. This is
done for ease of implementation but should not give the service more
power than calling onStopOperation exactly 15s after each operation is
triggered.
- If an operation is done before the allotted time is reached, the
service can declare the operation as finished manually by calling
onOperationFinished. This is a call back into the system, hence a
'client' binder is sent to the service. If the operation is finished
by calling this method onStopOperation will not be called.
- As the service instance might be killed and restored between
operations we add a opaque bundle 'params' to each operations. The users
of the API can use this to send data from the start command to the
operations. It can also just be set to null. The params are not meant to
store changing state in between operations. Such state needs to be
persisted using the regular methods (e.g. write it to disk)
- A service can be used for multiple recognition sessions. Each
recognition is uniquelity defined by its sound model UUID. Hence each
operation gets at least tree arguments: Operation ID, sound mode UUID, params
- As a small optimization the params are cached inside of the service
instance.
The time allowed for each operation is in a @SystemAPI global setting,
so the service can make sure it finishes the operations before they are
stopped. It might take some time to deliver the operations via the
binder, hence it is not recommended to try to use every last ms of
allotted time.
Test: atest SoundTriggerDetectionServiceTest (added in separate CL)
atest android.provider.SettingsBackupTest
Change-Id: I47f813b7a5138a6f24732197813a605d29f85a93
Fixes: 73829108
Check MODIFY_PHONE_STATE permission on
AudioManager.forceVolumeControlStream
Test: manual: verify UI can still select between two stream volumes
Change-Id: I50da25d50829193c9f9d7761bb6e58d1aa5cf3f4
"ImageReader" and "ImageWriter" must pass information about the
specific buffer transformation.
Currently only the "ImageReader" implementation of the
"android.media.Image" abstract classs will populate the
corresponding transformation, the remaining implementations will
use the default identity tranformation.
Bug: 75316204
Test: Manual using test application,
Camera CTS
Change-Id: If5c12134fbbef8cc20c3d369986ba613bc4f2cec
