Use explicit FloatProperty proxies for routing ObjectAnimator updates.
This prevents issues with Proguard-related shrinking/optimization for
custom class types.
Test: atest SystemUITests + manual validation of error logs
Bug: 203472868
Change-Id: Ie0889101f1063a929d2052756b1f4008f2b84a92
In order to propagate the information about whether the IME is using
light navigation bar or not from
android.view.ViewRootImpl
to
android.inputmethodservice.NavigationBarController
within the same process, this CL adds a new @hide method to
Window.Callback
as follows.
ViewRootImpl#performTraversals()
-> DecorView#onSystemBarAppearanceChanged()
-> Window.Callback#onSystemBarAppearanceChanged()
-> SoftInputWindow#onSystemBarAppearanceChanged()
-> NavigationBarController#onSystemBarAppearanceChanged()
Button color transition will be implemented in a subsequent CL.
Bug: 215549533
Test: Manually tested with ThemedNavBarKeyboard sample
1. Build aosp_coral-userdebug and flash it
2. adb root
3. adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons true
4. adb reboot
5. make -j ThemedNavBarKeyboard
6. adb install -r \
$OUT/system/app/ThemedNavBarKeyboard/ThemedNavBarKeyboard.apk
7. adb shell ime enable \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
8. adb shell ime set \
com.example.android.themednavbarkeyboard/.ThemedNavBarKeyboard
9. Open the Dialer app
10. Focus in the top edit field.
11. Tap "EXTENDED LIGHT NAVIGARION BAR" mode
12. Make sure that the navigation button color is optimized for light
navigation bar.
13. Tap "STANDARD LIGHT NAVIGARION BAR" mode
14. Make sure that the navigation button color is optimized for light
navigation bar.
Change-Id: I08566034bebfafff6777ce0152cd6ca1f66f6cad
InputMethodService uses the following IDs for extract view.
- R.id.inputExtractEditText
- R.id.inputExtractAction
- R.id.inputExtractAccessories
While the first one is public, others are not. It makes sense to make
all of the public so IMEs can customize it.
Bug: 210777608
Test: atest InputMethodServiceTest
Change-Id: I125767d67839293c0b0f40c750d0fb1bb77951e9
This is a mechanical refactoring CL so that we can avoid code
duplicate later.
Bug: 215550296
Test: Manually verified that there is no behavior change
Change-Id: I14d2c7609e156b9e627b26471d392cb47b14163b
With this CL, nav buttons rendered by InputMethodService can be
dynamically enabled or disabled when the gesture navigation mode is
updated.
Note that the feature is still disabled by default behind the flag.
Hence there should be no observable behavior changes unless the
feature is explicitly enabled with setprop.
Fix: 215552600
Test: Manually done as follows
1. Build aosp_coral-userdebug and flash it
2. adb root
3. adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons true
4. adb reboot
5. Tap any edit field to show AOSP Keyboard.
6. adb shell dumpsys input_method | grep mNavigationBarController
-> Confirm mRenderGesturalNavButtons is false.
-> Confirm mNavigationBarFrame is null.
7. Switch to gestural navigation mode.
8. adb shell dumpsys input_method | grep mNavigationBarController
-> Confirm mRenderGesturalNavButtons is true.
-> Confirm mNavigationBarFrame is not null.
9. Switch to 3-button navigation mode again.
10. adb shell dumpsys input_method | grep mNavigationBarController
-> Confirm mRenderGesturalNavButtons is false.
-> Confirm mNavigationBarFrame is null.
Change-Id: Id0cfa44cce5de515dc5d28254e1d41bdfc01e201
Seems that IInputMethod#revokeSession has been defined but has never
been called since at least Android 1.5.
Let's remove it for now for simplicity.
Bug: 192412909
Test: presubmit
Change-Id: I3de8de1226ae028ac2e6bae8aeb34cd83f4c4f41
This is the minimum implementation of rendering the back button and
the IME switcher button in the InputMethodService process.
Note that the feature is still disabled by default behind the flag.
Newly added UI logic should be running only when the feature flag is
enabled.
Bug 215545985: Enable canImeRenderGesturalNavButtons() by default
Here is the list of known blockers before enabling the flag.
* Bug 215552600: Subscribe gesture mode change.
* Bug 215551357: Show IME swicher button only when necessary.
* Bug 215549533: Support light navigation bar.
* Bug 215550296: Support floating IME.
* Bug 215554582: Set "input_method_rounded_corner_content_padding"
for each devices.
Also, after enabling the flag by default, we start cleaning up newly
added code under
android.inputmethodservice.navigationbar.
at Bug 215443343.
Bug: 205803355
Test: Manually done as follows
1. Build aosp_coral-userdebug and flash it
2. Switch to gestural navigation mode.
3. adb root
4. adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons true
5. adb reboot
6. Tap any edit field to show AOSP Keyboard.
7. Confirm that the back button on the navbar works.
8. Confirm that the IME switcher button on the navbar works.
Change-Id: I3e7e1f83554444131e2765dc159617bb9e2337c7
Now InputMethodService has been migrated to WindowProviderService.
We don't need to override isUiContext anymore.
Bug: 193247900
Test: presubmit
Change-Id: I1cb0f04aca02d0d2c623995666ce5315125a0b4a
IMS might throw IllegalStateException in
WindowContextController#attachToWindowToken when #initializeInternal
is called. A possible root cause may be #initializeInternal is called
after onDestroy, which detach IMS from ImeContainer.
This CL add a flag in #onDestroy to prevent #initializeInternal from
being called after #onDestroy.
Bug: 211062619
Test: presubmit
Change-Id: Ie7814da801878a3487123fefdc9e71d0e1ed28d7
This CL introduces a new runtime mode where the SysUI no longer
renders the back button and the IME switcher button when the IME is
shown, which is the first milestone to move those buttons to the IME
process.
To enable this mode, run the following commands:
$ adb root
$ adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons true
$ adb reboot
Keep in mind that you always need to reboot the device after changing
this sysprop.
Note that only AOSP-based gestural navigation mode is officially
supported by this flag, which is when
com.android.internal.R.integer.config_navBarInteractionMode
is set to
WindowManagerPolicyConstants#NAV_BAR_MODE_GESTURAL.
Note that nav button rendering in the IME process is yet to be done in
subsequent CLs. Hence the expected behavior right now is only one
thing that the SysUI stops rendering the back button and the IME
switcher button any more when the flag takes effect.
The flag is treated as off by default. Hence there should be no
visible behavior changes unless you manually enable it.
Alternatives Considered:
Instead of letting NavigationBarView directly read the sysprop, we
could propagate the information from the InputMethodService to the
SysUI via InputMethodPrivilegedOperations#setImeWindowStatusAsync().
This approach was abandoned because of the following reasons.
* Such a complex mechanism is not necessary for production code.
* There are some ad-hoc invocations of
IMMS#updateSystemUiLocked(0, mBackDisposition),
which makes it difficult to keep IMS and SysUI in sync.
Bug: 205803355
Test: Manually done as follows
1. Build aosp_coral-userdebug and flash it
2. Tap any edit field to show AOSP Keyboard.
3. Confirm that nav buttons are rendered in 3-button nav mode
4. Switch to gestural navigation mode.
5. Confirm that nav buttons are still shown when IME is visible.
6. adb root
7. adb shell setprop \
persist.sys.ime.can_render_gestural_nav_buttons true
8. adb reboot
9. Tap any edit field to show AOSP Keyboard.
10. Confirm that nav buttons are not shown when IME is visible.
11. Switch to 3-button navigation mode.
12. Tap any edit field to show AOSP Keyboard.
13. Confirm that nav buttons are shown again when IME is visible.
14. Switch to gestural navigation mode again.
15. Confirm that nav buttons are not shown when IME is visible.
Change-Id: I7a2e9f08072a97d61b78dddb144282a5728d1407
Introduce InputMethodManager.startStylusHandwriting(View) API
and IME lifecycle.
Bug: 203086136
Test: atest StylusHandwritingTest
Change-Id: I7b066c2841b713e7a00ae2ea4ca0ce04aad751c6
This is a follow up CL to my previous CL [1], which made it clear that
the following 4 tracing fields in SoftInputWindowProto had always been
logged with the same values.
- name: "InputMethod"
- window_type: WindowManager.LayoutParams.TYPE_INPUT_METHOD
- gravity: Gravity.BOTTOM
- takes_focus: false
This CL simply deprecates those fields in favor of simplicity and
smaller code size.
There should be no behavior change unless IME tracing is enabled.
[1]: I619ae6011f5e66dba126931719569a97513eaa7e
ea7801bd26
Bug: 192412909
Test: IME tracing still works
Change-Id: I04b59307ecf2c692282c7882ac839f77c94b938f
This CL merges
SoftInputWindow#initDockWindow()
into
InputMethodService#onCreate()
so that we can see what parameters are set to the IME window at a
glance, rather than having to check 2 different files.
The end result is expected to be the same, and in theory there should
be no observable behavior change.
If you are reading this commit message to look for why those
parameters have been set, here are some quick links to relevant CLs.
* `FLAG_DRAWS_SYSTEM_BAR_BACKGROUNDS`
- DecorView#mNavigationGuard is gone [1]
* `window.setDecorFitsSystemWindows(false)`
- Updated InputMethodService to not inset by navigation bar if
requested by automotive. [2]
- Smooth out IME animation for automotive devices [3]
* `setFitInsetsTypes(statusBars() | navigationBars())`
- Do let IME fit invisible insets [4]
* `setFitInsetsSides(Side.all() & ~Side.BOTTOM)`
- Make IME fit navgation bars at left and right sides [5]
* `receiveInsetsIgnoringZOrder = true`
- Let IME receive insets ignoring z-order [6]
[1]: I664630099b6eb3fe31675444ba94944cb0eb98b0
8f162c6e84
[2]: I4faf82bdd7536bd2d049ded04034a9635d8ca0d3
7eec316f54
[3]: I5d7b03d5c829a2679efdd06fa961d1158494e08f
b0d0d7c46a
[4]: I6e7d665c55839dfbb14c8d2e5365537416f5f6c6
145f71182a
[5]: I0ef3d6379a9ae52b3749154d2fdc54e9aa94a9e0
c8364e3878
[6]: I53c64a5598f246ad577f652156903e4666a30cd9
ea491da863
Bug: 192412909
Test: presubmit
Change-Id: If0f2bac45e6752612cc11e57d2fac55626221bd1
Now that SoftInputWindow is used only by InputMethodService [1], we
can safely simplify SoftInputWindow.
This is still mechanical refactoring. There should be no observable
behavior change.
[1]: 5ed8dae6bc9cca87d5f35e781f173477a2388c2e
Bug: 192412909
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/android/inputmethodservice/SoftInputWindow.java
Change-Id: I619ae6011f5e66dba126931719569a97513eaa7e
This is a mechanical refactoring CL as a preparation to remove the
dependency on
android.inputmethodservice.SoftInputWindow
from
android.service.voice.VoiceInteractionSession.
Before creating a copy of SoftInputWindow for VoiceInteractionSession,
this CL aims to clean up lint errors and style nits as many as
possible, notably:
* Addressing lint errors
* Adding missing @Override
* Making SoftInputWindow a final class
* Making internal member fields private
* Removing SoftInputWindow#{get,set}Gravity(), which are no longer used
* Renaming SoftInputWindowState to WindowState
There should be no observable behavior change in this CL.
Bug: 192412909
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/android/inputmethodservice/SoftInputWindow.java
Change-Id: I547489d3946bf523a59ada80f63cfd934e70c1f4
The flicker happens when the app in landscape mode with focusing the
search editor without enabling full-screen editText, after typing something
and pressing search button, the app quickly clears the editor focus then
makes the main activity focused and starts the fallback connection to
enable the fullscreen mode, so that the extracted view been inflated and
occcupied in mFullscreenArea,
Even though the full-screen mode changed to false during hiding the
keyboard, in updateExtractFrameVisibility() still makes mFullscreenArea
visible and flicker until the keyboard is hidden.
As the mFullscreenArea contains 2 frames: ExtractFrame & CandidateFrame,
Since ExtractFrame is used when enabling the full-screen editor mode,
for non-full-screen mode, we can rely on the candidate frame visiblity
to see if mFullscreenArea has to set visible, in case flicker happening
by unnecessary visible setting.
Fix: 211085869
Test: manual as steps:
1). Set device dark theme is on.
2). Open Messages on Landscape mode > Split screen.
3). Tap Search box > input something.
4). Tap Search icon on keyboard.
5). Expect no flicker happens when hiding the keyboard after 4).
Change-Id: I0d50ae68016993329e8bb84b90ec835445f3db31
IME_VISIBLE isn't set until the keyboard is "perceptibly" visible to the user (e.g. based on alpha). But we want to signal to taskbar as soon as we know IME will be visible.
Test: tap an edit field to open keyboard, ensure taskbar reacts immediately instead of halfway through the transition
Bug: 202511986
Change-Id: I39c15578ed3e5b729f4645ad76988b113f0b57a6
Historically TextView#setText() has internally called
InputMethodManager#restartInput(View)
simply because the text seen from the IME is going to be out-of-sync.
Although this behavior is semantically helpful for IMEs, especially
after the initial surrounding text information became available in
EditorInfo, issuing a sync IPC from the calling thread (UI thread
actually) is not plausible from the performance perspective.
This CL fills this gap by adding a new API
InputMethodManager#invalidateInput(View)
for the scenario where apps independently modify the text with keeping
other text metadata such as input-type to be the same.
All the observable behaviors from the IME remain to be the same as
InputMethodManager#restartInput(View).
For instance, any pending tasks that are already issued with
InputMethodService#getCurrentInputConnection()
will be effectively cancelled by using a recently added mechanism [1].
[1]: I383c3958d2ac1a8d217706509fa12a92b381bbb3
Fix: 203086369
Test: atest -c CtsInputMethodTestCases:InputMethodStartInputLifecycleTest
Change-Id: I3161755779080f98bcef0e47dd0c5247d8a3a256
Add the TextAttribute class and variant of setComposingText(),
setComposingRegion(), commitText() to support IME to take extra
information to editor.
Bug: 198732184
Test: atest CtsInputMethodTestCases:InputConnectionEndToEndTest CtsInputMethodTestCases:TextAttributeTest
Change-Id: Ic9c917b70726ca32c2097b0374951c20af9624c4
Originated from CL[1] to fix a crash edge case that happened when
calling InputMethodPrivilegedOperationsRegistry#put that assumes there
is only one pair of window token and IInputMethodPrivilegedOperations
in the container.
However, InputMethodPrivilegedOperationsRegistry is a process-level
singleton instances that may run into a timing when there are 2
InputMethodService (IMS) instances, one is just created and the other
is in the way of destorying.
Before the destorying one calls
InputMethodPrivilegedOperationsRegistry#remove, IMS#initializeInternal
invoked for the new one with the same window token, that makes system
ignored the initialization process because CL[1] introduced
InputMethodPrivilegedOperationsRegistry#isRegistered(token) and system
thoughts the token has been registered before, but actually this method
is problemetic to aware this token registraction is for previous IMS.
As the result, IME will crash when SoftInputWindow.show because the
windowState is still under TOKEN_PENDING and lose the token attachment.
To fix this crash timing issue, making
InputMethodPrivilegedOperationsRegistry be able to maintain more than
one pairs of IME token and IInputMethodPrivilegedOperations makes more
sense and we can remove the ignore logic in initializeInternal to
fix the token attachment issue.
[1]: Ie6bfbae735724fe744590e715124d2737d2b665d
Fix: 202081442
Test: atest CtsInputMethodTestCases
Test: atest MultiDisplaySystemDecorationTests
Change-Id: I21cec3f228520ed703cd8ad68ea0ef59c966ed9d
Binder tracing can be very expensive. In dogfood builds its triggered
time to time and it should only be called manually when needed.
Fix: 202721321
Test: atest CtsInputMethodtestCases
tested with winscope trace.
Change-Id: I0a4ee1b90e56ed1b20e44b5a0b42c17d565d05dd
This is a follow up CL to my recent CL [1], which aimed to consolidate
dependencies on InputMethodService from RemoteInputConnection.
One thing I overlooked was that InputMethodService did not retain a
strong reference to InputMethodServiceInternal object that I
introduced there, which means that the newly instantiated
InputMethodServiceInternal could be garbage-collected even before
InputMethodService became unreachable.
As a result, the following InputConnection APIs could start failing at
some point and would never work without restarting the IME, which is
likely to be the root cause of the recent flakiness in
InputConnectionEndToEndTest discussed in Bug 193822485.
* InputConnection#requestCursorUpdates()
* InputConnection#commitContent()
Also, the following functionality might have stopped working at some
point.
* InputMethodService#dump()
* InputConnection tracing in IME tracing
* Updating IME switching order based on user inputs
With this CL, the InputMethodServiceInternal instance is guaranteed to
be instantiated once and remain to be alive until
AbstractInputMethodService becomes unreachable.
[1]: I2aeeeacd27195ce10059d6590e098a4a969e774d
a975bfc447
Fix: 193822485
Fix: 199288389
Test: atest CtsInputMethodTestCases
Test: Manually verified with Imege Keyboard sample IME/app
Change-Id: I7ee0270bad94ed606048bfaf76e8545336715d83
We concluded that the behavior of sendDefaultEditorAction should be kept
for compatibility. To compensate that, we should update the javadoc to
reflect the current behavior.
Test: None
Bug: 28898996
Change-Id: Idcb2b7180f9e22818ab819715fe2723a05b4894a
This is a follow up CL to our previous CL [1], which introduced
early-exit paths to some RemoteInputConnection methods to protect
innocent IME clients from unexpected process crashes when an IME is
calling InputConnection APIs with invalid parameters.
Although protecting IME clients from crashes still makes much sense,
implementing it as an early-exit style in RemoteInputConnection may
expose observable inconsistency to IME developers in terms of the fact
that InputConnection#getText{Before,After}Cursor() can also work as a
fence operation that would not return until all the previously issued
InputConnection API invocations are handled in the IME client side.
With this CL, the following methods start behaving as a fence
operation even when an invalid parameter is passed, by checking the
parameters in the IME client side.
* RemoteInputConnection#getTextAfterCursor()
* RemoteInputConnection#getTextBeforeCursor()
* RemoteInputConnection#getSurroundingText()
There should be no performance impact for IMEs that do not make such
an invalid (and unnecessary) API calls.
[1]: I95169735198f8363c981a61e20234dfebfd645b1
1e72ef2893
Bug: 169114026
Fix: 194110780
Test: atest CtsInputMethodTestCases:InputConnectionEndToEndTest
Change-Id: Ie0c18d0c9b8bf8f02f2fcdca5aac7e580c6bf2cd
This CL effectively replaces my previous CL [1], which made
unimplemented methods in InputConnection not fatal errors, with a
simplified implementation that still gracefully take care of
unimplemented methods without causing app crashes.
Instead of propagating missing method information from the IME client
to the IME process, this CL will simply catch AbstractMethodError in
the IME client process. Doing so enables us to
1. preserve the strict invocation order of InputConnection APIs, and
2. achieve the same goal with fewer lines of code.
The additional cost of throwing (and catching) AbstractMethodError
every time the IME calls an unimplemented InputConnection API can be
justified as it is really an exceptional scenario, and avoiding it
would require extra maintenance cost as seen in
InputConnectionInspector.
The above overhead (and complexity) due to AbstractMethodError can be
avoided by adding default implementations to those InputConnection
APIs, but doing so requires API signature update hence API council
approval to go ahead, which is to be discussed in Bug 199934664.
[1]: I3c58fadd924fad72cb984f0c23d3099fd0295c64
19a80a1e80
Bug: 27407234
Bug: 27642734
Bug: 27650039
Bug: 194110780
Test: atest CtsInputMethodTestCases
Change-Id: I9e801e92496a6e16cee37664870c97ed096f1413
This is a follow up CL to our previous CL [1], which introduced a
nested SomeArgs to pass more integer parameters while handling
IInputMethod#startInput() callback.
Now that only 2 integers and 4 objects are required to handle
IInputMethod#startInput(), single SomeArgs should be good enough to
pack everything into a Message object.
This CL does nothing other than applying such a mechanical code clean
up. There should be no observable behavior difference.
[1]: I1a6300fe167eb205ee2b4214a6e270a52ebae062
eadb1392f8
Bug: 192412909
Bug: 194110780
Test: presubmit
Change-Id: I90eff3bfc5ed0f43472b0cd49aa532474a60c266
This is a follow up CL to my previous CL [1], which used
MissingMethodFlags mechanism [2] to let that API fail when the IME and
the target app are not running on the same display.
As discussed in Bug 194110780, however, there is a problem in the
MissingMethodFlags mechanism that it could have caused unexpected task
reordarings from the IME developer when sync InputConnection APIs
immediatelly fail without waiting for those tasks to be scheduled to
the target app then handled.
As a preparation to fully deprecate MissingMethodFlags, this CL
enables InputMethodManagerService to stop lying about
MissingMethodFlags.REQUEST_CURSOR_UPDATES
when the IME is rendered on a diffirent display than the target app.
Such check is now explicitly implemented in
RemoteInputConnectionImpl.
Other than that, there is no observable behavior change.
[1]: Ie2f7a5117cff3a13ad5c5806fd4b3abef7569549
3d2cc0fffd
[2]: I3c58fadd924fad72cb984f0c23d3099fd0295c64
19a80a1e80
Bug: 131368625
Bug: 194110780
Test: atest CtsInputMethodTestCases
Test: atest MultiDisplaySystemDecorationTests#testCrossDisplayBasicImeOperations
Change-Id: Iec12733d37e112b7271436bba15094ae2a55a450
This CL consolidates weak-ref handlings in RemoteInputConnection so
that IME developers can find more useful messages in logcat when they
are using RemoteInputConnection after InputMethodService#onDestroy().
RemoteInputConnection has been designed to not hold a strong reference
to its parent InputMethodService instance.
While IME developers can manually keep a strong reference to
(Remote)InputConnection object that they obtained from
InputMethodService#getCurrentInputConnection(), doing so does not
prevent the system from garbage-collecting InputMethodService
instance.
With this CL, an error message will be shown in logcat if somehow
RemoteInputConnection object is still touched after InputMethodService
is destroyed, which hopefully can help IME developers realize they
might be doing something unexpected.
Other than showing error messages in logcat, there is no behavior
change in this CL.
Bug: 192412909
Bug: 194110780
Test: atest CtsInputMethodTestCases
Change-Id: I514630d27c8953f62fdb34cd3133a662b3fbbf76
This CL converts our inhouse Completable class with CompletableFuture.
One of downsides of switching into CompletableFuture is performance.
It creates much more objects, especially in unsuccessful cases
including timeout scenarios:
* CompletableFuture#cancel() always creates a CancellationException
object with full stack trace. This is going to be problematic when
we start cancelling pending InputConnection tasks in Bug 195115071
from the IME client side.
* Timeout cases always creates a TimeoutException object with a full
stack trace.
* Exception cases always creates a ExecutionException object with
full stack trace.
Also, none of its getter methods directly fits our existing use cases
in the input method framework world. We must always use
CompletableFutureUtil to retrieve the result value so as not to
accidentally break existing APIs.
Other than above, there should be no observable semantic behavior
changes in this CL.
Bug: 192412909
Bug: 195699814
Test: presubmit
Test: atest -c FrameworksCoreTests:CompletableFutureUtilTest
Change-Id: I215bbc870f952effa262fa431064b36ace28e8f4
