This is a preparation to implement per-profile IME in
InputMethodManagerService (IMMS).
Multi-client IME is designed and implemented to be able to deal with
multiple profiles at the same time from its beginning [1]. This means
that when multi-client IME is enabled with system properties, it also
means that per-profile IME is enabled.
At the same time, the following classes need to change its behavior
whether per-profile IME is enabled or not.
* android.provider.Setings
* com.android.server.inputmethod.InputMethodManagerService
* com.android.server.textservices.TextServicesManagerService
* com.android.server.devicepolicy.DevicePolicyManagerService
* com.android.server.devicepolicy.OverlayPackagesProvider
The problem is that android.provider.Setings lives in the
frameworks.jar. Hence if we want to expose something like
PER_PROFILE_IME_ENABLED to android.provider.Setings, then such a flag
needs to live in frameworks.jar.
Note that this is expected to be a temporary change. Once per-profile
IME becomes always enabled in IMMS, we can safely roll back this
change.
Note also that static initializer of InputMethodSystemProperty is
expected to be evaluated only once as long as
InputMethodSystemProperty is loaded before Zygote.
[1]: I41dfe854557b178d8af740bc2869c936fc88608b
bae5bea23c
Bug: 120709962
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/java/android/view/inputmethod/InputMethodSystemProperty.java
Test: Manually verified as follows:
1. make -j MultiClientInputMethod
2. adb install -r $OUT/system/priv-app/MultiClientInputMethod/MultiClientInputMethod.apk
3. adb root
4. adb shell setprop persist.debug.multi_client_ime \
com.example.android.multiclientinputmethod/.MultiClientInputMethod
5. adb reboot
6. Make sure that multi-client IME is enabled
Change-Id: Iad8aba7edb1e60ccc1ce5192a11e01b6aa8d00a0
Hopefully no one has relied on this undocumented behavior that when
the caller has WRITE_SECURE_SETTINGS then null IME token is allowed in
IMM#setInputMethodAndSubtype().
Note that if the caller had WRITE_SECURE_SETTINGS they can achieve the
same goal by directly updating the following secure settings:
* Settings.Secure.DEFAULT_INPUT_METHOD
* Settings.Secure.SELECTED_INPUT_METHOD_SUBTYPE
Bug: 114488811
Test: CtsInputMethodServiceHostTestCases
Change-Id: Ic5c59299ace16778fc57a4ec2639508564f416a7
It seems that InputMethodManager#getShortcutInputMethodsAndSubtypes()
was designed to be a bit more generalized concept, but in reality it
just ended up being a convenient API that returns a single Voice IME
subtype if exists. As far as we can tell, It has never returned two
or mode pairs. It also has never returned non-voice
InputMethodSubtype.
In order to support per-profile IME mode in InputMethodManagerService
without introducing a bunch of new complexity and technical debt, this
CL re-implements IMM#getShortcutInputMethodsAndSubtypes() based on how
it has been used actually in the ecosystem.
The first thing this CL changes is that
IMM#getShortcutInputMethodsAndSubtypes() no longer takes subtype
locale into account when looking for the best voice IME subtype. This
is because InputMethodSubtype is no longer a recommended way to
represent IME languages. Ignoring subtype locale makes the
implementation much easier to understand and maintain.
The second thing this CL changes is that
IMM#getShortcutInputMethodsAndSubtypes() is now just a utility method
that is implemented in the client side on top of other well-defined
public APIs such as IMM#getEnabledInputMethodList() and
IMM#getEnabledInputMethodSubtypeList(). This means that this API
becomes per-profile IME ready for free once other public APIs become
per-profile IME ready.
[1]: Ibd0f7ef5101013569c303820a3adc9038a97356d
4e4569dab5
Bug: 120709962
Test: AOSP Keyboard still shows voice IME shortcut when the device has
one or more IMEs that expose voice InputMethodSubtype.
Change-Id: Iaf31e9f3213f4e644b64c9658f1b59d371e3c2b4
The app is not started yet, and does not contain any service for now.
Test: built, booted
Bug: b/112869080
Change-Id: Id5a0fd02c891100e85d86b1040e53beec3581950
The initial implementation of AbstractPerUserService assumed the
AbstractRemoteService instances would be created in demand, because that was
the aproach used by Autofill (to minimize the time system service is bound to
the autofill service process).
But for other systems like ContentCapture, it makes more sense to keep a
permanent connection to the remote service, which is running all the time, so
this change changes the infra to allow such permanent connection (which includes
defining an idle timeout value that never unbinds).
Bug: 117779333
Test: atest CtsContentCaptureServiceTestCases CtsAutoFillServiceTestCases
Change-Id: I43386a3fddc56f1dfd6e4e55f243eaa297921123
- Check consolidated zen policy in volume dialog, seek bar volumizer
and ZenModeControllerImpl instead of default notification policy
- Save ZenPolicy changes on restore
Test: atest ZenModeHelperTest
Test: atest ZenModeControllerImplTest
Bug: 111475013
Change-Id: I43b6dc8c6453739c50c874fe37415d425223d8c4
FragmentManagerImpl in AndroidX currently uses reflection to read
mListener, so it can wrap it with another listener. Adding add/remove
methods for AnimationListener's next to setAnimationListener removes the
need for AndroidX to touch mListener, which is private API.
Bug: 117519981
Test: atest AnimationTest
Change-Id: I69cb19d61078215ca6697b3d41f4c536decc2e6e
ResolverActivity now identifies that the intent is a browsable intent,
and thus omits the Always button and replaces it with a settings button
tha can be used to configure the user's wanted behaviour.
Also prints out a message explaining that the user is giving the app
an access to open URLs from a specific host.
Bug: 116610086
Test: manually tested on device (Pixel 2XL) - will add unit test to
document behaviour
Change-Id: I81988b9a4d082bc1e6491186d39532fd283f2ede
Implement controlWindowInsetsAnimation
Based on the leashes we have on the client, and the insets the
client has requested, we are able to move the surfaces around
such that the resulting insets will match what the client
requested.
Bug: 118118435
Change-Id: I0616e53455a6544aaf374c1b0eb10e258aced21d
In PermissionManagerService and DefaultPermissionGrantPolicy.
This mirrors what the permission controller is doing. Better make sure
all modules changing app-ops for runtime permissions do it the same way.
Test: Looked at pre-grants after boot, changed permissions after boot
Change-Id: I88386ec6842324b28ab408ea5cd113c9cc7de9fe
* changes:
DO NOT MERGE Set ContainerLayer for buffer-less surface
DO NOT MERGE: WM: Restrict SC Builder to set a single surface type
Implement construction of container layers
