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
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
Do not use startScoUsingVirtualVoiceCall() BluetoothHeadset
API to connect SCO audio. This will cause headsets to act as if an incoming
call was received which is not what we want for voice commands.
Bug 8157702
Change-Id: I271909d4d1f3822758740a8484e3d2d8b4f34c00
Float textures offer better precision for dithering.
In addition this change removes two uniforms from gradient shaders.
These uniforms were used to dither gradients but their value is
a build time constant. Instead we hardcode the value directly in
the shader source at compile time.
Change-Id: I05e9fd3eef93771843bbd91b453274452dfaefee
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
