Obsolete
Status Update
Comments
el...@gmail.com <el...@gmail.com> #2
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.
// 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.
ku...@gmail.com <ku...@gmail.com> #3
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.
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.
[Deleted User] <[Deleted User]> #4
It is a bad Idea to block all the touch event from apps. This makes developer unable to create useful system apps.
ko...@gmail.com <ko...@gmail.com> #5
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.
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.
en...@google.com <en...@google.com>
pe...@live.fr <pe...@live.fr> #6
@kosh20...@gmail.com
Could you share your solution because you seem to have achieved what i'm trying to do.
Could you share your solution because you seem to have achieved what i'm trying to do.
Description
public class OverlayExampleService extends Service {
private View layerView;
private WindowManager.LayoutParams wParams;
private WindowManager wm;
Animation anim = null;
@Override
public void onCreate() {
super.onCreate();
wParams = new WindowManager.LayoutParams(
150, 150, //Arbitrary size
WindowManager.LayoutParams.TYPE_SYSTEM_ALERT,
WindowManager.LayoutParams.FLAG_NOT_FOCUSABLE|WindowManager.LayoutParams.FLAG_NOT_TOUCH_MODAL|WindowManager.LayoutParams.FLAG_WATCH_OUTSIDE_TOUCH,
PixelFormat.TRANSLUCENT); //TODO: NOT_FOCUSABLE needed?
wm = (WindowManager) getSystemService(WINDOW_SERVICE);
LayoutInflater inflater = (LayoutInflater) getSystemService(LAYOUT_INFLATER_SERVICE);
layerView = inflater.inflate(R.layout.overlay, null);
layerView.setOnTouchListener(new OnTouchListener() {
@Override
public boolean onTouch(View v, final MotionEvent event) {
System.out.println("LayerView event loc: " + event.getX() + ", " + event.getY());
System.out.println("Raw event loc: " + event.getRawX() + ", " + event.getRawY());
return false;
}
});
// Add layout to window manager
wm.addView(layerView, wParams);
}
@Override
public int onStartCommand(Intent intent, int flags, int startID) {
return START_STICKY;
}
@Override
public void onDestroy() {
if (wm == null) wm = (WindowManager) getSystemService(WINDOW_SERVICE);
wm.removeView(layerView);
wParams = null;
layerView = null;
super.onDestroy();
}
@Override
public IBinder onBind(Intent intent) {
return null;
}
}
------------------------------------------
public class OverlayExampleActivity extends Activity implements OnCheckedChangeListener{
@Override
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity);
((CheckBox) findViewById(R.id.checkBox)).setOnCheckedChangeListener(this);
}
@Override
public void onCheckedChanged(CompoundButton buttonView, boolean isChecked) {
Intent serviceIntent = new Intent(this, OverlayExampleService.class);
if (isChecked) startService(serviceIntent);
else stopService(serviceIntent);
}
}
----------------------------------
From docs (
"Window flag: if you have set FLAG_NOT_TOUCH_MODAL, you can set this flag to receive a single special MotionEvent with the action MotionEvent.ACTION_OUTSIDE for touches that occur outside of your window. Note that you will not receive the full down/move/up gesture, only the location of the first down as an ACTION_OUTSIDE."
-----------------------------------
Similar reports:
------------------------------------
I tested the above code on Android 4.4 (Motorola Droid Razr Maxx) and received the buggy behavior. I also tested on 4.1.2 (Motorola Droid Razr) and DID get location data as I should. So, based on the SO question above, it seems the problem only affects 4.2+.
Also, attached adb bugreport output.