Test: manual verification on Caviar (automated test will be added later)
Test: CtsAutoFillServiceTestCases pass
Bug: 38341498
Fixes: 38323841
Change-Id: I15cc792de87987cc19a229c2ab2dfc317877f7ec
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
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: Ic6ec65c2560f67cade3b5ddde9f79ee13e9ba32c
Bug: 34600579
Test: manual - change device lock under synthetic password, verify
old data on disk is erased.
Change-Id: I247bd1f095dd27335e671981f9e2d77e149af84f
Merged-In: I247bd1f095dd27335e671981f9e2d77e149af84f
Bug: 34600579
Test: manual - change device lock under synthetic password, verify
old data on disk is erased.
Change-Id: I247bd1f095dd27335e671981f9e2d77e149af84f
Running cancel after toast is shown and adding some UI stress (or sleep
on UI thread) causes a crash from toast when trying to add the toast
window to the display. The toast must be triggered from app that is
above N MR1 (25).
The steps that crash the app are:
1. Show toast (Toast.makeText(...).show()), window token is created
2. Immediately cancel toast (Toast.cancel()), window token is removed
3. Stall UI thread (Thread.sleep, heavy task), both show and cancel
events are queued to UI thread from window manager
4. Crash trying to add toast but no window token exists
In Toast:handleShow(), the mNextView is required to add the toast to
display, if the mNextView is null before posting to window manager, then
when handleShow() runs later, it will ignore adding the toast to
display. The issue before is that mNextView is set to null after cancel
runs back from window manager in UI thread but the show post will always
happen first. Therefore set mNextView to null at the beginning of
cancel will ignore adding the toast to display and avoid the crash.
Bug: 37606432
Test: manual - write an app to Toast.show(), Toast.cancel(), then
Thread.sleep(), set app's sdk usage above 25 (N MR1) and show the
toast
Change-Id: I352e296c47b1b8776c78b6b0943b1dc809963026
Documentation pointing to the registerNetwork() overload including a
timeout argument was pointing to the version removed by commit
15fd4395e1. This makes it impossible to
cherry pick 15fd4395e1 due to the linter
complaining about unresolvable links.
This patch fixes the documentation to point to the registerNetwork()
with argument types NetworkRequest, NetworkCallback, int, in that order.
Bug: 36370941
Test: no functional change
Change-Id: Ieaf58f81d89fdf63f480fd15e65ed52822fc4f51
