* Foreground service notifications.
* Colorized notifications (where the snooze button's color would be wrong).
* FullScreenIntent notifications, which are timely.
* HUNs, since the expanded state could have the button.
Bug: 179178086
Test: manual
Change-Id: I3fa46d6493c14ddf7e9b9e28afb7de15b1ddd89a
Delete the overloaded version of setPendingIntentAllowlistDuration() without reasonCode.
Bug: 171305836
Test: atest cts/tests/app/src/android/app/cts/ActivityManagerFgsBgStartTest.java
Reboot device, observe "tempAllowListReason" in logcat.
Change-Id: Ib8bd22eefb5d5f308d2bcca17221499c2a6adc79
This reverts commit e756211374.
Reason for revert: Apparently this is used; b/179601086
NoNonSdkCheck: The original change erroneously removed the method from the block-list; this reinstates the method
Fixes: 179601086
Test: builds
Change-Id: I383bc0a0e2a319b24e11aa7a07a69603efff706f
Add more server flags that can be pushed to devices to influence geo
detection service behavior.
This renames DeviceConfig as ServerFlags and introduces an intermediary,
the ServiceConfigAccessor, to hide details and handle changes to config
values that need the location_time_zone_manager to restart.
Simulating server flag changes example:
adb shell cmd device_config put \
system_time primary_location_time_zone_provider_enabled_override false
Inspecting manager / provider states:
adb shell dump location_time_zone_manager
The following manual tests were conducted to check the plumbing:
Modifying settings behavior:
adb shell cmd device_config put \
system_time location_time_zone_detection_setting_enabled_override true
<Confirm the settings value cannot be changed by user>
adb shell cmd device_config put \
system_time location_time_zone_detection_setting_enabled_override false
<Confirm the settings value can be changed by user>
adb shell cmd device_config delete \
system_time location_time_zone_detection_setting_enabled_override
<Confirm it returns to normal>
Disabling the feature / location_time_zone_manager:
adb shell cmd device_config put \
system_time location_time_zone_detection_feature_supported false
<Confirm SettingsUI (after restart) doesn't show the geo detection option>
<Confirm manager is not started>
Enabling the feature / location_time_zone_manager:
adb shell cmd device_config put \
system_time location_time_zone_detection_feature_supported true
<Confirm manager is restarted>
Note: "cmd device_config" doesn't allow multiple config keys to be
changed at once, and any change to service config keys cause the
location_time_zone_manager to restart. When changing multiple, set
"location_time_zone_detection_feature_supported false" to stop the
manager, and "location_time_zone_detection_feature_supported true" when
all changes are done.
Test: Manual testing (see above)
Test: treehugger
Bug: 178107773
Change-Id: I07b57add1ed47197587907b9f0a85f38acc0a76a
- Introduce new oom_adj score to be used for EJs so that they won't
be killed before normal jobs but before any FGS. Also, add a new
bind flag to instruct the OomAdjuster about when to use this
new oom_adj score.
- Unlike other capabilities, any app (regardless of it's proc_state)
with network capability will be able to transfer it's capability
to other app by binding to it.
Bug: 177641226
Test: atest ./tests/app/src/android/app/cts/ActivityManagerProcessStateTest.java
Test: atest ./tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Test: atest ./services/tests/mockingservicestests/src/com/android/server/am/MockingOomAdjusterTests.java
Test: atest CtsJobSchedulerTestCases
Change-Id: I888764ff22fba92fe2cccf3d8442ed318a19ad2a
It's possible to statically verify that mTarget can never be null, and
that in every instance where an @NonNull annotation has been added here
it was previously impossible for null to be returned at that location.
The only exception is for getCreatorPackage(), where it is more
difficult to verify that it is impossible for this to be null.
Logically, it doesn't make any sense for a PI to not have a creator
package, and I have gone through every call flow for setting the creator
package I could fine to verify it can never be set to null.
Bug: 175221460
Test: manual sanity checks
Change-Id: Ia9e2c3c4ff8c9082190cd50129cedcbcfd219574
This CL was merged earlier (ag/13484966) and then reverted due to the
new behaviour breaking D2D transfers.
Merge it again with all changes being controlled by a flag (default
off), see UserBackupManagerService:getOperationTypeFromTransport in this
CL. View the diff between patchsets 1 and 2 to only see what's changed
between the earlier reverted code and the fixed version of it (i.e. with
the flag).
The flag can be changed via adb for now, we will set it to true by
default once other components are ready.
Bug: 174216309
Test: atest UserBackupManagerServiceTest
Change-Id: I7473c9b4f8d0c4d20155be76930279184ffb17c4
The platform has the concept of a location provider which could
be a plugin implemented by another package. The implementation
of a location provider plugin can make calls to APIs that require
a location permission, e.g. fusing data from different sources.
However, such accesses are counted in app ops as a location access
but the accessor is in this case the data source. It is also
possible that the package that provides the implementation of a
location provider also hosts other funcionality which may need to
call APIs that require a location permission.
This change allows a location provider to specify app op attribution
tags which which could be used when calling location to singal to the
OS that the access is for the location providing functionality of the
location provider. For location accesses of the provider package that
are not related to providing location to the OS the provider can use
any other non delcared as location attribution tags. Accesses with
the location attribution tags would be counted in app ops but instead
of towards the OP_COARSE_LOCATION/OP_FINE_LOCATION the would be
counted towards dedicated OP_COARSE_LOCATION_PROVIDER/
OP_FINE_LOCATION_PROVIDER ops. This would allow proper classification
while enabling auditability and tracking via the standard app op APIs.
<meta-data
android:name="android:location_allow_listed_tags"
android:value="foo;bar;baz"/>
Test: atest android.location.cts.fine.LocationManagerFineTest#testLocationAttributionTagBlaming
Bug:179062648
Change-Id: I36739ab42cedc94e1aa7a3bfd3b9aa213f5b3e97
There are four ways a package can be temp allowlisted:
1. Calling BroadcastOptions#setTemporaryAppWhitelistDuration() to
allowlist a BroadcastReceiver, this is a SystemApi.
2. Calling ActivityManagerService#setPendingIntentWhitelistDuration()
to allowlist a PendingIntent, this is not an API, it is an internal method.
3. Calling PowerWhitelistManager#whitelistAppTemporarily() to allowlist
a package, this is a SystemApi.
4. DeviceIdleController.addPowerSaveTempWhitelistApp(), this is an
internal method.
Also the package can be permanently allowlsited in
ActivityManagerService#mDeviceIdleExceptIdleAllowlist.
Move the BG-FGS-launch reasonCode from ActiveService.java to
PowerWhitelistManager.java. Define a list of temp allowlist reasonCode
in addition to the BG-FGS-launch reasonCode. The reasonCode is passed
around in DeviceIdleController and ActivityManagerService, it will be
used in statsd FGS metric.
At FGS start, check all above allowlists and record the reasonCode/reason/duration in
ServiceRecord#mInfoTempAllowListReason field.
If mInfoTempAllowListReason is not null, log the reasonCode/reason/duration in "Background started FGS" log
message, with key "tempAllowListReason".
Bug: 171305836
Test: atest cts/tests/app/src/android/app/cts/ActivityManagerFgsBgStartTest.java
Reboot device, observe all "tempAllowListReason" listed above in logcat.
BYPASS_INCLUSIVE_LANGUAGE_REASON=existing APIs
Change-Id: Ieb52d95aae3258817a67734c093cb12fc78a81fd
CTS-Coverage-Bug: 181160445
