- Wrap all public member variables in getters and make
slots private
- Rename clear* methods to cancel* to be more consistent
with existing public Notification API
Bug: 8656860
Change-Id: I84f7e71fbb627f859352a93089c6a531b44dac95
This allows a listener service to catch up on the current
state of the notification panel at any time, including at
startup.
Bug: 8656860
Change-Id: I1a3d665d84576e17870929a63dda334afc696010
Protip: Don't mess with Bundles after you've sent them off
for parceling in an RPC.
Note that this change reduces the payload size of
StatusBarNotification objects received in
onNotificationRemoved() callbacks; it scrubs out the
RemoteViews and Bitmaps just as the NoMan's internal archive
does. [You don't really need that information anyway when
hearing about a removed notification; most likely all you
need are the other slots on StatusBarNotification, but
nulling the whole Notification object breaks a lot of
clients.]
Bug: 8616295
Change-Id: Ic899045f2352b96dcf064d3e9e51dad52629aea3
Right now this only works if you go through the front door
(using setNotificationsEnabledForPackage()); if you set the
AppOps for a package otherwise the existing notifications
will not be cleared (but new ones will be blocked). Since
there's no UI for modifying AppOps today this shouldn't be a
problem.
Bug: 8489214
Change-Id: I84f8c76a0d03959127e9076ab2b7d37dbdaebb17
For the purposes of deciding whether or not to invoke the
"fallback vibrate", that is. (RingtonePicker will return
content://settings/system/notification_sound when "Default"
is chosen, so if the app pops this Uri directly into
Notification.sound, we should treat it like DEFAULT_SOUND
and look to see whether the system notification sound is
not None before running the fallback vibration.)
Bug: 8627641
Change-Id: Ia469b8e4d5d7647ce1a8a179f591ed7a3443b5c5
- Max 250 notifications preserved (was 1000)
- Known heavyweight extras are removed
- print some of 'em out in dumpstate, while we're at it
Bug: 8280039
Bug: 8537938
Change-Id: I9239128c32a1d9f5ef4e0dc62dc2d23e190871e9
This covers all useful data from the basic Builder as well
as each of the Styles that is not otherwise captured on the
Notification object itself.
Extras are now prettyprinted in dump() output.
Bug: 8270485
Change-Id: I47fc50860dab6409793f57e904cc60296310d5cf
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
The allowed packages are listed in
Settings.Secure.ENABLED_NOTIFICATION_LISTENERS. (Don't let
the plural fool you: only one listener will be supported in
the UI.)
Change-Id: Ia69f2ba05d8e555fd4d40b0cc89c62ed14af3cac
By only adding notifications to the archive when they are
removed we batch up multiple updates and only store the
final version. Some data is lost in this process, but we
save tons of memory storing otherwise redundant /
uninteresting data (e.g. each step of a download).
Change-Id: I008afefc1242bb7c433d45da2c36fcc626dd3706
Listeners should be notified for any notification if they
register for USER_ALL, or for any notification posted to
USER_ALL.
Bug: 8328357
Change-Id: Ib5024d41287090d1a390539a015d8cb4dfa854a7
Similar to getActiveNotifications(),
getHistoricalNotifications() returns a list of all
notifications that have been posted, in
reverse-chronological order. It currently includes duplicate
entries for notifications that have been updated (so it
really is tracking every notification that has been posted
to the system).
Change-Id: Icce8d6f96bbe76710c989fd0068ff971c6498605
Improve handling of vibration op, so that apps are
better blamed (there is now a hidden vibrator API that
supplies the app to blame, and the system now uses this
when vibrating on behalf of an app).
Add operation for retrieving neighboring cell information.
Add a new op for calling a phone number. This required
plumbing information about the launching package name through
the activity manager, which required changing the internal
startActivity class, which required hitting a ton of code that
uses those internal APIs.
Change-Id: I3f8015634fdb296558f07fe654fb8d53e5c94d07
If your notification is set to MIN priority, it will never
attempt to interrupt the user, either by an icon (already
implemented), or (new in this patch) by LED, vibration, or
sound.
Bug: 7648785
Change-Id: Ia0f8e010e62029d8d8ef1955dd20b7c79fb68398
The logic here was backwards, causing the (softer) fallback vibe
pattern to be applied if the notification specified a sound
(or DEFAULT_SOUND) and also DEFAULT_VIBRATE. The fallback
vibe should only play if you have *no* vibration set.
Bug: 7588655
Change-Id: Iecdd362729bccedf779b51cc9b90a12014328aff
(This relates to the new vibration fallback behavior, where
notifications that expect to make a sound should always
vibrate in vibrate mode. We should not vibrate if the
notification's sound is silent, but we should also not
vibrate if the notification uses the default sound and the
default is silent.)
Bug: 7537077
Change-Id: I08e149c8c00ef2d2f61e418d88a086cb5e9cf241
- When notifications vibrate as a fallback (that is,
because they want to play a sound but the device is in
vibrate mode), this no longer requires the VIBRATE
permission.
- As a bonus, if your notifications use DEFAULT_VIBRATE,
you don't need the VIBRATE permission either.
- If you specify a custom vibration pattern, you'll still
need the VIBRATE permission for that.
- Notifications vibrating in fallback mode use a different
vibration pattern.
- The DEFAULT_VIBRATE and fallback vibrate patterns are now
specified in config.xml.
Bug: 7531442
Change-Id: I7a2d8413d1becc53b9d31f0d1abbc2acc3f650c6
(Unless the notification specifies no ringtone AND no
vibration, in which case it will remain silent.)
Change-Id: I926d0fe0165b9622cd117e6c3ef6e3637772b444
Bug: 7490028
Otherwise notifications such as the USB debugging and OTA notifications will be
dismissed when any user is stopped.
Change-Id: I0ae0c1136a999dd3aade99ca9e71c714b359eab4
Many media files and source code files were marked as executable in Git.
Remove those.
Also a shell script and python script were not marked as executable.
Change-Id: Ieb51bafb46c895a21d2e83696f5a901ba752b2c5
1. The notification manager service is firing accessibility events
for notification for a background user. Events for the current
user's notifications should be sent.
bug:7326302
Change-Id: I00665385ba2106f161928dad1b76536c93c17f27
Add support for querying AudioManager to know whether speech
recognition is currently underway.
Don't play a notification if speech recognition is underway.
Bug 7314859
Change-Id: I1bd013a3168cfe1a6b6dcfd28565e1c3c512eb6a
Change RingtonePlayer to open content:// Uris based on requesting
UserHandle. Grant SystemUI visibility to all emulated storage so
it can play ringtones for apps without READ_EXTERNAL_STORAGE.
Resolve canonical file:// Uris before passing out of source app,
replacing any /emulated_legacy/-style paths with user-specific
variant so they can be opened by SystemUI. Calling for RemoteViews,
Ringtones, and Notifications.
Bug: 7202982
Change-Id: Ibf0eca8df80c1486711144a7b648f464aadfe099
Fixed one setting that was migrated but not marked deprecated.
Removed a hidden setting that is no longer used by the new
power manager service.
Bug: 7231172
Change-Id: I332f020f876a18d519a1a20598a172f1c98036f7
Also fix a bunch of system services that should be doing this. And
while doing that, found I needed to fix PendingIntent to evaluate
USER_CURRENT at the point of sending, not creation.
Note that this may end up with us having some notification shown to
non-primary users that lead to settings UI that should only be for
the primary user (such as the vpn notification). I'm not sure what
to do about this, maybe we need a different UI to come up there or
something, but showing the actual notification for those users at
least seems less broken than not telling them at all.
Change-Id: Iffc51e2d7c847e3d05064d292ab93937646a1ab7
Otherwise services like SystemUI will always open content://-style
Uris as USER_OWNER. Surfaces through createPackageContextAsUser()
which points all ContentResolver operations towards a given user.
Start using in RemoteViews, so that Notifications correctly resolve
image Uris to the sending user. Also add user support for "content"
shell tool.
Bug: 7202982
Change-Id: I8cb7fb8a812e825bb0b5833799dba87055ff8699
Replaced all remaining places that used it with explicit user
specification.
While doing this, I ran into stuff that was creating PendingIntent
objects (that now need to specify the explicit user they are for),
which are also posting notifications... but have no way to specify
the user for the notification.
So the notification manager in the system process now also gets a
formal concept of a user associated with the notification, which
is passed in to all the necessary aidl calls. I also removed the
old deprecated aidl interface for posting/cancelling notifications,
since we now always need a user supplied.
There is more work that needs to be done here, though. For example
I think we need to be able to specify USER_ALL for a notification that
should be shown to all users (such as low storage or low battery).
Along with that, the PendingIntent creation needs to be tweaked to
be able to handle USER_CURRENT by evaluating the user at the point the
pending intent is sent.
That's for another change, however.
Change-Id: I468e14dce8def0e13e0870571e7c31ed32b6310c
