summaryrefslogtreecommitdiff
path: root/packages/SystemUI/src/com/android/systemui/media/NotificationPlayer.java
Commit message (Collapse)AuthorAgeFilesLines
* Notification playback: pause on releaseJean-Michel Trivi2021-08-201-3/+17
| | | | | | | | | | When releasing a MediaPlayer outside of a playback completion (back to back notifications), pause and wait 100ms before releasing the player. Bug: 193832902 Test: create back-to-back notifications, check for glitch Change-Id: Ib8baba4bf2b41e75b526e8490b6c2f31c85c193c
* NotificationPlayer: release MediaPlayer on error and exceptionJean-Michel Trivi2018-07-111-18/+35
| | | | | | | | | | | | | Add a lock to synchronize changes to mPlayer in the playback thread and callback thread. Refactor the exception handling CreationAndCompletionThread to always release the player that was set up to play the sound. In the error and completion callbacks release the media player. Bug: 110021815 Test: play notifications with wrong URI, verify players are released. Change-Id: Ibbd06a64c8211dff24b4cfc5960d017721eca123
* NotificationPlayer: fix focus not abandoned on playback errorJean-Michel Trivi2017-12-271-2/+21
| | | | | | | | | | If an exception is fired when trying to start the MediaPlayer after audio focus was requested, it will not be abandoned on error or completion. Bug: 70727414 Test: see bug Change-Id: Ib2a07499829890a858d5a38d46c3575d2d7b6629
* NotificationPlayer: fix race conditionsJean-Michel Trivi2017-09-281-20/+54
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes two race conditions that affect the Looper used to signal the completion of a notification to abandon audio focus as well as the wakelock used between issuing a playback command and its actual start. Annotations are added to clarify which objects are used to synchronize which methods and variables. Looper for notification playback completion: Before a notification starts playing, audio focus is requested, which causes the ducking of media apps. When the notification completes, audio focus is abandoned. If a new notification is to be played while one is playing, the current player is stopped and the Looper on which we expect the MediaPlayer completion callback is .quit(). But there is a race condition between the quitting of the current Looper whenever a sound is started (in startSound()) and when quit when playback is stopped (command STOP), and when created in CreationAndCompletionThread.run(). If the Looper is quit when another notification starts to play, the completion callback cannot be received, and audio focus will not be abandoned. The fix consists in synchronizing all access to mLooper on mCompletionHandlingLock. Wakelock: Initializing and acquiring the wakelock, and releasing it are done in different threads (client thread vs CmdThread). There was no memory barrier between the initialization and release. The fix consists in making all wakelock operations synchronized on mCmdQueue. Test: issue multiple notifications that interrupt eachother, verify focus is abandonned (in logs, check "abandonAudioFocus()") Bug: 65866087 Bug: 64531811 Change-Id: Ie8f4091eaa96bd0bcb732e27423f6e31e76da98e
* NotificationPlayer: fix typo in logJean-Michel Trivi2017-03-201-1/+1
| | | | | Test: n/a Change-Id: I585f6ad39ef6dc0a93651deae6ca50051f732a1b
* NotificationPlayer: fix error listener, sync in playback threadJean-Michel Trivi2017-03-161-4/+9
| | | | | | | | | | | | The error and completion listeners should be set before MediaPlayer.prepare() is called, in case of an error during prepare. Move the sleep to synchronize the playback of the notification and the ducking from the MediaPlayer to the playback thread. Test: play a notification during media playback Bug: 35855841 Change-Id: I42f01f485f533c1cc84b9d927f0dc594cdb7ec8f
* Notification playback synchronized with audio focusJean-Michel Trivi2017-01-311-14/+19
| | | | | | | | | | | | | | | | | | | PlayerProxy: more control options (pan, delayed start), remove exceptions in method signatures. Use delayed start on notification playback for better sync between media apps and notifications Disabled for now: support for AudioService (through MediaFocusControl and PlaybackActivityMonitor) to enforce audio ducking of focus owners losing audio focus with AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK, and who don't play audio that has a content labelled as CONTENT_TYPE_SPEECH. This feature will be enabled when setting a VolumeShaper on a player works. Test: play music and play notification Bug 30258418 Change-Id: I4e4d911645306bbde17f74288f3b61781fe0e3fe
* Notification player: do not use stream typesJean-Michel Trivi2017-01-191-6/+12
| | | | | | | | | | | Don't go through stream types for the attributes of the notification to play when requesting focus Test: play notification with usage USAGE_NOTIFICATION_EVENT, verify that usage is communicated to MediaFocusControl Bug 30258418 Change-Id: Ieaab969d84728b04a6f34aa8a02cf18ba22d1aca
* NotificationPlayer supports MediaPlayer errorsJean-Michel Trivi2015-08-251-1/+10
| | | | | | | | | If an error is reported while trying to play a notification, behave as if the playback had completed. Bug 21093153 Change-Id: Iedc7691d0b8f4d68ad75cb04292a5d7d9350552f
* Add support for AudioAttributes in android.media.RingtoneJean-Michel Trivi2014-08-121-6/+38
| | | | | | | | | | Deprecate use of stream types. Map deprecated API to AudioAttributes. Add new methods to specify AudioAttributes on a Ringtone instance. Bug 16790748 Change-Id: Ifb3c2e838e1f119614459ad7d71d83a4d7c9ffdb
* Organize the imports in systemui.John Spurlock2013-06-121-1/+0
| | | | | | | To follow android conventions, more importantly to remove the unused. Change-Id: I75881718e84360a579a3b02c26489ad250bc9227
* Remove obsolete importsJean-Michel Trivi2013-02-131-4/+0
| | | | Change-Id: I67d357a1b0bac89447b1e237f61dd18aea7b912b
* Fix AudioFocus for back-to-back notificationsJean-Michel Trivi2013-02-131-12/+35
| | | | | | | | | | | | | | | | A single instance of NotificationPlayer will play notifications back-to-back, and was, for each requesting AudioFocus. But as a new notification was about to be played, its accompanying thread was terminated, and the completion listener was never called, and therefore AudioFocus was not released (e.g. two requests for one release). The fix consists in requesting AudioFocus only once and abandonning it when the only reported completion is received. Added a FIXME note about a better solution to be implemented. Bug 7680947 Change-Id: Ica9d5c1eb5d57c89ceebe66282af69f0f7d43667
* No AudioFocus for notifications when media played remotelyJean-Michel Trivi2013-02-121-6/+8
| | | | | | | | | | | Don't use AudioFocus when playing a notification when media is playing remotely. This behavior may be accompanied by rules in the device's audio policy to not route the notifications to the remote display. Bug 7485803 Change-Id: I8b96aa59cace75f6e9a0e73799ef8c75e9ee97aa
* Migrate ringtone playback to SystemUI.Jeff Sharkey2012-04-271-0/+340
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
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-13 12:46:27 +0000