The Android Developer Challenge is back! Submit your idea before December 2.

Visão geral de um aplicativo de mídia

Esta seção explica como separada um aplicativo de reprodução de mídia em um controlador de mídia (para a IU) e uma sessão de mídia (para o player em si). Ela descreve duas arquiteturas de aplicativo de mídia: um design cliente/servidor que funciona bem para aplicativos de áudio e um design de atividade única para players de vídeos. Ela também mostra como fazer com que os aplicativos de mídia respondam a controles de hardware e cooperem com outros aplicativos que usam o stream de saída de áudio.

O player e a IU

Um aplicativo multimídia que reproduz áudio ou vídeo geralmente tem duas partes:

  • Um player que pega mídias digitais e as renderiza como vídeo e/ou áudio
  • Uma IU com controles de transporte para executar o player e, opcionalmente, exibir o estado do player

ui-and-player

No Android, você pode compilar seu próprio player do zero ou escolher entre as seguintes opções:

  • A classe MediaPlayer fornece recursos básicos para um player básico que oferece suporte para os formatos de áudio/vídeo e fontes de dados mais comuns.
  • A ExoPlayer é uma biblioteca de código aberto que apresenta as APIs de áudio de níveis mais baixos do Android. A ExoPlayer oferece suporte a recursos de alto desempenho, como streaming DASH e HLS, que não estão disponíveis na classe MediaPlayer. Você pode personalizar o código da ExoPlayer, facilitando a adição de novos componentes. O ExoPlayer só pode ser usando com o Android versão 4.1 e posteriores.

Sessão de mídia e controlador de mídia

Embora as APIs para a IU e o player possam ser arbitrárias, a natureza da interação entre as duas partes é basicamente a mesma para todos os aplicativos de reprodução de mídia. A estrutura do Android define duas classes, uma sessão de mídia e um controlador de mídia, que impõem uma estrutura bem definida para construir um aplicativo de reprodução de mídia.

A sessão o controlador de mídia se comunicam entre si usando callbacks predefinidos que correspondem a ações de player padrão (reproduzir, pausar, parar etc.) e chamadas personalizadas extensíveis que podem ser usadas para definir comportamentos especiais exclusivos para o seu aplicativo.

controller-and-session

Sessão de mídia

Uma sessão de mídia é responsável por todas as comunicações com o player. Ela oculta a API do player do restante do aplicativo. O player é chamado apenas pela sessão de mídia que o controla.

A sessão mantém uma representação do estado do player (em reprodução/pausado) e informações sobre o que está sendo reproduzido. Uma sessão pode receber callbacks de um ou mais controladores de mídia. Isso permite que seu player seja controlado pela IU do seu aplicativo e por dispositivos complementares que executam o Wear OS e Android Auto.

Controlador de mídia

Um controlador de mídia isola sua IU. Seu código de IU só se comunica com o controlador de mídia, não com o player em si. O controlador de mídia converte ações de controle de transporte em callbacks para a sessão de mídia. Ele também recebe callbacks da sessão de mídia sempre que o estado da sessão muda. Isso proporciona um mecanismo para atualizar a IU associada automaticamente. Um controlador de mídia só pode se conectar a uma sessão de mídia por vez.

Ao usar um controlador de mídia e uma sessão de mídia, você pode implantar diferentes interfaces e/ou players no tempo de execução. Você pode alterar a aparência do seu aplicativo e/ou seu desempenho de forma independente de acordo com os recursos no dispositivo no qual ele está sendo usado.

Aplicativos de vídeo vs. aplicativos de áudio

Ao assistir a um vídeo, seus olhos e ouvidos são utilizados. Quando você reproduz um áudio, você ouve, mas também pode trabalhar com um aplicativo diferente ao mesmo tempo. Há um design diferente para cada caso de uso.

Aplicativo de uso

Um aplicativo de vídeo precisa de uma janela para visualizar conteúdo. Por esse motivo, um aplicativo de vídeo geralmente é implementado como uma só atividade do Android. A tela onde o vídeo é exibido faz parte da atividade.

atividade de player de vídeo

Aplicativo de áudio

Um player de vídeo nem sempre tem uma IU visível. Quando ele começa a reproduzir áudio, o player pode ser executado como uma tarefa de segundo plano. O usuário pode passar para outro aplicativo e trabalhar enquanto escuta o áudio.

Para implementar esse design no Android, você pode compilar um aplicativo de áudio usando dois componentes: uma atividade para a IU e um serviço para o player. Se o usuário passar para outro aplicativo, o serviço poderá ser executado em segundo plano. Ao dividir as duas partes de um aplicativo de áudio em dois componentes, cada uma poderá ser executada com mais eficiência por conta própria. A IU geralmente tem pouca duração em comparação a um player, que pode ser executado por muito tempo sem uma IU.

Atividade de áudio e BrowserService

A biblioteca de suporte fornece suas classes para implementar essa abordagem de cliente/servidor: MediaBrowserService e MediaBrowser. O componente do serviço é implementado como uma subclasse de MediaBrowserService, que contém a sessão de mídia e seu player. A atividade com a IU e o controlador de mídia deve incluir um MediaBrowser, que se comunica com o MediaBrowserService.

O uso do MediaBrowserService permite que dispositivos complementares (como o Android Auto e o Wear) descubram facilmente seu aplicativo, se conectem a ele, procurem conteúdo e controlem a reprodução sem precisar acessar a atividade da IU.

Aplicativos de mídia e a infraestrutura de áudio do Android

Um aplicativo de mídia bem projetado deve “se dar bem” com outros aplicativos que reproduzem áudio. Ele deve estar preparado para compartilhar o telefone e cooperar com outros aplicativos que usem áudio no dispositivo. Ele também deve responder a controles de hardware no dispositivo.

plays-with-others

Todos esses comportamentos são descritos em Controlar saída de áudio.

A biblioteca media-compat

A biblioteca media-compat contém classes que são úteis para compilar aplicativos que reproduzem áudio e vídeo. Essas classes são compatíveis com dispositivos que executam o Android 2.3 (nível de API 9) e versões posteriores. Elas também operam com outros recursos do Android para criar uma experiência confortável e familiar no Android.

A implementação recomendada de sessões de mídia e controladores de mídia são as classes MediaSessionCompat e MediaControllerCompat, que são definidas na biblioteca de suporte media-compat. Elas substituem as versões mais antigas das classes MediaSession e MediaController que foram introduzidas no Android 5.0 (nível de API 21). As classes compat oferecerem as mesmas funcionalidades, mas facilitam o desenvolvimento do seu aplicativo, pois você só precisa gravar para uma API. A biblioteca proporciona a retrocompatibilidade ao converter os métodos da sessão de mídia nos métodos equivalentes de versões mais antigas da plataforma, quando disponíveis.

Se você já tem um aplicativo que utiliza classes mais antigas, recomendamos atualizar para as classes compat. Quando usar as versões compat, você poderá remover todas as chamadas para registerMediaButtonReceiver() e quaisquer métodos de RemoteControlClient.

Medir o desempenho

No Android 8.0 (nível de API 26) e versões posteriores, o método getMetrics() está disponível para algumas classes de mídia. Ele retorna um objeto PersistableBundle contendo informações de configuração e desempenho, expressos como um mapa de atributos e valores. O método getMetrics() é definido para estas classes de mídia:

As métricas são coletadas separadamente para cada instância e persistem durante o ciclo de vida da instância. Se nenhuma métrica estiver disponível, o método retornará nulo. As métricas reais retornadas dependem da classe.