The trackball to dpad synthesis was using the MotionEvent's precision
field to determine a threshold for movement but the calculations
involved did not actually make sense for any value of precision
less than 2.0. This worked fine before since the InputReader
hardcodes the trackball's precision to 6.
Injected trackball events may have a different precision which can
result in the thresholds being set inappropriately. For example,
it was not possible to move focus by one unit at a time when
the precision was set to 1.0.
The old code was probably using precision as a way to set a
threshold based on the trackball moving by some minimum number
of physical ticks, in this case 2. But the code will work just
as well if we set an absolute threshold based on distance
traveled given that the input system is already expected to
normalize the trackball movements before delivering them to the
application.
So stop using precision.
Bug: 8473020
Change-Id: I3c6f7fb1b507f8cf5608b47550e7345fea3352fa
Redesigned how ViewRootImpl delivers input events to views,
the IME and to native activities to fix several issues.
The prior change to make IME input event delegation use
InputChannels failed to take into account that InputMethodManager
is a singleton attached to the main looper whereas UI may be
attached to any looper. Consequently interactions with the
InputChannel might occur on the wrong thread. Fixed this
problem by checking the current thread and posting input
events or callbacks to the correct looper when necessary.
NativeActivity has also been broken for a while because the
default event handling logic for joysticks and touch navigation
was unable to dispatch events back into the native activity.
In particular, this meant that DPad synthesis from touch navigation
would not work in any native activity. The plan is to fix
this problem by passing all events through ViewRootImpl as usual
then forwarding them to native activity as needed. This should
greatly simplify IME pre-dispatch and system key handling
and make everything more robust overall.
Fixed issues related to when input events are synthesized.
In particular, added a more robust mechanism to ensure that
synthetic events are canceled appropriately when we discover
that events are no longer being resynthesized (because the
application or IME is handling or dropping them).
The new design is structured as a pipeline with a chain of
responsibility consisting of InputStage objects. Each InputStage
is responsible for some part of handling each input event
such as dispatching to the view hierarchy or to the IME.
As a stage processes an input event, it has the option of
finishing the event, forwarding the event to the next stage
or handling the event asynchronously. Some queueing logic
takes care to ensure that events are forwarded downstream in
the correct order even if they are handled out of order
by a given stage.
Cleaned up the InputMethodManager singleton initialization logic
to make it clearer that it must be attached to the main looper.
We don't actually need to pass this looper around.
Deleted the LatencyTimer class since no one uses it and we have
better ways of measuring latency these days using systrace.
Added a hidden helper to Looper to determine whether the current
thread is the indicated Looper thread.
Note: NativeActivity's IME dispatch is broken by this patch.
This will be fixed later in another patch.
Bug: 8473020
Change-Id: Iac2a1277545195a7a0137bbbdf04514c29165c60
SurfaceView and TextureView do not currently support overlays
correctly; the docs now reflect this constraint.
Change-Id: I79183c02b51ae4cd14638198d0668b2c2e3e22e1
The new media button receiver with only a pending intent (no
component name) could be left hanging if the process that
registered it went away. These semantically need to be tied
to the calling process's lifetime; we now clean them up when
the calling process goes away.
Also added some additional cleanup of media button receivers
when packages change (updated, cleared).
And on top of that, a new "media" command for doing media
things. Currently lets you send media keys and monitor
remote display data.
Oh and finally added a new BaseCommand base class for
implementing these command line utilities.
Change-Id: Iba1d56f10bab1eec4a94a7bb1d1c2ae614c8bcf5
1) Make the box with the permission really go away when a
permission is revoked, not just invisible.
2) Change the order of the buttons, making the negative
button the "revoke" button, and the positive button "ok".
Change-Id: I73694583cbd014d3820f8df6c6b770caae299499
Previously they each had to be nonzero, which prevented
using the builder methods to create solid-on LED
notifications.
Change-Id: I30314ec33daa28ee2e1f0b87a184c3540254471c
Adding views to views (possible with the new Overlay API) is weird.
This change moves the view-management facilities of Overlay to a subclass
that is specific to the overlay returned from ViewGroup.getOverlay().
So now you can add drawables to all view overlays, but only add/remove
views to/from the overlay returned from ViewGroup.getOverlay().
Also, the previous approach of using an interface for Overlay was
changed to classes for both ViewOverlay and ViewGroupOverlay.
Finally, this change makes not handling touch correctly the proper,
and documented, behavior of overlay views. There are various tricky issues
to sort out with input in overlays (including click handling as well as focus)
and we don't want developers starting to use overlays as some kind of general
container hierarchy, so we're purposely constraining overlays to have visual-only
behavior.
Issue #8459085 Overlay needs to handle touch correctly
Change-Id: I207b8dbf528f87c92369d270d8b0a6556826d207
Add UI support for revoking optional permissions. When the user
taps on an optional permission, two new boxes will appear:
[Cancel] | [Revoke]
Selecting [Revoke] will revoke the permission from the app.
The [Cancel] / [Revoke] options are only shown for apps which support
optional permissions.
Bug: 8332307
Change-Id: I27e374773747737e3a6d7f48ea1448a0178e3393
Fix a bug where the content description of the big unified Home/Up
button was not getting set properly.
Add the ability to change the home-as-up glyph from ActionBar.
Add the ability to set a custom action description for the home-as-up
button, useful if the above functionality is used.
Bug 8548229
Change-Id: I0635799772c7234b68247dfc105dce7f11acda32
This is the best and only way for apps to listen for
notifications: create a NotificationListenerService, wait
for the NoMan to bind to you (as a result of the user
checking a box somewhere in Settings and agreeing to a
scary dialog box), and you'll start receiving notification
posted and dismissed callbacks. Your service, while enabled,
will also be able to clear one or all notifications.
Use this power wisely.
This change moves StatusBarNotification out of
com.android.internal into android.service.notification.
[Internal customers, including System UI and early users of
the system-only listener binder API, will need to be
updated.]
Bug: 8199624
Change-Id: I1be46f823d4b3ddc901109ec1e085cd6deb740c2
InputChannels are normally duplicated when sent to a remote process
over Binder but this does not happen if the recipient is running within
the system server process. This causes problems for KeyGuard because the
InputMethodManagerService may accidentally dispose the channel
that KeyGuard is using.
Fixed the lifecycle of InputChannels that are managed by the IME
framework. We now return a duplicate of the channel to the application
and then take care to dispose of the duplicate when necessary.
In particular, InputBindResult disposes its InputChannel automatically
when returned through Binder (using PARCELABLE_WRITE_RETURN_VALUE).
Bug: 8493879
Change-Id: I08ec3d13268c76f3b56706b4523508bcefa3be79
Don't install packages where we have multiple, conflicting
<uses-permission> lines for the same permission.
For example, a package which contains:
<uses-permission android:name="android.permission.INTERNET" android:required="false" />
<uses-permission android:name="android.permission.INTERNET" android:required="true" />
will now fail to install.
In addition, this change slightly refactors the code, and creates a new
parseUsesPermission() method.
Change-Id: I0f4bb8b51dc4a0c5b73458a70f706e19829275d2
Remove remnants from times long gone. We don't need to redraw the
union of the previous frame's dirty region and the new dirty
region.
Change-Id: I9fb96f99a6a72c2233f9ca563cf6432a42b2b65b
Don't honor <uses-permission android:required="false"> on older apps.
Lots of apps in the wild are improperly using this, and we don't
want to break them.
Bug: 8528162
Change-Id: I6e0a10bc9feac58d13ef624239c6b91e9fc34590
RectEvaluator is useful when animating object bounds.
The other change is a hidden API that allows temporary suspension
of layout, useful for animations which need to animate view bounds
without conflicting with layout passes that might happen in the middle
of the animation.
Change-Id: I3dc08cb6ec455dfa3409e825506b218d3ea63d7a
Some apps aren't particularly happy if a stray key event is dispatched
to a newly created window before its menu is prepared, causing the
action bar's Home/Up event to be dispatched. Ignore these clicks on
the Home/Up button before the menu goes through its initial prepare
step.
Note that it is still possible (and valid!) for Home/Up to be
dispatched even if the app chose to return false from
onCreateOptionsMenu or similar.
Bug 7085070
Change-Id: If4b7d5f8c5a08ce8a094f1919347604d78ddedfb
This commit replaces a regex pattern match for Linkify.PHONE_NUMBER
with a call to libphonenumber's PhoneNumberUtil.findNumbers().
Bug: 5533245
Change-Id: I0e0563b241fb62e77d7f49e4a8484c6b0685dd8f
Change name of BluetoothDevice#connectGattServer to BluetoothDevice#connectGatt
Add BluetoothGatt#getDevice to retrieve device from BluetoothGatt
Add BluetoothGatt#connect() to reconnect back to the server.
Make BluetoothGatt#close() public to clean up/unregister callback
Add BluetoothDevice.getType() to return int of
bug 8529188
Change-Id: Iebd9ac68cc7a64c43972e617dd3068f66c8ea0b2
