| 4e78706f439d318ae7a78927d98f734351a89f64 |
|
17-Jun-2015 |
Dan Sandler <dsandler@android.com> |
Patch up certain kinds of broken notifications.
Notifications in which the icon resource ID is changed after
Builder.build() is called (even, and particularly, as the
last step in the current implementation of
setLatestEventInfo()) were not having their icons properly
parceled. In these cases we now attempt to catch this at
parcel time and construct the necessary Icon object.
But wait! Parceling does not require a Context. So we don't
actually know which package to load the resource from.
Therefore we now allow an Icon to be constructed with an
empty ("") package name, which allows us to complete this
parceling task despite the fact that a Notification does not
know its own package name. (In case you attempt to load a
drawable for such an Icon, loadDrawable will spot the ""
package and instead substitute the Context from its
parameters to try to load the resource.)
As it happens, even though the Notification does not know
its own package name, BaseStatusBar does, because it was
provided at NM.notify() time and is therefore included in
the StatusBarNotification structure. So we can actually
patch up the Icon (if it is TYPE_RESOURCE) and be sure to
get the icon loaded out of the correct package.
While we've got the hood open, this change fixes a couple of
related problems:
• Foreground service notifications synthetically
constructed for naughty icon==0 notifications (which we
are still allowing...FOR NOW) were losing the
FLAG_FOREGROUND_SERVICE flag (because we're
re-build()-ing them from scratch rather than rewriting
the provided Notification object). Now we set the flag
and hang onto the new notification for next time
setForeground() is called.
• We now allow media notifications to avoid getting bumped
to the top of the notification list if they're
PRIORITY_MIN. You might want to do that, I guess?
Bug: 21333763
Change-Id: Ia5d1f1acb594c7677bcc75ee3d624da4ffca671f
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 7c74f78a85283912d7239214024ccca702622f21 |
|
04-Jun-2015 |
John Spurlock <jspurlock@google.com> |
Zen: New user flow for requesting DND access.
- User flow is now similar to requesting access to notification
content, namely prompting the user to visit a settings page
for enabling/disabling apps access.
- New ACTION_NOTIFICATION_POLICY_ACCESS_GRANTED_CHANGED intent
for apps to listen to this state change.
- Removed obsolete request method and associated internal callback
aidl.
- Added new android.permission.ACCESS_NOTIFICATION_POLICY permission
for apps to include as a signal that they want to request this access
(and therefore appear in the list on the settings page).
- Improve javadocs, outline the user flow in NotificationManager#isNotificationPolicyAccessGranted
and link to this method elsewhere.
- NoManService now persists the user-enabled package list across reboots
and does so per-user.
- Rename public settings intent to correspond with the noman api.
Bug: 21621663
Change-Id: I72cbc21cd736e6a157b6be5d1d0ba0b4a8e7ef4e
/frameworks/base/core/java/android/app/NotificationManager.java
|
| d63f9321e62064660d426efd5abbd885c4a24652 |
|
06-May-2015 |
Dan Sandler <dsandler@android.com> |
Icon support comes to Notification.
And you may ask yourself: what is that beautiful icon?
And you may ask yourself: where does that API go to?
And you may ask yourself: is it a resource? is it a Bitmap?
And you may say to yourself: my god, what have I done
(This patch fixes a number of bugs in the initial
implementation, but other than that, it's the same as it
ever was.)
Bug: 18568715
Bug: 21141842
Change-Id: I1d3f9427abd7f0bb57e533fcfac708851ff644b6
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 807749301fcbda892dfc8a5832b19acf7d1cf53b |
|
07-May-2015 |
John Spurlock <jspurlock@google.com> |
Zen: Simplify notification policy api, add zenmode api.
- Remove the concept of a notification policy management token
in favor of a simple grant/deny per app. Currently, all requests
are immediately granted.
- Add zen mode getter/setting, limit to apps that have been granted
policy access.
- Add intent for zen mode changes.
- Public name for zen mode = "interruption filter", moved from
NotificationListenerService to NotificationManager.
- Add settings metadata for new DND access Settings screen.
- Add the split sender settings for calls vs messages to the public
Policy api.
- This change is meant to finalize the public api, persisting
granted app status and showing the user-visible dialog will be
done as followups.
Bug: 18298798
Change-Id: I511be98d69939f057c0c7dc1a6dfe63d1c468193
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 994349c61e8697e626a7cd2b241a16b2b7669305 |
|
15-Apr-2015 |
Dan Sandler <dsandler@android.com> |
Rediscover your own notifications.
This new API, NotificationManager.getActiveNotifications(),
allows an app to recover the set of notifications it has
posted that are still active (un-cleared, un-canceled,
visible by the user). Along with the Notification object
you'll get the original tag and id you used to post it,
wrapped up in the somewhat awkwardly-named
StatusBarNotification data structure (previously only used
internally by NoMan/SysUI and NotificationListenerServices).
Bug: 17320461
Change-Id: I8cd610956fafed4e31526b663cebdc31231ad930
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 1fc476d51203c0b76ebd0f2062adf3059437b0dc |
|
14-Apr-2015 |
John Spurlock <jspurlock@google.com> |
Zen: Add notification policy management api.
- Allow apps to read and modify notification policy (currently
which items are prioritized in "priority only" mode), but only
after they've been granted access by noman.
- Access to read/modify notification policy requires a token provided
by noman. Enabled notification listeners are automatically given
tokens (new getter on NLS), but any other app can also request them.
- Currently, all requests are granted.
- Also add a new change intent when the public policy changes.
Bug: 18541928
Change-Id: I482d1c39852d0d961931515e0f0e059a8faee4ed
/frameworks/base/core/java/android/app/NotificationManager.java
|
| b2278d65714c0dd0a6f94d1913db1ebc8bfc8b06 |
|
07-Apr-2015 |
John Spurlock <jspurlock@google.com> |
An update on Downtime.
The update is that Downtime is obsolete. Replaced by the
ability to define multiple named schedule calendars.
- Make changes to ZenModeConfig to properly model manual
and automatic rules.
- Refactor the zen mode helper (and supporting classes) to
properly handle / report multiple claims on zen mode.
The "manual" rule (specified by the user in the UI) vs
one or more automatic rules.
- Automatic rules are still backed by condition providers,
but the layering is now cleaner. ConditionProviders is now
completely generic, has no ties to zen mode.
- Specifically, the new layering for zen mode (below noman) is:
ZenModeHelper: Source of truth for zen state
ZenModeFiltering: Subhelper dedicated to filtering rules.
ZenModeConditions: Subhelper dedicated to managing automatic rules.
ConditionProviders: Underlying engine for reporting named boolean state.
- Migration story for users with existing downtime config, migrated
to a single new calendar named downtime.
- For users with no existing downtime, two default calendars are created
for weeknights + weekends (icu4j for all locales will be done in a followup).
- Remove obsolete DowntimeConditionProvider/NextAlarmConditionProvider and tracking.
- Clean up obsolete resources.
- Add common zen summary description string computation.
- Add proper noman wrappers for the new model.
- Change the semantics of the global zen setting. It is now read-only. Setters
must call noman, added a "reason" to all calls for better attribution.
- Update zenmodepanel + volumedialog to the new model.
- Display the one or more automatic rules in the new zen footer summary.
- "Snooze" the automatic rules when the user explicitly turns zen off.
Bug: 20064962
Change-Id: Idd9deb865a6035ad0cfae660198dccb517e6d7cc
/frameworks/base/core/java/android/app/NotificationManager.java
|
| cdb57aeb0e2c83a887c86da0ca2a890df7f02f41 |
|
12-Feb-2015 |
John Spurlock <jspurlock@google.com> |
Allow sysui-managed remote volume controllers.
- Relax restriction on audio service calls that assume the volume
ui is systemui, allow calls from a blessed component app.
- Blessed component app service saved in secure settings.
- SystemUI mediates requests to replace the volume dialog, prompts
the user on activation.
- Show a low pri ongoing notification when the volume dialog is
being replaced, to allow user restoration at any time.
- Replace the controller management code in VolumeUI to use a
ServiceMonitor, backed by the new blessed app component setting.
- Add proper zen-related noman client wrappers, make avail to the
registered volume controller.
- Everything is still @hidden, no api impact.
Bug: 19260237
Change-Id: Ie1383f57659090318a7eda737fdad5b8f88737d4
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 530052a2fe3b6a6a4246ce28ab0ced647fe7f470 |
|
30-Nov-2014 |
John Spurlock <jspurlock@google.com> |
Zen: New behavior for built-in downtime + nextalarm conditions.
- Downtime: Allow user to enter downtime early, offer as an end
condition four hours before downtime starts. Available in
either none or priority, regardless of settings configuration.
- Downtime: Always exit before next alarm if zen=none.
- Downtime: Make more like any other condition provider, remove
special status (mostly).
- Downtime: New auto-triggering rules, allow triggering after a
manual condition ends, once.
- Decouple NextAlarm + Downtime providers, allow them to offer
their conditions at the same time.
- Downtime/NextAlarm: Update conditions if they change while being
requested, even if unsubscribed.
- Make all three built-in condition providers optional, via config.
- New internal helper for runtime config.
- Don't follow changes to next alarm, consider the condition false.
- Isolate downtime calendar logic into separate class (for testing).
- Allow a:bb -> a:bb as a valid downtime range (all day).
- Volume dialog: configuration establishes maximum number of visible
conditions, including built-ins.
- Zen mode panel: avoid widget updates during layout transition.
- Zen mode panel: move controller callers to background thread.
- Zen mode panel: hide/show/rebind rows instead of adding/removing.
- ZenLog: Add downtime autotrigger results.
- Volume panel: Smarter refresh on ringer/zen changes.
Bug: 16373455
Change-Id: I4f801018ddb0beb6eb9fa03a81c79f7949888a3f
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 2b122f4c2e691f0319e4f9ea5873989792bb56a6 |
|
27-Aug-2014 |
John Spurlock <jspurlock@google.com> |
Add a hidden system method to check call filter.
As a stopgap for dialer, add a NoMan method to check
whether or not contact extras meet the current notification
interruption filter, if phone calls are allowed at all.
Bug:17299986
Change-Id: I4d7e04b974d878504ef4e3a73cb6b602cdd2f73e
/frameworks/base/core/java/android/app/NotificationManager.java
|
| b4782526f5600d9759baac64b23e0c0cd05e2050 |
|
22-Aug-2014 |
John Spurlock <jspurlock@google.com> |
Display notification effects suppressor in the volume panel.
Bug:16958514
Change-Id: I0eac173875e8af62e3c6b39001722c3fda4517de
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 4600f9b60753adab4e65258a05744a46938fce86 |
|
22-Jul-2014 |
Christoph Studer <chstuder@google.com> |
Strip RemoteViews from Notifications, re-create them in SysUI
Bug: 16329721
Change-Id: Ic0bea763ffaec4c5644ca78705007211ac6b4b88
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 95d785346b4dae808a2d8f77356175e55a572d96 |
|
11-Sep-2013 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #10688644: Java crash in com.android.phone:
java.lang.SecurityException: Operation not allowed
There was a situation I wasn't taking into account -- components
declared by the system has a special ability to run in the processes
of other uids. This means that if that code loaded into another
process tries to do anything needing an app op verification, it will
fail, because it will say it is calling as the system package name but
it is not actually coming from the system uid.
To fix this, we add a new Context.getOpPackageName() to go along-side
getBasePackageName(). This is a special call for use by all app ops
verification, which will be initialized with either the base package
name, the actual package name, or now the default package name of the
process if we are creating a context for system code being loaded into
a non-system process.
I had to update all of the code doing app ops checks to switch to this
method to get the calling package name.
Also improve the security exception throw to have a more descriptive
error message.
Change-Id: Ic04f77b3938585b02fccabbc12d2f0dc62b9ef25
/frameworks/base/core/java/android/app/NotificationManager.java
|
| a14acd20b8d563319ea1a5974dca0e9a29f0aaef |
|
03-Apr-2013 |
Jeff Sharkey <jsharkey@android.com> |
Warn when exposing file:// Uris beyond a process.
Check for file:// Uris inside Intents, ClipData, Notifications and
RemoteViews when StrictMode option is enabled.
Also introduces Intent.prepareToLeaveProcess() to uniformly handle
Intents about to leave an app process.
Bug: 8529070
Change-Id: I8efb43877cbc5f21eb029fc6492b3ee1415059ef
/frameworks/base/core/java/android/app/NotificationManager.java
|
| f265ea9d8307282ff1da3915978625a94fc2859e |
|
01-Feb-2013 |
Dianne Hackborn <hackbod@google.com> |
App ops: vibration, neighboring cells, dialing, etc.
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
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 65c4a2b26cd8776b0927e9b0e07ecf53bd31b627 |
|
26-Sep-2012 |
Jeff Sharkey <jsharkey@android.com> |
Multi-user ringtone playback.
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
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 4120375d46091df8527bb701882e056fbb0e6b06 |
|
31-Aug-2012 |
Dianne Hackborn <hackbod@google.com> |
Remove Binder.getOrigCallingUid().
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
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 69ddab4575ff684c533c995e07ca15fe18543fc0 |
|
25-Aug-2012 |
Jeff Sharkey <jsharkey@android.com> |
Always-on VPN.
Adds support for always-on VPN profiles, also called "lockdown." When
enabled, LockdownVpnTracker manages the netd firewall to prevent
unencrypted traffic from leaving the device. It creates narrow rules
to only allow traffic to the selected VPN server. When an egress
network becomes available, LockdownVpnTracker will try bringing up
the VPN connection, and will reconnect if disconnected.
ConnectivityService augments any NetworkInfo based on the lockdown
VPN status to help apps wait until the VPN is connected.
This feature requires that VPN profiles use an IP address for both
VPN server and DNS. It also blocks non-default APN access when
enabled. Waits for USER_PRESENT after boot to check KeyStore status.
Bug: 5756357
Change-Id: If615f206b1634000d78a8350a17e88bfcac8e0d0
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 558459fe85f56f29a6ed6a4d0adb4a0bd6665884 |
|
14-Oct-2011 |
Joe Fernandez <joefernandez@google.com> |
docs: add developer guide cross-references, Project ACRE, Round 2
Change-Id: I39a534ae3a2a34b4dabc333a09961012ef911d3e
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 43a17654cf4bfe7f1ec22bd8b7b32daccdf27c09 |
|
07-Apr-2011 |
Joe Onorato <joeo@google.com> |
Remove the deprecated things from Config.java. These haven't been working since before 1.0.
Change-Id: Ic2e8fa68797ea9d486f4117f3d82c98233cdab1e
/frameworks/base/core/java/android/app/NotificationManager.java
|
| e97a3bce3c91d76b623f57d309f7bf74947494da |
|
07-Feb-2011 |
Daniel Sandler <dsandler@google.com> |
Minor cleanups to Notification docs.
Bug: 3240190
Change-Id: I25f954bf8346a0da281fa47c7e91abaff4eb4259
/frameworks/base/core/java/android/app/NotificationManager.java
|
| f3a6b901917b1609c6f1901bb36deb07a58fd20d |
|
02-Nov-2010 |
Brad Fitzpatrick <bradfitz@android.com> |
am 9df48a03: Merge "NotificationManager: droiddoc documentation improvements"
* commit '9df48a0305818122298a86ae9949f6688814928b':
NotificationManager: droiddoc documentation improvements
|
| b97c34948e5fcb765f46d655bbf358d06ef89a67 |
|
13-Oct-2010 |
Peter Collingbourne <peter@pcc.me.uk> |
NotificationManager: droiddoc documentation improvements
Specifically, corrects and improves the overview and the documentation
for the NotificationManager.notify(String, int, Notification) method
to reflect the fact that the pair (tag, id) is used for notification
matching.
Change-Id: Ic088a56f457285523d90d296853685393b8c3412
/frameworks/base/core/java/android/app/NotificationManager.java
|
| d0a2f86f357f346639a6648b4004266865c979b4 |
|
03-Aug-2010 |
Daniel Sandler <dsandler@android.com> |
Fix crash when startForeground posts a broken Notification.
The NotificationManager tries to crash the calling app, but
in the case of a service calling startForeground, the caller
is the ActivityManager, so system_server goes down.
NotificationManagerService#enqueueNotificationInternal is a
new internal-only method that accepts a UID/PID to use when
punishing bogus notifications (such as the one in
http://b/2869787).
Change-Id: I84a9854bae630bc90288cebb94f174809d5dac8c
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 6ecaff15836581336b1e8fad6ac42f3ff4a13544 |
|
25-Sep-2009 |
Fred Quintana <fredq@google.com> |
add a optional String to the key of notifications to allow users
to scope them
/frameworks/base/core/java/android/app/NotificationManager.java
|
| d8a43f61680bacf0d4b52a03ff3c7a07307377fc |
|
18-Aug-2009 |
Dianne Hackborn <hackbod@google.com> |
Fix issue #2047139: Remove Service.setForeground()
This API is becoming seriously abused, so now it is deprecated and has
become a no-op.
As an alternative, there is now a new API that allows you to make a service
be in the foreground but requires providing a persistent notification to
go along with this state, allowing the user to know about and control it.
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 9066cfe9886ac131c34d59ed0e2d287b0e3c0087 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/app/NotificationManager.java
|
| d83a98f4ce9cfa908f5c54bbd70f03eec07e7553 |
|
04-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@135843
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 076357b8567458d4b6dfdcf839ef751634cd2bfb |
|
03-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@132589
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 3dec7d563a2f3e1eb967ce2054a00b6620e3558c |
|
03-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //depot/cupcake/@137055
/frameworks/base/core/java/android/app/NotificationManager.java
|
| 54b6cfa9a9e5b861a9930af873580d6dc20f773c |
|
21-Oct-2008 |
The Android Open Source Project <initial-contribution@android.com> |
Initial Contribution
/frameworks/base/core/java/android/app/NotificationManager.java
|