Media controller android studio

Руководство по VideoView и MediaController

Android-включает в себя два класса, которые отвечают за реализацию воспроизведения видео на устройствах Android. Эти классы очень легко и просто реализовать при разработке приложений. Сегодня я расскажу вам о том, как использовать эти два класса: VideoView и MediaController , чтобы получить приложение воспроизводящее видео.

В этом примере мы будем играть mp4 с SDCard/External-storage с помощью android.widget.VideoView. Также мы будем управлять видео с помощью MediaController, который содержит кнопки, как «Воспроизведение/Пауза», «Перемотка назад», «Перемотка вперед» и ползунок прогресса, связав их методом VideoView.setMediaController() .

Пользователь будет иметь возможность контролировать видео с помощью MediaController нажав на видео (или VideoView), чтобы отобразить контроллер. Следуйте инструкциям ниже, чтобы получить рабочий код.

Шаг 1: Создайте новый проект в AndroidStudio. Убедитесь, что у вас на вашем устройстве/эмуляторе есть MP4-файл на флеш-карте.

Шаг 2: Добавить следующее разрешение в вашем Manifest-файле :

ПРИМЕЧАНИЕ: Вы получите диалоговое окно с сообщением «Невозможно воспроизвести это видео», если вы забыли добавить разрешения в манифесте или если нет MP4-файла на флешке.

Шаг 3: Напишите следующий текст в ваш layout-файл:

Шаг 4: Напишите это в MainActivity:

Источник

Media controller android studio

Media Controller Test

Create a simple MediaController that connects to a MediaBrowserService in order to test inter-app media controls. This tool is described in the Android documentation: Using the media controller test app.

This app works with the Universal Android Music Player sample, or any other app that implements the media APIs. https://github.com/googlesamples/android-UniversalMusicPlayer

1. Select an app from the list of those presented.
   • Only apps that register a service with an intent filter action of «android.media.browse.MediaBrowserService» will be shown.
2. Select the type of action to perform to start the player. Options are:
   • Search: Sends the text provided as a search via prepareFromSearch() or playFromSearch().
   • Media ID: Sends the text provided as a media ID via prepareFromMediaId() or playFromMediaId().
   • URI: Sends the text provided as a URI via prepareFromUri() or playFromUri().
   • No Input: Calls the methods prepare() or play() directly.
3. Text below the PREPARE and PLAY buttons updates based on changes to the media player state via onPlaybackStateChanged and onMetadataChanged and includes the current player state reported via PlaybackStateCompat.getState().
4. Swipe to the left to see typical media controls with the media’s art as a background, if provided.
5. Press back to return to the list of media apps.

It’s also possible to launch the app via ADB and the Activity manager (am).

Parameter	Extra Name
Package name	com.example.android.mediacontroller.PACKAGE_NAME
Search term	com.example.android.mediacontroller.SEARCH
Media ID	com.example.android.mediacontroller.MEDIA_ID
URI	com.example.android.mediacontroller.URI

To start the app and connect to UAMP:

adb shell am start -n com.example.android.mediacontroller/.LaunchActivity —es com.example.android.mediacontroller.PACKAGE_NAME «com.example.android.uamp»

To perform a search with the term «jazz?» one would use:

adb shell am start -n com.example.android.mediacontroller/.MediaAppControllerActivity —es com.example.android.mediacontroller.SEARCH «jazz?»

This app allows for testing how media apps respond to audio focus changes.

The app allows requesting and abandoning the following types of audio focus:

• AUDIOFOCUS_GAIN
• AUDIOFOCUS_GAIN_TRANSIENT
• AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK

For more information on audio focus please see Managing Audio Focus.

This tool displays the supported actions as reported by the MediaSession in the call to MediaSessionCompat.setPlaybackState() as a list of prepare and play actions on the main screen. For actions that are not declared as supported, it also colors the buttons red on the controller screen.

See the screenshots below for examples.

Copyright 2017 Google Inc. All rights reserved.

