IssueTracker

After scouring the source code, I found the source of the issue:

https://github.com/android/platform_frameworks_base/blob/79e0206ef3203a1842949242e58fa8f3c25eb129/services/input/InputDispatcher.cpp#L1417

    // Check whether windows listening for outside touches are owned by the same UID. If it is
    // set the policy flag that we will not reveal coordinate information to this window.
    if (maskedAction == AMOTION_EVENT_ACTION_DOWN) {
        sp<InputWindowHandle> foregroundWindowHandle =
                mTempTouchState.getFirstForegroundWindowHandle();
        const int32_t foregroundWindowUid = foregroundWindowHandle->getInfo()->ownerUid;
        for (size_t i = 0; i < mTempTouchState.windows.size(); i++) {
            const TouchedWindow& touchedWindow = mTempTouchState.windows[i];
            if (touchedWindow.targetFlags & InputTarget::FLAG_DISPATCH_AS_OUTSIDE) {
                sp<InputWindowHandle> inputWindowHandle = touchedWindow.windowHandle;
                if (inputWindowHandle->getInfo()->ownerUid != foregroundWindowUid) {
                    mTempTouchState.addOrUpdateWindow(inputWindowHandle,
                            InputTarget::FLAG_ZERO_COORDS, BitSet32(0));
                }
            }
        }
    }

--------------------------

It seems as though if the "outside touch" lands in a view that doesn't share its UID with the view that's listening for outside touches, the event coordinates are set to 0,0. This is definitely purposeful, but there are two points I want to raise:

1. This should definitely be mentioned in the docs, because right now they paint an incomplete picture.

2. Is this really needed from a security perspective? I'm far from well-versed in platform security so bear with me, but I don't see much a malicious app can do with this information... As far as I can tell, there's about nothing else an app can "see" outside of its own process, so what use is that touch information if the app can't "see" what you're tapping on?

Also, I rescind my previous observation about 4.1.2. That version returns 0,0 for the event location too.

I really appreciate what Android releases give us to develop apps. It's a constant and huge effort for us to easily develop apps. But as long as you, Google, comb every app on market out, looking for sassy or ilegal behaviours, kicking off those you decide to be not allowed, you SHOULD also take care of your politeness and sincerity to every well behaved developer.

I'm upset too with this documentation mistake. To me it sadly seems to be a lack of transparency, not a mistake writing docs. When I read in documentation

"Note that you will not receive the full down/move/up gesture, only the location of the first down as an ACTION_OUTSIDE."

It has no room for mistakes when writing it. It is clear: nothing, but location of dirst down event, is returned. Hence, give us what you say you are giving us. Otherwise, correct documentation, please.

I understand security is a top priority. But it seems you don't want us all building up useful apps on areas you don't want us to be.

Security would have been concerned if an app could inject clicks into another. But reading them? Sorry, but I disagree. As we all know, Google releases SDK's with no warranty, among a long list of legal terms. This mistake is covered by your license agreement. Should we kick you Google off, by your lack of sincerity in documentation? Well, depends on who reads these lines, me or a Google in charge member. Sad anyway.

It is a bad Idea to block all the touch event from apps. This makes developer unable to create useful system apps.

i know its late to reply but here how it works
add this flag to your windowsManager WindowManager.LayoutParams.FLAG_WATCH_OUTSIDE_TOUCH

and override onTouchEvent and check  if (event.getAction() == MotionEvent.ACTION_OUTSIDE).  this is how i managed to find away to solve this after few hours.

Thank you for reporting this issue. At this time it appears this feedback is no longer relevant with the latest version of Android Studio. If you continue to experience this issue please open a new bug and we can reinvestigate