AutofillManager keeps track of which views the AutofillServiec is interested to
save, so when these views are gone, the session is finished.
But when the AutofillService returns a dataset whose views it can not save,
the FillUi for these views are not hiding when the views are gone. This CL
fixes this issue by:
- Keeping track which non-savable views should be tracked.
- Pass the view (instead of it's id) when the UI on such views should be hid.
This CL also optimized some AIDL and internal calls by avoiding the creating of
unnecessary Lists.
Test: manual verification with Snapchat
Test: existing CtsAutoFillServiceTestCases pass
Test: new tests on MultipleFragmentLoginTest pass
Fixes: 38199452
Change-Id: I78fa357962dbc6667146d8e08cd6bacb63e0f337
This unforunately introduces another quasi-visibiltiy method but
I think this is the best solution, as the code is pretty clean.
Test: Navigate through, settings, make sure no flickering
Test: Launch music from notification
Test: Launch United app
Test: Go settings -> app -> settings repeadetly 100 times, make
sure light bar transition is always clean
Fixes: 38216281
Change-Id: I0b97334dea3bfef2966ad0c7dd8bbd9907f2574c
With the introduction of surfaceRedrawNeededAsync we may
be asked to gather the transparent region ahead of the SurfaceView
having been drawn.
Bug: 38324871
Test: Launch Chrome Canary a lot! No Flickers.
Change-Id: I35f09a1bb8316895fa704b10c912e64a8920bd90
We instead just want to leave it floating, and let
it's lifetime be controlled by the parent surface. This way it can
take part in animations. Normally the WindowManager handles this by
calling detachChildren but it seems sometimes stop arrives before
the window manager is even clued in. Rather than bringing ActivityManager
in to the detach children dance...this seemed more appropriate and very similar
to the behavior before SV->SurfaceControl port.
Bug: 37922210
Test: Manual from bug + Launch chrome a bunch
Change-Id: Iee4fb0078a6e8dfd4c7acdb0107f8edd3a995634
- Add check for keyguard drawn before stopping boot animation.
Otherwise blank screen can happen.
- Bind to keyguard service when sysui is launched to reduce waiting
time later.
- Increase keyguard timeout to 5 secs if it is not boot completed.
Otherwise (= normal screen on), keep the current 1 sec.
This timeout can still lead into blank screen so use bigger timeout
during boot-up to prevent such case.
bug: 37867510
Test: many reboots
Change-Id: Ibfdc42d295bb1d3f5b4ea316fe5aca9ab875e4be
Since we can't take a snapshot when screen is turned off, we need
to snapshot before we are turning the screen off. For this, we
- Add a callback from DisplayPowerController to give policy a
chance to do something before display will be turned off.
- Implement this callback by taking snapshots of all visible
tasks.
Test: Inspect logs/traces about screen off blocking to make sure
callback is working correctly.
Test: Insert artificial 500ms delay in onScreenTurningOff and make
sure we are unblocking screen off when turning on screen in the
meantime.
Test: Open Maps, go to recents, open maps again, scroll to another
location, toggle power button, make sure the old location isn't
shown during unlock.
Change-Id: I489f31358f838d418f894f996495946084f136a4
Fixes: 37107783
We were throttling content changed a11y events both in View
and in ViewRootImpl. This change eliminates the throttling
in View, so events can be consolidated to reduce the number
of IPCs.
Change-Id: I1e1ecf1afc399e4103da82e6ed1779abfd3ec955
The qemu.gles property will be ready after the SurfaceFlinger service is
initializing. Once the all required variable is set, it caches the
result for the future calls.
Bug: 37759781
Test: Test with imx6ul and imx7d pico boards.
Change-Id: Ib9f11a51ec8a0707be854f67fc8591149ab7fd49
Test: 1. AccessibilityNodeInfoTest#testMarshaling
2. Hack the check from the above test to run on each parcel, then turn on
TalkBack and ensure to system crashes and stack traces in logcat
3. A11y CTS: CtsAccessibilityServiceTestCases, CtsAccessibilityTestCases,
CtsUiAutomationTestCases
Bug: 33949542
Change-Id: I2cef9fcef9d6f84334614b0e81c6717484ef3436
Test: manual verification on Caviar (automated test will be added later)
Test: CtsAutoFillServiceTestCases pass
Bug: 38341498
Fixes: 38323841
Change-Id: I15cc792de87987cc19a229c2ab2dfc317877f7ec
In particular we are seeing this in the call sites from performTraversals
in monkey crashes. I don't have exact repro but it seems like a feasible
state to get in to...for example...WindowManagerGlobal#addView can trigger
removal of a dying view immediately without respect for the mIsInTraversal
flag when it calls doDie(). This means we can dispatch detached from window
setting mView == null while performing a traversal. There's some question
about why this doDie is even required but...seems a little nerve wrecking
to change at the moment and it seems best to just guard against null for now.
Test: Monkeys will test.
Bug: 37343098
Change-Id: I94f2569c1ef70819c083f2b2b34b59622e6c6260
We may be stopped, removed from the view hierarchy, and then only
attached again after the activity has been restarted, missing
our WindowStopped callback to set mWindowStopped=false. At this point
we are being added to a visible view, or in ViewRoot#performTraversals
so we can assume we are not stopped.
Test: Manual from bug.
Bug: 37682805
Change-Id: Idf8e061fb7f83b00992a274c7dd704f9e0fcff5f
