Due to more complex window layouts resulting in lots of overlapping
windows, the policy around FLAG_WINDOW_IS_OBSCURED has changed to
only be set when the point at which the window was touched is
obscured. Unfortunately, this doesn't prevent tapjacking attacks that
overlay the dialog's text, making a potentially dangerous operation
seem innocuous. To avoid this on particularly sensitive dialogs,
introduce a new flag that really does tell you when your window is
being even partially overlapped.
We aren't exposing this as API since we plan on making the original
flag more robust. This is really a workaround for system dialogs
since we generally know their layout and screen position, and that
they're unlikely to be overlapped by other applications.
Bug: 26677796
Change-Id: I9e336afe90f262ba22015876769a9c510048fd47
This fixes a bug where a View with filterTouchesWhenObscured will have
all touches filtered when in magnification accessibility mode. This is
due to magnification being a separate Window over top of the running
Activity. The method onFilterTouchEventForSecurity in View will then
always return false when filterTouchesWhenObscured is enabled on the
View. By adding the magnification Window to the list of Trusted Overlays
we can ensure that touches will work properly with this property
enabled.
This corresponds to AOSP change
I07706588a625682d05da5cb19f401139eb08a54c
Change-Id: Iba095433a1f9045349d1b47a58a33b850ed31c97
Add all of the underlying input system pieces, minux PointerController and
SpriteController, to inputflinger. This is in preparation for moving input to
its own process and the addition of the input HAL.
Try 2.
Change-Id: I5f571fe86eb570885ae994e1f0552fb558930346
Add all of the underlying input system pieces, minux PointerController and
SpriteController, to inputflinger. This is in preparation for moving input to
its own process and the addition of the input HAL.
Change-Id: I1419a740b38756bd0d54fef5f5ca337e6815b1b0
