WebView will use the node addresses as the id, and these address are 64 bits.
Fixes: 123234726
Test: atest ContentCaptureSessionTest ViewNodeTest ContentCaptureSessionTest \
CtsContentCaptureServiceTestCases \
CtsAutoFillServiceTestCases:VirtualContainerActivityTest \
CtsAutoFillServiceTestCases:VirtualContainerActivityCompatModeTest
Test: m update-api
Test: manual verification with Webview, as CtsAutoFillServiceTestCases:WebViewActivityTest is broken
Change-Id: Iaf3008ed2dd530e596489cb144da678a4dac48ca
Previously, privileged processes (w/ INTERACT_ACROSS_USERS_FULL) that
run as user X are automatically allowed to connect to the current IME
even when it runs as a different user Y.
However, as explained in my previous CL [1], there are many text
operations that are already fully multiuser-aware hence need to be
connected to the right user's services.
If EditorInfo#targetInputMethodUser [2] is not correctly set when it
should have been, it's highly likely that the IME client would need to
call TextView#setTextOperationUser() [3] as I did for System UI [1].
To detect such problems as early as possible, with this CL
IMMS#startInputOrWindowGainedFocus() no longer resolves null
EditorInfo#targetInputMethodUser as the current IME user for
privileged processes that have INTERACT_ACROSS_USERS_FULL permission.
If this CL broke some IME use case, most likely the IME client app
would need to be fixed.
[1]: Ibabe13e5b85e5bb91f9f8af6ec07c395c25c4393
7276946b92
[2]: Ia7ea944438d69669ccdf9111b34ba400e786a602
0f5eade4a4
[3]: I6d11e4d6a84570bc2991a8552349e8b216b0d139
401e3d4c84
Bug: 34886274
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: per-profile mode still works.
Test: Manually tested multi-user scenario as follows
1. Build and flash an AOSP build
2. Create a secondary user then switch to it.
3. make -j SoftKeyboard
4. adb install -r $OUT/system/app/SoftKeyboard/SoftKeyboard.apk
5. adb shell ime enable com.example.android.softkeyboard/.SoftKeyboard
6. adb shell ime set com.example.android.softkeyboard/.SoftKeyboard
7. make -j EditTextVariations
8. adb install -r $ANDROID_TARGET_OUT_TESTCASES/EditTextVariations/EditTextVariations.apk
9. adb shell am start \
-n com.android.inputmethod.tools.edittextvariations/.EditTextVariations
10. Tap the menu icon on the EditTextVariations then click "Direct Reply"
11. Tap reply icon on "Message from UserHandle{10}".
12. Make sure that SoftKeyboard Sample IME is shown.
13. Type "ggggg" then hit the space key.
14. Make sure that red underline is drawn under "ggggg"
15. Make sure that AndroidSpellCheckerService runs as user 10.
16. Set up a text screenlock.
17. Turn off the display.
18. Turn on the display.
19. Make sure that SoftKeyboard Sample IME is shown.
Change-Id: Ieb94ed14698ee2669adc5fb2ea0e93c7d0e09e8b
Instead of turning off the new window insets system fully on or
off, we introduce three modes:
0: Old system
1: New system for IME only
2: New system for IME + system bars
This allows us to launch the feature in IME only mode, in order to
avoid a lot of compatibility fallout around system bars.
Test: adb shell setprop persist.wm.new_insets 0/1/2
Bug: 118118435
Change-Id: Iaa49e62930b2539770cd313567dde4b102216097
This CL deprecates SuggestionSpan#ACTION_SUGGESTION_PICKED and related
constants [1].
There are multiple security concerns, open questions about
compatibility, and maintainance challanges in this protocol.
IME developers can implement their own suggestion picker UI on top of
CursorAnchorInfo API to achieve safer, should give more flexible UI
options, better security, and better compatibility.
[1]: Ia539de0acf66053e0349daec459d75e36805f6bf
f9f0100862
Fix: 123160396
Test: make -j checkbuild
Change-Id: I6d39e838ae47488055162cd44b5f553f68869b17
It was calling isVisibleToUser(), which is expensive.
Bug: 121039624
Test: atest CtsContentCaptureServiceTestCases
Change-Id: If641a01a5a6706743caefaa5fa34114902cd2c49
They can be expensive to calculate, so the cost/benefit is not worth it...
Bug: 121039624
Test: atest CtsContentCaptureServiceTestCases \
FrameworksCoreTests:android.view.contentcapture.ViewNodeTest
Change-Id: I2950fb5916ab8fceb5c089742e99c197e3d017e9
This flag was meant to indicate when a text was changed by the user (for example, using IME), but
that information is not readly available and would require changes in too many parts of the system,
so it's not worth the effort (at least for now...).
Test: m update-api
Test: atest CtsContentCaptureServiceTestCases \
FrameworksCoreTests:android.view.contentcapture.ContentCaptureSessionTest
Fixes: 121045053
Change-Id: Ifcdd5e5bb0c6c5c0f840fe0bbdbda8eca9bdb479
This is a follow up CL to our previous CL [1], which enabled spell
checker for background users. In that CL, we assumed that spell
checker user ID can and should always be determined by the calling
user ID. This assumption is not valid at least for direct-reply
notifications on System UI, because System UI always runs as user 0 no
matter who is the current active user.
In order to allow TextServicesManagerService (TSMS) connect to the
right user for such a special use case, this CL introduces a hidden
parameter "userId" to each IPC so that clients that have
INTERACT_ACROSS_USERS_FULL can override the target user ID when
necessary.
For instance, to interact with user 10's spell checker services, you
can obrain a special instance of TextServicesManager as follows.
TextServicesManager tsmForUser10 = context
.createPackageContextAsUser("android", 0, 10 /* userId */)
.getSystemService(TextServicesManager.class)
If the calling process does not belong to user 10, any operations on
that TextServicesManager will result in SecurityException unless the
calling package needs to have INTERACT_ACROSS_USERS_FULL.
This CL is just a preparation. There should be no user-visible
behavior change yet.
[1]: I06c27ef834203a21cc445dc126602c799384527b
06a2624049
Bug: 123043618
Test: spell checker still works
Change-Id: I31dda3ae8795190d44b0622b8335c34ddbc5dd48
This is a preparation to propagate the expected IME user ID from
direct-reply notification to InputMethodManagerService (IMMS).
When per-profile IME mode [1] is enabled, IMMS basically assumes that
the IME user ID should be determined by calling process's user ID.
This works for most of apps, but does not work for direct-reply hosted
in the System UI process, which always runs as user 0.
With this CL, client apps can explicitly specify the target IME user
ID by using @hide field in EditorInfo. For instance, to tell IMMS to
connect to user 10's IME, do this:
@Override
public InputConnection onCreateInputConnection(EditorInfo info) {
InputConnection ic = super.onCreateInputConnection(info);
info.targetInputMethodUser = UserHandle.of(10); // user 10
return ic;
}
The calling process will receive SecurityException if it does not
belong to user 10 and does not have INTERACT_ACROSS_USERS_FULL.
This CL is just a preparation. There should be no user-visible
behavior change yet.
[1]: Ied99664d3dc61b97c919b220c601f90b29761b96
a878b9500e
Bug: 120744418
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Change-Id: Ia7ea944438d69669ccdf9111b34ba400e786a602
To facilitate the need of returning color spaces about the composition
pipeline, add an API to query this information. This API will be used by Canvas
and Display, etc.
BUG: 120904891
Test: Build, flash and boot. Verify by checking returned values.
Change-Id: I97123ba1488ca76888a4c004128b4100a7c1f76c
This feature involves generating and loading code on the
application. Applications may use the preferCodeIntegrity flag to indicate they
do not want this behavior, so we need to respect this preference. We also
disable loading precompiled layouts for privapps.
Bug: 111895153
Change-Id: I5c563e9f6eb7dd5eb7aac7df3838888f71b38866
Initially it was creating a new thread, which infers in a ~0.3ms cost in the
initial activity creation. Examples:
Before:
com.android.settings: 403.542us
com.google.android.apps.nexuslauncher: 13147.397us
android.contentcaptureservice.cts: 481.979us
After:
com.android.settings: 25.677us
com.google.android.apps.nexuslauncher: 45.0us
android.contentcaptureservice.cts: 56.041us
Test: manually System.out check above
Test: atest CtsContentCaptureServiceTestCases
Fixes: 121039624
Change-Id: I4e7d90c4556467612d8b914fb3d3a5bc05a852bd
Now that we can have HDR10+ from composer, expose it in Java
Display.HdrCapabilities as well.
BUG: 118343714
Test: Build, flash and boot.
Change-Id: Ibe65c03fe81fe0afd336d54ef04e68a5bfa34833
To facilitate display color service to know the capability of protected content
in GPU composition, add an API to SurfaceControl to query back from composer.
BUG: 117436546
Test: Build. flash and boot. Verify by checking returned value.
Change-Id: I313c88e68dc4d2ae3f1e8e9d11b1f4d877a4d64f
This change enables the use of precompiled layouts, provided a couple of
conditions are met:
1. Precompiled layouts are enabled by the system property
view.use_precompiled_layouts.
2. There is a file called compiled_view.dex in the application's code cache
directory.
If these conditions are met, when a layout is inflated, the LayoutInflater will
first check if a precompiled version is available and use that. If anything goes
wrong, such as if the layout is not available or something goes wrong during the
inflation process, then the LayoutInflater will fall back on interpretting the
layout resource as before.
Bug: 111895153
Test: atest $ANDROID_BUILD_TOP/cts/tests/tests/view/src/android/view/cts/LayoutInflaterTest.java
Change-Id: Id050072c0206080322a0e876782ee2b66d03916d
When mouse pointer changes displays, it should also reload the
icon from new resources. Otherwise, if the densities of the
previous and new displays are different, the size of the pointer
sprite will look too small or too large.
- Add getDisplayContext to get the corresponding Context by displayId.
- Cache system pointer icons per display, clear if display removed.
- Fix icon moved to default when not resetting out of task bound.
Bug: 113559891
Test: Enable mouse pointer on default display, move to other screen
Change-Id: Ic42d0ec32d9c979281e13c83b9e8b57134fd4f0d
Some apps - like launcher and settings' FallbackHome - generate view-level events before ever
starting an activity (probably because they're using dialogs). Hence, we were scheduling a
flush request, but never cancelling it.
Bug: 120494182
Bug: 122959591
Test: atest CtsContentCaptureServiceTestCases
Change-Id: I4a5448f19902ae51c8f2679eb0c468757b98c3ff
As long as FragmentManagerImpl in AndroidX is not fixed, we need to keep
this annotation, or FragmentManagerImpl will crash.
Bug: 122893665
Test: atest AnimationTest
Change-Id: I5e21ee5f3ffb4c314ae7b5ea8f32d3880e2f2550
