Changes:
* Use TRIGGER_LOST_MODE permission to gate the
DevicePolicyManager API sendLostModeLocationUpdate
Bug: 223148704
Test: atest android.devicepolicy.cts.LostModeLocationTest
Change-Id: If15388a377c75b7581c9c2a35b3d9828f78e13fc
Merged-In: If15388a377c75b7581c9c2a35b3d9828f78e13fc
The notifyTaskSnapshotChanged may not be always called after
Binder.clearCallingIdentity. And because there was commit
67b0902 that avoids keeping unnecessary buffer in remote
processes, it may mis-close the buffer in system server if
the calling pid isn't cleared on binder thread.
e.g. there are several suspects from ActivityTaskManagerInternal
Though it might be the responsibility of the caller to clear
binder identity before calling internal interfaces.
Instead of adding clearCallingIdentity every where:
1. Explicitly set the listener as local to skip closing the buffer
so it is independent of which thread is calling.
2. Protect the persister when using the buffer.
Bug: 192143094
Bug: 220659717
Bug: 223950159
Bug: 225794452
Test: atest TaskSnapshotPersisterLoaderTest
Change-Id: I94e8e706e56a73fffe8189023bcef5efd797a24c
Update the javadoc for Instrumentation#setInTouchMode indicating that
starting from Android Tiramisu, this method will only take effect if the
instrumentation was sourced from SHELL or ROOT owned processes.
Test: m
Fixes: 222652344
Change-Id: I8af79acb11f17233f395412670c9f171aec80c59
Analysis:
1.Doing updateOomAdjInnerLSP in backgroud, and it would last for a long
time
2.Now start a new Activity, windowManager save the latest topUid into PendingStartActivityUids
3.updateOomAdj task in step.1 done, and then delete all uids in PendingStartActivityUids
4.The topApp will be rejected by AppOps due to the deleting in step.3
Signed-off-by: huang chaopeng <huangchaopeng@oppo.corp-partner.google.com>
Change-Id: I52c7c2a8d6cb86b27b1f008cb56f670ce7698dc9
When we know that an app moved to a procstate that is considered
an interaction event, the app will not be in idle state. So, avoid
calling into UsageStatsService for idle state in this case.
Bug: 209338078
Test: atest tests/cts/hostside/src/com/android/cts/net/HostsideRestrictBackgroundNetworkTests.java
Change-Id: I5648db595d2fd10a151da13e472fd905bcafe182
The call is protected by the signature permission
START_ACTIVITY_AS_CALLER. This will remove the need for additional data
to be passed from system server.
Bug: 222082547
Bug: 226354782
Test: atest ActivityTaskManagerServiceTests, atest ChooserActivityTest,
manual testing
Change-Id: I94f34a68e390569ec14dfebb1902a7c30558864f
In remote bugreport collection, Shell sends REMOTE_BUGREPORT_DISPATCH to
DevicePolicyManagerService which in turn notifies Device Owners that a
bug report is ready for collection. There existed a threat where a
malicous user could spoof the REMOTE_BUGREPORT_DISPATCH broadcast via
ADB to send a crafted bugreport to the Device Owner. Securing
REMOTE_BUGREPORT_DISPATCH is not as easy as it appears: putting a
permission on REMOTE_BUGREPORT_DISPATCH does not work since both the
legitimate sender and the malicious user are UID_SHELL. Instead, we
introduces a nonce which was sent from DPMS to Shell when bugreport is
triggered, and DPM will only accept REMOTE_BUGREPORT_DISPATCH when
a matching nonce is seen.
Ignore-AOSP-First: security fix
Bug: 171495100
Test: atest DeviceOwnerTest#testRemoteBugreportWithTwoUsers
Test: atest DeviceOwnerTest#testAdminActionBookkeeping
Test: atest BugreportManagerTest
Change-Id: I7649b4f22b74647d152d76bb46d5ca70bfa3617d
1. Add additional trigger onUserMayRequestUnlock
- point existing trigger points from SystemUI to this
2. Argument added to onUserRequestedUnlock to indicate if user wants to
dismiss keyguard.
3. Callback for result of grantTrust calls.
- curently only calls back if device was unlocked as a result of the
call
See design: go/au-noise-reduction
Note: changes made to SystemUI are manually tested and may need
refactoring which is being skipped now to meet the API Freeze deadline.
Bug: 225231929
Test: atest TrustTests
Test: Manual interaction with wake & fingerprint sensor
CTS-Coverage-Bug: 213944235
Change-Id: I8d08229f09c9a1f2295b7eb464d12cad0c6b8303
* changes:
RESTRICT AUTOMERGE Refactor device policy resource APIs to a separate class
RESTRICT AUTOMERGE move device policy resource APIs to a separate class
RESTRICT AUTOMERGE hide device policy resources constants
Right now there is 10 seconds grace period from Context.startForegroudService() to Service.startForeground() call, afterwards
we crash the app and thow ForegroundServiceDidNotStartInTimeException, at the same time generate ANR report.
Make the startForegroundService() to startForeground() grace period
configurable, increase the default value from 10 seconds to 30 seconds.
This value can be changed by command "adb shell device_config put activity_manager
service_start_foreground_timeout_ms 30000"
After the 30 seconds service_start_foreground_timeout_ms and ForegroundServiceDidNotStartInTimeException, delay the ANR generation for another 10
seconds configurable by service_start_foreground_anr_delay_ms.
This value can be changed by "adb shell device_config put activity_manager service_start_foreground_anr_delay_ms 10000".
At the end of service_start_foreground_anr_delay_ms, if the app's
process is still alive, the ANR report will be taken. Otherwise, there
is no ANR report.
Bug: 219514357
Test: adb shell device_config put activity_manager service_start_foreground_timeout_ms,
adb shell device_config put activity_manager service_start_foreground_anr_delay_ms,
Manual test, in test app, startForegroundService() but not call startForeground(), 30 seconds later, observe the ForegroundServiceDidNotStartInTimeException, 10 seconds later, try to take the ANR report.
Change-Id: I5f30d0996bff23f8a302cedef01eaa31e6ff29ce
Undo after dragging a predicted app icon onto the "Do Not Suggest" drop
target.
Bug: b/200841778
Test: Verified that the constant was usable from Launcher project.
Change-Id: I0f7e4f139a7b9012fd55bf72294dd8c1fab38a39
That way the logic to get a managed profile can be
customizable by OEMs.
Fixes: 214473624
Test: manual
Test: CTS tests to be added in a follow-up CL
Change-Id: Id183e987d2cb04040db028b9913188267d1a9a84
The following restrictions applies to the instrumentation of the sdk
sandbox processes:
* Instrumentation must be signed with the same certificate as the client
app the instrumented sdk sandbox belongs to.
* If there is a running instance of to-be-instrumented sdk sandbox
process, then it will be killed before the instrumentation starts.
* While instrumentation is running the client app won't be allowed to
connect to the instrumented sdk sandbox process.
* The --no-restart instrumentation of the sdk sandbox processes is not
supported.
Bug: 209061624
Test: atest SdkSandboxInprocessTests
Change-Id: Ia4b145c091bf8da600a77ea82fc9e3cd97757275
