History log of /frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
bcc046af4ef171aa3aa3c6b64efb5cafc1e46cd3 28-Sep-2012 Jeff Brown <jeffbrown@google.com> Bundle correlated switch changes atomically.

This is a prerequisite for headset jack detection on Manta.

Bug: 6548391
Change-Id: I549a194344511c0cee578b00f6a9ab5fdbdfb99c
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
83d616a9c7b9505153d258511eb5c16b552e268d 10-Sep-2012 Jeff Brown <jeffbrown@google.com> Make input system aware of multiple displays.

The input system needs to know about the window that has
focus, even if it is on a secondary display. So now we
send it the list of all windows and indicate which display
they are on. We filter the list of windows as necessary
when delivering touch events.

To keep things simple, monitor input channels and input
filters are not supported except on the main display.
We also do not pass the display id to applications; it is
only used inside the input system for now.

Properly scale touch coordinates based on the viewport.
This will be needed to ensure that touch works on external
display as well as when the internal display is being used
to simulate a different resolution.

Change-Id: I1815579a52fcc852c519b5391fc7ab8767c2dc59
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
d728bf514f257670fcb9aa22c6eaf97626072c93 09-Sep-2012 Jeff Brown <jeffbrown@google.com> Make display manager tell input system about viewports.

The window manager is no longer responsible for telling the
input system about the display viewport.

Change-Id: I932882bae55decef55f25093bb2a7ebac1620bb1
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
5338428ddbe662283bf88171c7ca361d51d78da8 21-Aug-2012 Jeff Brown <jeffbrown@google.com> Plumb the switch code into Dalvik.

Bug: 6548391
Change-Id: If0e918669ba27ca0e6561930d4abc427c34de42d
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
9630704ed3b265f008a8f64ec60a33cf9dcd3345 28-Jul-2012 Jeff Brown <jeffbrown@google.com> Power manager rewrite.

The major goal of this rewrite is to make it easier to implement
power management policies correctly. According, the new
implementation primarily uses state-based rather than event-based
triggers for applying changes to the current power state.

For example, when an application requests that the proximity
sensor be used to manage the screen state (by way of a wake lock),
the power manager makes note of the fact that the set of
wake locks changed. Then it executes a common update function
that recalculates the entire state, first looking at wake locks,
then considering user activity, and eventually determining whether
the screen should be turned on or off. At this point it may
make a request to a component called the DisplayPowerController
to asynchronously update the display's powe state. Likewise,
DisplayPowerController makes note of the updated power request
and schedules its own update function to figure out what needs
to be changed.

The big benefit of this approach is that it's easy to mutate
multiple properties of the power state simultaneously then
apply their joint effects together all at once. Transitions
between states are detected and resolved by the update in
a consistent manner.

The new power manager service has is implemented as a set of
loosely coupled components. For the most part, information
only flows one way through these components (by issuing a
request to that component) although some components support
sending a message back to indicate when the work has been
completed. For example, the DisplayPowerController posts
a callback runnable asynchronously to tell the PowerManagerService
when the display is ready. An important feature of this
approach is that each component neatly encapsulates its
state and maintains its own invariants. Moreover, we do
not need to worry about deadlocks or awkward mutual exclusion
semantics because most of the requests are asynchronous.

The benefits of this design are especially apparent in
the implementation of the screen on / off and brightness
control animations which are able to take advantage of
framework features like properties, ObjectAnimator
and Choreographer.

The screen on / off animation is now the responsibility
of the power manager (instead of surface flinger). This change
makes it much easier to ensure that the animation is properly
coordinated with other power state changes and eliminates
the cause of race conditions in the older implementation.

The because of the userActivity() function has been changed
so that it never wakes the device from sleep. This change
removes ambiguity around forcing or disabling user activity
for various purposes. To wake the device, use wakeUp().
To put it to sleep, use goToSleep(). Simple.

The power manager service interface and API has been significantly
simplified and consolidated. Also fixed some inconsistencies
related to how the minimum and maximum screen brightness setting
was presented in brightness control widgets and enforced behind
the scenes.

At present the following features are implemented:

