Require the caller of DPM.getPermittedInputMethodsForCurrentUser() to
hold the MANAGE_USERS permission. The only callers should be settings
apps which already hold this permission.
Bug: 62343414
Test: Manage IME list in the Settings app
Test: com.google.android.gts.devicepolicy.DeviceOwnerTest#testPermitInputMethods
Change-Id: I0d162f8f51d16e403a950ee5d942502c2cf20181
Require the caller of DPM.isDeviceProvisioned() to hold the MANAGE_USERS
permission. The only callers should be within the framework itself, or
apps involved in device provisioning which already hold this permission.
Bug: 62343414
Test: Set TestDPC as Device Owner and use it to reset password
Test: com.android.server.devicepolicy.DevicePolicyManagerTest
Test: com.android.server.locksettings.LockSettingsServiceTests
Test: com.google.android.gts.devicepolicy.DevicePolicyManagerTest
Change-Id: Ie53deb5ba8679a5b431f2a8da60ec9710c44d56f
As per discussion with Amit, it's better to define "conflict"
of ApnSetting in DevicePolicyManager API javadoc.
Bug: 72153573
Test: not required.
Change-Id: I765dace36a3c9c491c988dc0a87479cdec620e37
To know that onPostCreate callback should be executed we should use
TransactionExecutor for the entire transaction. It will fill
PendingActions object during the launch and the callback will be
triggered after onStart.
This CL changes local activity relaunch to use Lifecycler
infrastructure. We should immediately execute local recreate
requests, because if we wait until the scheduled message to be
handled, we may already be in a different state and final state
request in the scheduled relaunch transaction will already be
obsolete.
Bug: 72029061
Bug: 64610483
Bug: 76088057
Bug: 73747058
Test: ActivityLifecycleTests
Change-Id: Ia53ecd199c83d030932c4493064e58568805f2a5
TimeSparseArray - used to store UsageEvents - can keep at most one event
per millisecond, which can result in an event being replaced by another
event that occurred close enough that the system records it at the same
millisecond.
Test: atest android.app.usage.TimeSparseArrayTest
Fixes: 73832306
Change-Id: I860a101ab098f65d5c5832758832f43572865690
- Allow slice providers to override grant flow
- Remove overriding caller, that was a terrible idea
- Move where the same app check happens to allow for CTS
Test: CTS
Bug: 69168488
Change-Id: I61c81c0665a08420b7bc83e3660657b62b2cd6a8
Require the caller of DPM.getUserProvisioningState() to hold the
MANAGE_USERS permission. All callers should be apps involved in device
provisioning, which already hold this permission.
Bug: 62343414
Test: Run Device Owner sync auth provisioning manually
Test: Set up work profile with managed account manually
Test: com.android.server.devicepolicy.DevicePolicyManagerTest
Test:
com.android.managedprovisioning.finalization.UserProvisioningStateHelperTest
Test: com.google.android.setupwizard.tests.activity.QrScanControllerTest
Change-Id: Ib85433586d4dfb89019ca223fb925aca3d4bbf67
This patch addresses a request from the API Council (http://b/74409378).
It defines a new RemoteInput.Source annotation for RemoteInput source
constants.
Bug: 74409378
Test: atest RemoteInputTest
Change-Id: I78a006b6a600ea0c0603b2591d1a29596074a44e
Also, added test api AM.alwaysShowUnsupportedCompileSdkWarning
that allows for forec showing the warning for an activity
component running in a test harness.
Change-Id: I72f6a8425cb6adc6060c70b2165aa82b459769f7
Fixes: 75455658
Test: atest CtsActivityManagerDeviceTestCases:PrereleaseSdkTest
This counts the number of times the app was launched from outside
the app and ignores intra-app activity transitions.
Introduce a new permission for registering to observe app usage.
Fixes a bug where Settings couldn't force the app into another
bucket if it was recently launched.
Bug: 74335821
Fixes: 76100712
Test: Manual test using Settings
Test: UsageStatsTest to verify permission change
Change-Id: Ibd343c1cfa37089a3ac6fc30ba3194e21a9be499
Changed the existing hidden api setPackagesSuspendedAsUser to a system
api setPackagesSuspended that can be called by apps with either
MANAGE_USERS or SUSPEND_APPS permission. Additionally, the suspending
app can now specify optional extra information meant to be used by the
suspended apps and the launcher to deal with this state.
The following other APIs are added:
- isPackageSuspended(): Apps can query whether they are in a suspended
state
- @SystemApi getPackageSuspendedAppExtras(String): Apps with permission
SUSPEND_APPS can get the appExtras passed to PM when suspending the
app.
- @SystemApi setPackageSuspendedAppExtras(String, PersistableBundle):
Apps with permission SUSPEND_APPS can update app extras for a
suspended package.
- getPackageSuspendedAppExtras(): Apps can call to get the appExtras
passed in to PM when they were suspended.
Test: Can be run via:
atest com.android.server.pm.PackageManagerSettingsTests
atest com.android.server.pm.PackageUserStateTest
atest com.android.server.pm.SuspendPackagesTest
Bug: 74336673
Change-Id: I3b9ed2c8478b34ee2e8986f5f5fddb2839d102e3
The new notifications now have different font weights
and colors to make the shade more readable.
Fixes: 69168591
Test: runtest systemui
Change-Id: I0b635724fa122d292841e56efa84aa57fa364300
Add a new AppOp to allow bound system services
such as TelephonyDataServices and potentially
VPN providers to access the IPsec tunnel
management APIs. Since this is not directly
user-facing, and not all System apps should have
this privilege, the access is only granted via
an AppOp or to the system itself.
Bug: 66955045
Test: compilation (still WIP)
Change-Id: I0b0528c75c622d8538baeec019c3672cbed5d899
* changes:
Added new appear and disappear animations for heads up
Polished the heads up experience
Removed the heads up scrim and replaced it with more elevation
Insetting heads up notifications
Ensured that the heads-up notifications are always rounded
Heads up notifications are now corretly respecting insets.
instead of overlapping with any possible notches, we're
insetting heads up notifications and splitting the main
content from the header.
Fixes: 72748440
Test: runtest systemui
Change-Id: Ie53ea31fef4e468239c4346f9d1f192bcb26e11d
To know that onPostCreate callback should be executed we should use
TransactionExecutor for the entire transaction. It will fill
PendingActions object during the launch and the callback will be
triggered after onStart.
This CL changes local activity relaunch to use Lifecycler
infrastructure.
Bug: 72029061
Bug: 64610483
Fixes: 73747058
Test: ActivityLifecycleTests
Change-Id: I7d3fa6339fa6fe2634d0d1635f76e4d6ba03beb2
The service is meant to replace the PendingIntent based API. Once all
users of the PendingIntent based API switched the PendingIntent based API
will be removed.
To have as little as possible impact on the whole SoundTrigger framework
the RemoteSoundTriggerDetectionService class implements the same
interface as the PendingIntent based class. Hence the exising code has
very little change. Further once the old code can be removed the amount
of changed (and added) code is limited.
The RemoteSoundTriggerDetectionService -> SoundTriggerDetectionService
is a vanilla as possible service implementation. The special behaviors
are:
- The system holds a wakelock while service operations are in progress
and the service is bound as foreground. Hence the service can e.g.
listen to the microphone.
- Service operations have a certain amount of time they are allowed to
run. Once every operation is either finished or the the operation
exceeded the allotted time, the system calls onStopOperation for each
still pending operation. This is a similar model as for the commonly
used JobService.
Please note that if the time allowed for an operation is 15s and
op1 was run as 0si, and op1 was run at 5s, the service is allowed to run
until 20s. Hence _both_ onStopOperations will happen at 20s. This is
done for ease of implementation but should not give the service more
power than calling onStopOperation exactly 15s after each operation is
triggered.
- If an operation is done before the allotted time is reached, the
service can declare the operation as finished manually by calling
onOperationFinished. This is a call back into the system, hence a
'client' binder is sent to the service. If the operation is finished
by calling this method onStopOperation will not be called.
- As the service instance might be killed and restored between
operations we add a opaque bundle 'params' to each operations. The users
of the API can use this to send data from the start command to the
operations. It can also just be set to null. The params are not meant to
store changing state in between operations. Such state needs to be
persisted using the regular methods (e.g. write it to disk)
- A service can be used for multiple recognition sessions. Each
recognition is uniquelity defined by its sound model UUID. Hence each
operation gets at least tree arguments: Operation ID, sound mode UUID, params
- As a small optimization the params are cached inside of the service
instance.
The time allowed for each operation is in a @SystemAPI global setting,
so the service can make sure it finishes the operations before they are
stopped. It might take some time to deliver the operations via the
binder, hence it is not recommended to try to use every last ms of
allotted time.
Test: atest SoundTriggerDetectionServiceTest (added in separate CL)
atest android.provider.SettingsBackupTest
Change-Id: I47f813b7a5138a6f24732197813a605d29f85a93
Fixes: 73829108
