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
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
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
- Fixed PFLAG3_NOTIFY_AUTOFILL_ENTER_ON_LAYOUT value - it was overlapping with
PFLAG3_ASSIST_BLOCKED.
- Added missing permission on methods called by Shell command.
- Improved debugging.
Bug: 38173625
Test: android.autofillservice.cts.MultipleFragmentLoginTest#loginOnTwoFragments
Change-Id: Ie7880c97d38298e06134709c5c2e9e38fa1bacbb
No good will come from posting that a null View has
changed. Adding a null check so the failure will happen
when the bad call is made, rather than later when we
try to act on it in a handler.
Bug: 38122973
Test: Ran accessibility unit and cts tests.
Change-Id: I1e9aaf2a18180fcdfd0fbc0e5b716eb96446af33
packageManager.resolveActivity(intentWithUppercaseScheme, 0) returns null.
This means we don't find an activity to handle the browser intent.
Create a browser intent with url's scheme in lowercase instead.
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Fixes: 36504599
Change-Id: Idb0c5b73d54cf77d5d6fb4ee0af4478ec11e8b82
Logs:
- Smart selection occured
- TextView menu item activated on smart selection
- Smart selection reset
- Smart selection modified
Test: Manually checked logging happens as per go/tron-howto and verified
nothing is broken in related classes by running:
bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
bit FrameworksCoreTests:android.widget.TextViewActivityTest
Bug: 32572232
Change-Id: Ia9081d92ae9aea50d863455be770eecd0c73be1a
For apps targeting releases earlier than O setBitmap will attempt
to preserve the matrix from the previous bitmap. It does not however
attempt to reconstruct the save/restore stack or the clip.
Test: manual test of messenger app referenced in the bug
Bug: 37589964
Change-Id: I67f0928a3f84a8be41da38ef1868e79bdeb03e46
Previously, a default value was being propagated for surfaces constructed
though paths other than WindowManagerService.createSurfaceControl. This
allows us to handle all surfaces in VR in a better way
Bug: 36589137
Test: Launch chrome (uses SurfaceView)
Change-Id: I8434c356ebe51173cae161ec1405e3d5f9a17723
When transitioning between the fullscreen and pinned states
we often have a situation where we go from having a navigation and
status bar in the window to not. We'd like to use the source bounds
animation to crop these out rather than a sudden jump or scaling
but in order to do so we need to ensure they last until the end
of the animation. We track this state, and return the appropriate
value from isFloating. Furthermore, we add support to the bounds
animation to use the content frame as a source bounds when there
is no source bounds present, this means that we can crop out the
navigation and status bar so they will be invisible by the end of
the animation.
Bug: 37531386
Test: Manual
Change-Id: I72c549e3a3318534428d17b68ebee5832c32e6d7
