Made it possible for individual windows to disable pointer gestures
while the window has focus using a private API.
Cleaned up the InputReader configuration code to enable in-place
reconfiguration of input devices without having to reopen them all.
This change makes changing the pointer speed somewhat nicer since the
pointer doesn't jump back to the origin after each change.
Change-Id: I9727419c2f4cb39e16acb4b15fd7fd84526b1239
First step of improving app screen size compatibility mode. When
running in compat mode, an application's windows are scaled up on
the screen rather than being small with 1:1 pixels.
Currently we scale the application to fill the entire screen, so
don't use an even pixel scaling. Though this may have some
negative impact on the appearance (it looks okay to me), it has a
big benefit of allowing us to now treat these apps as normal
full-screens apps and do the normal transition animations as you
move in and out and around in them.
This introduces fun stuff in the input system to take care of
modifying pointer coordinates to account for the app window
surface scaling. The input dispatcher is told about the scale
that is being applied to each window and, when there is one,
adjusts pointer events appropriately as they are being sent
to the transport.
Also modified is CompatibilityInfo, which has been greatly
simplified to not be so insane and incomprehendible. It is
now simple -- when constructed it determines if the given app
is compatible with the current screen size and density, and
that is that.
There are new APIs on ActivityManagerService to put applications
that we would traditionally consider compatible with larger screens
in compatibility mode. This is the start of a facility to have
a UI affordance for a user to switch apps in and out of
compatibility.
To test switching of modes, there is a new variation of the "am"
command to do this: am screen-compat [on|off] [package]
This mode switching has the fundamentals of restarting activities
when it is changed, though the state still needs to be persisted
and the overall mode switch cleaned up.
For the few small apps I have tested, things mostly seem to be
working well. I know of one problem with the text selection
handles being drawn at the wrong position because at some point
the window offset is being scaled incorrectly. There are
probably other similar issues around the interaction between
two windows because the different window coordinate spaces are
done in a hacky way instead of being formally integrated into
the window manager layout process.
Change-Id: Ie038e3746b448135117bd860859d74e360938557
In Honeycomb we introduced navigation controls in the status
bar, for xlarge devices without physical buttons. What about
phones? The status bar is pretty cramped already, and
besides, it's at the top of the display most of the time,
not at the bottom where your thumb is likely to be.
Enter the navigation bar. It's a new window type that
appears atop almost everything (including the keyguard); the
window manager subtracts its rectangle from the default
visible rectangle of other windows (including the status bar
and notification shade).
However, it behaves (on phones) like the status bar in that
applications that request fullscreen windows can get access
to those pixels. Well, almost; they need cooperation from
the navigation bar implementation to make the navbar
disappear, just like the status bar.
The current SystemUI implementation of the navigation bar on
phones is still rough, but it has the basics:
+ back, home, and menu keys (NB: we're showing menu all the
time right now because checking the api level of the
package owning the top window is currently a poor
indicator of whether the app requires the menu key)
+ it tries to stick to the same physical end of the device,
regardless of device orientation (on a phone, this is
the strip of land closest to the microphone)
Change-Id: Ic613a3351220af0bbfbdef63e1d99cbefd5ed1c2
This enables the system bar to carve out a region through which
events will be sent to the IME behind it.
Bug: 3238092
Change-Id: I69b855a8d9b5b3ee525266c0861826e53e5b5028
This change implements two heuristics.
1. When events are older than 10 seconds, they are dropped.
2. If the application is currently busy processing an event and
the user touches a window belonging to a different application
then we drop the currently queued events so the other application
can start processing the gesture immediately.
Note that the system takes care of synthesizing cancelation events
automatically for any events that it drops.
Added some new handle types to allow the native dispatcher to
indirectly refer to the WindowManager's window state and app window
token. This was done to enable the dispatcher to identify the
application to which each window belongs but it also eliminates
some lookup tables and linear searches through the window list
on each key press.
Bug: 3224911
Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
