* 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
Bug: 155422223
Test: make
insertInOrderBarrier and insertReorderBarrier are @hide and deprecated.
Remove them and update all callers to enableZ and disableZ, which are
already public.
Update native code to refer to enableZ instead of insertReorderBarrier.
In addition, remove @hide Canvas#isRecordingFor. This method was
originally used to prevent a single RenderNode from being in two display
lists. This is now supported, so there's no reason to avoid it. The one
caller used it to determine whether to reorder drawing its child Views
(which, as the comment says, makes sense to determine based on whether
the Canvas isHardwareAccelerated) and whether to call
insertReorderBarrier/insertInOrderBarrier (now enableZ/disableZ). In the
latter case, there is no need for a conditional, since enableZ/disableZ
only work on a hardware Canvas.
Change-Id: Ib216a19d6aeff40b2e23532bacd62d1795c2ab27
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
Bug: 155422223
Test: make
Follow on to Ie7172fb93364a1e04ab844b8fa64887bf9d8b005. Remove @hidden
APIs on Canvas - instead call setCompatibilityVersion from the
Compatibility class already in the Java package. This is a step towards
moving Canvas into a mainline module. Note that this means these are set
when the application is bound, rather than when the first View is
created.
Change-Id: I3f73d77ba7351a6cb653dd550210698c6482e1bb
* 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
