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
Fixes the KEYCODE_HOME case, awakes when home is
started for any reason.
Also awaken when toggling recents (and not locked).
Bug:8557212
Change-Id: I6578ae3971740a03c27596b838d27a5ab9b03752
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
Old: [ IC ] %s running
[ ON ] %s is running
New: [ IC ] %s is running
[ ON ] Touch for more information or to stop the app.
Additionally, disallow these misbehaving services from
supplying their own content views; if you attempt to run a
foreground service with icon == 0, this is the notification
you will get, period.
Bug: 8525548
Change-Id: I2bfd7340396ef925885e8c2160a720f9eff07a35
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
