Bug #7222476
There were two issues:
- Blending was ignored with color filters
- The addition vector of a color filter was treated as integer values
instead of float values
Change-Id: Id94065704a30ee8aaaa5724a9f3a3cff7c50ced7
This also fixes up the drag regions so that quick settings
is only assigned the right 1/3 of the display (or 100dp,
whichever is larger). It had been that more than half of the
status bar, when dragged, would pull down QS.
Bug: 7217002
Change-Id: I515b6e19deab305b99784c7287d8f04fa9b22dc7
Keyguard wasn't resetting dpm's count when a successful password
was made. The result is the device would get wiped earlier than
it should.
Also fixes a TODO left over from keyguard refactoring that
allowed face unlock to trigger the same logic (ouch!).
Fixes bug 7219258
Change-Id: I2bd13c50a9beb8225d3237e86d5e34b73d0eb3cf
1. The active window for accessibility purposes is the either the
window the user is touching or the window that has input focus. We
were using the touch exploration gesture end event to figure
when the user stops touching the screen so we can set the active
window to the input focused one. However, we do not send such
gesture end if the user does not touch explore. If the user only
taps we do not consider this touch exploring. We now have dedicated
accessibility events for first and last touch and this change uses
them as a guide when to update the active window.
bug:6523219
Change-Id: I6262c0c5f408b02dbaa127664e4b426935d7f81f
1. The crash was happening if: two active pointers are performing a drag;
there are some inactive pointers down; the main dragging pointer (we are
merging the dragging pointers into one) goes up; now an inactive pointer
goes up and the explorer tries to inject up for the dragging pointer
which is no longer in the event resulting in a crash. Basically two
problems: inactive pointers were not ignored; 2) having only one
active pointer should not only send the up event but also transition
the explorer in touch exploring state.
bug:6874128
Change-Id: I341fc360ebc074fe3919d5ba3b98ee5cb08dd71e
Required wiring up startActivitiesAsUser()
Bug: 7224950
Also fix a bug in navigateUp in secondary user
Change-Id: I114ae2de0457362d62e899fdb94b12239a3eb778
1. The keyguard force hides some windows when it is shown and as soon
as the keyguard goes away there windows are made visible. However,
the window transition that the keyguard is moving away is reported
before the force hidden windows are shown which makes the screen
magnifier compute the magnified region with an incomplete list of
windows of interest.
bug:7215285
Change-Id: I3abc4d97b7a74de8183ad20477dadf66c82da037
This one got left out in the last round of method hiding.
This got lost in the last round of method hiding.
Change-Id: I3c6aa234dd29933cb32d0cd91830d47289e7e639
If any window on the default display has focus, then it
gets focus as usual. If no window on the default display
has focus, then we consider windows on the secondary display.
In the future we will need more elaborate schemes for
managing focus across multiple displays, but this is enough
for testing purposes now.
Bug: 7183618
Change-Id: I21ddb9904eb9e574e42d28743aeca51f4ffebf64
This is a simple hack for testing and development purposes.
It makes the framework place the main window of an activity
on to a secondary display instead of on the default display.
Set the "debug.second-display.pkg" to a substring of the
package name of the activity that you want to have show
up on the secondary display, such as "com.example.android.apis"
Bug: 7183618
Change-Id: I0a9e7f27c8ff253253b9de57d4bc49f31d95a0e2
When Activity#getParentActivityIntent() returns an Intent without an
explicit target, resolve it in order to determine a correct parent
stack.
Bug 7223318
Change-Id: I3e88129f1e538cc3d932d6b4f735a5bec54bb4ad
