Obsolete
Status Update
Comments
lb...@gmail.com <lb...@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.
ch...@google.com <ch...@google.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.
Description
An alternate form of library referencing should be used that is workspace-relative rather than filesystem-relative.
I found this bug while grading student assignment submissions. I provided a common library for business logic. Some students put this in a different directory than their projects, while others put it in the same directory. When I imported their projects to grade, several did not compile. This could be a big problem for development teams if they do not lay out their working directories the same way.
Host OS: Windows 7
SDK tools version (available in the "About" section of the 'android' tool
UI): Rev 20
Eclipse version: 3.7.2
ADT plug-in version: 20.0.0.v201206242043-391819
Platform targeted by your project: 2.2
Version of the platform running in the emulator: sdk-eng 2.2 FRF91 43546 test-keys
STEPS TO REPRODUCE:
1. User 1 creates app App1 in /dev/workspace
2. User 2 creates library Lib1; sends to User 1
3. User 1 puts Lib1 in /tools/libs (his workspace)
4. User 1 imports Lib1 into workspace (non-copy)
5. User 1 makes App1 reference Lib1 as a library project
App1 project.properties contains
android.library.reference.1=../../libs/Lib1
6. User 1 sends App1 to User 2
7. User 2 imports App1 into /dev/workspace
8. App1 cannot find Lib1 (it looks for /dev/libs/Lib1)
EXPECTED RESULTS:
If App1 and Lib1 are in the same Eclipse workspace, App1 should be able to find Lib1, regardless of the actual directories containing App1 and Lib1.
OBSERVED RESULTS:
App1 requires Lib1 to be in the same filesystem-relative location for all developers.