In the test we trigger the manual autofill request programmatically,
because the focus isn't on the field, we will not get the callback
from IME.
It would be better not to ask IME for inline request if the request
is manual and the view is not focused because it's a simpler/safer
approach and manual request without focus should be rare.
Bug: 154661868
Test: atest CtsAutoFillServiceTestCases
Change-Id: I783b2542094cdea547ebd58ce89f30d9cd421708
* changes:
Send fixed rotation adjustments to the associated client
Add support to override display adjustments by token
Add fixed rotation display adjustments
The transform hint is used to prevent allocating a buffer of a
different size when a layer is rotated. The producer can choose to
consume the hint and allocate the buffer with the same size.
Provide the graphic producer a transform hint if the layer and its
children are in an orientation different from the display's
orientation. The caller is responsible for clearing this transform
hint if the layer is no longer in a fixed orientation.
Bug: 152919661
Test: atest VulkanPreTransformTest
Test: confirm with winscope trace, buffers are allocated taking into
account the transform hint in fixed orientation scenarios
Test: go/wm-smoke
Change-Id: I2ccc21ed8af015716e6cdfde1e3cec67c99f3339
So the real information of display can be adjusted according
to the adjustments for the application started with fixed
rotation transform.
The enabling adjustments may be sent in different ways:
- Launch activity
The information is bundled with LaunchActivityItem.
- Resume activity or update non-activity window
Send a standalone FixedRotationAdjustmentsItem.
The disabling adjustments (null) are always sent by
FixedRotationAdjustmentsItem.
Bug: 147213487
Test: AppConfigurationTests#testRotatedInfoWithFixedRotationTransform
TransactionParcelTests#testFixedRotationAdjustments
Change-Id: I5238888a5c8352db83fc12749f4de2bfabf46026
If an activity is launched with fixed rotation transform,
its window layout and configuration will be rotated. But
if it gets real information from the display, the values
(getRotation, getRealSize, getRealMetric, getCutout) are
inconsistent with the actual appearance.
This change provides the basic information to adjust the
returned values.
Bug: 147213487
Test: atest DisplayAdjustmentsTests#testFixedRotationAdjustments
Change-Id: I864d5759f41209d5f93c4a9011b720675c25e765
If we cannot get flag information from the AutofillManagerService
after the timeout, we should not crash the process, we need to
handle the enabled information properly.
Also fix NPE because of null component name while calling
AutofillManagerServiceImpl.isWhitelistedForAugmentedAutofillLocked().
Bug: 151273845
Test: atest CtsAutoFillServiceTestCases
Test: manual. Copy the text from Messenger and paste on search bar,
no crash occurred and can paste text correctly.
Change-Id: I8d7ca35226052944fd68fef60a013a65a7fb57c1
If a motion event classified CLASSIFICATION_AMBIGUOUS_GESTURE, it would
multiplied the AmbiguousGestureMultiplier from configuration for the
touch slop, we have to make sure this value should be start from 1 or
the touch slop could be zero and click action may fail.
Bug: 155160957
Test: manual
Change-Id: I61e1262b4f3de61214297b678956cc14fa2f24ef
Also, make Bubbles a TYPE_TRUSTED_APPLICATION_OVERLAY!
Test: make a permission dialog appear while bubbles appear (wait for any HUNs to go away)
Fixes: 149320322
Change-Id: Ib4b93635929cf996753a21717383c327256477b3
If the client didn't change any insets, we don't need to update the
requested state while receiving controls. The requested state at the
server side can still be up-to-date for free.
This CL also sends the requested state to window manager if the local
state is not the same as the dispatched state.
Fix: 155752039
Test: atest InsetsControllerTest
Change-Id: I676a88d3ef823d8717d03e80261e6e7a5f7e8c5f
An input channel specifies the file descriptors used to send input
events to a window in another process. And All of the file descriptors
open in the calling process shall be closed when process terminated.
The server side could receive the socket broken event when the process
terminated, we should do the unregister channel before close the file
descriptor or do it automatically without error if there is no valid
window.
- Change the order that remove window before dispose the receiver.
- Unregister input channel when windowless window removed.
Bug: 133782251
Test: open app and exit by back key or recent apps, check if any
error log occurs.
Change-Id: I59d0084c2c771544e7ee226ce53c574f60c6b988
* Before this change, when the inline suggestion view is detached from
the IME window (e.g. due to layout change), the remote view content
will not show again even after the view is reattached to the window
on the IME side. This patch fixes it by requesting the remote view
owner (the ext services) for a new SurfacePackage when the view is
re-attached to the window (see javadoc of SurfaceControlViewHost for
why this works).
* This patch also fixes the issue where the SurfaceControlViewHost was
never released in the ext services. This is done by notifying the
ext services (through system server) when the view is detached from
the IME window, and then the system server will release the
SurfaceControlViewHost if after N(=500) ms the view is not re-attached
to a window.
* After the SurfaceControlViewHost is released, if the view is
re-attached to the window later, a new SurfaceControlViewHost will be
created to back the same InlineContentView.
* The current code structure also lays a foundation for a subsequent
change to allow reusing the same remote view for inline suggestions
during filtering.
Test: atest CtsAutofillServiceTestCases (sanity test)
Bug: 153615023
Bug: 154683107
Change-Id: Idc587e1e82a96b792c351796464821b7aad7cd89
Revert "Refine FocusHandlingTest"
Revert submission 11182377-fix_b_152373385
Reason for revert: Fix b/155781821
Reverted Changes:
If20cdb43e:Keeps the served view of the window when focus to ...
I50402165b:Refine FocusHandlingTest
Bug: 152373385
Bug: 155781821
Change-Id: I44469caf5a5ceaf247c4e6b0694da9da1f3c0eb1
If we ask the BLASTBufferQueue to redirect a buffer in to a transaction
but then lose the buffer the app will of course eventually ANR as it
is stuck on EGLSwapBuffers. Here we fix two cases where this could have
happened:
1. Currently if we are blast syncing and report draw is true
we send the buffer to the WM. This is from an earlier version of
the code and is not correct. The WM now explicitly notifies us
if it wants to receive the buffer, and so we avoid sending it if
it hasn't asked.
2. We should pause the renderer in addition to fencing it
otherwise a render thread animation frame could sneak in. We are
right on the verge of kicking off a new frame so this shouldn't
have much impact besides ensuring overlapping frames don't
confuse our transaction logic.
Bug: 155300507
Test: Existing tests pass.
Change-Id: I816d806da6c09ae12734de8909c0e61af433f93f
This reverts commit 02d3a8ad07.
Reason for revert: the original change caused the infinite message loop.
Bug: 155794233
Change-Id: I3d72541cd51cd8b16ce4f44124d486b4615b09da
The divider surface buffer will be allocated even if the user does
not enter split mode. Avoid it by only copy surface when it show and
release it when it hidden.
Bug: 150190730
Test: reboot and check adb shell dumpsys SurfaceFlinger
Change-Id: Id70a2626b2a921cff6243d992c6b053e329ef92b
Introduces new test api to access the background view of status bar and
navigation bar.
Bug: 154720832
Test: atest WindowInsetsPolicyTest
Change-Id: If38d3f57edfbb2631d4c1e47ed5347a332edacfb
Previously, we've notified it only when we have the control.
But to update color views, we should notify it even when we have no control.
Bug: 154720832
Test: atest WindowInsetsPolicyTest
Test: make sure no regression on b/150195782, b/151425506
Change-Id: I44b88ddc206f36d8ef11dae9c1477739a185ff21
* The use case of this API was for augmented autofill service to send
updated suggestions
* Before this change, the dynamic autofill request by the augmented
autofill service only triggers a manual request, but this has caused
some regular autofill providers to always some suggestion due to
their special handling for the manual request. Thus the augmented
autofill service will not receive the request.
* With this cahnge, the request cancels the previous session to start a
new session, and also it triggers a regular request (non-manual) so
the autofill provider will not special handle the request.
Test: atest CtsAutoFillServiceTestCases
Bug: 154543563
Change-Id: I233125a6070394a102ad40b9a50b98a43d952b9f
In SurfaceControlViewHost#release we currently immediately
release mSurfaceControl and then call ViewRootImpl#doDie.
However doDie executes on a handler so the ViewRootImpl may try
and use the SurfaceControl between posting and executing
the message. Actually this release is totally erroneous,
mSurfaceControl is the same object used by the ViewRootImpl
and the ViewRootImpl will release it when processing
doDie().
Bug: 155575445
Test: Existing tests pass
Change-Id: I6a4bf41ba38636ff884aa73d2653b1bab6958b00
This metrics now is used for calculating the value reported by
Display#getSize. It could be extended to have more function later.
Also replace getCurrentMetrics usages to make them report
Display#getSize value.
Bug: 148904274
Test: atest WindowMetricsHelperTest
Change-Id: I182b6e63f7c28752eee22839cb9e69f073046c3f
* Before this change, the suggestionRoot would intercept all touch
events so that it can optionally forward them to the IME process
to support scrolling, no touch event will be sent to the child
view through the regular event dispatching process.
* With this change, we move the touch event transferring (to IME)
logic from SuggestionRoot's onTouchEvent to dispatchTouchEvent.
Now the touch events before a scroll is detected will be sent to
the child chip view, and only the touch events after a scroll is
detected will be sent to the IME.
* This patch also move the OnClickListener and OnLongClickListener
from the root view to the chip view, since the touch events now
either goes to the chip view or to the IME process.
* Note that in order to achieve this, given that we can't change
the API, and there is existing OnLongClickListener registered
to the chip view, we have to add a @hide API to the View to
get the existing OnLongClickListener and attach a new one to the
chip view, such that we can do the additional work of sending
the long click event to IME, when the view is long clicked.
* This patch should also fix the a11y talkback mode bug where
double-tapping on the view doesn't autofill the value.
Double-tap and hold also works that it triggers the attribution
dialog.
Test: atest CtsAutoFillServiceTestCases (sanity test)
Bug: 155245913
Bug: 154149807
Change-Id: I6f7be1ea5c0955969abb4ccae0cb421423095c4d
Previously, we generally required fully qualified names for referring
to inner class constructors (like #Notification.Builder()) despite that
not being valid javadoc. Now, we properly support #Builder() syntax and
the old syntax will error.
Bug: 6963924
Test: make doc-comment-check-docs
Exempt-From-Owner-Approval: cherry-picked from master
Change-Id: Ib2e4360493275b79c72487ee1cb173bb5e0fd35f
Merged-In: Ib2e4360493275b79c72487ee1cb173bb5e0fd35f
(cherry picked from commit 4c4aa41272)
These were previously being suppressed by doclava but with this change,
all failures are fixed and the suppression logic has been removed.
To fix the issues, there were a few possible changes made:
- broken reference to a public API (such as incorrect parameters): fixed
- unnecessary @link inside an @see tag: fixed
- @see referring to an @hide or @SystemApi: reference removed
- broken references to inner class constructors
- worked around by fully qualifying the constructor
Bug: 6963924
Test: make doc-comment-check-docs
Exempt-From-Owner-Approval: cherry-picked from master
Change-Id: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
Merged-In: Ifbdce2de96cdffa560bd90f549fa7184d1f9af85
(cherry picked from commit e0624c7a40)
To prevent low-priority refresh rate considerations from overriding the
app frame rate as specified via the new setFrameRate() api, split the
display refresh rate range into "primary" and "app request" ranges. The
primary range includes the low priority considerations, while the app
request range removes two lower priority considerations.
In general, surface flinger will keep the display refresh rate within
the primary range, but layers with frame rate settings via the
setFrameRate() api may cause surface flinger to pick a refresh rate
outside the primary range. Surface flinger will never choose a refresh
rate outside the app request range specified by display manager.
Bug: 148978562
Test: - Added a new unit test to DisplayModeDirectorTest to verify that
display manager strips lower priority considerations when
deciding the app request range.
- Added a new unit test to RefreshRateConfigsTest to verify
RefreshRateConfigs handles the primary vs app request range
correctly.
- Manual test: Confirmed that with the "force 90Hz refresh rate" option
turned on, we don't switch to 60Hz when playing a 60Hz video.
- Manual test: Confirmed that with the "force 90Hz refresh rate" option
turned on, when an app calls setFrameRate(60), we stay at 60Hz.
- Manual test: Modified a Pixel 4 XL to prefer 60Hz in low brightness,
entered low brightness, and confirmed we don't touch boost to 90Hz.
- Manual test: Confirmed that Maps stays at 60Hz on Pixel 4.
- Manual test: Turned on verbose logs in RefreshRateConfigs.cpp,
confirmed they look good.
- Manual test: Inspected dumpsys output, confirmed the primary and
app request refresh rate ranges are printed correctly.
Change-Id: I2a7f5ded0831c90b9b1ac09d941963a63b824098
