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
ActivityView content should never be letter- or pillar-boxed
and it doesn't have overscan areas, so we can skip setting
display override info for a virtual display that backs it.
Bug: 72220802
Test: Manually resize with ActivityView demo app
Change-Id: I211449eaea50ec5d3214d63e7eb93a1d2ed2c0fd
Specify how to compare with bucket constants since new
bucket constants could be introduced later.
Fixes: 73790511
Test: builds
Change-Id: Ib99ec5fe208bc612869df8bfc69a26ee6be31fa5
