| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
Now InputMethodService has been migrated to WindowProviderService.
We don't need to override isUiContext anymore.
Bug: 193247900
Test: presubmit
Change-Id: I1cb0f04aca02d0d2c623995666ce5315125a0b4a
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
a975bfc447b04fe90a5ec9c3d4757810f7d07af1
Fix: 193822485
Fix: 199288389
Test: atest CtsInputMethodTestCases
Test: Manually verified with Imege Keyboard sample IME/app
Change-Id: I7ee0270bad94ed606048bfaf76e8545336715d83
|
| |\
| |
| |
| |
| |
| |
| |
| | |
cc2f80f5a0 am: ddfa753ff0
Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/15125751
Change-Id: I3e6c55f06e97c0a5e72cac7b181db4d0e2d0e624
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before WindowProviderService, Service can add windows with several
window types. This is previously not allowed for WindowProviderService
because a context can only associate with a window container.
However, it may cause regressions because Service is used to add
windows with multiple types.
This CL allows WindowProviderService to do so, but WindowProviderService
can only associate with the window type returned by #getWindowType.
This CL also extracts some methods to WindowContext interface so that
WindowContext and WindowProviderService can reuse the same interface.
Test: atest WindowContextPolicyTests StrictModeTest
Test: atest ContextIsUiContextTest ContextGetDisplayTest
Test: atest WindowContextTest WindowContextTests
fixes: 191959013
Change-Id: Ie16916b370a4cbb8a17ccaec9870d47b4b089390
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is a mechanical refactoring CL that has no behavior change.
This CL removes the direct dependency on AbstractInputMethodService
from whenever possible. As a result, the following classes no longer
directly depend on AbstractInputMethodService.
* android.inputmethodservice.IInputMethodWrapper
* android.inputmethodservice.RemoteInputConnection
* com.android.internal.inputmethod.ImeTracing
* com.android.internal.inputmethod.ImeTracingClientImpl
* com.android.internal.inputmethod.ImeTracingServerImpl
This is still a purely mechanical refactoring. There should be no
observable behavior change.
Bug: 192412909
Test: atest CtsInputMethodTestCases
Test: Manually verified that IME tracing still works
Change-Id: I2aeeeacd27195ce10059d6590e098a4a969e774d
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a mechanical refactoring CL that has no behavior change.
Currently all the utility methods defined in
InputConnectionProtoDumper return ProtoOutputStream, while the
returned instances will always be converted into byte[] eventually.
With this CL, those utility methods return byte[] instances directly,
which is expected to make it easier for ART/dexpreopt to do more
optimizations such as code inlining because instances of
ProtoOutputStream will no longer be escaped from those methods.
Bug: 192412909
Test: atest CtsInputMethodTestCases
Test: Manually verified that IME tracing still works
Change-Id: I7b24aee5428da312972aa86b8658429b421490f8
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also introduce IWindowManager#getDisplayIdToLaunchIme to make IMS
be aware of the launched display to prevent extra onConfigurationChanged
callback
Bug: 149463653
Test: atest MultiDisplaySystemDecorationTests CtsInputMethodTestCases
Test: atest ContextTest ContextIsUiContextTest
Test: manual - moving IME between 2 displays and displayArea within
display - config change received
Test: manual - the app to show IME crashed and focus is set to the
next task - no config change
Change-Id: Ie565e30ed5dd3f2cfe27355a6dded76dc3adc14b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change dumps information through IME tracing for the getter methods
exposed by the InputConnection interface. The dump is done through the
ImeTracing interface and is triggered by events in the wrapper classes
used to handle InputConnection implementations corresponding to:
- different apps
- InputMethodService
The new data is available under inputConnectionCall in the clients
output proto.
Bug: 154348613
Test: flash a device
start IME tracing by calling "adb shell ime tracing start"
end IME tracing by calling "adb shell ime tracing stop"
pull generated trace files and visualize in Winscope
or start tracing directly through ADB Connect and visualize traces
Change-Id: Iabd6af1b858803030848a0ef5e7dd9ecfc562716
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Optimized the tracing logic for the IMS information. The
InputMethodService triggers a tracing dump through the new method
triggerServiceDump, exposed by the meTracing interface. This
change was done to be able to support custom dumps from clients
and custom dumps from InputMethodService.
This change only covers the IMS information. The IMMS
information will be dumped in next changes.
Bug: 154348613
Test: start IME tracing by calling "adb shell ime tracing start"
end IME tracing by calling "adb shell ime tracing stop"
pull trace using "adb pull /data/misc/wmtrace/ime_trace_service.pb ime_trace_service.pb"
Change-Id: Icda0f82d76fb7db5b2bd8d021069b1ff15a4e15b
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Having a hidden abstract method for a class that can be extended
means that public implementors cannot implement these hidden methods
posing a risk that custom implementations will not have required
abstract methods resulting in an exception.
Bug: 151134792
Test: make update-api
Change-Id: I758d12465fabc671be19bedeeceb16885de23c87
Exempt-From-Owner-Approval: large scale suppression of existing issues,
no-op in terms of behavior
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL implements a mechanism to dump InputMethodService and IME
related server states into a proto file which can later be imported
to Winscope to allow easy debugging.
The Design Doc for the IME tracing project is: go/ime-tracing
Bug: 154348613
Test: start trace by calling "adb shell ime tracing start"
end trace by calling "adb shell ime tracing stop"
pull trace using "adb pull /data/misc/wmtrace/ime_trace.pb ime_trace.pb"
Change-Id: Icbfb8c11e882f29eb45dea9d4c23315c48e9d619
|
| |
|
|
|
|
|
|
|
|
| |
IMS handles configuration and display changes from the server side
and render views to inteact with users. Thus IMS should be marked as
an UI context
fixes: 157027563
Test: atest ContextTest
Change-Id: I0a2307c4764acf8b9fc0254a9ee2fc8a344bb7ef
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL re-implements the way to propagate user action on an IME to
InputMethodManagerService (IMMS) so that we can dynamically update IME
Subtype rotation list discussed as requested in Bug 7043015.
It turns out that my previous CLs [1][2][3][4] are unnecessarily
complex because I tried to monitor user behavior in the IME client
process rather than in the IME process. In the end, I ended up
introducing a sequence number protocol for the sake of performance
with a ton of complexity.
This could have been implemented in a much safer and simpler way by
sending user action signals from the IME process to IMMS, because
A. IME already knows when it switches to a new subtype. IME needs to
send a signal only once per subtype change. There is no need to
use sequence counter.
B. Malicious IME client is unable to disturb IME rotation list by
sending a fake signal because the IPC endpoint is no longer exposed
to IME client processes.
In case there remain some applitations that still call this hidden API
via reflection without gracefully handling exceptions, this CL keeps
InputMethodManager.notifyUserAction() as a stub method so as not to
break such applications.
[1]: I11ed9a767588f8080753cd9bce011dac7db579ad
d7443c83ceae0bdd20d68bf84648cf3b40115d85
[2]: I7f3e13a7226ef0dceee82b67e8a0d8536f7e9807
2a6a8d2fbb063c84e388c185402c4ca788618c72
[3]: I19ad8542659bc092b92ee13eb9f1d68ddd4b815a
b56c6c721fc01fba8e36632d8e28f5123831abc5
[4]: I03fa436df0a5e348b3f93170aab3a8ac5a7e1677
c21ccc151631663d71230a3c1c756d94b575ab9e
Bug: 113177698
Fix: 114159783
Test: Manually verified as follows
1. Build and flush aosp_taimen-userdebug
2. make -j SoftKeyboard
3. adb install -r $OUT/system/app/SoftKeyboard/SoftKeyboard.apk
4. adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
5. Open AOSP Keyboard settings
6. Enable "English (US)", "French", and "German"
7. Open SoftKeyboard settings
8. Enable "English (United States)", "English (GB)"
9. Open the Dialer app and tap the top edit field.
10. Make sure that the IME layout rotation order when tapping the
globe key will be updated only when you tap the keyboard to enter
some character.
11. Also confirm it with "adb shell dumpsys input_method" by checking
"mSwitchingController:" section there.
Change-Id: Icc1f9c7f530f0144ecfd460e86114e109ae0044e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a preparation to work on Bug 36897707.
For instance, the reason why most of IME-related callbacks in
InputMethodService get called on the main thread is because
IInputMethodWrapper keeps forwarding incoming IPCs into the
main looper of the IME process as follows:
InputMethodManagerService (IMMS)
------
-> one-way binder IPCs over IInputMethod
------
-> IInputMethodWrapper (on the binder thread(s))
-> Handler (to dispatch tasks to main thread)
-> InputMethodImpl.* (on the main thread)
-> InputMethodService.* (on the main thread)
By adding explicit annotations such as @BinderThread and @MainThread
in relevant methods, this CL makes that kind of investigation much
easier than before.
Bug: 36897707
Test: compile
Change-Id: I8f9afe9a1986a9fa41fb66fdc64e8f0f67e45c2e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that we can let the system to call
InputMethodService#exposeContent(InputContentInfo, EditorInfo), which
added in my previous CL [1], during the IME is calling
InputConnection#commitContent() as follows.
[IME]
InputContentInfo contentInfo = new InputContentInfo(
contentUri,
new ClipDescription(description, new String[]{mimeType}),
linkUrl);
getCurrentInputConnection().commitContent(
inputContentInfo,
InputConnection.INPUT_CONTENT_GRANT_READ_URI_PERMISSION,
null);
[App]
try {
contentInfo.requestPermission();
// Load inputContentInfo.getContentUri() here.
} finally {
contentInfo.releasePermission();
}
This gives us flexibility to let InputConnection#commitContent() do all
the magic for IME developers like other APIs such as
Context#startActivity(), rather than asking them to call one more API to
grant a temporary URI permission like a scenario where
Context#grantUriPermission() is used.
[1]: I2772889ca01f2ecb2cdeed4e04a9319bdf7bc5a6
25e0813e6eb6315b1016db805fa9b791b4ae5cc2
Bug: 29450031
Change-Id: I99536cd58c9984af30b0bafb4a1dd25a26634a2d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The input method manager service now supplies an input channel for
communication while creating an IME session on behalf of the
application.
This change significanly reduces the overhead of IME event dispatch
by using a standard input channel to send input events rather than
using binder. This results in fewer thread context switches
and fewer object allocations.
What's more, the IME may perform additional batching of the motion
events that it receives which may help it catch up if it is
getting behind while processing them.
Bug: 7984576
Bug: 8473020
Change-Id: Ibe26311edd0060cdcae80194f1753482e635786f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Trackball and generic motion events now pass through the IME in case
it would like to handle them before passing them on to the view
hierarchy.
While I was at it, I also...
...fixed the documentation on InputMethodService.onKeyUp()
...added documentation to InputMethodService.onTrackballEvent()
...added trackball and generic motion events to the "input" command
...fixed input consistency verification involving ACTION_OUTSIDE
Bug: 7050005
Change-Id: I40ab68df4a9542af6df25de6ec2ec500e4c02902
|
| |
|
|
|
|
|
|
|
|
|
| |
- added showInputMethodSubtypePicker to public API
-- show the selector dialog for subtypes
- added getter, setter and event handler to InputMethodManagerService
- extract InputMethodSubtype to the top level class for using it in aidl
- TODO: make an enabler for input method subtypes
- TODO: handle the event of changing an input method subtype in LatinIME
Change-Id: I49f8c6675ac4b06511635d14a37bd398738eff33
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This takes care of allowing us to cancel the back button. The
back button is a bear because it is strewn all over the place --
everywhere you can close something, there is some code looking
for the back button that now needs to deal with being canceled.
The main things changed are activity (of course), dialog,
input method, search dialog. There are some other misc places
in the framework (and some I missed here that I will get in a
second pass).
To facility all of this, the key dispatching APIs now provide
a lot more support for dealing with looking for cancelled keys,
and incidentally also provide an actual API for catching long
key presses. This also helped clean up the code in PhoneWindow
where it deals with all of the combinations of key pressed and
releases. (And also allows people to override
Activity.onKeyLongPress() to provide a different long press
action for a standard key like search.)
And while I was doing this, I reworked how we detect long
presses by having this be part of the key event delivered by
the window manager. This should greatly reduce (hopefully
outright eliminate) the problems with long presses being
mis-detected when an application is being slow.
Change-Id: Ia19066b8d588d573df3eee6d96e1c90fdc19f57d
|
| | |
|
| | |
|
| | |
|
| |
|
