When an app takes a long time to handle broadcasts, we start deferring
further broadcasts to it to make sure that other broadcast traffic in
the system can continue to make progress. Global delivery order is
technically rearranged, but delivery order from the point of view of any
given app remains consistent with issuance order.
When alarm broadcasts are issued, we prioritize delivery of deferred
alarms to the alarm recipients (i.e. we suspend the deferral policy and
catch up as promptly as possible) in order to minimize wake time spent
waiting for the alarm broadcast to be delivered. Once an app with a
deferred broadcast backlog is no longer the target of an in-flight
alarm, we re-impose deferral policy on it.
This policy intentionally trades off increased broadcast delivery
latency to apps that take a "long" time to handle broadcasts, in
exchange for lowering delivery latency to all other apps in the system
that would previously have had to wait behind the slow app.
In addition, broadcast dispatch policy parameters can now be overlaid
via the usual global Settings mechanism. In particular, configuring the
"bcast_slow_time" parameter to a value in milliseconds higher than the
queue's broadcast timeout period will disable the new slow-receiver
policies.
Bug: 111404343
Test: device boots & runs
Test: tests/ActivityTests
Change-Id: I76ac79bdf41ca3cfcc48515bca779ea0f5744c0b
Required for feature tuning and experiments
Also
- Updates Javadoc as per API review request
- Updates TextClassificationConstants test
Bug: 120794314
Bug: 118296637
Bug: 34780395
Test: atest core/tests/coretests/src/android/view/textclassifier/TextClassificationConstantsTest.java
Test: (MANUAL)
1. Install an app that handles Intent.ACTION_TRANSLATE
2. Run adb shell settings put global text_classifier_constants system_textclassifier_enabled=false,lang_id_threshold_override=0
3. Select foreign text
4. Observe that a "Translate" option is shown in the selection toolbar
1. Install an app that handles Intent.ACTION_TRANSLATE
2. Run adb shell settings put global text_classifier_constants system_textclassifier_enabled=false,lang_id_threshold_override=2
3. Select foreign text
4. Observe that a "Translate" option is not shown in the selection toolbar
Change-Id: I02b6ca48669e66a24150b04bba2ebfcf9ebe6bfd
With this CL, SHOW_IME_WITH_HARD_KEYBOARD will be shared within the
same profile group.
Since AccessibilityManagerService always reads
SHOW_IME_WITH_HARD_KEYBOARD from the profile parent user [1], in
practice sharing SHOW_IME_WITH_HARD_KEYBOARD within the same profile
group would be the easiest and safest way for now to avoid breaking
SHOW_IME_WITH_HARD_KEYBOARD.
Note that with my previous CL [2], InputMethodSettings already adjust
the target user ID by checking CLONE_TO_MANAGED_PROFILE when writing
secure settings. Hence no change in the InputMethodManagerService
side is necessary.
When work profile is not enabled, there should be no behavior change.
[1]: I530481e102ac376a4506b662862ee1ee74815b40
03a65b04d8
[2]: Ieefefb8630ddef3b247ebb865a604e5c72dfb49c
15be5e6f1c
Fix: 123379418
Test: manually verified as follows.
1. Build aosp_taimen-userdebug and flash it.
2. adb root
3. adb shell setprop persist.debug.per_profile_ime 1
4. Install Test DPC.
5. Enable managed profile with Test DPC.
6. Attach a Bluetooth hardware keyboard.
7. make -j EditTextVariations
8. adb install -r \
$ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/EditTextVariations.apk
9. adb shell am start --user 10 -n \
com.android.inputmethod.tools.edittextvariations/.EditTextVariations
10. Focus in the top edit field on the EditTextVariations.
11. Tap the IME switcher icon on the navigation bar.
12. adb shell settings get secure --user 0 show_ime_with_hard_keyboard
-> 0
13. adb shell settings get secure --user 10 show_ime_with_hard_keyboard
-> 0
14. Toggle "Show virtual keyboard" button to enable it.
15. adb shell settings get secure --user 0 show_ime_with_hard_keyboard
-> 1
16. adb shell settings get secure --user 10 show_ime_with_hard_keyboard
-> 1
Change-Id: Iacb79b24d6bd97495ac81a58c1df651cf594a8c2
To help confirm that we're actually testing developer-visible
behaviors, we need to build against public APIs, since there have
been plenty of examples in this suite of "testing" hidden API
behaviors, which are then misleading to developers.
Bug: 120429729
Test: atest cts/tests/tests/provider/
Exempt-From-Owner-Approval: Trivial API annotations
Change-Id: I07fe33e54f611a6060217f0706fb99b809961f4d
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
