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
This will allow apps to delegate posting to persistently
running apps, to decrease the numbers of times apps need to wake up
just to post a notification.
Bug: 111452544
Test: runtest systemui-notification
Change-Id: I1ead239747f2871f222d0ce6a971d1448a0766ad
Now we have Font class. It is good to move max weight constant from
Typeface to Font.
Bug: 112327179
Test: atest FontTest
Change-Id: I3946ac150a02bf0cafa0fc81e61e69c31b45ed1d
These APIs are necessary to implement hyphenation by third party developers.
Bug: 112327179
Test: atest android.graphics.cts.PaintTest#testSetGetHyphenEdit
Change-Id: I692a56d3d1b15100503eb6d8e0f59d6c5c8af81b
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
This is a mechanical refactoring to split out boilerplate code around
IPCs from InputMethodManager to another file.
Bug: 114418674
Bug: 113177698
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: I9ca251482867daea84c2777f74fd9b8a2b0f29cd
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
Bug: 68490704
1) Add annotation in some places where it was missed: constructors of Fade and Slide
2) Add Fade.IN and Fade.OUT into a set of allowed values for Visibility.MODE IntDef. Without it Lint will false alarm on this line:
new Fade().setMode(Fade.IN);
It should be allowed as Fade.IN is just a proxy value for Visibility.MODE_IN.
Test: n/a
Change-Id: I56d8ba5f49b1cf8f6a61357f58ac76312e7cf037
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