Licensed under the Apache License, Version 2.0 (the «License»); you may not use this file except in compliance with the License. You may obtain a copy of the License at

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an «AS IS» BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

Источник

Android programmers blog

Simply about difficult

Поиск по этому блогу

пятница, 17 октября 2014 г.

Custom MediaController Android

Так сложилось что мне не подошел стандартный Meedia Controller который используется в VideoView, и поэтому я пошел искать кастомный и нашел на одном из американских сайтах с туториалами . Там как раз рассказывают как создать кастомный MediaController со своими елементами, в общем для меня это было то что нужно, и я решил что эту статью нужно перевести к себе в блог, может она мне еще пригодится, а может не только мне…

Вот так будет выглядеть сам медиаплеер с видео:

Для начала нам нужно создать леяут который будет отображать наше видел, им будет FrameLayout внутри которого будет SurfaceView который собственно и будет выступать за видео проигрыватель.

Далее давайте создадим экран, а точней фрагмент экрана который собственно будет самим контроллером, там где будут кнопки пауза, перемотать, развернуть в весь экран и ползунок перемотки видео.

Он будет иметь следующий вид:

Так, с разметкой мы закончили, теперь нам нужно создать класс проигрывателя который будет создавать поверх нашего SurfaceView будет отображать кнопки с контролами. Кстати нам понадобятся кое какие картинки в дальнейшем поэтому загрузите картинке ниже и засуньте их в папку res/drawable-xhdpi.

Сохранили? Молодцы! Теперь создаем класс VideoControllerView и вставляем в него код который ниже:

В этом классе мы показываем наши контроллы на экране, обрабатываем нажатия, переопределяем некоторые методы, обрабатываем паузу, плей, перемотку и т д. Если есть желание разобраться код вполне себе понятный, но по сути разбираться в нем не нужно если вы не собираетесь написать собственный. Если вы хотите только использовать его как контролл то вам нужно создать активити — MainActivity, и вставить этот код:

В этом классе мы:

• Инициализируем все нужные нам контроллы.
• Запускаем видео.
• Обрабатываем ивенты паузы, плея, прокрутки и остальными.

controller.show(); — показывает наш контроллер, вы его можете вставить в любое место по которому вы бы хотели его вызывать, я лично поставил в onClick для SurfaceView, мне лично удобней когда я по клику на видео вижу контроллы.

Лично для меня этот код был очень полезен, я его использовал в своем проекте и на данный момент я думаю он мне пригодится в дальнейших работах.

Источник

Android и звук: как делать правильно

В статье рассматривается архитектура и API для создания приложений, воспроизводящих музыку. Мы напишем простое приложение, которое будет проигрывать небольшой заранее заданный плейлист, но «по-взрослому» — с использованием официально рекомендуемых практик. Мы применим MediaSession и MediaController для организации единой точки доступа к медиаплееру, и MediaBrowserService для поддержки Android Auto. А также оговорим ряд шагов, которые обязательны, если мы не хотим вызвать ненависти пользователя.

В первом приближении задача выглядит просто: в activity создаем MediaPlayer, при нажатии кнопки Play начинаем воспроизведение, а Stop — останавливаем. Все прекрасно работает ровно до тех пор, пока пользователь не выйдет из activity. Очевидным решением будет перенос MediaPlayer в сервис. Однако теперь у нас встают вопросы организации доступа к плееру из UI. Нам придется реализовать binded-сервис, придумать для него API, который позволил бы управлять плеером и получать от него события. Но это только половина дела: никто, кроме нас, не знает API сервиса, соответственно, наша activity будет единственным средством управления. Пользователю придется зайти в приложение и нажать Pause, если он хочет позвонить. В идеале нам нужен унифицированный способ сообщить Android, что наше приложение является плеером, им можно управлять и что в настоящий момент мы играем такой-то трек из такого-то альбома. Чтобы система со своей стороны подсобила нам с UI. В Lollipop (API 21) был представлен такой механизм в виде классов MediaSession и MediaController. Немногим позже в support library появились их близнецы MediaSessionCompat и MediaControllerCompat.

