summaryrefslogtreecommitdiff
path: root/core/java/android/view/DragEvent.java
Commit message (Collapse)AuthorAgeFilesLines
* Add maxTargetSdk restriction to unused APIs.Mathew Inwood2020-10-291-3/+4
| | | | | | | | | | | | | | | | | | | 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-4/+3
| | | | | | | | | 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-3/+4
| | | | | | | | | | 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
* 1/ Add basic infra for global drag handling in the ShellWinson Chung2020-10-231-12/+89
| | | | | | | | | | | | | | | | | | | | | | | | - Add private window flag INTERCEPT_GLOBAL_DRAG_AND_DROP (protected by MANAGE_ACTIVITY_STACKS permission) to be considered as a part of the normal flow for global drag and drops even if the window is not visible. In addition, the window with the flag receives the clip data on DRAG_STARTED and the drag surface on DROP. If the window consumes the drop, then it will relinquish cleanup of the drag surface from the system. - Add MIMETYPE_APPLICATION_ACTIVITY for an app to report that they are starting a global drag of an activity. The associated data must include an intent with the pending intent and user to launch the activity for. - Add a test drag handler on the shell end to receive the drag, setup a drag layout, and just launch the intent (for now). Bug: 169894807 Test: atest DragDropControllerTest Test: atest DragDropTest Change-Id: I7f5cdca3cf515b693a8f1e507e90e22a670b5fa6 Merged-In: I7f5cdca3cf515b693a8f1e507e90e22a670b5fa6 Signed-off-by: Winson Chung <winsonc@google.com>
* 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
* All Parcelable CREATOR fields are @NonNull.Jeff Sharkey2019-02-281-1/+1
| | | | | | | | | If they were null, then the Parcelable would fail to work. Bug: 126726802 Test: manual Change-Id: I7929ffa2f20e5de1c8e68e8263cca99496e9d014 Exempt-From-Owner-Approval: Trivial API annotations
* 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
* Clarify that getLocalState is always valid for DragEventSiarhei Vishniakou2017-09-051-2/+3
| | | | | | | | | | | The method getLocalState() always returns valid data (if the data was stored in startDragAndDrop to begin with), but the documentation currently states that the events with action ACTION_DRAG_ENDED do not have valid local state. Bug: 62067188 Test: bit CtsViewTestCases:android.view.cts.DragDropTest Change-Id: Ia2f8e5e0bb068aa7ac4aac3f18a5cf01d1a73c32
* More fixes in drag/drop docs.Vadim Tryshev2016-09-301-11/+16
| | | | | | Bug: 31702571 Test: Built docs, inspected in Chrome. Change-Id: Ib7c421a6eacac5e352bbba64eedb9f8b689cbe60
* Update/correct Drag and Drop docs.Vadim Tryshev2016-09-231-13/+23
| | | | | | | | | | | This CL reflects the N MR1 behavior and fixes some bugs. Defining the compatibility behavior will be done separately. Bug: 31702571 Change-Id: I2a79871f47849f9f5a9c3377a3061208488e6ecb
* Merge "Eliminating the “black hole” effect with location/drop events." ↵TreeHugger Robot2016-09-201-0/+2
|\ | | | | | | into nyc-mr1-dev
| * Eliminating the “black hole” effect with location/drop events.Vadim Tryshev2016-09-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, a container view that doesn’t accept events, but has a child that accepts events, prevents its parent from receiving LOCATION/DROP events while the drag is over the container (but not the child). This is a bug. With this fix, such a container will prevent the parent from invoking a (second) LOCATION/DROP event only if the event was really delivered to any of its descendants. To know whether the event was delivered, I added DragEvent.mEventHandlerWasCalled member. EXITED/ENTERED events are now generated upon delivery of the event that has coordinates in it. Current view that has drag focus is now global to reflect the fact that it’s one per process. Bug: 31469490 Change-Id: I248e8d1de87b7734853136eb4719f7571cea91d5
* | Update JavaDoc for DragEvent.getLocalStateVladislav Kaznacheev2016-09-081-0/+4
|/ | | | | | | | Explicitly state that "local state" is local to the window which has started the drag operation. Bug: 31372686 Change-Id: Idbea7586c4e74097362067fa90390b97744181bb
* Fix docs for DragEventVladislav Kaznacheev2016-07-111-4/+4
| | | | | | | | Document that getClipDescription() and getLocaState() do not return valid data when getAction() == DragEvent.ACTION_DRAG_ENDED. Bug: 30016099 Change-Id: Id98fe8c5d6f052fc51c8c9e8d55329e162bd96b1
* Fix inconsistencies in DragEvent.getX/getY behavior and JavaDoc.Vladislav Kaznacheev2016-05-161-5/+6
| | | | | | | | | | Make getX/getY return view-relative position as specified in the class JavaDoc. Fix obvious errors in JavaDoc for getX/getY Bug: 28793547 Change-Id: Ic2ac646189711e7466594d4fc8326408fc0348e1
* Rename DropPermissions to DragAndDropPermissionsVladislav Kaznacheev2016-04-201-14/+16
| | | | | Bug: 28296057 Change-Id: Ic95cb4ae9c351d903df78628e983dec2bacd0ad5
* Bind DropPermissions life cycle to ActivityVladislav Kaznacheev2015-12-221-14/+3
| | | | | | | | | Move requestDropPermissions from DragEvent to Activity. Permissions will be granted using UriPermissionOwner associated with this activity and revoked when the activity is destroyed (if DropPermissions.release is not called before that). Change-Id: Ic8f8fc3f56f57e83b9bc34ae8c96d82c2c9c4e1d
* Rename and simplify DropPermissionHolderVladislav Kaznacheev2015-12-161-18/+25
| | | | | | | | | | Rename DropPermissionHolder to DropPermissions and move all server-side implementation details into a separate class. Rename DragEvent.getDropPermissionHolder to requestDropPermissions and make it take the permissions implicitly. Change-Id: Ia83f7cb8af07ce13ba9536d24b0f9d63331d8736
* Handle content URI permissions on dropVladislav Kaznacheev2015-09-161-6/+31
| | | | Change-Id: I846071f01ecd1eff8e3a54a1806e68e1a4b335d2
* docs: add developer guide cross-references, Project ACRE, Round 2Joe Fernandez2011-10-141-0/+6
| | | | Change-Id: I39a534ae3a2a34b4dabc333a09961012ef911d3e
* sdk doc change: Copy/Paste/Drag/DropJoe Malin2011-01-271-78/+250
| | | | Change-Id: Ifb9ed554ae1a72ce6badff1c79d95c02f30525e9
* Include the local state obj in ACTION_DRAG_STARTED eventsChristopher Tate2011-01-201-3/+4
| | | | | | | | | | | | | | | Fixes bug 3362502 The underlying cause was that the DragEvent.obtain() variant which clones an existing event was failing to copy the local state field. This change also moves the logic for inserting the local state object into DragEvents about to be dispatched from the Binder incall thread into the main-thread code sequence. This is to eliminate any potential SMP memory coherency issues around drag start vs incoming events needing to refer to the local state object. Change-Id: I368e8936dbf8a00b7d5cc19c2ef0101bd75b6b2d
* Fail more gracefully when window state changes during dragsChristopher Tate2011-01-191-1/+1
| | | | | | | | | | | | | | | In particular, if a new window was created out from under the drag, the drag-move event dispatch logic would wind up blithly assuming that it would find a valid touch-dispatchable window under the finger. When this was untrue, it would NPE, but the NPE was caught and discarded safely by higher-level guard code. With this change, we now avoid the NPE entirely and report the spurious condition as part of the debugging log stream. (Also add the local-state object to DragEvent.toString()'s output.) Change-Id: Idfa5f45d049e48415ee59c8b0ffb5b0ed4098ce3
* API CHANGE: drags can now carry an originator-only object payloadChristopher Tate2010-12-011-3/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | When calling startDrag(), the app can now supply an Object to be passed along in every DragEvent that the app winds up receiving itself. This object is *not* passed to any other applications; it's strictly app- local. The purpose is to allow state tracking/management to be done directly through the drag mechanism rather than requiring out-of-band code. An example of the utility here might be TextEdit widgets. A drag that starts in one TextEdit but ends in a different one should be treated as a copy/paste operation, where the originating TextEdit is not altered. However, a drag that starts and ends in the *same* TextEdit is a 'move' operation within that TextEdit; the text is removed from its original position and inserted at the drop point. To support this easily, the drag/drop code in TextEdit can now pass a pointer to the originating view as the local state object. Then, the drop recipient could tell whether the drag started within the same TextEdit without needing to implement any other out-of-band state tracking. This CL (and its accompanying CLs in a few other packages where the startDrag() API is being used) adds the new local-state parameter to the API, but does not actually change the behavior of any existing clients. Change-Id: Icba73b2ab4a650b7a94485a19633065b0ef9058c
* Hide DragEvent pool implementation and add docsChristopher Tate2010-11-191-3/+113
| | | | Change-Id: Idaead8ab604c69d6dbc1bd5de3afa86e1fae8396
* Report drag success/fail in the DRAG_ENDED messageChris Tate2010-10-211-7/+16
| | | | | | | | | | | | | DragEvent.getResult() returns 'true' if the drop was ultimately accepted; false otherwise. The validity of this datum is only guaranteed when the DragEvent's action verb is ACTION_DRAG_ENDED. Also fixes the drag-start timeout handling (though the offending app is not yet officially declared ANR). Implements bug 3097807 Change-Id: I6908ac628c72ff7d6193d87060d769a559a78d0e
* Fix obtain() when the pool is still emptyChris Tate2010-10-201-6/+12
| | | | | | Fixes bug 3116798 Change-Id: I187e79892cd2b60173ef4ebef5d2eab56eb5eb42
* Refinements to drag/dropChristopher Tate2010-10-041-2/+7
| | | | | | | | | | | | | | | | | | | Thumbnail measurement & drawing has been moved out into a delegate class called View.DragThumbnailBuilder. This consolidates the thumbnail-related code as well as ensuring that the drag initiator does not have to know a priori where to place the thumbnail relative to the touch point *before* the thumbnail measurement step, as was previously the case. startDrag() no longer needs to be told where the current touch point is at the time the drag is launched. Drag events are now dispatched only to VISIBLE views. Dispatch shouldn't double-recycle events any more when the target window is local to the system process. Change-Id: I49419103765a0cad2e18ddfcdd6dacb94daf1ff1
* Drag/drop APIs and infrastructureChristopher Tate2010-09-301-0/+186
A View initiates a drag-and-drop operation (hereafter just called a "drag") by calling its startDrag(ClipData) method. Within the processing of that call, two callbacks are made into the originating View. The first is to onMeasureDragThumbnail(). Similarly to the core onMeasure() method, this callback must respond by calling setDragThumbnailDimension(width, height) to declare the size of the drag thumbnail image that should be used. Following this, the View's onDrawDragThumbnail(canvas) method will be invoked to actually produce the bits of the thumbnail image. If all goes well, startDrag() will return 'true', and the drag is off and running. (The other arguments to startDrag() provide reconciliation between the current finger position and where the thumbnail should be placed on the screen relative to it.) Potential receipients of the ClipData behind the drag are notified by a new dispatch mechanism, roughly parallel to motion event dispatch. The core routine is the View's onDragEvent(event) callback, with the mechanics of dispatch itself being routed through dispatchDragEvent(event) -- as in the case of motion events, the dispatch logic is in ViewGroup, with leaf View objects not needing to consider the dispatch flow. Several different event 'actions' are delivered through this dispatch mechanism: ACTION_DRAG_STARTED: this event is propagated to every View in every window (including windows created during the course of a drag). It serves as a global notification that a drag has started with a payload whose matching ClipDescription is supplied with the event. A View that is prepared to consume the data described in this event should return 'true' from their onDragEvent() method, and ideally will also make some visible on-screen indication that they are a potential target of the drop. ACTION_DRAG_ENTERED: this event is sent once when the drag point enters the View's bounds. It is an opportunity for the View to set up feedback that they are the one who will see the drop if the finger goes up now. ACTION_DRAG_LOCATION: when the drag point is over a given View, that View will receive a stream of DRAG_LOCATION events, providing an opportunity for the View to show visual feedback tied to the drag point. ACTION_DRAG_EXITED: like DRAG_ENTERED, but called when the drag point leaves the View's bounds. The View should undo any visuals meant to emphasize their being the hovered-over target. ACTION_DROP: when the drag ends at a given point, the View under that point is sent this event, with the full ClipData of the payload. ACTION_DRAG_ENDED: paralleling the DRAG_STARTED action, this is the global broadcast that the drag has ended and all Views should return to their normal visual state. This happens after the DROP event. Change-Id: Ia8d0fb1516bce8c735d87ffd101af0976d7e84b6
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-12 22:11:49 +0000