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
IME was not able to hide itself correctly after lock screen, resulting
in visibility state being inconsistent.
Bug: 154753046
Test: atest KeyguardLockedTests#testImeShowsAfterLockScreenOnEditorTap
WindowInsetsControllerTests
Change-Id: Ice33d68e999627b7b62410d22cd51e18f8e23d34
Previously, the client won't send the modified insets state to window
manager if the dispatched state and the local state are the same. The
following case can make the requested insets state at the server side
stale:
1. Window A requests an insets source to be invisible while having
the control.
2. Window A loses the control.
3. The new control target requests the insets source to be visible.
4. Window A receives the new insets state from server.
5. Window A also requests the insets source to be visible while not
having the control.
6. Window A gain the control.
7. Window A won't send the new requested state (visible) to window
manager because the local state and the dispatched state are the
same.
8. Window manager keeps assuming that window A is requesting the insets
source to be invisible which is incorrect.
This CL stores what insets state is sent to server, and updates/sends
the state to server while gaining the control if the requested state is
changed.
Fix: 146964271
Test: Manual.
Change-Id: I6ee533d9316c769faef539bfb980197c351ee8d1
An earlier CL with benchmarks has shown that sending strings as UTF-8
is 50% faster for US-ASCII strings, and still 68% faster for complex
strings referencing higher Unicode planes. (So an improvement in
both cases!)
Since code across the OS still makes heavy assumptions about Parcel
strings typically being UTF-16, we need to carefully migrate
Parcelables by hand, which is what this CLs begins doing.
Bug: 154436100
Test: manual
Change-Id: I9a675473e0ce3a4a5c5e305dd851b40bb1560e1c
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
Change-Id: Ib2e4360493275b79c72487ee1cb173bb5e0fd35f
Fixes an issue where the WindowInsetsController was only available after
the first traversal.
Bug: 155280356
Test: atest WindowInsetsControllerTests
Change-Id: I225efcaa31e97da9e8ebc6bd7d24c433c8e80826
