This adds a field Settings.Global.BATTERY_CHARGING_STATE_UPDATE_DELAY
that overrides the value of battery_charged_delay_ms in
Settings.GLOBAL.BATTERY_STATS_CONSTANTS.
This new field can then be set for experimentation, and easily reset to
default by deleting, or setting it to a negative value.
Expose a method in BatteryManager to set a value for this new setting.
Bug: 111360323
Test: adb shell settings put global battery_charging_state_update_delay 999
adb shell dumpsys batterystats --settings # should see battery_charged_delay_ms=999
adb shell settings put global battery_charging_state_update_delay -1
adb shell dumpsys batterystats --settings # should see battery_charged_delay_ms=90000
Change-Id: Ic308af938836a1f9c235cec341808b6c6c28d22d
NFC Panel is the third Settings Panel, which hosts NFC related settings.
Currently the panel only holds the NFC slice, but is open to future
additions.
Test: atest SettingsPanelTest
Bug: 120142616
Change-Id: Ib9e36b6c645ecb8788c558f505197723836f4616
Best-practices mean that we should start using this path for remote
configuration, instead of Settings.Global values.
Bug: 112545973
Test: manual
Change-Id: Ic6f1e9eca28690a212baeb52bd119717c3f495a4
In order to reduce the startup impact to near zero, we are
creating a whitelist to be checked before parsing rules.
The whitelist will be generated by the APK based on apps
mentioned in the rules files. At app launch, only those in
the whitelist will do full rules checking.
The whitelist will be checked via Global Settings, which will
be populated by the ANGLE APK when intents are received. The
APK will listen for intents at boot (LOCKED_BOOT_COMPLETED)
and when ANGLE itself is updated (MY_PACKAGE_REPLACED).
The whitelist can also be populated by hand:
adb shell settings put global angle_whitelist app1,app2,appN
We plan to further mitigate the ANGLE-enabled app impact
by parsing the full rules when creating the whitelist, off of
the critical path.
Note: Developer Options will continue to work, regardless of
whitelist. But temp rules will not be loaded if the app is
not whitelisted.
Test: atest CtsAngleIntegrationHostTestCases
Test: atest google/perf/app-startup/hermetic-apps/cold-dropcache-test -v
Bug: 80239516
Bug: 122528316
Change-Id: I96e5b4d5b4774f59aadbd1e52295437a395cab6b
To support app compaction P/H experiments, migrate it's
settings away from using the key/value pair string the
rest of ActivityManagerConstants uses, and use the
DeviceConfig APIs instead.
Test: boots, works, atest FrameworksServicesTests:AppCompactorTest
Bug: 122879579
Change-Id: I9d1ae17d9671d0443b728ecdeca7102ba34d9c2f
According to new requirements in b/121179845, we are changing the
API pattern from "add/remove" to "set(set<string>)" to support
"enable all packages" operation. Setting the whitelist to null
will enable all packages. This behavior is consistent with existing
methods in DevicePolicyManager, e.g. setPermittedInputMethods.
Also corrected some languages in the comments and annotations.
Bug: 121179845
Test: atest ManagedProfileTest#testCrossProfileCalendar
atest DevicePolicyManagerTest
Change-Id: I87f17a2094792e44fdeb672658bddb871c2c1eeb
Use a whitelist to control which packages may use location piercing
settings on LocationRequest.
Test: Manually
Bug: 118883513
Change-Id: I16e8496c49b6bef016cb7f090969ed97a39e38c2
When user selects a eSIM subscription, Settings app informs Telephony.
Telephony needs to take actions such as writting it into global
settings, switch profiles and notify registrants, for example
AlternativeNetworkAccessService.
Bug: 120945564
Test: unittest
Change-Id: I846d9444aac368d183e06744c9eb8aa0c08dfe6a
Instead of keeping reading the whitelist everytime, we want to store it in
Settings.Global variable and reuse it later.
BUG: 120869311
Test: Build, flash and boot.
Change-Id: I5e39757383c5ba7d31af7efb3e6e8a2996e669f4
This introduces a setting that turns off sticky Battery Saver above a
certain threshold and disables Battery Saver if it was enabled due to
the sticky setting.
Bug: 112232746
Test: atest com.android.server.power.batterysaver.BatterySaverStateMachineTest
Test: atest android.provider.SettingsBackupTest
Change-Id: Ib9a9fd627a56529404b41fbabedf8bb4a372074e
- Register a role observer in VoiceInteractionManagerService. Once the
role is changes map the new role setting onto the old settings.
- As the assistant role is now always set, there is no need to have code
in AssistUtil for the case the assistant setting is not set
- Remove old config option for the default assistant. The default
assistant is not configured via the roles config
Bug: 110557011
Test: - Set, unset and swtiched assistant via the settings UI
- for voice interaction service
- for assist activity
- Booted from freshly wiped device and saw assitant to be set to
default
Change-Id: I8596f49c6f6496e8b70cf3236aaa7d7557443a93
Vendors can still set the default behavior by pm.dexopt.priv-app-oob*
system properties, but still the experiment flag can override the
behavior.
This change also removes the audit log because the setting provider is
not ready. The old code works because we use the default system property
(which may be inconsistent to settings).
Test: cmd package compile -m speed -f com.google.android.dialer
am start com.google.android.dialer
cat /proc/`pidof com.google.android.dialer`/maps |grep oat |grep /data
# Compiled code IS mapped as executable
Test: device_config put fsi_boot oob_enabled true
pkill com.google.android.dialer; am start ...
# Compiled code is NOT mapped as executable
Test: device_config put fsi_boot oob_enabled false
# Compiled code IS mapped as executable
Test: device_config put fsi_boot oob_enabled true
device_config put fsi_boot oob_whitelist com.android.vending,com.example
# Compiled code is NOT mapped as executable
Test: device_config put fsi_boot oob_enabled true
device_config put fsi_boot oob_whitelist com.android.vending,com.google.android.dialer
# Compiled code IS mapped as executable
Test: device_config reset untrusted_clear
# Compiled code IS mapped as executable
Test: atest DexManagerTests
Bug: 120793002
Change-Id: I67f29ac593bd2c33dc8c75ce2135cf9ec5490650
Instead of generating only a handful of thumbnail "kinds", none of
which scale with display density, shift to generating only a single
thumbnail whose dimensions are limited to half the smallest screen
width of the device.
This change also shifts to storing thumbnails on the relevant volume
where the source data actually came from. This solves the problem
of having to GC thumbnails for a storage device that we haven't seen
in a long time.
Bug: 119887587
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I2ce6c5051b7058d2f1bba523c077e84a1f0b46e9
This reverts commit 16522412eb.
Reason for revert: solution needs some adjustments - will update with a better solution.
Change-Id: I74ed92225017a8c1ac23176ed176663acfef7578
