Specifically: don't do it if the package is enabled at the
time the PACKAGE_CHANGED broadcast is sent. (We only want to
cancel notifications when packages enter the disabled
state.)
Bug: 6589355
Change-Id: Iba754cef27e2bdff35a13e403a867933c996f562
Clean up related to new Vibration policy.
The vibrate behavior is now only derived from:
- presence of a vibrator on the device
- current ringer mode selected: NORMAL, VIBRATE or SILENT
If no vibrator is present the ringer mode can only be NORMAL or SILENT.
The control of ringer mode via volume keys when volume keys control the "master"
stream type (RING on phones, MUSIC on tablets) is as follows:
If a vibrator is present:
VOL- and volume equals 1: NORMAL => VIBRATE
VOL- and volume equals 0 and not continuous press: VIBRATE => SILENT
VOL+ and in SILENT mode: SILENT => VIBRATE
VOL+ and in VIBRATE mode: VIBRATE => NORMAL, volume = 1
If no vibrator is present:
VOL- and volume equals 0 and not continuous press: NORMAL => SILENT
VOL+ and in SILENT mode: SILENT => NORMAL, volume = 0
VIBRATE_ON and VIBRATE_IN_SILENT settings are not stored/retreived any more.
AudioService checks and corrects ringer mode and stream volumes if necessary when reading from
DB at boot time.
Also:
Added dump for stream volumes in AudioService.
Added device names missing in AudioSystem for USB accessory and USB device.
Issue: 6036529
Issue: 6414950
Issue: 6448163
Change-Id: I77fb821ec63e4e566320cac2701b4ac466e86aef
Introduce IRingtonePlayer, which handles playback for both Ringtone
objects and Notifications. SystemUI now hosts this player, which it
registers with AudioService. It also keeps MediaPlayer instances
warm, and cleans them up after stop() or Binder death.
Move both Ringtone and NotificationManagerService to play back audio
through this new interface.
Bug: 6376128, 6350773
Change-Id: I1dcb86d16ee3c4f07cdb2248d33dcff4ead3609a
When a package's ability to post notifications is disabled,
all outstanding notifications from that package are
immediately canceled, and the score of any future
notification from that package is set so low that the
notification manager won't even send it to the status bar.
No UI for this yet, but you can try it out:
adb shell service call notification 8 s16 $PKG i32 (1|0)
Bug: 5547401
Change-Id: Ieccac5746b40f60debd902a45d1dedbc91dcdc89
Moved the core logic of Vibrator into SystemVibrator, potentially
allowing for the creation of other Vibrator subclasses.
Fixed several places where we were creating new Vibrator
instances unnecessarily instead of getting it from the Context.
It is safe to make Vibrator abstract because its constructor
was hidden from the SDK so it was not possible to subclass it.
Bug: 6334179
Change-Id: I18ece6544c26a7efb2d5099f8346a10aef8a5e18
Two parts to this:
1. Stop treating FLAG_ONGOING_EVENT notifications specially
(in particular, ordering them at the top of the panel).
2. Set the priority bits on the system UI notifications
appropriately (low).
Change-Id: I3bde7e573654c5aad5e1c5d29e6a21ba94edcc5b
This change introduces a few new bits of data on
Notification that will help the Notification Manager and
System UI route and display them more intelligently:
-> priority: an integer in a predefined range that
indicates the app's best guess as to the relative
importance (to the user, right now) of that information
-> kind: a tag (really, set of tags) indicating the general
type of notification (realtime, asynchronous, etc)
-> extras: a Bundle of additional key/value pairs
associated with this notification (currently @hidden)
The notification manager takes these data into account when
assigning to each notification a score which is passed with
the notification on to the system UI, where it can be used to
affect presentation. For example:
- Spammy apps (identified explicitly by the user or by
some other means) will have their notifications scored
very negatively by the notification manager, allowing
the UI to suppress them
- Notifications of higher score might be shown larger
or in a different way
- Very important notifications (indicated by a very high
score) might interrupt the user during an otherwise
important task (videochat, game, etc)
Implementation note: This replaces/extends the old internal
notion of "priority", which was mostly used to organize
ongoings and system notifications at the top of the panel.
Change-Id: Ie063dc75f198a68e2b5734a3aa0cacb5aba1ac39
Switching activity stacks
Cache ContentProvider per user
Long-press power to switch users (on phone)
Added ServiceMap for separating services by user
Launch PendingIntents on the correct user's uid
Fix task switching from Recents list
AppWidgetService is mostly working.
Commands added to pm and am to allow creating and switching profiles.
Change-Id: I15810e8cfbe50a04bd3323a7ef5a8ff4230870ed
Also do not blink for notifications received when the screen is on.
Bug: 5233071
Change-Id: I15675ca317007d4b900ef74e60d11a5bca3d7333
Signed-off-by: Mike Lockwood <lockwood@android.com>
The new specification calls for LED to continue blinking until the user
pulls down the notification shade in the status bar.
Bug: 5143247
Change-Id: Id004cc3d1d9d76108329e57c6fbd8a8100068e0a
Signed-off-by: Mike Lockwood <lockwood@android.com>
Notification manager was sending the delete intent even when
the notification was clicked and not just when cleared.
Change-Id: I9f8ae973b7972bc34cd15d213e58a961138fa7e5
Signed-off-by: jhtop.kim <jhtop.kim@samsung.com>
NotificationManagerService keeps track of requested toasts in a
queue. Any package can trigger a DoS by repeated enqueue of
toasts which eventually results in a leak of WeakReferences in
system_server and causes dalvik (hosting system_server) to
abort the same.
Change-Id: I5e23c1bf7e195b07344711d2c6719fa568f2dfaf
Add support for separate USB connected and configuration events
Include both USB connected/disconnected and configuration state
in USB_STATE Intent
Remove redundant USB_CONNECTED and USB_DISCONNECTED Intents
Now we just have the sticky USB_STATE broadcast
Move USB disconnnect rebouncing from Tethering to UsbService
Change-Id: I1dea480f4b0daf14247cf37c5f2060498882c002
Signed-off-by: Mike Lockwood <lockwood@android.com>
USB: Add functions for querying if a USB function is supported and enabled.
Rename android.hardware.Usb to UsbManager and UsbObserver to UsbService
Change-Id: I920a211934d993eab8ce744c1cc7b05342389286
Signed-off-by: Mike Lockwood <lockwood@android.com>
This change improves upon the notification priority API
introduced in change I9e738cc4, allowing privileged clients
to set the priority of a notification when posting it
directly to INotificationManager. StatusBarTest is updated
to test this new feature.
The new LocationController in SystemUI uses this facility to
post a high-priority ongoing notification whenever GPS is in
use (replacing the functionality of the legacy GPS status
bar icon).
Also happens to fix http://b/3325472 (adding a log message
when notifications are dropped because of a missing icon).
Bug: 3412807
Change-Id: I523016ffa53bf979be98ddc4a2deb55a6270c68a
Add support for separate USB connected and configuration events
Include both USB connected/disconnected and configuration state
in USB_STATE Intent
Remove redundant USB_CONNECTED and USB_DISCONNECTED Intents
Now we just have the sticky USB_STATE broadcast
Move USB disconnnect rebouncing from Tethering to UsbService
Change-Id: Id13eb0c5d51152d2a538985d680ba1db7d2241dc
Signed-off-by: Mike Lockwood <lockwood@android.com>
In preparation for an upcoming change that will make UsbService into a real system service
Change-Id: Id85d624cfc6b10b49a08105cfaaacc667a492c12
Signed-off-by: Mike Lockwood <lockwood@android.com>
Remember, the system and main logs are
- Shared resources
- Primarily for recording problems
- To be used only for large grained events during normal operation
Bug: 3104855
Change-Id: I136fbd101917dcbc8ebc3f96f276426b48bde7b7
If they don't, the click events will be passed through to the individual
views in the notification view, which may have their own PendingIntents
attached.
Previously, it was against the UX spec to allow this, but now we are
changing that and will have buttons in there.
Change-Id: I674234212f64b2b8802a0708b7eed0614e147ca3
If they don't, the click events will be passed through to the individual
views in the notification view, which may have their own PendingIntents
attached.
Previously, it was against the UX spec to allow this, but now we are
changing that and will have buttons in there.
Change-Id: Ie3b2e96c6a1c4449fa86ed571f3ad0f047320d31
Merge commit '91cf049f34b4f3d53d39e868104f11156a332b65'
* commit '91cf049f34b4f3d53d39e868104f11156a332b65':
Only pulse notification light if a new notification has been received since the screen was last turned off
Merge commit '76e4fa19264793e3ed7e2ee7afccfc808a1a7458' into gingerbread-plus-aosp
* commit '76e4fa19264793e3ed7e2ee7afccfc808a1a7458':
Only pulse notification light if a new notification has been received since the screen was last turned off
Merge commit '5085848ddbadaafa088ed85753156adc2e54554d'
* commit '5085848ddbadaafa088ed85753156adc2e54554d':
Make the LED colors when charging customizable by the vendor
Merge commit '209e651805dd40ea87df7ff67f2755605be9308c' into gingerbread-plus-aosp
* commit '209e651805dd40ea87df7ff67f2755605be9308c':
Make the LED colors when charging customizable by the vendor
Line-item veto is there, but allows you to cancel some
notifications you probably shouldn't be canceling. (Should
hide the "X" in those cases.)
No preference given to "sticky" notifications, because
there's no such thing yet.
Notifications are now limited to 4 visible icons, per spec.
The implementation is a total hack for now.
Change-Id: Ibdf433ae94189117f983c510fe5e0cff0bf5c44c
