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
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
When callers are inserting or updating raw "_data" paths, we need to
sanity check them to make sure they're not "crossing the streams"
between storage devices. For example, it would be really broken to
insert a file on the SD card into the "internal" storage volume.
This also enforces that callers don't "cross the streams" between
multiple storage volumes on devices that support them, since
otherwise they'd end up with very confusing behavior, such as
the same underlying file being inserted into multiple databases.
Also, the "internal" storage volume should really only be used for
common media (such as ringtones), and it shouldn't be allowed to
point into private app data directories, since MODE_WORLD_READABLE
has been deprecated for many years now.
Bug: 117932814
Test: atest MediaProviderTests
Test: atest cts/tests/tests/media/src/android/media/cts/MediaScanner*
Test: atest cts/tests/tests/provider/src/android/provider/cts/MediaStore*
Change-Id: I267eacd45bbd270b8ce9b28de9d6e209f780f31a
If a non-persistent service is being restarted and it was killed due to
low memory previously, instead of restarting the service in one second,
we now restart it based on its last known oom_adj value. The backoff
logic of consistent restarts remains the same.
Additionally, when the service is due to restart, if the memory pressure
is still considered to be critical, the new logic will further delay the
service restart.
Initial test results: # of restarts dropped by 40-50% on average with
the optimized logic when the memory pressure was gradually increased.
Tested manually via memeater. Increased the memory pressure by 500 mb
at a time via the following command: adb shell memeater 500
On a 4gb device, no significant restarts were noticed when memory
pressure was increased by 2gb in total. When increased by 3gb in total,
services started to restart and the above results were observed via
the logged output over a 5 min period.
Bug: 79848281
Test: manually (steps listed above)
Change-Id: Idcd1300882321c6033e569736150a8bf7889678b
The notification_assistant package will contain flags controling the
default Android Platform implementation of the Notification Assistant
(named ExtServices).
The flags will be read in
android.ext.services.notification.AssistantSettings.
Bug: 120792826
Test: build
Change-Id: Ib57ca8bb707e1582f315390d5d2eb833033b7d25
- Add nullability annotations for some methods
- Update the java doc of isRootsUri to make it more clear
Change-Id: I8b065d526e11fe8d71bb1aec223918e7559967e0
Fix: 122549058
Test: make
