summaryrefslogtreecommitdiff
path: root/core/java/android/view/InputWindowHandle.java
Commit message (Collapse)AuthorAgeFilesLines
* Drop the cloned windows from visible window listryanlwlin2022-05-311-0/+1
| | | | | | | | | | | Currently the cloned windows is avaialbe from window list, however the node info from the cloned window is incorrect. To avoid confusion, we would drop them for a short term solution. Bug: 230300971 Test: manually test with switchaccess adb shell dumpsys accessibility to observe the window list Change-Id: I7a03376567698a493c9eb5e26d1f3390aacdb408
* Add isClone to InputWindowHandlechaviw2022-04-281-0/+5
| | | | | | | | | Add a flag about whether the window is a clone to help identity the original windows vs clones Test: Builds Bug: 230300971 Change-Id: Iac006d73d2e0100b5f8261a30a1dd2ff3f1bae88
* Ensure handwriting session can only be started from inside app boundsPrabir Pradhan2022-03-221-0/+32
| | | | | | | | | | | | | | | | | | | Initialize the touchable region of the handwriting window to be cropped to the focused window bounds. This means the handwriting window will only spy over the app bounds. When attempting to start a handwriting session, ensure that we are currently recording a gesture in the handwriting window. This means we can only start handwriting if the gesture originated within the app bounds. When a handwriting session starts, change the touchable region of the handwriting window to be over the entire display, so that scribbles outside the app window can sent to the IME. Bug: 226081811 Test: manual: using test apps in split screen Change-Id: I95b67ec7be40dc80ed67c91d0ee0b32296e532ca
* Use InputConfig flags in InputWindowHandle APIPrabir Pradhan2022-03-041-34/+68
| | | | | | | | | | | | | | | | | | | | Use the android.os.InputConfig flags to control input window behavior in InputWindowHandle. This consolidates the old boolean flags and inputFeatures flags into one set of flags so that the InputConfigs are the sole set of flags that change change how an input window behaves. After this change, InputFeatures and LayoutParamsFlags are specific to WM, which is responsible for converting them into InputConfig flags. Trivial conversions between these flags are done in InputConfigAdapter. The LayoutParams type and flags are still part of the this API to send these attributes to native code. However, they are no longer used by input. Bug: 216806304 Test: manual: verify touch functionality Test: atest WindowStateTests Change-Id: I5b384770272c111680783ee8ab01ecd6e03f42be
* WindowInfo: Merge InputConfig and Feature flagsPrabir Pradhan2022-03-031-0/+1
| | | | | | | | | | InputFeatureFlags are now a WM-only flag, but is temporarily used by InputWindowHandle until the cleanup is completed. Bug: 216806304 Test: atest libgui_test Test: atest inputflinger_tests Change-Id: I1260431e99d2c50261dc8b0356dc3e21ba76d39f
* Merge "Cache IWindow in InputWindowHandle" into sc-v2-dev am: 16805b4c7e am: ↵Chavi Weingarten2021-08-231-2/+12
|\ | | | | | | | | | | | | | | 16a27e576d Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/15640823 Change-Id: Iddf97951d52d494af882abb4d5f25fdfe24468cb
| * Cache IWindow in InputWindowHandlechaviw2021-08-231-2/+12
| | | | | | | | | | | | | | | | | | | | Converting IBinder to IWindow is inefficient so instead cache IWindow object directly. When calling native to Java, the IWindow object may not be populated yet so we lazy cache it when getWindow is called. Test: atest WindowAddRemovePerfTest Fixes: 197219430 Change-Id: I15f7d7cd9775592a5545ddaf276c1b1db2777ac9
* | Merge "Pass IWindow to InputWindowHandle." into sc-v2-dev am: f3cee944ae am: ↵Chavi Weingarten2021-08-181-0/+15
|\| | | | | | | | | | | | | | | fbcf878cfa Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/15530149 Change-Id: I2c3c780469cececa2774107cfcc3e5e07db88c4e
| * Pass IWindow to InputWindowHandle.chaviw2021-08-181-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | This allows listeners to identify which WindowInfo belongs to which IWindow. Using InputChannel token may not work since not every Window has an InputChannel, but every window should have an IWindow token. There may still be WindowInfo data that doesn't contain an IWindow token if they were created as pure layers, and not windows. Test: IWindow token sent to listeners Bug: 188792659 Change-Id: Ie90453d40906c0ee8312a23a6f4c8e85310bbaf7
* | Merge "Add transform matrix to InputWindowHandle." into sc-v2-dev am: ↵Chavi Weingarten2021-08-161-0/+9
|\| | | | | | | | | | | | | | | 73f529933e am: 9b735dcba7 Original change: https://googleplex-android-review.googlesource.com/c/platform/frameworks/base/+/15515189 Change-Id: If596140bb2ec4c6a6a301995723c1c5a537c13e8
| * Add transform matrix to InputWindowHandle.chaviw2021-08-161-0/+9
| | | | | | | | | | | | | | | | | | | | | | Added the transform matrix from WindowInfo native to the Java side InputWindowHandle. This is to allow clients that register a WindowInfoListener to translate the window's screen coordinates to window space. Test: Transform is now sent to WindowInfoListener Bug: 188792659 Change-Id: Ifba8488ff470d3c6c8066e23b871c3d541cff0a1
| * Renamed and moved InputWindow and related fileschaviw2021-06-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | In preparation for the hierarchy listener interface, moved the InputWindow structs into libgui and have libinput dependant on libgui. Also renamed InputWindow to exclude Input since it will be used for more generic purposes. Test: Builds and flashes Bug: 188792659 Change-Id: Ib0a32c9920dc8110ceee4d6617ac030eb5cc0d99 Merged-In: Ib0a32c9920dc8110ceee4d6617ac030eb5cc0d99
* | Renamed and moved InputWindow and related fileschaviw2021-06-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | In preparation for the hierarchy listener interface, moved the InputWindow structs into libgui and have libinput dependant on libgui. Also renamed InputWindow to exclude Input since it will be used for more generic purposes. Test: Builds and flashes Bug: 188792659 Change-Id: Ib0a32c9920dc8110ceee4d6617ac030eb5cc0d99
* | Remove portalToDisplayId from InputWindowHandleSiarhei Vishniakou2021-06-241-6/+0
|/ | | | | | | | | All of the existing users have already moved off of virtual displays. There are no more users of this functionality. Bug: 167946720 Test: compile only Change-Id: I8e602b781227c9ad18c933f4ed77cdc2f21efbb0
* Reduce unnecessary invocation of setInputWindowInfoRiddle Hsu2020-11-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Usually most fields of InputWindowHandle don't change frequently. Therefore, only the changed instances need to be updated. That reduces the overhead of JNI invocation (especially NativeInputWindowHandle::updateInfo which may be called from setInputWindowInfo). There should be no behavior change. - Add a InputWindowHandle.ChangeDetectionWrapper to wrap the original handle. So the changes of its fields can be tracked. - Make InputApplicationHandle java side immutable. Its content should be rarely changed. Then it is easier to compare by instance. This might also reduces the race condition of accessing its field from InputDispatcher because the instance is different. - Move some fields that won't change of InputWindowHandle to the constructor of WindowState to reduce unnecessary updates. - When a window cannot receive input, reuse the per-window input window handle to populate the disabled info, so there won't be a shared instance that its fields always need to be updated. - Reduce unnecessary Region#translate if the offsets are zero. - For a simple activity launch, the invocation amount of setInputWindowInfo is reduced 90% (from 126 to 11). - The metrics updateInputWindows_mean of WmPerfTests is reduced 50%+ (from 0.89ms to 0.38ms on an old mid-end device). Bug: 168008622 Test: WindowStateTests#testUpdateInputWindowHandle WindowInputTests InternalWindowOperationPerfTest Change-Id: Ief84bbe6e6fa4da5309912059904932ccf775b75
* Block untrusted touches opt-inBernardo Rufino2020-10-051-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The feature is disabled by default and can be in one of 3 modes: disabled, permissive and block. In permissive we only log but don't block the touch. This knob is implemented in a global setting block_untrusted_touches. It can also be disabled per occluding app using app-compat infrastructure, so if you disable for a certain app, overlays of that app won't have the chance of blocking touches. More details on these on go/try-cross-uid-touches. Each window has 3 modes related to touch occlusion: ALLOW, USE_OPACITY or BLOCK_UNTRUSTRED. Check code comments for the meaning of each. If the feature is turned off for the app, then the mode is ALLOW. Else if it's a SAW, then it's USE_OPACITY. Else it's BLOCK_UNTRUSTED. These states are passed to InputDispatcher, who then perform the proper checks and blocks or not the touch. If input dispatcher deems the touch unsafe, depending on the feature mode, we filter out such touches and log a message to logcat. I also introduce a global (secure) setting MAXIMUM_OBSCURING_OPACITY_FOR_TOUCH which represents the maximum opacity allowed per UID that's obscuring the touch-consuming window according to some rules, which are discussed in topic CL for InputDispatcher code. This maximum is initially set to 0.8, but we'll be conducting local experiments to determine the final value. Test: atest WindowUntrustedTouchTest Test: atest inputflinger_tests inputflinger_benchmarks libinput_tests Test: go/try-cross-uid-touches for manual testing Bug: 158002302 Change-Id: I462858ad5f0d11b1261748489385e6409e38e4b1
* Rename InputWindowHandle hasFocus to focusableVishnu Nair2020-08-181-5/+2
| | | | | | | | | | | | | A window with hasFocus set to true, means the window can be focusable. The current name is confusing when mutliple windows set the field to true. Rename this to focusable and also remove canRecieveKeys field which is not used. Test: presubmit Test: drag freeform windows Bug: 151179149 Change-Id: I1b2354da0dc241d5e887e599e43f0426671289b8
* Unify dispatching timeout constantsSiarhei Vishniakou2020-08-041-1/+1
| | | | | | | | | | | | | | | | | | | | The same constant is defined today with slightly different names in both WindowMananagerService and ActivityTaskManagerService. To prevent proliferation, make a constant in aidl and use it here. Also, the two constants used to be in either nanoseconds or milliseconds. Make all constants in milliseconds because aidl does not support "const long", and 5 seconds' worth of nanoseconds does not fit into an int. Bug: 143459140 Test: interact with device after booting Test: adb shell dumpsys input Change-Id: Ia9b3f56d8eddcc6f2f0132bac9254655b180837f Change-Id: If4d40b63c41f6fb54b99d167da8db1924945f3ef
* Change InputWindowInfo::isTrustedOverlay() to be permission and flag basedChris Ye2020-05-191-0/+3
| | | | | | | | | Add private flag to WindowManager.LayoutParams. If the flag is set, check if caller has INTERNAL_SYSTEM_WINDOW permission. Bug: 155781676 Test: atest WindowManagerServiceTests Change-Id: I70151697cc01e8427129f951f0ebadc4805b2d56
* Remove layer from window handle since it's no longer usedchaviw2019-12-301-4/+0
| | | | | | Fixes: 146671630 Test: go/wm-smoke Change-Id: Ieae773147b1eb7d43fc2688d8570f98075dda8ea
* Replace client token with a new token in InputWindowHandleVishnu Nair2019-10-101-7/+3
| | | | | | | | | | | | | | | | | | | | The tokens are used to map input data to its window and its channel. Currently InputWindowHandle tokens uses the client IWindow binder token if the input is associated with a client window or a newly generated token for temporary surfaces (drag input surface), and windowless surfaces. These tokens are also used to send policy related events. From the token, it is not obvious what the token represents for which component. This is a cleanup cl that removes the use of client before adding an explicit token for handling policy related events. One use case of client token was to support pointer capture but this will move to using the input channel socket. Removing the client token allows windows to share its input token with other processes to enable features like transfer focus without leaking the client token. Bug: 134365580 Test: go/wm-smoke Test: atest PointerCaptureTest WindowFocusTests Change-Id: I49e4c54d977f98e855af9e7ed54443588fdb66c9
* Remove SurfaceControl#getHandle from JAVA apis 2/2Vishnu Nair2019-06-251-5/+3
| | | | | | | | | | | | Holding on to a reference of the handle in Java will keep the server-side surface alive until the reference is removed by GC. This may cause surfaces to be kept alive longer than necessary. Instead hold on the surface control and call SurfaceControl#release which will release the local reference to the server-side surface. Bug: 136004147 Test: go/wm-smoke Change-Id: Iff7d48ae1593cea2e188aa07c417f4c5a98887d5
* Input: Override touchable region bounds with surface bounds 1/2Vishnu Nair2019-03-121-1/+42
| | | | | | | | | | | | | | Take advantage of the surface flinger layer hierarchy to set touchable region. - Let a client set a surface touchable region to its own bounds. - Let a client set a surface touchable region to another surface bounds. - Let a client bound its touchable region to a surface. Test: go/wm-smoke Test: existing tests Change-Id: Id5ef8b35f4779861c1537811a045a44ee2394fdf
* Let the activity embedded in ActivityView can be directly touchedTiger Huang2019-01-301-2/+6
| | | | | | | | | | | | | | The goal is to eliminate the latency caused by forwarding the event. In this CL, we put an input portal window behind an ActivityView, and subtract the touchable region of the the ActivityView, so that the user can touch through the portal window, and let the touch arrive on the embedded activity. Bug: 120675821 Test: Manual test with ActivityViewTest Test: atest CtsActivityManagerDeviceTestCases:ActivityViewTest Change-Id: I6776387b65cf6a7d2ea60cb00ffdd38be22081ac
* Forward SurfaceInsets to InputWindowInfoRobert Carr2018-11-271-0/+2
| | | | | | | | | | | | So that SurfaceFlinger can set the appropriate frame. See frameworks/native commit and InputWindow.h for detailed discussion. Test: Manual Bug: 80101428 Bug: 113136004 Bug: 111440400 Change-Id: I5df12fa3f90335f2045ee7107d3b1242ff0d00c5
* Replace InputWindowInfo#inputChannel with an IBinder token.Robert Carr2018-11-271-2/+3
| | | | | | | | | | | | The IBinder token is now being used as the UUID for InputWindows. We can pass it around without the channel to avoid unnecessary FD parcelling, duping, and other juggling. Test: Existing tests pass. Bug: 80101428 Bug: 113136004 Bug: 111440400 Change-Id: I8eba3fa05f249b7dfcb5c3d9817241cbfe9ab76c
* WindowManager: Communicate with input system by WindowTokens.Robert Carr2018-11-141-5/+1
| | | | | | | | | | | | | | | | Once we switch to a model of passing InputWindowInfo through SurfaceFlinger, the handles will be parcelled and we will no longer receive the same literal object back from "interceptKeyBeforeQueueing" or other input callbacks. This means the approach of saddling a WindowState on to the object for later retreival will no longer work. Instead we pass the IBinder WindowState#mClient in when registering the input channel, and modify the input system to pass it back to us as a sort of UUID. Bug: 80101428 Bug: 113136004 Bug: 111440400 Test: Home button still works. Change-Id: I0f41e0d08b034aa037518c3a8fb21be1453565da
* Plumbing for SurfaceControl#setInputWindowInfo.Robert Carr2018-11-141-0/+127
The standard SurfaceControl plumbing, plus moving InputWindowInfo from the services jar to the framework jar so that it is accessible from SurfaceControl. Bug: 80101428 Bug: 113136004 Bug: 111440400 Test: None Change-Id: I3443a98cd04ac6b36977e1874641a34c6befca34
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-22 09:21:42 +0000