In some cases (deferred restore) the app data needs to be cleared even
if the app has implemented backup agent. As a quick fix introduce
PACKAGES_TO_CLEAR_DATA_BEFORE_FULL_RESTORE secure setting, which
transport can fill prior to restore.
Bug: 69069240
Test: adb shell settings put secure packages_to_clear_data_before_full_restore com.google.android.apps.nexuslauncher && adb shell bmgr restore com.google.android.apps.nexuslauncher
Change-Id: I2a4651365d9cf4747f32d2ba69312f54cd03d118
Test: Manual test with: settings put global low_power_mode_suggestion_params start_nth=2,end_nth=3
Bug: 74120126
Change-Id: If165892477b41547a3880e2e961a38328b33c5bd
Spec: go/ebs-low-battery-mode-flow
- Basically when the user manually enables battery saver 4 times,
we show this notification to suggest turning on "scheduled"
(i.e. auto) battery saver.
- We show it through 8th time. If the user hits "no thanks",
or if auto-saver is enabled already, we will not show it.
- Introduced a new notification channel "HINTS" with
IMPORTANCE_DEFAULT.
Bug: 74120126
Test: Manual test with ll development/scripts/battery_simulator.py
Change-Id: I713abc59dc7caee6882ba848c3e3aabaf778c2bd
The content resolver can throw in some instances when using the blocked
number provider. Rather than crashing all of telecom, adding exception
handling to provide graceful fallback in these cases.
Test: Compile / build
Bug: 74965829
Merged-In: Iae4c2dfc912e0d2a4194deb62568ee2f78ce4e22
Change-Id: Iae4c2dfc912e0d2a4194deb62568ee2f78ce4e22
(cherry picked from commit b408ebe557)
- When battery saver is enabled manually (i.e. via PM.setPowerSaveMode()),
it'll stick, and we'll re-enable battery saver even after a reboot
or a charge.
- Extracted all battery saver state transition logic into a separate
class.
Fix: 75033216
Bug: 74120126
Test: Manual test with "dumpsys battery set ...."
Test: atest $ANDROID_BUILD_TOP/frameworks/base/services/tests/servicestests/src/com/android/server/power/batterysaver/BatterySaverStateMachineTest.java
Change-Id: If020cd48f341b339783fe09dd35bc7199e737a52
Test: dumpsys power
Test: incident_report power
Test: atest CtsBatterySavingTestCases
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
The time only mode flag has not been used yet, so the change should
be low impact.
Bug: 38259902
Test: m -j32
Change-Id: Ie01870633dbaaf51989a148f105a995f58f0da4e
Part of push to make backup and restore agent timeouts configurable. Creates
a Global setting for the current static BackupManagerService timeouts so
that they can be overriden with P/H. We keep the current default values,
which will be updated once we investigate what more appropriate values are.
Remame the constants to better reflect what they're used
for. Next, we will update the framework to use these constants.
This depends on the refactor of how we observe changes to key value
backup settings (ag/3709997).
Bug: 70276070
Test: m -j RunFrameworksServicesRoboTests ROBOTEST_FILTER=BackupAgentTimeoutParametersTest
Change-Id: Id506314ce0c8bd5e4d1d8b4001b26cbad0056c99
This will help us run P/H experiments by controlling the
whether traced runs through P/H.
This will allow to gradually roll out traced and, in an
emergency, remotely disable it.
Run:
$ adb shell 'ps -A | grep traced'
Should see traced.
$ adb shell 'settings put global sys_traced 0'
$ adb shell 'ps -A | grep traced'
Should no longer see traced.
Test: See above.
Bug: b/71737179
Bug: b/74383547
Change-Id: I1f564421d9abae14d7d80769e9517eb363dae33a
Merged-In: I1f564421d9abae14d7d80769e9517eb363dae33a
This also fixes dumping of settings that use a prefix.
Since the proto isn't being used yet, I thought it would be nice to
clean it up so we start using it with a clean format.
Bug: 74611860
Test: flash device and check incident output.
Change-Id: Ib99ccab7929208cf8b4404715b0bd417852314c6
The current comment is a little confusing, and this ends up in the
public documentation here:
https://developer.android.com/reference/android/provider/Settings.System.html#HAPTIC_FEEDBACK_ENABLED
See b/22390263 entry for a link to at least one instance where an actual
developer was confused by this.
This CL changes the comment to match what we call the setting in the UI
of the Settings app. Note that it's possible this could become stale
someday (e.g. we used to label this "Vibrate on touch" and switched to
"Vibrate on tap" at some point), but this description will probably
still be ok and remain an improvement over what we have now.
Bug: 22390263
Test: N/A (comment only change)
Change-Id: I717a7c5a2f9ecc38cfe6f0c1c0379a868f810782
