When referring to a client (piece of software), it's better not to use
a personified pronoun, such as "his" or "their". Changed to "the".
Change-Id: I5d79e70a9135d6f1e8da493fcdd50921b9696e31
Test: none (docs-only change)
Bug: 160937339
For non-telephony networks, this was always set to 0 before R.
In R, it is currently set to the same value as the network type.
This is incorrect because the two have different namespaces.
or example, currently, any network of type WIFI (==1) will have
a subtype of NETWORK_TYPE_GPRS (==1). Similarly, all ETHERNET
networks will have subtype NETWORK_TYPE_1XRTT, all VPN networks
will have a subtype of NETWORK_TYPE_TD_SCDMA, etd.
Bug: 161653721
Test: builds, boots
Change-Id: I07e111c1762e0021c931cefc27f193f78578748b
Inline APIs.
* limitations with multiple locales.
* limit on max number of suggestions.
* guidance on managing the order of inline suggestions when inflating.
Fixes: 161486684
Test: atest android.autofillservice.cts.inline
Change-Id: Ia560d48f95730d79bc340ff9eb0cf4a5909bf0d3
Set supported flags from AudioAttributes into VibrationAttributes on the
builder constructor.
Fix: b/161761418
Test: manual
Change-Id: I4a8e1db278843b2f9f19aba43b0b8f264cb696bd
We use same reference from TextView to set the initial
surrounding text. The actual surrounding text may be
modified before retrieval since the mSurroundingText
is mutable. Use a copy of subText should avoid this
concurrent issue.
Bug: 160390184
Test: atest FrameworksCoreTests:EditorInfoTest
Change-Id: I6082a4cae2fcdc4c529dc14e2e5e7a45ab1aae4d
When dismissing a dialog with EditText focused and keyboard shown,
the keyboard does not get correctly dismissed.
This happens because after CL[1] landed, returning to the activity won't start
new input connection, and the activity will thus not regain control over
the IME.
This fix restores the previous behavior, where IMM will start a fake input
connection even without an editor.
[1]: I1ef3d341af9d473d94d52fd1890deafbae2bc9e1
Fix: 161273049
Test: atest CtsInputMethodTestCases
Test: manual as follows
0) Have some files downloaded in the device
1) Launch Files app > Browse > Click Internal Storage
2) Long press on any file > From menu, click "Rename"
3) Enter some name with soft keyboard and click "OK"
4) Expect Keyboard should hide
Change-Id: I022ad658844142ff4a4cf3b91953013f2bfbb58a
The issue occurs because TextView#isFromPrimePointer assumes multi-touch
events are happening on the same TextView and relies on
ACTION_UP/ACTION_CANCEL to reset the Prime pointer id.
consider following scenario:
1. ACTION_DOWN (pointer 0) landed on ViewA,
ACTION_DOWN (pointer 1) landed on ViewB.
2. ACTION_MOVE landed on both ViewA and ViewB, triggering a drag.
3. When all fingers are released, ACTION_CANCEL (pointer 0) will be
landed on both ViewA and ViewB, so the prime pointer in ViewB is not
reset due to pointer index mismatch.
This CL always reset prime pointer id whenever ACTION_UP/ACTION_CANCEL
is triggered.
Bug: 157399040
Test: manual
Change-Id: Id35d9eac939378482fa50e85bb5cda58469240ad
In the legacy layout world, if a window has FLAG_FULLSCREEN, then its
stable insets won't be affected by status bar. This CL makes the layout
logic compatible.
Fix: 160593171
Test: InsetsStateTest InsetsControllerTest ImeInsetsSourceConsumerTest
Change-Id: I59717e699470273e2462c1ad864e00bb9a126677
Checking carrier privileges for UIDs with lots of shared apps can incur
a significant performance hit. For UIDs that are fixed and trusted
(system and phone), skip the permission check and always allow.
Also, double the cache size for getPackageInfo in order to reduce the
rate of cache misses.
Bug: 160971853
Test: manual verification -- observed lower rate of cache misses for
getPackageInfo from com.android.phone.
Change-Id: I1399cab579308479d7cf191b8795441cbcd3ff65
As CL[1] we introduced WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR start
input reason to ignore start new input when the focused view is
same as current served view and the input connection remains the same for
prevent additonal onStartInput / onFinishInput callback to
InputMethodService.
The main idea in the CL is good but how to judge whether the input connection
remains the same is not accurate.
CL[1] only checking if IMM#mServedInputConnectionWrapper self and its
input connection instance is stil exists, that breaks the following cases
to start new input:
Case 1:
- When device screen off / on to go back to focused app, this case will
fit WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR use case, so
IMM#mServedInputConnectionWrapper won't be deactivate and clear, this
makes wrong when user taps IME picker dialog to switch IME, will hit
again WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR and never start new
input for new IME.
Actually, in InputMethodManager has an ad-hoc check mRestartOnNextWindowFocus
to start new input when device screen off / on case and switching IME,
we should not ignore start input since that will conflict with the above
case.
Case 2:
- As served view is now tracked by ImeFocusController which is per-window
based instance from the IME focus handling refectoring CL[2],
but InputMethodManager instance is still per-display based, so
IMM#mCurrentTextBoxAttribute might be changed when the same app clinet has
multiple IME focusable window focus changed, because focusing to the next
IME focusable window will start new input connection and changes
IMM#mCurrentTextBoxAttribute, so when focusing back to the
original window, the served view in the original window's
ImeFocusController will same as focused view, in that case if we didn't
check if IMM#mCurrentTextBoxAttribute is really aligned with the given
focused view, will mis-judge start new input timing and caused user can't
type because the input connection state is obsoleted.
Those cases can be addessed by using new introduced method
IMM#isSameEditorAndAcceptingText, if the focused view is not aligned
with same editor or the editor is inactive, we should start new input
for Case 2, that also can fix Case 1 that we previously ignored starting
new input when switching IME.
Beside, we also found CL[3] leverages
InputMethodManager#mRestartOnNextWindowFocus to start new input when window focus
changed, since originally this ad-hoc check is only used to re-start input
for Case 1.
As we re-visited the necessary start new input scenerio is only when:
- Device screen off -> on
- Switching IME
- the input connection obsoleted
(this also includes when window focus changed)
As the result, we can remove all unnecessary logics in IMMS
instroduced by CL[1] and remove unnecessary
InputMethodManager#mRestartOnNextWindowFocus from CL[3], and preserve
the behavior is almost same as Q.
[1]: I2da99ae67b9ce4051dec0c0f0e975ebe6e1ab118
[2]: Ib455704fe1e9d243f93190a84f230210dbceac2a
[3]: I8d4fff94ba9313b773bc27fcbd019cc88580d3e9
Fix: 160391516
Bug: 158624922
Bug: 152373385
Test: atest FocusHandlingTest
Test: atest InputMethodServiceLifecycleTest
Test: manual for case 1
0) pre-install 3rd party IME app
1) launch message app and taps Search bar to focus.
2) turn off screen
3) turn on screen to back to focused app
4) press IME switch icon from nav bar
5) choose next IME, expect the IME should be changed.
Test: manual for case 2
0) Sample app with 2 activites, each activity the layout has
EditText
1) Launch activity A, focus EditText
2) Launch activity B and focus EditText
3) Press back key to back to activity A
4) Verify if typing with keyboard is workable.
Change-Id: I1ef3d341af9d473d94d52fd1890deafbae2bc9e1
If the local state and mLastDispatchedState are the same, the logic in
onStateChanged will skip updating the requested state. This could be an
issue, for example, a new focused window requested to hide status bar,
but status bar has already been hidden by the previous focused window,
so the new focused window will never send the requested state to server.
This can easily happen when an immersive activity is re-created due to
the configuration change.
This CL updates the requested state if any visibility within it is not
the same as the requested visibility of the source consumer, while
receiving controls.
Fix: 160854328
Test: atest InsetsControllerTest
Test: Swipe to show transient bars after rotating an immersive activity
Change-Id: I5d9acb1b59252fa80e66070db86b2555764588da
In a normal case, the app will get either a visibility changed to
false or stopped from system server to indicate that the content
should be cleaned up. In those cases, it will request a relayout
to WM, which will notify VRI that the surface is gone. Since the
VRI surface is removed, the SV and bounds layer will get notified
that they should be destroyed. On the next relayout, the VRI will
get a new surface and notify SV and the bounds layer to create
new surfaces.
The scenario in the bug happens when VRI receives a visibility change to
false, but doesn't process the information fast enough. By the time it
calls relayout, WMS is in the state where the client is visible again. This
time the relayout will return a valid surface so the SV and bounds layer
will not get cleaned up. The reason this causes issues is VRI now has a
new main surface. The bounds layer is parented to the old layer that's been
deleted so it's not parented to anything. The SurfaceView is a child of
the bounds layer so it also renders offscreen.
The reparent needs to be done on the client side since WMS won't
reparent the children to the new surface if it thinks the app is
closing. WMS gets the signal that the app is stopping, but on the client
side, it doesn't get stopped since it's restarted quick enough. WMS
doesn't want to keep around old children since they will leak when the
client creates new children.
This change will reparent the bounds layer to the new VRI surface. It's
possible WMS will take care of this in certain cases where the app
isn't stopped. But for those cases, the reparent will not have
any effect since the bounds layer will be correctly parented.
Fixes: 159545768
Test: Can no longer repro black SV in maps
Test: Test app with SV and delay in onPause no longer has the same issue
Change-Id: I616652e1cc4380ebbcb386586d8d5889fcc19497
This change ensures that while parsing a package, we require an explicit
wildcard in the queries->intent->data->host field. Prior to this change,
we were defaulting to wildcard when not provided. This resulted in,
e.g. someone trying to get visibility to just browsers actually getting
access to all packages that handle any web intent.
Fixes: 160868841
Test: atest AppEnumerationTests IntentFilterTest
Change-Id: I771845467928b6655fe19efe89bd2ca548dca6e5
Fixes a flicker that occurs during transitions between windows.
This happens for two reasons:
1.) Control is immediately transferred to the new window, and the
previous window didn't get a chance to play the animation.
This is addressed by adding logic to keep control on the
exiting window for the duration of the transition - similar to
what we do with the target for z-ordering purposes.
2.) Upon the input connection being severed, the InputMethodService
immediately hides its window, preventing any animations whenever
the input connection changes
This is addressed by moving hiding of the surface into the
controlling windows - where upon receiving control, we now
trigger removal of the IME surface if we don't show it.
Additionally:
- Now ensures that any requests from the ImeInsetsSourceConsumer
ensure that they come from the window that is currently served
by IMM.
- Removes the transparancy clause from isImeTargetFromDisplayContentAndImeSame
to match the updated IME target computation in DisplayContent in [1].
[1]: Iedd5f7407926167f4891ce9b7e9a79e22751e668
Fixes: 153145997
Fixes: 150902448
Test: atest WindowInsetsAnimationControllerTests
Test: atest DisplayContentTests InsetsSourceConsumerTest
Test: Open app with IME, press HOME button, verify IME smoothly animates away
Test: Open Messages, open a thread, open IME. Click search icon, verify IME opens in the search activity
Change-Id: I4910c2a06cc67b0470477b245fc1de54b75f10f9
If a requestLayout happens on a child view after the measure
pass, before the layout pass then the child view will not layout.
This can happen if a view calls requestLayout during measure
or during SurfaceView surface destroyed callback.
This fix addresses the second scenario by moving the callback
to after the layout pass.
Bug: 159183008
Test: Repro steps in bug
Test: go/wm-smoke
Change-Id: Ie2794a3751c99cabf6e07445c91159e35eeb1729
The current implementation has a problem where:
In the autofill side, there can be multiple autofill sessions existed
at the same time. But in the IME side, there is always only one
InlineSuggestionSession at any given time. It will cause the previous
autofill session to fail communication with IME.
It would better change to drop down UI when the autofill inline
suggestions don't be shown in IME.
How to reproduce this issue:
To add an input field with autofillable into the authentication activity
of InlineFillService. To tap on the input field of the authentication
activity during the authentication flow. After completing the
authentication, the inline suggestions won't be shown in IME.
BTW, if the input field is marked as non-autofillable, this issue won't
occur.
Manual verification:
1.Tested this patch with InlineFillService and it worked well.
2.Feng also helped to test this patch with the webview
(sort of randomly), and didn't find any broken case
Bug: 158877106
Test: atest CtsInputMethodTestCases
Test: atest CtsAutoFillServiceTestCases
Test: new CTS test Ie1d9055b0eabfcaa00861869467be8dcee25833e
Test: manual verification with InlineFillService
Test: Feng also helped to test this patch with the webview
Change-Id: Ib06edd823fa4478f34362164f3f7dd3544e51705
Add null checks in both ContextWrapper and before obtaining
ContextImpl#getOuterContext.
Test: atest ContextTest#testIsUiContext_ContextWrapper
fixes: 160037462
Change-Id: Ic6a71dd9ac4b195d219d6e5431f2f2b199a400fa