- Wake locks.
- User activity.
- Wake up / go to sleep.
- Power state broadcasts.
- Battery stats and event log notifications.
- Dreams.
- Proximity screen off.
- Animated screen on / off transitions.
- Auto-dimming.
- Auto-brightness control for the screen backlight with
different timeouts for ramping up versus ramping down.
- Auto-on when plugged or unplugged.
- Stay on when plugged.
- Device administration maximum user activity timeout.
- Application controlled brightness via window manager.

The following features are not yet implemented:

- Reduced user activity timeout for the key guard.
- Reduced user activity timeout for the phone application.
- Coordinating screen on barriers with the window manager.
- Preventing auto-rotation during power state changes.
- Auto-brightness adjustment setting (feature was disabled
in previous version of the power manager service pending
an improved UI design so leaving it out for now).
- Interpolated brightness control (a proposed new scheme
for more compactly specifying auto-brightness levels
in config.xml).
- Button / keyboard backlight control.
- Change window manager to associated WorkSource with
KEEP_SCREEN_ON_FLAG wake lock instead of talking
directly to the battery stats service.
- Optionally support animating screen brightness when
turning on/off instead of playing electron beam animation
(config_animateScreenLights).

Change-Id: I1d7a52e98f0449f76d70bf421f6a7f245957d1d7
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
b696de5c10ebcc7bf42d8487fc0e56e0e937754d 28-Jul-2012 Jeff Brown <jeffbrown@google.com> Move and rename user activity event type constants.

Change-Id: Ie565808796773b6896e71ddfac6aaaf8031de846
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
4f8ecd80296508a1dc69d3f3a23fd91e962c2784 19-Jun-2012 Jeff Brown <jeffbrown@google.com> Move power manager to a new package.

Change-Id: I5f5a6435e64354b7d6535e8e9a63934ba7a3f448
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
93de746e5554bc9397ca8109f57875d92e64eabc 03-May-2012 Jeff Brown <jeffbrown@google.com> Separate the internal and external display rotations.

When attached to an HDMI touch screen, the input system needs
to know the size and rotation of the external display independent
of the internal display. The size was already being reported
separately but not the rotation. The inconsistency can cause problems
if the internal display's natural rotation is portrait but
the external display's natural rotation is landscape.

Change-Id: Id344f04c1ba032625f6265766be66f9ddaa2cc0b
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
daa3753a04699724d2cfe824ac1f5a266d643a05 02-May-2012 Jeff Brown <jeffbrown@google.com> Improve handling of built-in keyboard.

The window manager policy made some incorrect assumptions about the
meaning of the Configuration.keyboard field. We need to be more
careful about distinguishing between built-in and external keyboards.

Most of this change is to move the determination of the parts of
the Configuration related to input devices into the WindowManagerService
leveraging new features of the InputManagerService to good effect.

Then we plumb through the flag that indicates whether a device
is internal or external so that we can be more particular about
how the lid switch effects changes to the Configuration.

Bug: 6424373
Change-Id: I36a1c22ade35e578955465a25940a33f227b9763
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
5bbd4b4f5fc19302fa017ad6afee6eb2d489d91a 21-Apr-2012 Jeff Brown <jeffbrown@google.com> Get alias for Bluetooth devices.

Bluetooth devices can be renamed by the user. Make the
input system aware of the user-specified name and transparently
pass it down to applications. This enables the keyboard
layout picker Settings UI to use device names that are
consistent with what the user set in the Bluetooth UI.

Bug: 6363157
Change-Id: I8eea26ce2c69c2a3f09c8de02e9e847610e0419c
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
6ec6f79e1ac1714e3b837796e99f07ff88f66601 18-Apr-2012 Jeff Brown <jeffbrown@google.com> Support loading keyboard layout overlays from resources.

Added the concept of a keyboard layout overlay, which is
a key character map file that has "type OVERLAY".

Added support for loading keyboard layout overlays from
resources dynamically. The layouts are reloaded whenever they
are changed in the Settings application or an application
is installed. This is somewhat more aggressive than necessary
so we might want to optimize it later.

