| Age | Commit message (Collapse) | Author |
|---|
|
Cherry-picked from klp-modular-dev
Provide an abstract class for system services to extend from,
similar to the android.app.Service.
This will allow services to receive events in a uniform way,
and will allow services to be created and started in the
correct order regardless of whether or not a particular
service exists.
Similar to android.app.Service, services are meant to implement
Binder interfaces as inner classes. This prevents services from
having incestuous access to each other and makes them use the
public API.
Change-Id: Iaacfee8d5f080a28d7cc606761f4624673ed390f
|
|
Migrate transient bar mode to IMMERSIVE_STICKY, and
introduce new behavior for IMMERSIVE: namely the
opaque bars are revealed by clearing the flags on swipe.
Remove low-profile optimization that confuses api demos
and other apps using low-profile as a signal.
TransientNavigationConfirmation renamed to
ImmersiveModeConfirmation, and its associated resources,
since the confirmation is now shown when the nav bar is
shown in either of the two immersive modes.
Remove unused Toast.makeBar and associated hidden framework
bits now that the confirmation uses a cling instead.
Bug:11062108
Change-Id: Iae49d31973940b9bee9f5b1827756db5eaa76aa3
|
|
Bug 11154482
Change-Id: I55107fec51bf5efada136052c451f293976360d6
|
|
1. The singleton print spooler isntance is created when the print spooler
service gets a connection to the system and is destroyed when this
connection is removed. Note that if the spooler has work, then the
connection to the system will not be removed.
When the spooler is created, it reads the stored state and notifies the
system which in turn dispatches this to the print services.
When the system connects to the spooler and passes it a connection, we
schedule a delayed check whether there is work for the spooler. We do
not handle this immediately to avoid intermitted spinning on and off
of the spooler process if a client makes a sequence of queries while
the spooler has really no work.
2. Fixed a bug in the NotificationManagerService where adding a notification
and removing it immediately after that does not remove the notification.
The code that is adding a notification is run on a handler thread while
the code to remove it on the calling thread. This creates a race and
erroneous results. Now the removal is also scheduled on the handler.
3. Many small fixes here and there.
Change-Id: I6415c253139fa6616393fbe23c659d031a29e1f6
|
|
for foreground services.
* commit '9e6f26a8e1e69b1c49676d60a5ebe36c0a0f23f9':
Allow the user to block notifications for foreground services.
|
|
Stepping carefully around the fix in change Idc788527, we
perform security (and AppOps, and therefore user block)
checks against the uid passed to enqueueNotificationInternal
rather than the Binder caller.
Bug: 9502541
Change-Id: I91745db92823381df75721c1b8f11013a7fa4ecc
|
|
Summary of feature:
Do not mute notifications when speech recognition recording is
active, but when an app has requested audio focus with
AudioManager.AUDIOFOCUS_GAIN_TRANSIENT_EXCLUSIVE.
Implementation:
Move definition of AUDIOFOCUS_NONE to AudioManager where other
audio focus codes are defined.
Add support for querying the current audio focus type.
When audio focus is requested as GAIN_TRANSIENT_EXCLUSIVE, make
the corresponding loss by LOSS_TRANSIENT.
Before playing a notification, check whether GAIN_TRANSIENT_EXCLUSIVE
has been requested.
Bug 8251963
Change-Id: I41edc77326b70639d2fdcb4642c53109995b72a8
|
|
This CL adds an interface and classes for scoring notifications.
The NotificationManagerService initializes an array of scorers
specified as a resource. When a Notification is enqueued, the
getScore() method is called successively on the scorers, each
getting the Notification to be scored, and the score outputted
by the previous scorer. At present there is a single scorer
which prioritizes Notifications that mention the display name of
a starred contact.
To turn off the StarredContactNotificationScorer:
adb shell settings put global contact_scorer_enabled 0
Change-Id: Ic16c80952e7c85bdde292ebb3f7900efb01f2e29
|
|
As a prelude to introducing fancier scoring functions, this CL
moves scoring and everything that depends on it into a handler.
This allows the NotificationManagerService to report back to the
calling process right away about whether or not the notification
is valid; not blocking while score is computed, and non-statusbar
notification modalities are activated.
Change-Id: Iaf77bc89544bb7bcb7adeda60885d74c3170541c
|
|
icon==0 notifications." into jb-mr2-dev
* commit '5be52fb5ae462b83b0619b95e7991e52bc2031b2':
Temporarily restore some support for icon==0 notifications.
|
|
jb-mr2-dev
|
|
SYSTEM_UID or PHONE_UID." into jb-mr2-dev
* commit '0a2ff8db4339261d701ad542ac770fb92bf2127b':
Do not block notifications or toasts for SYSTEM_UID or PHONE_UID.
|
|
The specific bug is this: SIM PIN unlock attempt toasts are
sent from com.android.settings/.IccLockSettings which runs
as the phone process; NoMan wasn't having any of that and
was blocking the toasts.
With this change we treat SYSTEM_UID and PHONE_UID the same
for all security checks, and furthermore we guarantee that
all notifications and toasts from those UIDs will be
permitted.
Bug: 9098802
Change-Id: Idc788527aa2cb38e015fe92773766a514167999e
|
|
Enhance Toast to support new standard toast bar style, similar
to the undo bar in Gmail. Toast bars can be interactive,
and can have a single action. Add a new toast duration to
indicate persistent toasts (no auto-hide delay).
Use the new toast bar to implement a feature hint when hiding
the navigation bar in hideybars mode.
Per UX, the feature confirmation bar can also be dismissed on
any outside touch as long as the user confirmed it using the
OK button at least once globally.
Bug: 8754108
Change-Id: Iaa85d3b4da7ada1952a562f1e31de04380f5d587
|
|
jb-mr2-dev
|
|
This is WRONG WRONG WRONG but certain apps rely on it to
poke the LED and so forth. In a future release this will
stop working.
Bug: 8623399
Change-Id: I49bb8ccc6891b1398ceec94c64d6c3a510ad1c38
|
|
Bug: 9069919
Change-Id: I06130105cb703de35de76ab2fceba3855fa5407a
|
|
|
|
We don't want to save all the heavyweight stuff, but we
can't lighten the notification in place because there may be
other active references.
Bug: 8839246
Change-Id: Id6dcc1cf5ae196ee3e42908d6b3ec4e928e9f0c5
|
|
PACKAGE_CHANGED is called when either the application or any
of its components change. Rework old early exit code to
handle component-level disabling wrt listeners.
Note PACKAGE_CHANGED can take quite a while to reach NMS.
Up to ten seconds (!) after component-disabling in app.
Bug:8982243
Change-Id: Ia325516140dd9288466a663192a5326019f071ab
|
|
Bug: 8979640
Change-Id: I9f1d118e5ce210b829476e0971f3d55fc778c227
|
|
Use ForUser overload when reading setting inside system server.
Bug: 9000206
Change-Id: Ie87aed578d29425d8f32b23aeb8aa7118922c889
|
|
Bug: 8813471
Change-Id: Icf6c69811392c4567a5c842740e463fb957e7563
|
|
Bug: 8575629
Change-Id: Iafc8ab2f7460c8eacc37fc077cf5a3df16cf2911
|
|
Bug: 8656860
Change-Id: If3062b9fc00270e5f0ecfe67e593b9a28c6bccdd
|
|
- 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
|
|
jb-mr2-dev
|
|
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
|
|
Bug: 8537938
Change-Id: I2e4eccc3bd6d57fe5cef340d9e67986d78d3be95
|
|
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
|
|
Use with INotificationManager.registerListener(). Limited to
system only right now.
Change-Id: I65b6a8778267022cdc5e58eb75ae607a54b1cc52
|
|
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
|
|
The ACCESS_NOTIFICATIONS permission is signature|system only.
Change-Id: I41338230aee9611117cbdac251c1b6b6c3cebf00
|
|
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
|
|
Change-Id: I23064ce3014d2446d009bbdff92b301280e8b989
|
|
ambient." into jb-mr1.1-dev
* commit '8f7eddbef33f97e7d4439707ac0039be4c81ef0e':
PRIORITY_MIN notifications should be truly ambient.
|
|
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
|
|
vibe pattern" into jb-mr1.1-dev
* commit '8fef4a820ee217f25fbf29234e90d68dff448222':
DEFAULT_VIBRATE must always use the default vibe pattern
|
|
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
|
|
sound is Silent." into jb-mr1.1-dev
* commit '00679b5b467dbc19ce2223b5501976c5c3f66fa9':
Do not vibe when the default notification sound is Silent.
|
|
jb-mr1.1-dev
* commit '2bb5dc6a367ce869939728b2978be7ca61a4b8b8':
Notification vibration improvements:
|
|
(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
|
