The strategy of beginning the count at 1 isn't enough
and we need to explicitly debt each request to report
draw. Imagine the case where a ViewRootImpl reports draw
multiple times, while we are waiting for a SurfaceView draw
completion callback. Without the explicit draw debt, the ViewRoot
would be counted as drawing for the SurfaceView and we could
notify the WM too early.
Test: Open Chrome a few hundred times. go/wm-smoke.
Bug: 38324871
Change-Id: I5762a98d1cc808125033ba3d1db8a3ea39a9e071
To some extent we rely on the app to call the draw callback
if they want the app to work properly, but this case is fairly easy
to detect, so why not prevent it and provide a helpful log.
Bug: 62051758
Test: Warm start camera a few times. go/wm-smoke.
Change-Id: I39f4e015bfa15a1e0c37dba70b4a700803a6a274
The UI Thread is whatever we happen to be attached to, or the current thread if we are unattached.
Bug: 38180075
Test: Repro from bug. go/wm-smoke.
Change-Id: I3f75882aa13de2b781c71ebbc7b09888981521b3
- Fixed WebView < > and API calls.
- Improved description of virtual views.
- Described how to set boundaries of virtual views.
- Improved AUTOFILL_FLAG_INCLUDE_NOT_IMPORTANT_VIEWS doc.
Bug: 37567048
Test: ran 'm -j doc-comment-check-docs' and checked resulting HTML
Change-Id: Ic0d1e9ff2703c87d4007f0092a2f8dfe0efca6db
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
This mostly rolls back ag/710190, which caused
AccessibilityEvents to contain their source nodes. These
nodes were not completely accurate, and populating them
increases the overhead of AccessibilityEvents, particularly
when large numbers of content changes happen. Having the
service reload the node if it needs the update content
should be sufficient. I have fixed several bugs since this
change went in to address issues with the accessibility
cache containing stale data. I think ensuring that the newly
loaded data is up-to-date will fix whatever issues carrying
the node along was intended to fix.
Bug: 33961523
Test: A11y CTS still passes. I also tried TalkBack on a
couple of switch controls, which is where I have previously
seen the most issues with up-to-date announcements.
Change-Id: Ie5a70bb0e89d49255c6a4c1c83d32b755c06902f
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
This commit checks whether the state_focus is specified in the
foreground of a view. If it is, the default focus highlight won't
show up.
Test: cts-tradefed run singleCommand cts --skip-device-info
--skip-preconditions --abi armeabi-v7a -m CtsViewTestCases -t
android.view.cts.View_DefaultFocusHighlightTest#testIsDefaultFocusHighlightNeeded
Bug: 37288730
Change-Id: I5256eb656c1b8729d685edb914e867ee9a3a92a4
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