Before system-ready, the input system uses just the generic
keyboard layouts that are included on the device system image.
After system-ready, it considers the user's selected keyboard
layout overlay and attempts to load it as necessary. We need to
wait until system-ready before doing this because we need to
be in a state where it is safe to start applications or access
their resources.

Bug: 6110399
Change-Id: Iae0886d3356649b0d2440aa00910a888cedd8323
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
a47425a13c19f95057df78b8bb65bb25657e8753 13-Apr-2012 Jeff Brown <jeffbrown@google.com> Add support for input devices that have vibrators.

Added a getVibrator() method to InputDevice which returns a Vibrator
associated with that input device. Its uses the same API as the
system vibrator which makes it easy for applications to be modified
to use one or the other.

Bug: 6334179
Change-Id: Ifc7f13dbcb778670f3f1c07ccc562334e6109d2e
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
af9e8d38184c6ba4d2d3eb5bde7014a66dd8a78b 13-Apr-2012 Jeff Brown <jeffbrown@google.com> Notify applications when input devices change.

This change allows the InputManager to keep track of what input
devices are registered with the system and when they change.
It needs to do this so that it can properly clear its cache of
input device properties (especially the key map!) when changes
occur.

Added new API so that applications can register listeners for
input device changes.

Fixed a minor bug in EventHub where it didn't handle EPOLLHUP
properly so it would spam the log about unsupposed epoll events
until inotify noticed that the device was gone and removed it.

Change-Id: I937d8c601f7185d4299038bce6a2934fe4fdd2b3
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
9f25b7fdf216c9ef0bd2322cd223eeaf0d60f77f 10-Apr-2012 Jeff Brown <jeffbrown@google.com> Request key maps from input manager service.

Instead of each application loading the KeyCharacterMap from
the file system, get them from the input manager service as
part of the InputDevice object.

Refactored InputManager to be a proper singleton instead of
having a bunch of static methods.

InputManager now maintains a cache of all InputDevice objects
that it has loaded. Currently we never invalidate the cache
which can cause InputDevice to return stale motion ranges if
the device is reconfigured. This will be fixed in a future change.

Added a fake InputDevice with ID -1 to represent the virtual keyboard.

Change-Id: If7a695839ad0972317a5aab89e9d1e42ace28eb7
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
27fd3420ac0498ff5086f71023f443966541aa04 09-Apr-2012 Jeff Brown <jeffbrown@google.com> Fix lid switch interpretation.

Also remove unnecessary permission check for method that is
only called internally.

Change-Id: I32f63fc3e96b06709d18b046ee2d3c8f310de70d
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
603b44589682db3ff33ade172facb0c5e309f1be 07-Apr-2012 Jeff Brown <jeffbrown@google.com> Ensure that apps crash if they throw exceptions.

Previously, if an app threw an uncaught exception in an input,
vsync or native activity callback, it would log the exception then
continue limping merrily along. In the case of input, it
could result in an ANR occurring because we had not drained
all of the pending input events and marked them as finished
(we only marked the most recent one finished).

Bug: 6304124
Change-Id: I87d76f7fd605e1a8af1237c66d8d62973080277e
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
e38fdfae9196afd1bdc14c5ec6c12793af1e2550 06-Apr-2012 Jeff Brown <jeffbrown@google.com> Add a unique input device descriptor.

The purpose of the input device descriptor is to make it possible
to associate persistent settings for each input device, such as the
keyboard layout.

The descriptor is a hash of the information we have about the
device, such as its vendor id, product id, unique id, name,
or location.

Bug: 6110399
Change-Id: Idb80f946819b3f0dbf4e661bb0a753dbc2b60981
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp
4532e6158474a263d9d26c2b42240bcf7ce9b172 05-Apr-2012 Jeff Brown <jeffbrown@google.com> Refactor input system into its own service.

Extracted the input system from the window manager service into
a new input manager service. This will make it easier to
offer new input-related features to applications.

Cleaned up the input manager service JNI layer somewhat to get rid
of all of the unnecessary checks for whether the input manager
had been initialized. Simplified the callback layer as well.

Change-Id: I3175d01307aed1420780d3c093d2694b41edf66e
/frameworks/base/services/jni/com_android_server_input_InputManagerService.cpp