IssueTracker

As a work-around, you can override dispatchDragEvent in the ViewGroup that's being cheated the events:

    @Override
    public boolean dispatchDragEvent(DragEvent ev){
        boolean r = super.dispatchDragEvent(ev);
        if (r && (ev.getAction() == DragEvent.ACTION_DRAG_STARTED
                    || ev.getAction() == DragEvent.ACTION_DRAG_ENDED)){
            // If we got a start or end and the return value is true, our
            // onDragEvent wasn't called by ViewGroup.dispatchDragEvent
            // So we do it here.
            onDragEvent(ev);
        }
        return r;
    }


Looking at the source more I'm beginning to think that maybe the current behavior is intentional. (Which is a little frightening to me.) If it is though; I think it should be at least mentioned in the documentation. As of now the docs give more of the impression that the started and ended events are guaranteed.

Although even that is not true. If a view is added or set to visible during a drag it may receive the ended event, but never the started event. And if you do either of the aforementioned during an ended event you'll likely get a ConcurrentModificationException. But that's a separate bug.

I'm glad this is recorded here and someone figured out it was a bug and the cause of it because I've been stumbling around trying to figure out this issue in our app. Can't believe it's been 2 years and it's still around.

The only children Views I drag around are EditText's (which normally have this exact problem because of their onDragEvent() imlementation), thankfully I already needed to subclass them so I can easily override their onDragEvent() method to simply return false in all cases:

    @Override
    public boolean onDragEvent(DragEvent event) {
        return false;
    }

Note: this skips all the original source code that is in TextView.onDragEvent() so there may be side-effects, but I haven't noticed any missing functionality in my use cases. In fact, by skipping the source code you avoid a nasty NPE crash that happens when trying to drag around EditText widgets, see issue 36935316 for details.

I also ran into this issue.  

As noted by the original poster, the doc and code are inconsistent -- either one or the other should be changed.  It seems that two years would be sufficient time to at least add a two sentence note to the documentation.

What is the status of this?

still no news about this bug?

[Comment deleted]

I'm running into this bug and don't really find a way to deploy the work around, the dragged view is never receiving events from the system during the drag operations.
I need to make the view visible when the drag ended.

Same here. On the start of drag and drop event i make receiver view visible, at the end of it it's gone. Works for the first time, but after visibility is changed - never receive start event.
Seems like nothing is going to change about this issue.

Thank you for your feedback. We have tried our best to address the issue reported, however our product team has shifted work priority which doesn't include this issue. For now, we will be closing the issue as "Won't Fix (Obsolete)". If this issue still currently exists, we request that you log a new issue along with the latest bug report here: https://goo.gl/TbMiIO and reference this bug for context.