The current model for setting up a functionfs
function is:
UsbDeviceManager#setCurrentFunctions() ->
intent is sent to MtpReceiver to write the descriptors ->
init/hal waits for descriptors to write, then pulls up gadget ->
Gadget is configured, a USB_STATE intent starts MtpServer
The main downside of this is a lack of reliability because
the Mtp process could be killed at any point. Normally, a
gadget is unbound if its control endpoint is closed. no_disconnect
works around this, but is still a little janky. In addition, the
extra intent delays the startup of the gadget.
With the new model, UsbDeviceManager writes the descriptors
on initialization. Since it is a system service, it won't be killed.
UsbDeviceManager#setCurrentFunctions() ->
init/hal pulls up gadget ->
Gadget is configured, a USB_STATE intent starts MtpServer
MtpServer calls UsbManager#getControlFd to get a dup of the control
endpoint.
Also modify permissions so system server can access mtp files.
Bug: 72877174
Test: Change usb configurations to ptp/mtp
Change-Id: Id17d2b5930f4e1f37ec1b4f00add9d594174ad49
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
- renaming of MediaFormat keys related to grid config
- add methods to MediaMetadataRetriever to get image/frame
with default bitmap config
- fix java doc
bug: 74831433
Change-Id: Iec607e615d34bea0620070592e4adcfc04cbccae
When get caps is called on an MediaCodec object, try to
use the codec info for that MediaCodec first as it should
be available during codec construction. Only when that
somehow failed go and initialize the full MediaCodecList,
as building the entire list could be very slow.
And when cloning the CodecCapabilities from MediaCodecInfo,
copy the fields directly and the fields (other than the ones
modifiable by client) are immutable after construction.
bug: 74073607
Test:
CTS media post submit:
cts-tradefed run cts-dev --module CtsMediaTestCases --compatibility:module-arg CtsMediaTestCases:include-annotation:android.platform.test.annotations.RequiresDevice
Change-Id: I4ae5f2431da8528e1eca093c5cfb98abcb4a5bbf
(cherry picked from commit 90d7304a83)
This implements following APIs from both session and controller.
- skipToPlaylistItem()
- skipToNextItem()
- skipToPreviousItem()
Bug: 74175632
Test: Run CTS with MediaComponents/runcts.sh
Change-Id: I47d94346c997314ff39797bac3034aa507058036
This CL refactors methods in MediaSession2Stub that handles incoming
binder calls from the controller by adding methods to do followings
in one place.
1. Check if the session hasn't closed.
2. Check if the controller is allowed for the command
3. Call SessionCallback#onCommandRequest() for APIs that would be
sent directly to the MediaPlayerBase or MediaPlaylistAgent if
allowed.
This CL also adds missing command code for setRating().
Bug: 74581821
Test: Run CTS tests with MediaComponents/runcts.sh
Change-Id: I9b96e26b7644cff3c54269773590c73ff30f956c
