This is the last step to remove the dependency on IInputMethodClient
from WindowManagerService.
With my previous CL [1], now WindowManagerService (WMS) depends on
IInputMethodClient just because it implements lifecycle management of
IInputMethodClient on behalf of InputMethodManagerService (IMMS).
This CL mechanically moves that responsibility from WMS to IMMS for
better separation of concerns. It is a bit ironic that this CL is
partly undoing my previous CLs [2][3] that removed
IInputMethodManager.addClient() though.
This CL aims to preserve the current observable behavior (e.g. when
InputMethodManager instance is being created) as much as possible.
Most likely there would be no observable behavior difference when seen
from other components.
[1]: I444077b1e4af4033f67ab72c181fac85b601e08a
41f89c3bcc
[2]: I453200fd5847e9a78876affb6a1caec221525e1d
e24ed79edb
[3]: Id91dd600120e4981aa1d9005ce644728968430c9
fffc0e53c6
Fix: 115993358
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I7726c70613ea72d6e78fa5754e9fc840f0a40f11
InputMethodManager#sInstance is a long live static object so we have to
set its field with right value, otherwise any object referenced by it
cannot be gc including potential activity context.
Now InputMethodManager#mCurRootView is set to null in
InputMethodManager#onPreWindowFocus which is invoked when app's
ViewRootImpl received ViewRootImpl#W#windowfocusChanged from WMS.
However, in the ViewRootImpl#W#windowfocusChanged, mViewAncestor is a
weak reference which get() may returns null sometimes.
One scenario is the ViewRootImpl#W#windowfocusChanged is called after
ActivityThread#handleDestroyActivity. The activity is destroyed and its
ViewRootImpl get GC'd. Then InputMethodManager#onPreWindowFocus won't
get called and InputMethodManager#mCurRootView won't be set to null.
And it is a proper time to set InputMethodManager#mCurRootView to null
when the window it served dismissed.
Fix: 116078227
Test: Break at ActivityThread#handleDestroyActivity and ViewRootImpl#W#windowfocusChanged
Change-Id: I8fabb30f14bcb2cd7019e29b6642b4562d49d248
Signed-off-by: daqi <daqi@xiaomi.com>
When taking a full display screenshot, there's no longer a need for min
and max layer. Instead, the entire display will be screenshotted. If
only some layers should be screenshotted, then use the captureLayers method
instead.
Also, condensed the methods so there is only one screenshot method for
displays that returns a GraphicBuffer. SurfaceControl can then convert
it to the desired format, like Bitmap or Surface.
Test: Rotation, adb shell screencap, power + volume down, bugreport.
Change-Id: Ia5a293e89d2cf3811fd06ffcbafeee389a32840e
This is a preparation to allow InputMethodManager to have per-display
instances rather than the current per-process singleton instance.
When I introduced InputMethodPrivilegedOperationsRegistry [1], there
was an assumption that InputMethodManager was a per-process global
singleton object.
Now that we are going to break up that global per-process instance
into multiple per-display instances, having multiple
InputMethodPrivilegedOperationsRegistry instances probably does not
make much sense, because it would likely to increases the risk of
compability issues in existing IMEs. Although IME developers soon
really need to use the right Context to obtain the right instance of
InputMethodManager anyway, unnecessarily introducing compatibility
pitfalls that can be avoided in the Framework side is not my
intention.
With this CL, following 9 methods can continue to work no matter
whether InputMethodManager is a per-process singleton or not.
This is fine because those APIs had been mistakenly exposed in
InputMethodManager and already deprecated in favor of newly added ones
in InputMethodService.
* InputMethodManager.hideSoftInputFromInputMethod
* InputMethodManager.hideStatusIcon
* InputMethodManager.setInputMethod
* InputMethodManager.setInputMethodAndSubtype
* InputMethodManager.shouldOfferSwitchingToNextInputMethod
* InputMethodManager.showSoftInputFromInputMethod
* InputMethodManager.showStatusIcon
* InputMethodManager.switchToLastInputMethod
* InputMethodManager.switchToNextInputMethod
[1]: If762714b2003fa6477e1318110f63e13968c1d7e
eec552e9e9
Bug: 115893206
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I4a61470f06ffac5f7a512536f8431489db0108f4
This is a preparation to deprecate the following two methods.
* InputMethodManager#getInstance()
* InputMethodManager#peekInstance()
Since we soon need to stop relying on the current per-process
InputMethodManager singleton model to fully support multi-display,
those two methods really need to be deprecated.
With this CL, framework code no longer depends on
InputMethodManager#peekInstance(), which is also marked as deprecated
in this CL.
InputMethodManager#getInstance() is a bit tricky because it also works
as a constructor of such a per-process singleton instance. Remaining
two call-sites of this method will be migrated in a subsequent CL.
This is a mechanical refactoring, which in theory should have no
observable logical behavior difference.
There could be a small performance regression, but it is basically not
avoidable to correctly support multi-display scenarios.
Bug: 115891476
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest CtsWidgetTestCases:android.widget.cts.EditTextTest
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Test: atest FrameworksServicesTests:com.android.server.textservices
Change-Id: I5db31491f3d47d3ad4a621e956995135c72e007b
We need to prevent apps from trying to decorate the permission grant
requests. Hence the the permission controller app (which will become a
mainline module) will need to set the
PRIVATE_FLAG_HIDE_NON_SYSTEM_OVERLAY_WINDOWS private window flag.
Test: Built
Bug: 110953302
Change-Id: I7dfed6aac8ec487ac0665ad33c2892cad416224a
The AccessibilityManager is a singleton, so we need to update it everytime
an activity is resumed.
Test: manual verification with Chrome (CTS test is an overkill here)
Test: atest CtsAutoFillServiceTestCases # to make sure it didn't break anything
Fixes: 112690889
Change-Id: If011db203dee96ec511da80f4e49395c0340f482
Based on some analysis, these fields/methods are likely false positives.
Set maxTargetSdk=P so that any apps using them are required to migrate off
them in future. See the bug for more details.
Exempted-From-Owner-Approval: Automatic changes to the codebase
affecting only @UnsupportedAppUsage annotations, themselves added
without requiring owners approval earlier.
Bug: 115609023
Test: m
Change-Id: I719b5c94e5b1f4fa562dd5d655953422958ad37e
Also update the two common implementations using these:
Activity and Dialog.
BUG: 78245676
Test: make
Change-Id: If7b95b73df7dedb12210819d831ba7102344facf
This affects several files beyond those mentioned in the bug.
I didn't fix some instances because the files had code
problems that blocked presubmit checks.
Test: make ds-docs
Bug: 37094741
Change-Id: I642f0384fef2b267ebc970bae1b4fb90bae667e7
Exempt-From-Owner-Approval: Docs-only change
1) Moving WMS.setInputMethodWindowLocked to DisplayContent,
each display can have its own IME window.
2) Add getDisplayIdFromWindow in WindowManagerInternal,
used for InputMethodManagerService to know which display
for given IME window token.
3) Support add / remove IME window according displayId.
4) Modify WMS.inputMethodClientHasFocus to traverse all active display
if inputMethodClient focused.
5) Add displayId parameter for IInputMethod.initializeInternal to
update context display then client can addView to right display.
Note: 1) There should be zero behavior difference as long as the target
app is running on the default display.
2) The current implementation is not final and there are still
chances that the current IME may not work well or even crash
depending on how the IME is implemented.
Bug: 111364446
Test: manual, use ActivityView & launch Messages in VirtualDisplay,
tap search icon to see if soft input keyboard shown &
app window size is adjusted by soft input.
Change-Id: I8da315936caebdc8b2c16cff4e24192c06743251
This property is used to help accessibility services to
improve the typing experience
Bug: 110990026
Test: atest AccessibilityNodeInfoTest
Change-Id: I5295ac8b321e1539df7c83ee7b8b376df5ef8721
The main motivation of this refactoring is to move InputMethodUtils to
com.android.server.inputmethod as a package-private class. With a lot
of cleanup CLs in Bug 77730201, the only remaining utility method that
is used by multiple Java package is this constructLocaleFromString()
method.
This is purely a mechanical refactoring. There should be no
observable behavior difference.
Bug: 114660660
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Change-Id: Ic47b680ad9efde104015d34311f49e224d3fb56f
Also add the annotations to the most common implementation
of Factory2 - Activity.
BUG: 78245676
Test: make
Change-Id: I49f1cf57be240525916a624f215fdff4701f32a5
This reverts commit 16703c4b47.
Reason for revert:
Just realized that this was not the best approach.
We could already make LocaleUtils package-private too before this CL.
So the right approach was moving these methods to new Java class(es)
instead of moving these methods to LocaleUtils.
Bug: 77730201
Bug: 114660660
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Change-Id: I29c87b9692f0f5e8255835579e2fb5270bc6c9c3
With my change [1] in Android N, applications no longer need to
manually call this hidden API even when directly implementing
InputConnection interface without extending BaseInputConnection [2].
So far applications that we have confirmed to be using this hidden API
is Chromium and browsers that are supposed to be built on top of
Chromium source code [3]. Actually my change [1] was per request from
Chromium team and Chromium does not use this hidden API on Android N
and later devices [4].
Moving forward, with this CL applications that target API 29 and later
are no longer allowed to use this hidden API since we see no actual
use case of this hidden API on Android N and later devices so far.
If you have any reason to continue relying on this hidden API, please
leave a comment in Bug 114740982.
[1]: I571d6cc9c6e461d8994aa7496e7e18be13766411
159dd47db3
[2]: This scenario had not been suppored until Android N.
See also other CLs that are tagged with Bug 24688781.
[3]: https://cs.chromium.org/chromium/src/content/public/android/java/src/org/chromium/content/browser/input/InputMethodManagerWrapperImpl.java?rcl=525c72b0f4694d6b3f93bcc7797d0411c2fa683c&l=113-128
[4]: crbug.com/551193
Bug: 114159783
Bug: 114740982
Test: compile
Merged-In: I41d6419438cef92cce81cc33d9db00dd2ee89d33
Change-Id: Iac81f49413605271fccc0b8aec3e6ed95925f061
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
d7443c83ce
[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
With my change [1] in Android N, applications no longer need to
manually call this hidden API even when directly implementing
InputConnection interface without extending BaseInputConnection [2].
So far applications that we have confirmed to be using this hidden API
is Chromium and browsers that are supposed to be built on top of
Chromium source code [3]. Actually my change [1] was per request from
Chromium team and Chromium does not use this hidden API on Android N
and later devices [4].
Moving forward, with this CL applications that target API 29 and later
are no longer allowed to use this hidden API since we see no actual
use case of this hidden API on Android N and later devices so far.
If you have any reason to continue relying on this hidden API, please
leave a comment in Bug 114740982.
[1]: I571d6cc9c6e461d8994aa7496e7e18be13766411
159dd47db3
[2]: This scenario had not been suppored until Android N.
See also other CLs that are tagged with Bug 24688781.
[3]: https://cs.chromium.org/chromium/src/content/public/android/java/src/org/chromium/content/browser/input/InputMethodManagerWrapperImpl.java?rcl=525c72b0f4694d6b3f93bcc7797d0411c2fa683c&l=113-128
[4]: crbug.com/551193
Bug: 114159783
Bug: 114740982
Test: compile
Change-Id: I41d6419438cef92cce81cc33d9db00dd2ee89d33
This change is need when integrating CustomDescription artifacts (like
CharSequenceTransformation) with SaveInfo.FLAG_DELAY_SAVE, as different
views might have the same autofill id on different activities.
Test: atest CtsAutoFillServiceTestCases:MultiScreenLoginTest
Test: atest CtsAutoFillServiceTestCases # to make sure it didn't break anything
Fixes: 113593220
Change-Id: I7db1df7a56dec7180a2172bb2022b042f115c7b8
