Test: Looked at settings on fresh device. Saw update. Looked at upgraded
device and saw change from 300 -> 1000
Fixes: 78112231
Change-Id: Iecb5b1250fa8613201ef8a85f8221aa8608785dc
Increase the DND version and reset the setting so those who
are upgrading P->P see the new flow.
Test: manual
Change-Id: I9286f022d1fa6520305ff03dbce54c4eec0e371a
Fixes: 77658931
Actually skip the backup data for the unsupported key.
Bug: 77867300
Test: manual (adb shell bmgr restore com.android.providers.settings from
a backup set created by sdk 101)
Change-Id: I3d6a97ecbc0b048a3d07329542771f434e7e154d
We no longer want to backup and restore screen brightness as it could
leave the new device in an unusable state and doesn't make sense
cross-device.
Test: 1) atest SettingsBackupTest
2) atest SettingsValidatorsTest
3) Manual:
- Old backup set that has screen brightness does not restore with change
- Screen brightness does not backup or restore with change
Bug: 77583401
Merged-In: I8a6d950717e6aeb9bf6773c14708ee70069f9df0
Change-Id: I8a6d950717e6aeb9bf6773c14708ee70069f9df0
(cherry picked from commit 931b41b71a)
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
I'll do SystemSettingsProto in a separate CL.
Bug: 76011704
Bug: 74975371
Test: flash device and check incident.proto output
and m EMMA_INSTRUMENT_STATIC=true EMMA_INSTRUMENT=true out/target/common/obj/APPS/CtsStatsdApp_intermediates/jacoco/work/instrumented/updated.stamp
and atest CtsIncidentHostTestCases:com.android.server.cts.SettingsIncidentTest
Change-Id: I47d4843ff21bbdde0cdc0a1f5754c22c4e642aa7
This is a large CL, so I'll do the other two protos in separate CLs.
Bug: 76011704
Bug: 74975371
Test: flash device and check incident.proto output
Change-Id: I285e6495b122c36eded9f6fc3afa39c92c293ed5
also: m EMMA_INSTRUMENT_STATIC=true EMMA_INSTRUMENT=true out/target/common/obj/APPS/CtsStatsdApp_intermediates/jacoco/work/instrumented/updated.stamp
also: atest CtsIncidentHostTestCases:com.android.server.cts.SettingsIncidentTest
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
The old location_mode API hardcoded gps and network location provider when it enables/disables location, without checking whether the providers exist on device.
It causes bugs when used together with the new
LocationManager.setLocationEnabled() APIs.
This fix modified LocationManager.setLocationEnabled() API when user
tries to disable location on device. Besides turning off the providers
from LocationManager.getAllProviders(), it also turns off GPS and
network provider explicitly.
To reduce times of binding to the service and chance of race condition, we also
modified SettingsProvider.updateLocationProvidersAllowedLocked() to
accept a string param with multiple location providers to be
enabled or disalbed at the same time.
Bug: 73261572
Test: Manual on chromebook
Change-Id: I2e59e0d4cf395b98cd481af5d7f3c762274d7826
It is not clear when the day should start. Further a day might have
25 hours in the case of daylight savings time.
Hence a day in this case is the last 24 hours, not a calendar day.
Keeping track of the time of each operation might waste memory as we
don't need that much precision.
Hence keep track how many operations were performed in the last 24
hours in buckets of hours. If the total count reaches a maximum suppress
any further operations.
The maximum is configurable via global settings. It can be updated
by apps that have the appropriate permissions. Hence if the default
value turns out to be incorrect, it can be adjusted after release.
This does not throttle based on battery state as it is better to
completely unload the sound model to not even have a detection event.
Test: atest SoundTriggerDetectionServiceTests (separate CL)
atest android.provider.SettingsBackupTest
Bug: 73829108
Change-Id: Ied8570b60b61b6a055bd2576d1502c1b36424efa
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
Work notifications settings should only allows the user to cause
notifications to be redacted, not hidden alltogehter. If some user
had it hidden, change it to redacted on upgrade.
Bug: 64829587
Test: manual
Change-Id: Iff88638b2536481fb7ff66ac8a29512c95fbada6
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
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
For dual SIM devices, add provision to configure different default
Network modes for each slot, using the existing system property to
configure this default network modes.
Bug: 28384694
Test: manual - Checked different default NW mode can be set
for each slot.
Merged-Id: I72b11522cb51a425e28ddc407014387a20cb2cd7
Change-Id: I72b11522cb51a425e28ddc407014387a20cb2cd7
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
