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
Bug: 74061412
Bug: 73893665
Test: Manual, I5669a97c70d726826c5c00bc1413c2f97d95d88c
ImageDecoder typically does not scale a Bitmap up to handle density.
This saves memory, and we already handle the density by scaling at
draw time. But some apps rely on the size of the Bitmap without taking
density into account. For backwards compatibility, on apps that are
built for a pre-P version of Android, scale up in ImageDecoder.
Change-Id: I9991d1286e386b47fc57bcfbf0c6652beb1a53ef
A double stop request is possible when display is being locked.
An activity may receive a "sleep" message followed by "stop",
both of which try to move it to stopped state.
An example when this happens: a keyguard is set up and the screen
is being locked. The keyguard will occlude the activity, which
causes a transition to paused state and, eventually, to stopped
state. A "sleep" message can be sent sometime before "stop" message
and will ignore that activity is in the process of becoming stopped.
Change-Id: I09e2c26004664b6e73ac5c2b6fe88bdf8271cf34
Fixes: 74967786
Test: FrameworksCoreTests:ActivityThreadTest
This change takes care of the flow from WindowManagerService to
PinnedStackController, all the way to PipTouchHandler. It also
introduces a WindowManager hook that allows Launcher to pass in
shelf visibility and height. A separate change is made to send
signals from Launcher to SysUI. (ag/3724896)
Bug: 73961893
Change-Id: I2ff54e78bc2dc35c806b902464048b051a4d6394
Test: atest CtsActivityManagerDeviceTestCases:ActivityManagerPinnedStackTests
Adds some annotations, deletes an unused API method, and adds some
comments.
Test: Flashed onto marlin-eng and verified there are no crashes.
Bug: 72562867
Change-Id: I6c93ee4aeeacf6842795256c76551cfb1c28888d
The transition delay will be the latency until all the leashes
were created etc. Thus, the actual latency is going to be in
WINDOWS_DRAWN_DELAY.
Also fix an issue where we inadvertently started a transition,
and then the transition logger was hanging.
Bug: 72967764
Test: Swipe up from home button, observe eventlog
Change-Id: I2b1fb7d9d694a629a33653c1fa3d5ed47f53de6b
it's a no-op (and silent fail) when called from a non-system user.
DevicePolicyManagerService#setStorageEncryption also has its Javadoc
fixed.
Bug: 74591983
Change-Id: Ie191ad255cbfcade921d172641f134d6c49a17b1
Fixes: 74591983
Test: N/A - just javadoc changed
Change the Slog.d to Slog.w and enable them, so that we can see them.
They seem to represent important failure events when people call the
public API into StatsManager.
Bug: 74997752
Test: none
Change-Id: I1c577b32358158f73453a8a3066013e0f3733d87
