summaryrefslogtreecommitdiff
path: root/core/java/android/view/InputEventReceiver.java
Commit message (Collapse)AuthorAgeFilesLines
* Change close guard logged messagesIoannis Ilkos2021-12-211-1/+1
| | | | | | | | | Unless we are looking at stack traces (e.g. from strict mode) it's not possible to identify which type of object is not being closed (most methods are 'close' or 'release). Change the logged text to clarify. Change-Id: Ib90eac716f43c2c2caf8d8c6fb64a7bd90562da9 Test: manual
* TouchMode (6.1/n) Fully detaching touch mode from focus eventAntonio Kantek2021-11-121-4/+2
| | | | | | | | | | | | | | | Note: ScreenshotTests properly exercises both IWindow#onFocusEvent and JNI InputEventReceiver. Bug: 193718270 Test: atest FrameworksCoreTests:ViewRootImplTest Test: atest com.android.server.wm.ScreenshotTests Test: atest FrameworksCoreTests Test: atest CtsInputMethodTestCases Test: atest CtsInputTestCases Test: atest CtsSecurityTestCases Test: atest CtsWindowManagerDeviceTestCases Change-Id: I63d973978a048498e59c8df34f624b623e8e9289
* Roll forward of "Revert "TouchMode (5/n) Implementing onTouchModeChanged""Antonio Kantek2021-11-041-2/+2
| | | | | | | | | | | | | This reverts commit 8e8e721f61625ae013da5fbae42f7f192083be04. Reason for revert: ViewRootImpl#windowFocusChanged to also change touch mode. Fixes: 173468133 Bug: 193718270 Test: atest FrameworksCoreTests CtsWindowManagerDeviceTestCases Change-Id: I21780b86574c395cd6c2c5c05a88078c050edb8c
* Revert "TouchMode (5/n) Implementing onTouchModeChanged"Yan-De Chen2021-11-041-2/+2
| | | | | | | | This reverts commit 487559898c52a9a3baed8dde6a2d26936bef4918. Reason for revert: Broken test(b/205063292) Change-Id: I477ab2ca44571d99f46fe53e38033a6746522c7e
* TouchMode (5/n) Implementing onTouchModeChangedAntonio Kantek2021-11-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | Changing touch mode will now have effect on every existing window (including sys UI windows). Manual testing steps (on gcar_emu): 1. Start emulator; 2. Ensure touch mode on by tapping anywhere in the status bar or nav bar; 3. Tap on the launcher icon in nav bar; 4. Tap on the 3 dots in the top right corner; 5. Tap on the Close button in the dialog; 6. Rotate clockwise once to enter rotary mode. This will exit touch mode and now with this CL it will have effect on the sys UI process; 7. When tapping on home button in the nav bar, sys ui will be in touch mode as expected. Fixes: 173468133 Bug: 193718270 Test: manual (see steps above) Test: atest FrameworksCoreTests:ViewRootImplTest Change-Id: If37cd5c48087f5a25d7b8cee8fe29a5e11d9d6ae
* TouchEvent (2/n): Receiving touch mode events in InputEventReceiverAntonio Kantek2021-08-091-0/+10
| | | | | | | | | This CL enhances InputEventReceiver to receive incoming TouchModeEvent from the transport layer. Bug: 191935212 Test: manual (build) Change-Id: I6dba5ab213f52e26c25d856a3cb8b27bfdb81d40
* Send input timeline from app to InputDispatcherSiarhei Vishniakou2021-03-241-4/+6
| | | | | | | | | | | | | | | | InputDispatcher will receive the timing information from the app. This timing information will contain: 1) inputEventId : the input event id that corresponds to the current set of times 2) gpuCompletedTime : the time at which gpu has finished processing the frame and the buffer is getting sent from the app to surfaceflinger 3) presentTime : time time at which the frame was displayed Bug: 169866723 Test: tested by printing the data that was passed Test: atest InputEventSenderAndReceiverTest Change-Id: I9bf38473d07c7bd4df3de6bc77b0173faa257f06
* Move drag event to InputDispatcher (2/n)arthurhung2021-03-091-0/+10
| | | | | | | | | | This CL adds the ability to receive a DRAG event through the InputChannel, and adds the appropriate processing logic to InputEventReceiver. Bug: 158242495 Test: atest libinput_tests Change-Id: I94d5fa545d920be52e03702d0d24712fd11c497c
* Pass actual present time to ViewRootImplSiarhei Vishniakou2021-03-051-0/+10
| | | | | | | | | | | | | | | | To measure end-to-end touch latency, we need to report the actual present time to ViewRootImpl. ViewRootImpl, in turn, will report this information to InputDispatcher. Finally, InputDispatcher will combine all known information for a specific input event, and will report this data to westworld. In another patch, we will add a new call, 'reportLatencyInfo', to InputPublisher. This call will allow the app to send this latency data to InputDispatcher. Bug: 169866723 Test: printed the input event present times inside ViewRootImpl Change-Id: Ibd3a2cfeb1a340eb15cd2165071df1f8589634af
* SyncPointerCapture (4/n): Receive capture events in InputEventReceiverPrabir Pradhan2020-11-171-0/+14
| | | | | | | | | Since a capture event was added to the InputChannel, this CL lets InputEventReceiver receive the capture events sent by the publisher. Bug: 141749603 Test: build, crosshatch boots Change-Id: I608f3cf86d96e4d2b00b28f88fa2b7aa6e83b6dc
* Add maxTargetSdk restriction to unused APIs.Mathew Inwood2020-10-291-2/+3
| | | | | | | | | | | | | | | | | | | These are APIs that have @UnsupportedAppUsage but for which we don't have any evidence of them currently being used, so should be safe to remove from the unsupported list. This is a resubmit of ag/12929664 with some APIs excluded that caused test failures; see bugs 171886397, 171888296, 171864568. APIs excluded: Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord; Landroid/os/Process;->myPpid()I Landroid/os/SharedMemory;->getFd()I Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I Bug: 170729553 Test: Treehugger Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
* Revert "Add maxTargetSdk restriction to unused APIs."Hongwei Wang2020-10-281-3/+2
| | | | | | | | | This reverts commit 72f07d6a8a32db4a0dedd7682a0b3385be2b9cd6. Reason for revert: Droidcop-triggered revert due to breakage https://android-build.googleplex.com/builds/quarterdeck?testMethod=testAppZygotePreload&testClass=android.app.cts.ServiceTest&atpConfigName=suite%2Ftest-mapping-presubmit-retry_cloud-tf&testModule=CtsAppTestCases&fkbb=6936597&lkbb=6936969&lkgb=6936551&testResults=true&branch=git_master&target=cf_x86_phone-userdebug>, bug b/171886397 Bug: 171886397 Change-Id: Ibe0f0430a3451477c1ee8ef56a596e91ea1e7672
* Add maxTargetSdk restriction to unused APIs.Mathew Inwood2020-10-271-2/+3
| | | | | | | | | | These are APIs that have @UnsupportedAppUsage but for which we don't have any evidence of them currently being used, so should be safe to remove from the unsupported list. Bug: 170729553 Test: Treehugger Change-Id: I4c8fd0006f950de9955242e93968fb0996ceb372
* Add dump of InputConsumer to ViewRootImplSiarhei Vishniakou2020-08-211-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To further debug ANR issues, add dump of InputConsumer-related objects to ViewRootImpl Example dump: android.view.ViewRootImpl$WindowInputEventReceiver mInputChannel: 25697fd com.google.android.pixel.setupwizard/com.google.android.pixel.setupwizard.user.WelcomeActivity (client) mSeqMap: {} mReceiverPtr: mInputConsumer: mResampleTouch = true mChannel = 25697fd com.google.android.pixel.setupwizard/com.google.android.pixel.setupwizard.user.WelcomeActivity (client) mMsgDeferred: false Batches: <empty> mSeqChains: <empty> mBatchedInputEventPending: false mFinishQueue: <empty> Choreographer: mFrameScheduled=false mLastFrameTime=1625545 (8 ms ago) Bug: 160561987 Test: adb shell dumpsys activity -v all | grep -i input -C 50 Test: adb shell dumpsys activity service SystemUIService | grep -i EventReceiver -C 20 Change-Id: I99807c264ced8eb939b90a30e2ff91775fbdec40
* Pass source to dispatchBatchedInputEventPending (1/2)Arthur Hung2020-03-171-8/+2
| | | | | | | | | | | | The API requestUnbufferedDispatch allow View could receive the event in unbuffered way. But doing processUnbufferedRequest in onInputEvent is too late for the first event. Instead, we should pass the source of the input event up to onBatchedInputEventPending, and then we can use that to determine whether we could consume event immediately or not. Bug: 149715123 Test: atest ViewUnbufferedTest Change-Id: I4344a99de77d3758cc7d1df155394c89fa828f2e
* Move focus dispatch to input (2/2)Siarhei Vishniakou2020-01-101-3/+21
| | | | | | | | | | | | | | | Input now tells the app when it has focus. Touch mode information will now also be sent to the apps through input. When a key targeting a non-focused display is processed, run the 'moveDisplayToTop' synchronously to ensure that setInputWindows with the correct window focus information is completed. This would ensure that the focus event is enqueued before the key event. Bug: 70668286 Test: atest WindowFocusTests Change-Id: Iff0b88a05441b29834741aa3dfae31d55871ddd6
* Call InputEventReceiver.dispose from the right threadTiger Huang2019-12-231-0/+3
| | | | | | | | | | | | | | | | | | TaskPositioner attaches the InputEventReceiver to the animation thread. This CL makes it to dispose the receiver in the same thread to avoid race conditions. This CL also makes InputEventReceiver.finalize call dispose from the right thread. Bug: 122054478 Fix: 122096091 Test: 1. Make a task enter free-form mode. 2. Drag and drop the task. 3. Check if InputEventReceiver.dispose and finishInputEvent are executed in the same thread. Change-Id: I2f8831e7fccca4f96562f2abe4962811339d02e9
* Use new UnsupportedAppUsage annotation.Artur Satayev2019-12-181-1/+1
| | | | | | | | Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library. Bug: 145132366 Test: m && diff unsupportedappusage_index.csv Change-Id: I5be7335b23a92b8ac80d2fd890198273b66ad644
* Update input policy to handle embedded windowsVishnu Nair2019-11-071-0/+11
| | | | | | | | | | | | | | | ANR - If embedded windows are slow in handling inputs the system should blame the embedded app. PointerDownOutsideFocus - if a user taps outside the currently focused window onto an embedded window, treat it as if the host window was tapped. Rename blessInputSurface -> grantInputChannel and add a name to embedded windows. Bug: 134365580 Test: b WindowlessWmTest Test: atest CtsWindowManagerDeviceTestCases:WindowlessWmTests Change-Id: If88970cf6ce17669b41fec995535151a492fab12
* Dispose InputChannel when dispose InputEventReceiverArthur Hung2019-07-261-1/+5
| | | | | | | | | | | | There would be an error if an InputChannel didn't be disposed before finalized. The client InputChannel created by ViewRootImpl or SystemUI that would also create an InputEventReceiver to receive input events, and hold the client InputChannel, so if the InputEventReceiver is going to be disposed, the InputChannel should be disposed as well. Test: manual Bug: 128679213 Change-Id: I24c16f032403e8a982a84a5e0adbfabcdc016f0f
* Add @UnsupportedAppUsage annotationsMathew Inwood2018-08-201-0/+4
| | | | | | | | | | | | | | | | | | | | | | For packages: android.view.textservice android.view.textclassifier.logging android.view.textclassifier android.view.inputmethod android.view.autofill android.view.accessibility android.view This is an automatically generated CL. See go/UnsupportedAppUsage for more details. Exempted-From-Owner-Approval: Mechanical changes to the codebase which have been approved by Android API council and announced on android-eng@ Bug: 110868826 Test: m Change-Id: I4147b038ed7adf0311ee9918b44766f82a057eaf
* Move display id into MotionEventSiarhei Vishniakou2018-03-061-4/+3
| | | | | | | | | Display id is now part of MotionEvent. Test: atest view.MotionEventTest view.KeyEventTest Bug: 64258305 Change-Id: Ifadd6b34f4dd5a91669baf146daa62944d1de974
* Fix keyboard focus in VRTarandeep Singh2017-08-021-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Consider this VirtualDisplay (VD) scenario: HostActivity creates a VD which holds SettingsActivity. When EditText on SettingsActivity is tapped, it gains focus. On eventual taps, it loses focus i.e. the Window in VD loses focus and the host activity in primary display gets the focus instead. This happens because WM's TaskTapPointerEventListener.onPointerEvent() is called on the default display only. Root cause: 1. Tap detector isn't registered for non-default display. 2. Tap detector has no info on which displayId touch was received. 3. InputFlinger doesn't deliver InputMonitor events for non-default displays (fixed in a separate CL) Fixing above results in onPointerEvent(MotionEvent) to deliver the Touch events successfully to VD. We restrict these changes to physical multi-displays and VR VirtualDisplays (which uses virtual touch device). [VrManagerService calls WMInternal.setVr2dDisplayId(int)] In future, displayId should be part of InputEvent. Bug: 64258305 Bug: 62033391 Test: bit FrameworksServicesTests:com.android.server.wm.DisplayContentTests Change-Id: I3626f4de5aa9bcf905da9abd39f3ab1baefc4c48
* Fix import statement in view|transition|animation packages.Aurimas Liutikas2016-10-121-2/+2
| | | | | | | This change also remove trailing whitespace. Test: code still compiles Change-Id: I7eff4546320d67d2bae58d31bad0625ea0791b8f
* AArch64: Use long for pointers in view/input classesAshok Bhat2014-01-091-5/+5
| | | | | | | | | | | | | | For storing pointers, long is used in view/input classes, as native pointers can be 64-bit. In addition, some minor changes have been done to conform with standard JNI practice (e.g. use of jint instead of int in JNI function prototypes) Change-Id: Iafda9f4653c023bcba95b873637d935d0b569f5d Signed-off-by: Ashok Bhat <ashok.bhat@arm.com> Signed-off-by: Marcus Oakland <marcus.oakland@arm.com> Signed-off-by: Kévin PETIT <kevin.petit@arm.com>
* Speculatively schedule input consumptionMichael Wright2013-10-261-3/+6
| | | | | | | | | | | | | | | | | | | | | With the new tuned vsync offset, vsyncs are likely to occur shortly after the input is received, meaning we will empty the input queue, and thus won't schedule input consumption until more input is received. If an application then speculatively posts draw commands to the main looper faster than 60 hz, it will eventually end up blocking in eglSwapBuffers. Since we're blocking in eglSwapBuffers, we won't even schedule consumption until after the current frame (8-16ms), and it's entirely likely we won't actually get around to consuming input until after the next frame (another 16 ms of latency). This means we can often go 16-32ms without processing any input events, causing very noticeable amounts of jank. Rather than waiting for the next input event to schedule input consumption, speculatively schedule it every frame as long as we've consumed some motion batch during this frame. Bug: 11398045 Change-Id: I25e46308e00e9f9de00a1d8906f6b0e0f2e845b4
* Fix reference cycle in InputEventReceiver and Sender.Jeff Brown2013-04-021-2/+5
| | | | | | | | | | | | If the receiver or sender was not properly disposed, then the underlying input channel might be leaked because the native peer was holding a strong reference to the object. Switched to using a weak reference. Also updated Binder to use a new helper created for this purpose. Change-Id: I19680bf96d0548777bff02aa1d91874d1e8e41da
* Fix improper use of CloseGuard.Jeff Brown2012-08-271-1/+9
| | | | Change-Id: I37131a86e27a4be55956384a3566de9dcfd90fe5
* Resample touch events on frame boundaries.Jeff Brown2012-04-271-4/+8
| | | | | Bug: 6375101 Change-Id: I8774e366306bb2b6b4e42b913525bf25b0380ec3
* Implement batching of input events on the consumer side.Jeff Brown2012-02-131-9/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | To support this feature, the input dispatcher now allows input events to be acknowledged out-of-order. As a result, the consumer can choose to defer handling an input event from one device (because it is building a big batch) while continuing to handle input events from other devices. The InputEventReceiver now sends a notification when a batch is pending. The ViewRoot handles this notification by scheduling a draw on the next sync. When the draw happens, the InputEventReceiver is instructed to consume all pending batched input events, the input event queue is fully processed (as much as possible), and then the ViewRoot performs traversals as usual. With these changes in place, the input dispatch latency is consistently less than one frame as long as the application itself isn't stalled. Input events are delivered to the application as soon as possible and are handled as soon as possible. In practice, it is no longer possible for an application to build up a huge backlog of touch events. This is part of a series of changes to improve input system pipelining. Bug: 5963420 Change-Id: I42c01117eca78f12d66d49a736c1c122346ccd1d
* Remove type tests when recycling input events.Jeff Brown2011-12-031-11/+1
| | | | Change-Id: I1c2d5980a763c457a0546bbf601e686c601a4c03
* Refactor InputQueue as InputEventReceiver.Jeff Brown2011-12-011-0/+151
This change simplifies the code associated with receiving input events from input channels and makes it more robust. It also does a better job of ensuring that input events are properly recycled (sometimes we dropped them on the floor). This change also adds a sequence number to all events, which is handy for determining whether we are looking at the same event or a new one, particularly when events are recycled. Change-Id: I4ebd88f73b5f77f3e150778cd550e7f91956aac2
generated by cgit v1.2.3 (git 2.25.1) at 2025-12-21 17:26:23 +0000