| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Permission should only allow cancellation of other app notifications, not enqueueing.
Fix checkapi breakage.
Change-Id: Idbcfd4617057984250dc4d4fa32ff55bfbb155e2
|
| |
|
|
| |
Change-Id: I055b17873e174f71174898a7649b1e221fd8c436
|
| |
|
|
|
|
|
| |
If the call is from a user process, using USER_CURRENT_OR_SELF avoids a security
exception in such cases.
Change-Id: I2f25917ecfabc80d3a193d63020ad11480edf8ec
|
| |
|
|
|
| |
Change-Id: I8a5e1d15d17d56089158b24f9a4b246ae6e60285
JIRA:CYAN-1550
|
| |
|
|
|
| |
Change-Id: I407e34f9c60d3140f78abca133b4fda5dd45f311
JIRA:CYAN-689
|
| |
|
|
| |
Change-Id: Iade96474c26dbeb3a5a671170f563220562d9b3c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Commit 5713307e3d2eb457ba148df3683ad09733727506 (in ICS) attempted to
fix the problem that the notification LED wasn't reenabled after
turning off the screen again, but introduced another bug in the
process: If another pending notification with LED at the time when the
notification with the new magic flag introduced by that commit (which
was used by phone and MMS apps) was active, the LED still wouldn't be
turned on at screen off time. Also, this commit didn't handle locking
correctly.
This commit essentially reverts 5713307e and makes sure the LED is
reevaluated when the screen is turned off again.
- This change also makes the assignment of the LED when multiple pending
notifications want to use the LED more clear: The notification with
highest priority gets the LED. If multiple notifications with same
priority exist, the most recent one gets the LED.
JIRA:CYAN-652
Change-Id: I1df0b40cca2af7a08c240677d22d2a95097b7184
|
| |
|
|
|
|
|
|
|
|
| |
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
Signed-off-by: Chirayu Desai <cdesai@cyanogenmod.org>
|
| |
|
|
|
|
|
| |
4.2.2 touched the NotificationManager service, and some logic went missing in the merge it seems.
This should take care of it.
Change-Id: Ib3b88c83d2936871fbe25f1acbd10fd60c577944
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
core/java/android/os/Trace.java
core/java/android/widget/Toast.java
core/res/res/values-cs/strings.xml
core/res/res/values-el/strings.xml
core/res/res/values-iw/strings.xml
core/res/res/values/config.xml
core/res/res/values/symbols.xml
media/java/android/media/AudioService.java
packages/SystemUI/res/values-sv/strings.xml
packages/SystemUI/src/com/android/systemui/statusbar/phone/NotificationPanelView.java
packages/SystemUI/src/com/android/systemui/statusbar/policy/BatteryController.java
packages/SystemUI/src/com/android/systemui/usb/StorageNotification.java
policy/src/com/android/internal/policy/impl/keyguard/KeyguardHostView.java
policy/src/com/android/internal/policy/impl/keyguard/KeyguardMessageArea.java
policy/src/com/android/internal/policy/impl/keyguard/KeyguardViewManager.java
policy/src/com/android/internal/policy/impl/keyguard/KeyguardViewMediator.java
services/java/com/android/server/NotificationManagerService.java
services/java/com/android/server/power/ElectronBeam.java
Change-Id: I60b8ddf20a1d7bcf9dc7b1a4ed841aaa4d953294
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| | |
Change-Id: I4fa1f55c8209e6890b6cea13b0ed4d781f9f615d
|
| | |
| |
| |
| | |
Change-Id: I4fb84fdb0c9e1592c2a421011c303a789cde8c8c
|
| | |
| |
| |
| | |
Change-Id: Ica967ff6bf5842a08421583449876ba73de13d51
|
| | |
| |
| |
| | |
Change-Id: Ia3d84f0ed6174234e07b1a5faa244cd63b4f6b4c
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Allows to change the new feature of AOSP 4.2, where all notification are
changed to vibrations on vibrate mode. Instead, allow the old behaviour
to silence sound notifications and to only play vibrations if desired.
Alle credits go to romanbb from AOKP, I just ported it.
Original AOKP-Commit:
https://github.com/AOKP/frameworks_base/commit/c1b2bb9b5d0c33e790973841bb2acaa5ea5d51fe
Change-Id: Id27dd2975d3383f6d7395a0ee995d7832e87ca66
|
| | |
| |
| |
| | |
Change-Id: I930d4cc75e655c5bc37532e6a1425d27bd1ee661
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
1) NPE in Power penu
This fixes the NPE when the Reboot item is disabled and the Profiles
switcher is not
2) NPE in notification manager if profiles disabled
No active profile group is returned and a NPE is triggered when a
notification override is being set
Change-Id: I5fa003ce08daf5ef86ddeca5d432dcea2e34a718
|
| |\ \
| | |
| | |
| | | |
Change-Id: I1f5dddb99c9d381607124ae963fdadf990715e18
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- 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 same
vibration pattern but can be changed easily in future.
- The DEFAULT_VIBRATE and fallback vibrate patterns are now
specified in config.xml.
Bug: 7531442
Change-Id: I7a2d8413d1becc53b9d31f0d1abbc2acc3f650c6
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Updated 4.2 support for the old T-Mobile theme engine, as usual
needs the provider and switcher apps installed as well.
I'm finally dropping the 400+ commit history on this, since everybody
else keeps picking it up from CM as a single patch anyway... But
for the record, nothing of this would be possible without Josh, Ed,
and the rest of the TMo guys who wrote and maintained it until 2.2:
amit chabra <amit.chabra@t-mobile.com>
Amit Kohli <amit.kohli@t-mobile.com>
Chris Cogar <chriscogar@t-mobile.com>
Dirk Sigurdson <dirk.sigurdson@t-mobile.com>
Ed Carrigan <edward.carrigan@t-mobile.com>
Gaurav Sharma <gaurav.sharma3@t-mobile.com>
Hui Feng <hui.feng@t-mobile.com>
John Ritz <john.ritz1@t-mobile.com>
Josh Guilfoyle <josh.guilfoyle@t-mobile.com>
Mark Roberts <mark.roberts48@t-mobile.com>
Pankaj Kumar <Pankaj.kumar6@t-mobile.com>
Samuel Cheung <samuel.cheung@t-mobile.com>
Sergey Ten <sergey.ten6@t-mobile.com>
Change-Id: I7148d51be48f28a2dc4bdf9ec9018f04b268ffc4
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit includes:
- Power menu Reboot
- Power menu screenshot
- Profiles
- Lock screen Calendar
- Lock screen Weather
- Notification light customization
- Battery light customization
- IME Selector notification toggle
- and a few more things to support Settings
Change-Id: Ibd63116df90b06f6ce6adb8a0343059bbb999bfb
|
| |/
|
|
|
|
|
| |
(Unless the notification specifies no ringtone AND no
vibration, in which case it will remain silent.)
Change-Id: I926d0fe0165b9622cd117e6c3ef6e3637772b444
|
| |
|
|
|
|
|
|
|
|
|
| |
is specified.
Bug: 7490028
Otherwise notifications such as the USB debugging and OTA notifications will be
dismissed when any user is stopped.
Change-Id: I0ae0c1136a999dd3aade99ca9e71c714b359eab4
|
| |
|
|
|
| |
Bug: 7430689
Change-Id: I2430b20137705ed2d6dc0f870690acda0662392b
|
| |
|
|
|
|
|
| |
This also adds the userid to notification_* eventlogs.
Bug: 7325802
Change-Id: I48055caf1344acd58b61607bf0be38cc299fc7be
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
Bug: 7298189
Change-Id: Ie9c160f12067f1b9426acbfee67ef81e8f5f7992
|
| |
|
|
|
| |
Bug: 7298302
Change-Id: I1e176f7b17bb51b878f2e8b345804780df92d487
|
| |
|
|
|
|
|
| |
Which also takes care of the ACTION_USER_REMOVED case.
Bug:7277853
Change-Id: I0a6bade11bd0d420df03e16e69a386cfccfa07cc
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |
|
|
|
|
|
|
|
| |
posted.
This keeps all the fullScreenIntent logic (including
multiuser implications) in one place.
Change-Id: I4ef284daf90464f105780ade1d971e9e081fbbb5
|
| |
|
|
|
|
| |
USER_ALL notifications will still play/vibe for any user.
Change-Id: Ie8cc69bd1541193ed9c4207ef38a8d4898af0a9d
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Fix a couple of places where incorrect userIds were being passed in.
Change-Id: I398c676e0488ff7e584be96e96c8b32652134238
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The activity manager now keeps track of which users are running.
Initially, only user 0 is running.
When you switch to another user, that user is started so it is
running. It is only at this point that BOOT_COMPLETED is sent
for that user and it is allowed to execute anything.
You can stop any user except user 0, which brings it back to the
same state as when you first boot the device. This is also used
to be able to more cleaning delete a user, by first stopping it
before removing its data.
There is a new broadcast ACTION_USER_STOPPED sent when a user is
stopped; system services need to handle this like they currently
handle ACTION_PACKAGE_RESTARTED when individual packages are
restarted.
Change-Id: I89adbd7cbaf4a0bb72ea201385f93477f40a4119
|
| |
|
|
|
|
|
| |
Introduce API to get per-user storage information, keep track
of services associated with users, and various small cleanup.
Change-Id: I5d4e784e7ff3cccfed627d66a090d2f464202634
|
| |
|
|
|
|
| |
This is the start of turning this into a formal public API.
Change-Id: I5786d2c320f1de41a06ed5d0f65adb68967287a0
|
| |
|
|
|
|
|
|
|
|
| |
Use notification manager as an indicator of when to stop the screensaver
due to immediately-needed user interaction.
Any notification with a fullScreenIntent will now exit the screensaver.
Bug: 6976796
Change-Id: Id91cd4c32f3fad018b56f4dfe24b37110bab32d8
|
| |
|
|
| |
Change-Id: Ib34e294747405b7ab709cb0bbb2d9a0cc80ce86a
|