Major changes:
1. ConversationAction is now in top-level.
2. Removed TypeConfig, and repurposed TextClassifier.EntityConfig for
general use. It would be better to rename it to be something like
TypeConfig. But just a bad name is probably not worth to deprecate
the existing APIs.
3. Hints constants are moved to Request object.
4. Action constants are moved to ConversationAction object.
Test: atest TextClassifierTest.java
BUG: 120841922
Change-Id: Ia466aaf4c5050a9c7e404dcd3b295f5ef7e4ce6f
In order to support BYOD (Bring your own device) use cases, Android
phones can associate multiple users into a single profile group so
that other system components such as launcher can help users
seamlessly switch user identity without doing a heavy-weight
device-level user switching.
For instance, an Android device can be configured to work for two
different users Alice and Bob, while Alice also has two different
identities: one as her private account and the other for her
work-related account.
Profile group X == Alice:
Parent user X (user id: 0)
for personal account, under her control.
Child user 1 (user id: 10)
for work-related account, partly under system-admin's control.
Profile group Y == Bob:
Parent user Y (user id: 11)
private account, under his control.
The above configuration allows system-level data separation not only
between Alice (user 0) and Bob (user 11) but also between Alice's
personal account (user 0) and Alice's work-related account
(user 10). For instance, Calendar app that runs under user 0 cannot
see any data for other users including user 10.
IME is one of known exceptions in the above design. For instance, when
Alice is using the device, the system launches InputMethodService,
which is the code-level representation of IMEs, only for the user 0
then gives it a special ability to interact with all the applications
that run under the same profile group.
Profile group X == Alice:
IME works as user 0 but interacts with apps that run under
user 0 and 10.
Profile group Y == Bob:
IME works as user 11 and interacts with apps that run under
user 11.
Of course there are non-trivial imprications by sharing the same
instance of InputMethodService across profiles but this was basically
the only option when we initially introduced in Android 5.0 [1]
because of multiple challenges (schedule, complexity, performance
concerns, and so on). To to mitigate the risk, we also introduced APIs
that allow system administrators to whitelist what IMEs can be enabled
for the entire profile [2]. Even with such a whitelist feature, we
have received multiple feature requests to completely separate IME
instances by profile boundaries, like other applications behave.
This is why this CL was authored.
With this CL, a new runtime mode "per-profile IME" is introduced
behind the flag. When the flag is enabled:
* InputMethodManagerService (IMMS) may calls IMMS#switchUserLocked()
from IMMS#startInputOrWindowGainedFocus() every time when a
different profile's IME client gains IME focus.
* SpellCheckerService also enables per-user mode, which has been
temporarily disabled [3].
* DevicePolicyManagerService no longer disable packages that contain
system IMEs when creating a new profile user.
* Following IME APIs start returning result based on the caller's
user (profile) ID.
* InputMethodManager#getInputMethodList()
* InputMethodManager#getEnabledInputMethodList()
* InputMethodManager#getEnabledInputMethodSubtypeList()
There are still multiple known issues though. Hopefully we can address
those issues in subsequent CLs.
* Inline-reply from non-primary profiles is still dispatched to the
main profile's IME because SysUI is always running under main
profile (Bug 120744418). This probably can be addressed by
allowing the IME clients that have INTERACT_ACROSS_USERS_FULL to
specify the target user ID in some @hide parameter.
* IMMS#switchUserLocked() is not yet fully optimized (Bug 28750507).
New client app's UI thread can be blocked more than 100ms,
depending on the number of installed IMEs and the number of IME
subtypes implemented by those IMEs.
* Even after IMMS#switchUserLocked() is fully optimized, IMEs'
cold-startups are known to be slow. One way to optimize this is
keeping binding to those IMEs, but doing so would require 1)
non-trivial amount of code changes and 2) doubles RAM consumption.
* Virtual keyboard settings page for profile users are not yet
available (Bug 120748696).
* Migration from shared-profile IME mode to per-profile IME mode is
not yet supported (Bug 121348796). By default, IME packages will
be automatically disabled when a profile user is created. This
means if the device switches from shared-profile IME mode to
per-profile IME mode, IME packages continue to be disabled hence
the user cannot type anything for those profiles.
Anyway, there should be no behavior change unless the debug flag is
explicitly flipped.
[1]: I3bd87b32aec69c3f8d470c8b29b144f4e849c808
734983fff3
[2]: I921888660d29a5370395db87adf75d4d106660c9
9c9cbac5b71a23ed0dbab0f44cb78a820514cfc6
[3]: Ic046f832f203115106409a53418a5746eb6d4939
3f8c568883
Fix: 120709962
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: Made sure that there is no behavior change if the debug flag is
not set as follows.
1. Install Test DPC
2. Enable managed profile with Test DPC
3. make -j EditTextVariations
4. adb install -r $ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/EditTextVariations.apk
5. Open two EditTextVariations instances in split-screen mode
5.1. One is for the main profile
5.2. The other is for the managed profile
6. Make sure that main profile's instance of AOSP Keyboard is used
for both applications.
7. Make sure that main profile's instance of Android Spell Checker
is used for both applications.
8. adb shell ime list -a -s --user all
-> Only "com.android.inputmethod.latin/.LatinIME" is shown.
9. adb shell dumpsys textservices
-> Only result for user #0 is shown.
Test: Made sure that basic text input can be done with
"per-profile IME" mode enabled as follows.
1. adb root
2. adb shell setprop persist.debug.per_profile_ime 1
3. adb reboot
4. Install Test DPC
5. Enable managed profile with Test DPC
6. make -j EditTextVariations
7. adb install -r $ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/EditTextVariations.apk
8. Open two EditTextVariations instances in split-screen mode
8.1. One is for the main profile
8.2. The other is for the managed profile
9. Make sure that AOSP Keyboard will be re-launched to correspond to
the focused IME client's user profile.
9.1 When EditTextVariations for the main profile is focused,
AOSP Keyboard for the main profile is shown.
9.2 When EditTextVariations for the work profile is focused,
AOSP Keyboard for the work profile is shown.
10. Make sure that different instances of Android Spell Checker are
used based on target application's profile
11. adb shell ime list -a -s --user all
-> "com.android.inputmethod.latin/.LatinIME" is shown for both
user #0 and user #10.
12. adb shell dumpsys textservices
-> Both user #0 and user #10 have results.
Test: atest DevicePolicyManagerTest#testSetPermittedInputMethods_failIfNotProfileOwner
Test: atest com.android.server.devicepolicy.OverlayPackagesProviderTest
Change-Id: Ied99664d3dc61b97c919b220c601f90b29761b96
Tests are in ag/5989968
Fixes: 121047489
Test: atest CtsContentCaptureServiceTestCases # to make sure nothing broke
Test: atest
CtsContentCaptureServiceTestCases:android.contentcaptureservice.cts.BlankActivityTest#testTargetServiceName_enabled
Test: google3 test with test app
Change-Id: I4f11a324beb938a28cd150c35bb3d83c77e59e0b
Also fixed AssistStructure.ViewNodeBuilder.setVisibility() so it doesn't mess
up with the flags when it receives an invalid value.
Test: atest FrameworksCoreTests:android.view.contentcapture.ViewNodeTest
Test: atest CtsContentCaptureServiceTestCases
Fixes: 121135096
Change-Id: I2280c6922ca5a02aa4ed16ba3e8b39b9cb2f4b55
Also, change to use android.util.Log rather than Slog, which should
be used by system service only.
Test: Try out adb shell setprop log.tag.androidtc and observe verbose
logging.
Change-Id: Ie86c6b3f8bd39957f041ffe3a10abb7584f96f83
Rework how dispatching works for apps targeting Q+
(flagged off at the moment behind VRI.USE_NEW_INSETS)
We properly dispatch windows in the hierarchy by fixing the issue
that insets modified by onApplyWindowInsets affected all other
views later in prefix order, including siblings and siblings of
parents.
Furthermore, we get rid of stopping dispatch if they are consumed,
as it gets a lot more complicated with the granular information we
add what consumed actually means.
Test: ViewGroupTest, ViewTest
Bug: 118118435
Change-Id: I9dfb69ebb93b334bb34d17889282293bec94e1af
Implement WindowInsets.get(Max)Insets(int typeMask) to allow the
developer to query the inset by inset type.
Also rework InsetsState.calculateInsets to actually construct the
WindowInsets instance that contains this information.
Test: InsetStateTests
Bug: 118118435
Change-Id: Ie316e074c020bdb9808c11608812dea572c8de5d
WindowInsets now keeps track of all insets per type. Insets are
non-additive, i.e. every inset starts out relative to the window
edge, so the IME inset would include the navigation bar inset, but
not vice-versa.
We remove decorWindowInsets because it wasn't used at all.
For compatibility, we map the constructor where we pass in a Rect
to TOP_BAR. This is fine as every query to systemWindowInsets
stableInsets will include this type, so we don't need the
information where it came from.
Test: WindowInsetTest
Bug: 118118435
Change-Id: I1cb37d328060293f9a876e61d4a09e6675fa7197
1. SelectionEvent will be still logged via SelectionSessionLogger
to make sure we don't break existing logs.
2. New features including language detection and conversation actions
are logged via TextClassifierEventTronLogger.
3. Added TYPE_ACTIONS_GENERATED to log when actions are generated.
This is used to calcuate the recall, i.e. among all the requests,
how many of them TextClassifier returns something.
Test: atest TextClassifierEventTronLoggerTest
Test: Turn on the DEBUG flag and observe the logging.
BUG: 120803809
BUG: 120828422
Change-Id: I33f2ce58885d90bc35316f54abcd42b137b42a13
We remove explicit layer destruction and replace it
with reparent->null, completing the transition to
a reference counted model.
Test: Manual
Bug: 62536731
Bug: 111373437
Bug: 111297488
Change-Id: I6be5ae01218e566deb713ed9079b36e1135ff2ec
Not leaking in practice but if it were used on an already initialized
SurfaceControl Java Wrapper it would leak the old native object by
failing to cal dec strong.
Bug: 111373437
Test: Boots
Change-Id: Ie8f59788630bc2ba05bbdcbbefed4124a4032170
Apps can call addChild through AccessibilityNodeProvider, so it's
possible that an app adds a node itself as a child node. This will break
down the integrity of UI tree and cause failure to operation in
UIAutomator. Thus I suggest do this integrity check when adding child.
Test: as follows
- built
- flashed
- booted
- run my test script based on uiautomator
Change-Id: I8cba22a1d9d1a49365c6bce4241ef5067502fb79
Signed-off-by: qinyige <qinyige@xiaomi.com>
Long-story short, they must be flushed right away...
Test: atest CtsContentCaptureServiceTestCases
Bug: 121033016
Change-Id: I1b3132ad49674d43bf63717f79848b6e4b23b605
