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
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
In Bug 77730201, we cleaned up a bunch of files so that only modules
inside framework/base depend on InputMethodUtils. This CL is a
preparation of a further hardening.
Just by moving two utility methods from InputMethodUtils to
LocaleUtils, InputMethodUtils is used only from
InputMethodManagerService and its direct dependencies. This allows us
to make InputMethodUtils package-private class to make sure anyone
outside our team is unexpectedly depending on InputMethodUtils in a
subsequent CL.
This is 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: Ie8cb198880a145a7b81d2bf1eae1531ac3614019
There was a small mistake in my previous CL [1].
What updateStatusIcon() takes is a resource ID for Drawable, not ID
for an integer value.
These @*Res annotations are still just hints for IDE and lint tools.
They are actually all @Retention(SOURCE) hence this kind of mistake
has no impact at run time actually.
This CL also adds the right annotation for corresponding methods in
InputMethodManager and InputMethodManagerService.
[1]: I995c4b922f91b94438c1292392b2c3030598594f
c7ca36845e
Bug: 114418674
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Id7fd610c07643c79b8ec03efbda24b3dc0686844
This is one further step towards deprecating 8 IME APIs that were
accidentally defined InputMethodManager (IMM) instead of
InputMethodService (IMS).
With this CL, API calls to those 8 deprecated ones in IMM will be
forwarded to IMS so that we can completely remove corresponding IPC
methods from IInputMethodManager.aidl. This guarantees that processes
that have no InputMethodService running there become unable to access
IPC methods behind such IME APIs that are intended to be used only
from IMEs.
One tricky thing is that the following 4 public APIs have been allowed
to processes that have WRITE_SECURE_SETTINGS permission, even if such
a process does not have active InputMethodService.
* InputMethodManager.setInputMethod
* InputMethodManager.setInputMethodAndSubtype
* InputMethodManager.switchToLastInputMethod
* InputMethodManager.switchToNextInputMethod
In general, user mode apps should not have WRITE_SECURE_SETTINGS
permission. Thus it might be not that difficult for us to simply
deprecate such a special rule. Bug 114488811 is tracking that effort.
For now, this CL preserves the existing behavior when a null IME token
is specified to those 4 APIs.
Bug: 114418674
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: If762714b2003fa6477e1318110f63e13968c1d7e
This is a follow up CL to previous CLs [1][2][3] that made sure that
APIs that are exposed only to IMEs should live in InputMethodService
instead of InputMethodManager.
Now that we have a dedicated Binder inferface [4] that allows
InputMethodService (IMS) to directly send IPCs to
InputMethodManagerService (IMMS) without relying on
InputMethodManager (IMM), it is natural for the above public APIs in
IMS to stop relying on IMM.
This CL also addresses a small concern that it is no longer obvious
when those APIs become available. Previously, it was a bit more
obvious that passing null IME token doesn't work so IME developers
could imagine that those APIs were unavailable until attachToken() is
called.
With this CL, InputMethodPrivilegedOperations starts showing warning
messages when called too early, which we hope help IME developers
understand why those APIs do nothing when called too early.
[1]: I3163f3cbe557c85103ca287bee0874a3b4194032
d8d03a8e1b
[2]: If6a786c5774805d041ea9672ef2721e4a38df7fc
fbc2f7acd5
[3]: I6efd5ca473e33e6faeadb7eea7772b9d2b8ca12b
164cfba536
[4]: I2f3ec3c5de546fb3603275a4b64000ed3f863b65
c54c117164
Bug: 114418674
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I995c4b922f91b94438c1292392b2c3030598594f
Unless it is also touching any internal field that needs to be
synchronized with InputMethodManager#mH, just making IPC to
InputMethodManagerService (IMMS) does not need any additional
serialization in the caller side. IMMS itself already has internal
lock to serializate incoming operations.
Bug: 114418674
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I214d2c481c9fe862fbb9ec0759df2c798915b9f0
Fixes a couple of issues seen with PiP animations.
1. SurfaceView expands over the parent bounds.
2. SurfaceView and/or its background surface draws over the surface inset region of the parent.
Creates a child surface in ViewRootImpl that will crop any region outside its surface bounds after
adjusting for surface insets. Changed SurfaceView to parent to this new surface.
Test: manually run through PiP animations for Maps and YouTube.
Test: go/wm-smoke
Change-Id: Ib4b8e7f6753eda1e690e1ff6c92ce27165fa693e
Historically, InputMethodService (IMS) has relied on
InputMethodManager's hidden methods to communicate with
InputMethodManagerService (IMMS). Because of this, InputMethodManager
(IMM) has ended up being a mixture of IPC endpoint for both IME
clients and IME itself.
There are multiple problems.
* IMM is instantiated in almost all user mode processes. This means
that unnecessary IPC endpoints have been accessible to them via
reflection. Even though those endpoints refuses request without a
valid IME window token, and even though we have tighten up use of
private APIs in the runtime level, exposing unnecessary IPC
endpoints is still questionable.
* Mixing multiple responsibilities has been caused unnecessary
complexity in IMM. In Bug 70282603, we have moved some APIs from
IMM to IMS to sort out this complexity that are surfaced in API
boundary, but in the implementation level everything remained to be
the same.
Now that Bug 70282603 is fixed, the natural next step is to start
implementing actual an IPC connection from IMS to IMMS without relying
on IMM.
Here is the new diagram that describes (most of) IPC interfaces around
IMEs.
APP---(1)---IMMS
\ |
\ |
\ |
\ |
\ |
(2) (3)
\ |
\ |
\ |
\ |
\|
IME
(1): IInputMethodManager.aidl: send requests from APP to IMMS
IInputMethodClient.aidl: send requests from IMMS to APP
(2): IInputMethodSession.aidl: send requests from APP to IME
IInputContext.aidl: send requests from IME to APP
-> this is the actual interface behind InputConnection
(3): IInputMethod.aidl: send requests from IMMS to IME
IInputMethodPrivilegedOperations.aidl:
send requests from IME to IMMS
IInputMethodPrivilegedOperations.aidl is what this CL is adding.
With that, this CL moves 5 IPC methods
from IInputMethodManager.aidl (1)
to IInputMethodPrivilegedOperations.aidl (3).
There remain some IPC methods that are intended to be used only from
IMEs in IInputMethodManager.aidl because those methods have been
unfortunately exposed via public APIs in InputMethodmanager.
Although all of those public APIs were deprecated in Android P as part
of Bug 70282603, we still need to keep maintaining those APIs until
(most of) IMEs migrate to APIs that are newly introduced in
InputMethodService. It would take several years.
IInputMethodManager#getInputMethodWindowVisibleHeight() is another
method that we cannot migrate right now because some apps have already
relied on its corresponding hidden method in IMM, as discussed in Bug
113914148.
Fix: 113177698
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I2f3ec3c5de546fb3603275a4b64000ed3f863b65
I don't know whether this comment was valid in the initial
implementation or not, in the current system InputMethod.attachToken()
is not (indirectly) exposed to the IME client process vir Binder
interface. The only Binder interface that is exposed from the IME
process to the IME client process is IInputMethodSession, not
IInputMethod that implements attachToken().
One may think that a malicious app could try to call
Context.bindService() with InputMethod.SERVICE_INTERFACE to directly
obtain IInputMethod, but it should fail because IMEs must be
protecting their InputMethodService with BIND_INPUT_METHOD so that
only the system can bind to them.
This CL clarifies this point in both JavaDoc and its implementation.
If an IME happened to receive multiple attachToken(), it is an OS bug
and worth letting people know by crashing the IME process.
Fix: 114164394
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ia1e1d5ce020155b906e42a222f27b76905217395
InputMethodManager#getInputMethodWindowVisibleHeight() has been kind
of unintentionally exposed to all the IME client processes and we know
some apps are already relying on this hidden API via reflection, which
is bad especially because it would be getting harder and harder to
keep maintaining the semantics of this not-well-defined hidden API
once we start supporting features like multi display. Thust this CL
adds TODO comments there to warn people who are going to touch this
method.
This CL does nothing except for adding comments. Hence there should
be no behavior change.
Bug: 113914148
Test: compile
Change-Id: Id2084530bdb82deef226d8207d2f311d2e78b28d
Some accessibility actions (e.g., click) aren't counted as touch
currently. Hence, windows that are monitoring touches outside of
themselves wouldn't be notified when an accessibility action
takes place on another window.
WindowsInfo doesn't record if a window monitoring touches outside
nowadays. In order to find out this kind of window, add the field
for it.
Bug: 76228634
Bug: 62725890
Test: check if dialogs (e.g., volume panel or a11y menu) dismiss
after performing a11y action click.
Test: atest CtsAccessibilityServiceTestCases
Test: atest CtsAccessibilityTestCases
Test: atest WindowStateTests
Change-Id: I4fd84848b8a445e6df22251d68449ae8b502c601
inputMethodClientHasFocus() implemented by WindowManagerService is an
internal method that is used only from InputMethodManagerService.
For obvious security reasons, we do not need to expose this method to
application processes. We can easily achieve this by simply moving
this method from IWindowManager to WindowManagerInternal.
Note that this is a mechanical refactoring. There should be no
observable behavior change.
Fix: 112722651
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I20c618174d8279a9a57f458fb908235f452b2281
Also marking a few tests as flaky and fixing a couple
others.
Test: atest in:
frameworks/base/services/accessibility
frameworks/base/core/java/android/accessibilityservice
frameworks/base/core/java/android/view.accessibility
Change-Id: I217329655105ce3fa8d78e74c4d39aadcfcd8362
One DisplayContent contains one InputMonitor now.
- Change setInputWindow of InputManagerService updated by displayId,
so Window Handles in InputDispather can be updated by each DisplayContent.
- Only exist one focus in current state, reset it if in removed DisplayContent,
will be updated by default display or focused display.
- Add displayId parameter for createInputConsumer and destroyInputConsumer,
so InputConsumer from PIP, RecentApp and Wallpaper can be supported in multi-display.
Bug: 111363643
Test: atest WindowManagerSmokeTest ActivityManagerMultiDisplayTests
Test: atest com.android.server.wm.DisplayContentTests
Test: atest libinput_tests inputflinger_tests
Change-Id: I999c355be1789af5759f00206475d004e10116e3
setFinalCrop functionality is reimplemented by creating a new bounds layer
and applying a crop on this layer. see ag/4625718
Test: go/wm-smoke
Change-Id: I3ffb6dc2e2afd5170f6c6dee9e928ed0600656b1
InputMethodManagerInternal is an internal delegate mechanism for
InputMethodManagerService to expose some internal privileged
operations to other components in the system server process. Hence
the current package android.view.inputmethod does not make much
sense. Most likely this package was mistakenly chosen when it was
initially introduced by me [1].
Anyway, this is a mechanical refactoring and there should be no
behavior change.
[1]: I747c37ff6dd8f233faef43f2b5713a4320e848eb
fa6e0a80e2
Fix: 112722706
Test: make -j checkbuild
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I706654eceaa0212d21e053dd25c9d290da512e49
