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
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
This is a no-op method.
Bug: 112722651
Test: compile
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ic990588c868f9173bbbe73dcfc5b193642dcc294
Expose existing native functionality. In preparation for use as
bufferless-input-catching-surfaces.
Bug: 80101428
Bug: 113136004
Bug: 111440400
Change-Id: I455792aec3ee58d9dd20016b484ce7c27808d522
Shared libraries were failing to retrieve correct resource ids from the
values of attributes in xml files. The packages of the shared ids were
not changed from 0 to their runtime assigned package ids.
Bug: 112776204
Test: atest FieldsClassificationTest#testGetAlgorithm
Change-Id: I509bc7632f5ec3e9b644e590934e6cf569a4d938
For some timing cases client side may not get desired display with old
displayId.
For this issue, client side has just received configuration change and
handle it in ActivityThread#handleActivityConfigurationChanged. At the
same time, DisplayManagerService was about to destory display. When
ViewRootImpl want to update display with new DisplayAdjustments, it got
null because the old displayId was removed.
For this scenario, fallback to use default display. Usually there should
be other displayId change event comes from server side to ask client update.
Change-Id: Ifb843f82b753761cb6306e7482b38a0ffd89498d
Fix: 73558361
Test: atest CtsWindowManagerDeviceTestCases
Test: atest CtsActivityManagerDeviceTestCases
I added a reference to a view in a pooled object,
but did not clear the reference to it when releasing it.
Thus the links to the View (and its Context) live as long
at the static object.
This code is only called when accessibility is on.
Bug: 112792715
Test: make
Change-Id: If716c33b91aac3a1da5fd4a857daa5b4b9b7e151
Adds an option to mask the cutout by effectively shrinking the logical display
such that developers can test apps as if the device did not have a notch.
Bug: 112876936
Test: Go to Settings > Developer Options > Simulate display with cutout > "No cutout". Cutout should be hidden. Rotate screen, take screenshots, screenrecord, screen off animation should all work as expected.
Change-Id: I5cdb201734d238bf3785ab55843114e4b5b4ee41
DisplayListCanvas, that draws Bitmaps on the Android framework,
has a bitmap size limit. Let's respect the limit to guarantee
that SystemUI won't crashloop when a bitmap is over 100MB
Test: manual, setting wallpaper
Change-Id: Iff91e73722a912efe095f80e263e160cc2456a11
Fixes: 111330638
Bug: None
Test: I solemnly swear I tested this conflict resolution.
Change-Id: I0807ae67e0ed3e84f17af962dc8b7a3152f8103f
Merged-In: I4147b038ed7adf0311ee9918b44766f82a057eaf
For packages:
android.view.textservice
android.view.textclassifier.logging
android.view.textclassifier
android.view.inputmethod
android.view.autofill
android.view.accessibility
android.view
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: Ie4663ebd4640b2893e575e599582d2c9530da313
Merged-In: I4147b038ed7adf0311ee9918b44766f82a057eaf
For packages:
android.view.textservice
android.view.textclassifier.logging
android.view.textclassifier
android.view.inputmethod
android.view.autofill
android.view.accessibility
android.view
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: I4147b038ed7adf0311ee9918b44766f82a057eaf
