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
1. Parse the new config and prefer it over the old config specified by
android:fullBackupContent.
2. Add a new parameter to LocalTransportParameters to allow testing this
functionality in CTS.
Bug: 180522596
Test: atest FullBackupRulesHostSideTest
Change-Id: If18edfcdb2b9637d380251f48fdbc56cca6af3ec
The Parcel read/write speed of MergedConfiguration/InsetsSource
becomes 4x+ faster.
Because writeParcelable sends additional type info which is
unnecessary if the type is known on the reading side, replace
the usages to writeTypedObject and well-written readFromParcel.
That saves the time of class lookup and object creation.
Bug: 181025587
Test: vogar --mode app_process --benchmark \
frameworks/base/core/tests/benchmarks/src/android/os/ParcelableBenchmark.java
Change-Id: I29548ce6c2e5886f0e90a5dc70d8e9ecc0fb25a8
- Exposed the following as testAPIs:
* markProfileOwnerOnOrganizationOwnedDevice with
MANAGE_PROFILE_AND_DEVICE_OWNERS permission
* forceSecurityLogs with FORCE_DEVICE_POLICY_MANAGER_LOGS permission
* forceNetworkLogs with FORCE_DEVICE_POLICY_MANAGER_LOGS permission
* setDeviceOwner
* setActiveAdmin
* forceRemoveActiveAdmin with MANAGE_PROFILE_AND_DEVICE_OWNERS permission
* clearSystemUpdatePolicyFreezePeriodRecord with CLEAR_FREEZE_PERIOD
permission
- Changed getDeviceOwnerComponentOnAnyUser to accept
MANAGE_PROFILE_AND_DEVICE_OWNERS permission
Bug: 180500227
Test: verified that cts tests can call the APIs
Change-Id: I824980d1f408f1e0bf536c9526f1666dead31d82
I5431d22bd8faa75e3deab1960a2f721784f98d42 introduced a basic ANR
controller interface to allow services within the system_server
register to delay the ANR dialog during an ANR.
Some limitations of that interface were:
1. No way to cancel the ANR dialog if the normal function of the app
resumed during the delay
2. The AnrController#getAnrDelay method was serving a dual purpose of
returning the delay and showing an interim UI
3. The interim UI might live within an updatable mainline
module, hence forcing the system_server to block (asynchronously) on
the 'getter' for the binder call.
This cl addresses the problems above with the following new
methods on AnrController: onAnrDelayStarted and onAnrDelayCompleted.
These methods provide a clearer interface for the following reasons:
1. onAnrDelayCompleted will return a boolean value to indicate whether
the ANR dialog should still be shown after the delay
2. onAnrDelayStarted is a more explicit API that can be called
asynchronously without blocking to notify external components to show
an interim UI
3. The existing getAnrDelay can be handled completely within the
system_server without blocking on an external binder call
See design (2a) in go/transcoding-anrs for more details
Test: Manual
Bug: 170486601
Change-Id: Idb9190a0e6014ce64bf1412c26f6ae03f97e922d
