Careless mistake on my part :). Sorry about that.
Test: Try an app with two SV like Netflix verify top SurfaceView doesn't occlude bottom one.
Bug: 62375611
Bug: 62113351
Change-Id: Ia33aabf8b8e276f70365d62b82f113ecd3bee2fa
This reverts a part of 2ae1bf568b
RecyclerView relies on the old behavior. Will un-revert this (with
targetSdk check) once we have a solution for RecyclerView
Bug: 38352147
Test: RecyclerView Focus tests now pass
Change-Id: I7b0dfda295cd75e407bbd39a948b5585f8ed6e08
Previously, it was possible for the view hierarchy to be measured,
laid out, and drawn around a window frame size that did not match
the current configuration. This stems from new configurations not
always propagating back from WindowSession#relayout, which is
called from ViewRootImpl.
This changelist makes WindowManagerService#relayoutWindow always
return the latest configuration. It also adds rotation to the
configuration.
Fixes: 32839232
Test: go/wm-smoke
Test: Open Camera while rotating phone to landscape. Added
temporary logs to detect inconsistencies between measurements
and reported rotation on draw.
Change-Id: I39daca338b4f87eff1a509eb99493f01e710ced1
Most @SystemApi methods should be protected with system (or higher)
permissions, so annotate common methods with @RequiresPermission to
make automatic verification easier.
Verification is really only relevant when calling into system
services (where permissions checking can happen on the other side of
a Binder call), so annotate managers with the new @SystemService
annotation, which is now automatically documented.
This is purely a docs change; no logic changes are being made.
Test: make -j32 update-api && make -j32 offline-sdk-docs
Bug: 62263906
Change-Id: I2554227202d84465676aa4ab0dd336b5c45fc651
- When the window for the activity enters PIP, update the outline provider
to override the alpha of the shadow (to be opaque) to ensure that is is
visible. Only applies to the task root activity.
Bug: 36741700
Test: Launch YT, ensure that there is a shadow when after it enters PIP
Test: go/wm-smoke
Test: android.server.cts.ActivityManagerPinnedStackTests
Change-Id: If089dae84e4916d3d0e7bbeb316215b46e522e05
In N we used a Dim-Layer to add a background to SurfaceView, from
the WM side. In O we forgot to reimplment this with the new SurfaceView
and so we once again can have holes for apps which don't implement
surfaceRedrawNeeded.
Bug: 62113351
Test: Manual from bug. go/wm-smoke
Change-Id: If3dac51886b9a8083140da7b5bc1b349da57860f
- focusAfterDescendant ViewGroups that were also clusters would
continue to be remembered for restoreFocusedInCluster after
gaining focusable children. This caused undesired cluster-focus
loops
- focusableViewAvailable wasn't being called in all cases (specifically
when views were added). This meant focusAfterDescendant views
wouldn't transfer focus to children in some cases.
- 0-area views which became focusable weren't reporting
focusableViewAvailable. Since views gaining area doesn't report
focusableViewAvailable, this was another case of state change not
being accounted for. Also, this restriction doesn't exist for
gaining focus so these views are actually focusable despite having
0 area.
- focusableViewAvailable was reporting focusable views even when
ancestors (and therefore the new focusables) were not visible.
- restoreFocusNotInCluster tried to focus invisible views
- restoreFocusNotInCluster was sending focus to focusAfterDescendant
viewgroups which had focusable children IN a cluster.
Bug: 38010274
Bug: 38009598
Bug: 38352147
Test: cycling works in situations reported in bugs.
Added CTS tests around focusableViewAvailable and
FOCUS_AFTER_DESCENDANTS
Change-Id: I77f214f5384dcf9092324e08fc1daa3f1155bbad
- This reduces the copy of the hardware bitmap when it is
parceled/unparceled.
Bug: 38507414
Bug: 62021436
Test: Launch Overview to/from app, ensure that the header bar shows
Test: go/wm-smoke
Change-Id: I85a9a59a0a3699d1642158061d10fddef34393c3
Signed-off-by: Winson Chung <winsonc@google.com>
When the device is unlocked using the fingerprint sensor in an
orientation opposite to the lockscreen orientation, the app that
will be visible is first relaunched in the current lockscreen
orientation and then later relaunched in the correct orientation.
If the keygaurd is going away then:
- Don't let keyguard affect device orientation. We want to use the
orientation of the app that will be visible.
- Allow the rotation sensor to be enabled even though draw isn't
complete so window manager can get the updated or last rotation
reading.
- Don't clear the previous proposed sensor reading to allow
window manager to use the information to update the orientation as
needed vs. falling back to the previous orientation.
Change-Id: I8369723d6a77f2c602f1ef080371fa7cd9ee094e
Fixes: 38494778
Test: Launch an app that doesn't fix orientation like clock, hold
the device in landscape, press the power button, unlock the device
using the fingerprint sensor, and verify the the app isn't
relaunched.
When the user manually requested autofill and the service returned just 1
dataset, the app was automatically filled with it.
The motivation here was that since the user explicitly asked for autofill,
it'd ok - and better for the user - to release the data to the app without
the selecting a dataset.
This assumption was ok initially, but now the API to manually request autofill
is public, so a malicious app could use to get autofill data without user
interation.
Test: CtsAutoFillServiceTestCases pass
Fixes: 62164695
Change-Id: I47c3d8c557533526572aa67a4240c0a57f54268d
- The current code always used the default min edge size to calculate the
PIP bounds when the aspect ratio changes, so if a PIP app sets the aspect
ratio in response to the an action, the bounds would be resized down
incorrectly.
- This CL fixes the issue with current aspect ratio not being initialized
correctly, and also ensures that SystemUI always updates the min edge
size when expanding the PIP.
Bug: 38324839
Test: android.server.cts.ActivityManagerPinnedStackTests
Test: go/wm-smoke
Change-Id: Ida0f68b2f8f93f9bf1915dda8762a156704d4709
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
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
