Rearrange how we generate the transition specs, which involves
creating a thumbnail on the mainthread (about 10ms on large
devices): First, we put launching the activity onto a handler
thread (with default priority), to free up the main thread. Then,
we immediately start generating the thumbnail such that when the
future calls us we have the generated spec already handy.
For that we need to be able to supply a specs future into
ActivityOptions, to avoid race conditions. Furthermore we need to
make sure not to call into WM while creating specs, to avoid WM
lock contention.
Test: App -> Recents -> Same app, inspect app transition logs
Test: Double tap recents for quick switching
Bug: 32668632
Change-Id: I6001e29145f8e56deb9c4ead46c53c87c9191436
Merged-In: Ic6ec65c2560f67cade3b5ddde9f79ee13e9ba32c
Bug 38277003
The back stack was being moved while executing operations and
then again when the postponed transaction was executed. It should
only be done once.
Test: Ie47e1f2f158325b9cfd6edb5c40c65d764ff9056
Support Lib Change: I3159c2345a7b77fa82f1c602f4639f51b5a47980
Change-Id: I3b7a032e7e8a9aec565157d42dcaa7232b256ae8
When the autofill service returns a null FillResponse, the session is marked
"gone" because the service cannot autofill it. But there might be cases where
the view structure change and it's now autofillable, so need to allow users
to manually request autofill again in such cases.
Fixes: 38205945
Test: CtsAutoFillServiceTestCases pass
Test: LoginActivityTest.testAutofillManuallyAfterServiceReturnedNoDatasets()
Test: LoginActivityTest.testAutofillManuallyAndSaveAfterServiceReturnedNoDatasets()
Change-Id: I9b23c255e563dd0646bf266d31ddb10dcc4f7f6d
- Now keep track of the time a job was enqueued, and order
the pending list by that.
- Added configuration constants for rescheduling: maximum
times to reschedule, minimum backoff times.
- Fixed printing of active jobs -- the method to get the current
JobStatus was old and didn't require the caller to hold a
lock, so made a copy, which didn't contain all the data we were
interested in. Now with our simple locking, we can just make
that require the caller hold a lock and return the real
JobStatus object.
- Include oom_adj and procstate when printing information about
processes being killed.
- Expanded documentation of BroadcastReceiver.goAsync().
Test: bit CtsJobSchedulerTestCases:*
Change-Id: I2e45f181e45be9836c74cbff1b844ffdf6e93019
The return result from starting activity actually represents two
pieces of information. First, it conveys whether the activity
started. Secondly, it conveys whether there was a fatal error if
the activity did not start. Many parts of the code assume that a
value greater than or equal to the defined success means that the
activity successfully started. This is not the case as there are a
number of results greater than success where the activity does not
start.
This change addresses the issue by introducing three distinct
result ranges. The first represents results where the activity
could not start due to a fatal error. The second represents results
where the activity did not start due to a non-fatal error. The last
range represents successful activity starts. Two convenience methods
have been added to ActivityManager to return whether the result
represents a fatal error and whether the result was successful.
Change-Id: Ifaf844c353641a28b03b3c2d7b6be053fd9b8b44
Fixes: 38021882
Test: cts-tradefed run cts-dev --module DevicePolicyManager --test com.android.cts.devicepolicy.DeviceOwnerTest#testLockTask_deviceOwnerUser
Because we were relying on the output to go in the right direction
already, this could be wrong. We're now only following the given
lightness direction if it is even possible to satisfy contrast.
Test: runtest -x core/tests/coretests/src/android/app/NotificationTest.java
Change-Id: I06d934a6b5c328ebbf0cf707030b0d707ccb5ab4
Fixes: 38182819
Previously the colorization wouldn't work if the notification
was not targeting N and above, since for those the
remoteviews would be built into the notification and we couldn't
colorize it.
Test: runtest -x packages/SystemUI/tests/src/com/android/systemui/statusbar/notification/MediaNotificationProcessorTest.java
Fixes: 38147364
Fixes: 37743600
Change-Id: Iabad02a4515c42676c0660293e58cf62d5d8ff88
- for apps that don't target O but use channges
- Rename misc channel if it already exists
- Add method so settings can tell if it needs to show legacy config
Bug: 38120923
Test: runtest systemui-notification
Change-Id: I5c7c077321f1792851b003b9d9e42505dddd50f0
