There were a couple of problems with the new paddingHorizontal
and layout_mareginHorizontal attributes. For one thing, the behavior
of layout_marginHorizontal needed to change with respect to marginStart/End.
Instead of the implemented behavior where Horizontal took precedence over
start/end, the behavior is being changed such that start/end can override
horizontal. This makes it consistent with the way that the attributes work
for padding.
Also, the attribute docs were not correct. For one thing, they needed to be
updated to match the new behavior for marginHorizontal. Also, the docs for
the padding attributes (including the docs for the existing "padding") were
not correct for the behavior as-implemented (specifically with respect to the
precedence of the attributes where paddingStart/End are concerned).
Bug: 37756178 double-check logic of horizontal/vertical attributes wrt start/end attributes
Test: Updated cts tests, submitting at the same time
Change-Id: I85a102549022cbec7d7b5c76f31ac985db103372
Per bug, updating code snippet to clarify that it's an example of an
implementation of the method. Oscar & Felipe, please check that I did
it right!
Also fixed a couple of HTML syntax errors while I had the file open
(badly formatted escape-characters that Chrome figured out, but other
browsers might choke on) and a spelling error.
Revised Javadoc is staged to:
http://go/dac-stage/reference/android/view/View.html#autofill(android.view.autofill.AutofillValue)
Test: make ds-docs
Bug: 38347106
Change-Id: I587a66c53fd5ebeeb6108529723d2d7a74c61cf7
Allows creating a HW Bitmap from the drawing
commands of a RenderNode.
Bug: 38507414
Bug: 37698012
Test: Sample in HwAccelerationTest
Change-Id: I57c60b2c8bf5194f4412ad4b7f1c1f35e2e4c757
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
