Creating the surface for every change (such as creation and
visibility) can lead to issues swapping buffers. This
changelist limits the action to only when the size changes.
Change-Id: Ic549d244613a93a43a9f4ddf284bbfb0c13300fa
Fixes: 62801621
Test: follow repro steps in bug, verified no crash.
Test: go/wm-smoke
Causes too many GCs and related slowdowns.
Verified that assistant launch from holding down home button is now
faster than N.
Test: make and flash
Bug: 62769566
Change-Id: Ib0c1f7a45831b241d3376d1e56db3c6937913b1b
Fixes: 62678460
Test: Tap recents while the dialog is shown and ensure it's not in a
separate task
Change-Id: I0572ddc84d76643ac8a373939273c221ff20676f
onCreate might be called with a state not produced by
onSaveInstanceState. In this case the last autofill ID is not set, so we
incorrectly restore it to NO_ID instead of LAST_APP_AUTOFILL_ID
Change-Id: Id40c06bf223c0e3c6235b2d50779e3f4532898b5
Fixes: 62296699
Test: cts-tradefed run cts-dev -m CtsAutoFillServiceTestCases
(cherry picked from commit 1266d08be5)
Override dispatchTouchEvent for the root FrameLayout
of NavigationBar to process ACTION_OUTSIDE MotionEvents
and dispatch directly to DeadZone to keep track of the
most recent outside tap.
Clarified documentation of ACTION_OUTSIDE behaviour.
Bug: 37552674
Test: open IME, tap any key, then quickly tap on top half
of the home button. The home button tap is ignored
and device does not go to homescreen.
Change-Id: Icb5cf6c76959f3514b8b94c09e38cc5434f31b23
updateAutofillValue() was crashing some apps when the mText was not set at the
time it was called. One solution would be to not set mText at all - since the
Autofill Service should rely only on getAutofillValue() - but that could break
existing services.
Hence, a safer solution is to set that field if it's null.
Test: existing CtsAutoFillServiceTestCases tests pass
Test: manual verification using Fly Delta app
Fixes: 62751039
Change-Id: I91a8e0ed5db4148f5eb5729b8e254aa3531f15e4
- This flag will be set once provisioning is completed
and reset when SetupWizard is re-enabled.
Test: None. Adding a static variable.
Bug: 62419382
Change-Id: Ie3e4c118d26f6bd035a451ed1914e73bdeda4e3f
The root cause of the exception was that the activity destroy listener was
reacting to any activity being destroyed instead of just the one used with
the CompanionDeviceManager
Fixes: 62549525
Test: Ensure the attached bug no longer reproduces
Change-Id: I2f977e9ac9176247f5be9d08d19b3875f2b4a703
Autofill seems to need IDs to be preserved across things
like configuration changes, while accessibility will not
function without views with unique ids. Separating out the
two types of IDs. We can re-combine them once it's clear
that both demands can be satisfied.
Bug: 62301218
Test: Run a11y and autofill CTS, and verify that the play
store app functions with TalkBack after a screen rotation.
Change-Id: I17a99de2874768fc0ade3aa354130dd1f6b4cd7e
There are some apps that use the Surface object itself to indicate
changes. As a result, recycling the existing Surface object for
updates can lead to such apps ignoring events such as size changes.
This changelist restores the original behavior for legacy apps, where
the underlying native Surface object is recreated during updates.
Fixes: 62108743
Test: go/wm-smoke
Test: Open affected application, observe expansion to fullscreen when
nav bar disappears. Rotate to other orientation and observe
expansion to fullscreen.
Change-Id: I874602b6b8686c6ecb05cf7b1a04ec4b700ad3f9
Session was using findViewNodesByAutofillIds(ids) before, which not only was
not optimal, but error prone (for example, it could return a non-empty array
with an empty value).
Test: CtsAutoFillServiceTestCases pass
Fixes: 62532979
Change-Id: If984f1263cc3f2aac1d1e098687fe02d73c55211
Currently if View.setTooltipText is called while
the tooltip is being shown for that view, it will
update the displayed text. The tooltip then will
resize to wrap around the new text, but not change
its position. This looks confusing if the new text
is significantly shorter or longer.
Removing this functionality until proper
re-positioning is implemented.
Bug: 38491655
Test: android.view.cts.TooltipTest passes
Change-Id: I79689288185888854b992b89e19fe381d3ac50e4
Bug: 62692677
Test: Use an activity options that requires the bitmap copy, ensure
that it does not crash.
Change-Id: I20bdab1b91dfe47f7fe134fd17fe104eb4b27ec1
- Unify logic for detecting availability of the accessibility button
- Ensure the initial visibility state is propagated to A11yMS
- Ensure services only receive availability callbacks for changes
Test: Manual, created test accessibility services
targeting specific breakages
Bug: 38345417
Change-Id: I2250b32830cdfc2ecdc1dff7b7130dced2c1db29
Test: existing CtsAutoFillServiceTestCases pass
Test: manual verification using Contacts app
Test: manual verification adding a CTS test case that crashes the app, but such
test cannot be commit because once the issue is fixed, it crashes the
service (the right way to test this fix is through unit tests against
exceptional conditions, but we don't support those on Autofill yet).
Fixes: 62649290
Change-Id: I8fc01fa929270219cd40035ff02eaf0dda5ecbfa
Let's first understand how mView could become null. Notice
at the beginning of performTraversals, there is a check that
mView != null, and so it is nulled while we are in the function.
mView is package private and there are only two places which assign
to it, ViewRootImpl#setView and ViewRootImpl#doDie. setView is guarded
by mView == null. But mView was not null (per the check at the beginning
of performTraversals) and so mView is being nulled by doDie().
doDie() only has 3 callpoints:
1. ViewRootImpl#die(). Here though, calling it is guarded by
!mIsInTraversal. !mIsInTraversal is unconditionally set at the
beginning of performTraversals, and so this isn't our caller.
2. ViewRootHandler, handling MSG_DIE. This runs on the same thread
as performTraversal, and so it can't be our nuller.
3. WindowManagerGlobal#addView. This must be our nuller.
We see WindowManagerGlobal#addView will call doDie in the case that
we attempt to add a view which we had previously set to be removed
but deferred removal of. Now we can construct a reasonable sequence
for getting here:
1. requestLayout(). Perform traversals ends up on handler.
2. removeView(). MSG_DIE ends up on handler, View ends up in mDyingViews
3. performTraversals is executed by the handler
4. From a callback initiated by performTraversals (e.g. measure)
the client calls WindowManagerGlobal#addView on the view which
was just removed.
5. We are still in performTraversals so MSG_DIE hasn't been processed
yet. This means that WindowManagerGlobal will perform the doDie
immediately nulling mView.
6. We return to performTraversals and crash.
We can see shortly after the offending call to doDie, a new ViewRoot will be
constructed and so whatever traversal we are doing on the old one doesn't
seem particularly important. It doesn't seem that we can do any better
than letting it fall through without crashing.
Bug: 38421184
Test: go/wm-smoke. Feed to the monkeys.
Change-Id: I55f310a3533175c9df4a82878be5a60fd01b80c1
Change-Id: I997b8ae515f7bf2570edca4ed7ab4b46198148a5
Fixes: 62591398
Test: Manual; install instant app and see that it doesn't dexopt
Test: Manua; update gservices flag, install instant app and see that it does dexopt
...can't hide themselves
Tune the policies for when we tell about apps running in the
background after their services have stopped.
- If it ran while the screen was on, the time we require for it
to be running is much shorter (a couple seconds) as well as the
time we tell about it having run (with another tunable for the
minimum time we tell about this).
- If it has only run while the screen is off and stops a sufficient
amount of time before the screen goes on (currently a second) then
we will not show anything when the screen goes on.
- If it stops when the screen turns on, we will make sure the user
sees about it for a short period of time (currently 5 seconds).
Also includes some improved debug output about handler message
queues.
Test: manual
Change-Id: Iab438410d7182b2dfe4f9c1cce7069b26b34834c