It only runs when the screen is on.
Test: manual, invoking gesture with different system settings
Bug: 75252670
Change-Id: I934d0bbb0a9fffecf34ebaadf77f3e1241d4faf7
The syntax of that setting changed from P Developer Preview1 to the final P, so
it's safer to use a new name than risk breaking devices during the update.
Bug: 74458004
Test: atest CtsAutoFillServiceTestCases:VirtualContainerActivityCompatModeTest\
FrameworksCoreTests:SettingsBackupTest
Change-Id: I1c507e8eae20f598dfe259178667ae6c2bc892ff
- Show the battery saver confirmation dialog only for the first time.
- Start counting # of manual activations, which will be used in a
follow-up CL.
Bug: 74120126
Test: Manual tests with ./vendor/google_experimental/users/omakoto/android-battery-tester
Test: m -j ROBOTEST_FILTER=BatterySaverUtilsTest RunSettingsLibRoboTests
Test: cd frameworks/base/packages/SystemUI/tests && \
atest src/com/android/systemui/power/PowerUITest.java src/com/android/systemui/power/PowerNotificationWarningsTest.java
Change-Id: If6a081a6222e6a87c4cd332364c89856e7648a36
For experimentally varying parameters of the framework's various wifi
scoring methods.
Bug: 65216267
Test: atest SettingsBackupTest
Change-Id: I6b1476aff8c18e4dd2b5ae8d41b5a48d2b4de283
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
This enables us to mess with the different scan intervals and shift
clients to a different scan mode in the background based on what scan
interval values we choose for the different power modes.
Bug: 71765044
Test: None. Just adding a key.
Change-Id: Id48ebc521dd3fe8a68c9c4c0bdb1018ea5b3743e
Previously, we wrote a log entry regardless of permission checks, so
the logging could be misleading. Now we only send the log to statsd
after verifying that this setting mutation is valid.
Test: Flashed onto marlin-eng and verified stats-log as expected.
Bug: 73493944
Change-Id: I2a8b052aa8c380ffc5d15caec089fffcdc5823f4
This reverts commit 6750352248.
Reason for revert: Added SElinux policy to allow the service to be started. Verified by local testing on the latest pi-wear-dev.
Bug: 74018496
Bug: 75974893
Change-Id: I9bd8939f6292be9c160e19ebdf934023792059ba
This feature is only available for certain carriers at the current time.
To facilitate test team productivity, adding a system setting which can
be accessed from the Telecom debug menu to enable this functionality.
Test: Manual
Bug: 28189985
Change-Id: I4c812cecd2832a722e5dc73b7c719a9e0594064d
