* 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