Следует сразу отметить, что MediaSession не имеет отношения к воспроизведению звука, он только об управлении плеером и его метаданными.

MediaSession

Итак, мы создаем экземпляр MediaSession в сервисе, заполняем его сведениями о нашем плеере, его состоянии и отдаем MediaSession.Callback, в котором определены методы onPlay, onPause, onStop, onSkipToNext и прочие. В эти методы мы помещаем код управления MediaPlayer (в примере воспользуемся ExoPlayer). Наша цель, чтобы события и от аппаратных кнопок, и из окна блокировки, и с часов под Android Wear вызывали эти методы.

Полностью рабочий код доступен на GitHub (ветка master). В статьи приводятся только переработанные выдержки из него.

Для доступа извне к MediaSession требуется токен. Для этого научим сервис его отдавать

и пропишем в манифест

MediaController

Теперь реализуем activity с кнопками управления. Создаем экземпляр MediaController и передаем в конструктор полученный из сервиса токен.

MediaController предоставляет как методы управления плеером play, pause, stop, так и коллбэки onPlaybackStateChanged(PlaybackState state) и onMetadataChanged(MediaMetadata metadata). К одному MediaSession могут подключиться несколько MediaController, таким образом можно легко обеспечить консистентность состояний кнопок во всех окнах.

Наша activity работает, но ведь идея исходно была, чтобы из окна блокировки тоже можно было управлять. И тут мы приходим к важному моменту: в API 21 полностью переделали окно блокировки, теперь там отображаются уведомления и кнопки управления плеером надо делать через уведомления. К этому мы вернемся позже, давайте пока рассмотрим старое окно блокировки.

Как только мы вызываем mediaSession.setActive(true), система магическим образом присоединяется без всяких токенов к MediaSession и показывает кнопки управления на фоне картинки из метаданных.

Однако в силу исторических причин события о нажатии кнопок приходят не напрямую в MediaSession, а в виде бродкастов. Соответственно, нам надо еще подписаться на эти бродкасты и перебросить их в MediaSession.

MediaButtonReceiver

Для этого разработчики Android любезно предлагают нам воспользоваться готовым ресивером MediaButtonReceiver.

Добавим его в манифест

MediaButtonReceiver при получении события ищет в приложении сервис, который также принимает «android.intent.action.MEDIA_BUTTON» и перенаправляет его туда. Поэтому добавим аналогичный интент-фильтр в сервис

Если подходящий сервис не найден или их несколько, будет выброшен IllegalStateException.

Теперь в сервис добавим

Метод handleIntent анализирует коды кнопок из intent и вызывает соответствующие коллбэки в mediaSession. Получилось немного плясок с бубном, но зато почти без написания кода.

На системах с API >= 21 система не использует бродкасты для отправки событий нажатия на кнопки и вместо этого напрямую обращается в MediaSession. Однако, если наш MediaSession неактивен (setActive(false)), его пробудят бродкастом. И для того, чтобы этот механизм работал, надо сообщить MediaSession, в какой ресивер отправлять бродкасты.
Добавим в onCreate сервиса

На системах с API Так это выглядит

Android 4.4

MIUI 8 (базируется на Android 6, то есть теоретически окно блокировки не должно отображать наш трек, но здесь уже сказывается кастомизация MIUI).

Уведомления

Однако, как ранее упоминалось, начиная с API 21 окно блокировки научилось отображать уведомления. И по этому радостному поводу, вышеописанный механизм был выпилен. Так что теперь давайте еще формировать уведомления. Это не только требование современных систем, но и просто удобно, поскольку пользователю не придется выключать и включать экран, чтобы просто нажать паузу. Заодно применим это уведомление для перевода сервиса в foreground-режим.

Нам не придется рисовать кастомное уведомление, поскольку Android предоставляет специальный стиль для плееров — Notification.MediaStyle.

Добавим в сервис два метода

И добавим вызов refreshNotificationAndForegroundStatus(int playbackState) во все коллбэки MediaSession.

Android 4.4

Android 7.1.1

Android Wear

Started service

