* 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
* 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
Fixes an issue where the WindowInsetsController was only available after
the first traversal.
Bug: 155280356
Test: atest WindowInsetsControllerTests
Change-Id: I225efcaa31e97da9e8ebc6bd7d24c433c8e80826
Such that all it's goodness can also be used in context when
ViewRootImpl isn't available, like the SystemUI controller used
for Car and Split
Test: InsetsControllerTest
Fixes: 154631128
Change-Id: I54a3f8a34810472d9273e4627a7811b7abd0863f
Update the APIs documentation and add test cases
Bug: 152316540
Test: atest InlinePresentationStyleUtilsTest
Change-Id: Icff5d5b36fecd94ceb7db5446eefa16b4b1aac3b
Previously, was only 'adjusting' the secondary split for
ime. So the secondary had functional insets and drag/drop.
However, the primary wasn't being adjusted (accorcding to
WM). This caused its insets to be calculated against its
originla position (which allowed ime insets to potentially
overlap it) and it meant that WM didn't use its visual
position when calculating drag/drop coordinates.
So, this does the same with the primary stack as what was
done with secondary.
However, doing this required some other fixes in WM. Basically,
if appbounds is explicitly overridden, just use them instead of
intersecting with parent. Also, WSA doesn't apply crop for
splits (maybe it shouldn't apply crop to anything anymore).
Additionally, insets calculation was applying top insets to the
bottom if the inset frame's top wasn't exactly equal to the
window's top -- because of a catch-all else condition. So this
adds checks for matching the bottoms as well.
Bug: 154056542
Bug: 151862790
Test: Open two apps in split screen and open IME in secondary. Drag
from secondary to primary.
Change-Id: I2391783e726e4a1c8ed3150628af2f398218fe90
Divider used to have a touch-region that allowed apps
to receive touch events that would normally overlap the
divider window as long as they weren't in the center.
Re-introduce this by allowing windowless windows to
pass through a touch-region. This region is always
constrained to the window size to prevent security issues.
Bug: 154840035
Test: Enter split and observe touch events away from
center of divider.
Change-Id: I85310c78beda7bd5574df78e2a83462e965d1154
Because of the new app visibility constraints introduced in Android R,
apps may be unable to load icons from the TextClassifierService (TCS).
This is because the TCS returns "Icons" based on resources to the apps.
These resources were globally available until this new restriction.
In this CL, the TCMS rewrites responses with Icon(typ=RESOURCE) coming
from a TCS to responses with Icon(typ=URI). The new icons are backed
by a content provider that may be used to retrieve the necessary icons.
Bug: 151847511
Test: atest tests/tests/textclassifier/src/android/view/textclassifier/cts
Test: atest core/tests/coretests/src/android/view/textclassifier
Test: Select a phone number text, check that the "Call" icon shows
Change-Id: Ib63e54462508029cdf0e56c2c6a82ff4e81b02a8
This patch let DecorCaptionView report back to it's owner about height
change, instead of let the DecorView query the height. The previous
query points enableCaption() and updateDecorCaptionStatus() cannot
ensure the caption layout is finished and attached to the phone window.
Such that it may return a zero caption insets when it shouldn't be, if
the app do window configuration change handling by restarting.
The layout will ensure the caption insets get set when everything is
ready.
There will be no caption height change when resizing or moving, make
sure the calculated insets always include the caption regardless of the
frame position.
Bug: 154792488
Test: Manuel test with message and settings app.
Test: go/wm-smoke
Test: atest InsetsControllerTest#testCaptionInsetsStateAssemble
Test: atest InsetsSourceTest#testCalculateInsets_caption_resizing
Change-Id: I1728628eccb32b912210a64fe3a1c9cbe9e3b302
JNI calls aren't free and we don't need to burn one
to call update with the values we just passed in.
Bug: 152501005
Test: Existing tests pass
Change-Id: Iaf272edb03d4ec195b75e9ef7e6c122604025dcb
This error showed because DecorContext uses application context
to get WindowManager. This CL changes to use PhoneWindow to obtain
WindowManager instance. Also refactor ctr to obtain context from
PhoneWindow.
Bug: 152806048
Test: manual - enable strict mode and check the error log not shown.
Test: atest DecorContextTest
Test: atest MemoryTests#testActivityRecreation
Change-Id: I1d416b9cdb015c9bc3553571041f3b14bb9da5da
CL[1] intends to reset served view and restart input state when focus to
the next window, which the main idea is try to make the lifecycle of the
input connection can more aligned with the window focus change.
However, this behavior change unexpectedly breaks Gboard
TranslatesUIExtention that will closeExtensionView when
onFinishInputView -> onDeactivate called, while launching language
selection dialog.
Remove the reset logic as the lifecycle of input connection still
needs to break down.
[1]: I8d4fff94ba9313b773bc27fcbd019cc88580d3e9
Fix: 152373385
Test: To make sure not break Bug 148489857 and Bug 148788569, following
auto / manual test to verify:
- Auto: atest FocusHandlingTest#testKeyboardStateAfterImeFocusableFlagChanged
- Manual:
1) Build / install EditTextVariations
2) Select menu -> Direct-Reply, make sure Notification comes up.
3) Tap EditText on Notification, verify soft-keyboard is visible.
Change-Id: If20cdb43ecd013c330c5e16c73e9af972bd89f33
1. Avoid a seperate IPC querying in to system-server
to initialize the mUseBLAST flag.
2. Avoid calling property_get_bool with each BufferQueue
creation.
Instead we piggy-back both values inside addWindow return values.
Bug: 152501005
Test: Existing tests pass
Change-Id: If130560a8230f8d399cf7631264d551522939faa
Add test to verify that requestedVisibleAwaitingControl starts
animation. This is followup test for comment in commit
I958fc5747382109aa2f21bc1067a28746e7242d8
Bug: 154440912
Fix: 153577930
Test: atest ImeInsetsSourceConsumerTest
Change-Id: I08db27151605ac53b0575b08343b5a75dc2e5fc2