В принципе у нас уже все работает, но есть засада: наша activity запускает сервис через binding. Соответственно, после того, как activity отцепится от сервиса, он будет уничтожен и музыка остановится. Поэтому нам надо в onPlay добавить

Никакой обработки в onStartCommand не надо, наша цель не дать системе убить сервис после onUnbind.

А в onStop добавить

В случае, если к сервису привязаны клиенты, stopSelf ничего не делает, только взводит флаг, что после onUnbind сервис можно уничтожить. Так что это вполне безопасно.

ACTION_AUDIO_BECOMING_NOISY

Продолжаем полировать сервис. Допустим пользователь слушает музыку в наушниках и выдергивает их. Если эту ситуацию специально не обработать, звук переключится на динамик телефона и его услышат все окружающие. Было бы хорошо в этом случае встать на паузу.
Для этого в Android есть специальный бродкаст AudioManager.ACTION_AUDIO_BECOMING_NOISY.
Добавим в onPlay

В onPause и onStop

И по факту события встаем на паузу

Android Auto

Начиная с API 21 появилась возможность интегрировать телефон с экраном в автомобиле. Для этого необходимо поставить приложение Android Auto и подключить телефон к совместимому автомобилю. На экран автомобиля будет выведены крупные контролы для управления навигацией, сообщениями и музыкой. Давайте предложим Android Auto наше приложение в качестве поставщика музыки.

Если у вас под рукой нет совместимого автомобиля, что, согласитесь, иногда бывает, можно просто запустить приложение и экран самого телефона будет работать в качестве автомобильного.

Исходный код выложен на GitHub (ветка MediaBrowserService).

Прежде всего надо указать в манифесте, что наше приложение совместимо с Android Auto.
Добавим в манифест

Здесь automotive_app_desc — это ссылка на файл automotive_app_desc.xml, который надо создать в папке xml

Преобразуем наш сервис в MediaBrowserService. Его задача, помимо всего ранее сделанного, отдавать токен в Android Auto и предоставлять плейлисты.

Поправим декларацию сервиса в манифесте

Во-первых, теперь наш сервис экспортируется, поскольку к нему будут подсоединяться снаружи.

И, во-вторых, добавлен интент-фильтр android.media.browse.MediaBrowserService.

Меняем родительский класс на MediaBrowserServiceCompat.

Поскольку теперь сервис должен отдавать разные IBinder в зависимости от интента, поправим onBind

Имплементируем два абстрактных метода, возвращающие плейлисты

И, наконец, имплементируем новый коллбэк MediaSession

Здесь mediaId — это тот, который мы отдали в setMediaId в onLoadChildren.

Плейлист

Трек

UPDATE от 27.10.2017: Пример на GitHub переведен на targetSdkVersion=26. Из релевантных теме статьи изменений необходимо отметить следующее:

• android.support.v7.app.NotificationCompat.MediaStyle теперь deprecated. Вместо него следует использовать android.support.v4.media.app.NotificationCompat.MediaStyle. Соответственно, больше нет необходимости использовать android.support.v7.app.NotificationCompat, теперь можно использовать android.support.v4.app.NotificationCompat
• Метод AudioManager.requestAudioFocus(OnAudioFocusChangeListener l, int streamType, int durationHint) теперь тоже deprecated. Вместо него надо использовать AudioManager.requestAudioFocus(AudioFocusRequest focusRequest). AudioFocusRequest — новый класс, добавленный с API 26, поэтому не забывайте проверять на API level.
  Создание AudioFocusRequest выглядит следующим образом

Теперь запрашиваем фокус

Разумеется, все вышеописанные изменения вносить необязательно, старые методы работать не перестали.

Вот мы и добрались до конца. В целом тема эта довольно запутанная. Плюс отличия реализаций на разных API level и у разных производителей. Очень надеюсь, что я ничего не упустил. Но если у вас есть, что исправить и добавить, с удовольствием внесу изменения в статью.

Еще очень рекомендую к просмотру доклад Ian Lake. Доклад от 2015 года, но вполне актуален.

Источник