Esta página foi traduzida pela API Cloud Translation.

Guia de migração do AndroidX Media3

Os apps que estão usando a biblioteca com.google.android.exoplayer2 independente e o androidx.media precisam migrar para o androidx.media3. Use o script de migração para migrar arquivos de build do Gradle, arquivos de origem Java e Kotlin e arquivos de layout XML do ExoPlayer 2.19.1 para o AndroidX Media3 1.1.1.

Visão geral

Antes de migrar, consulte as seções a seguir para saber mais sobre os benefícios das novas APIs, as APIs a serem migradas e os pré-requisitos que o projeto do app precisa atender.

Por que migrar para o Jetpack Media3

É o novo lar do ExoPlayer, enquanto o com.google.android.exoplayer2 foi descontinuado.
Acesse a API Player em todos os componentes/processos com MediaBrowser/MediaController.
Use os recursos estendidos das APIs MediaSession e MediaController.
Anuncie os recursos de reprodução com o controle de acesso detalhado.
Simplifique o app removendo MediaSessionConnector e PlayerNotificationManager.
Compatível com versões anteriores com APIs de compatibilidade de mídia (MediaBrowserCompat/MediaControllerCompat/MediaMetadataCompat)

APIs de mídia para migrar para o AndroidX Media3

ExoPlayer e suas extensões
Isso inclui todos os módulos do projeto legado do ExoPlayer, exceto o módulo mediasession, que foi descontinuado. Apps ou módulos que dependem de pacotes em com.google.android.exoplayer2 podem ser migrados com o script de migração.
MediaSessionConnector (dependendo dos pacotes androidx.media.* de androidx.media:media:1.4.3+)
Remova o MediaSessionConnector e use o androidx.media3.session.MediaSession.
MediaBrowserServiceCompat (dependendo dos pacotes androidx.media.* do androidx.media:media:1.4.3+)
Migrar subclasses de androidx.media.MediaBrowserServiceCompat para androidx.media3.session.MediaLibraryService e código usando MediaBrowserCompat.MediaItem para androidx.media3.common.MediaItem.
MediaBrowserCompat (dependendo dos pacotes android.support.v4.media.* do androidx.media:media:1.4.3+)
Migrar o código do cliente usando o MediaBrowserCompat ou MediaControllerCompat para usar o androidx.media3.session.MediaBrowser com androidx.media3.common.MediaItem.

Pré-requisitos

Verificar se o projeto está sob controle de origem

Verifique se é possível reverter com facilidade as alterações aplicadas pelas ferramentas de migração com script. Se o projeto ainda não está sob controle de origem, agora é um bom momento para começar. Se, por algum motivo, você não quiser fazer isso, faça um backup do projeto antes de iniciar a migração.
Atualizar o app
- Recomendamos atualizar o projeto para usar a versão mais recente da biblioteca ExoPlayer e remover todas as chamadas para métodos descontinuados. Se você pretende usar o script para a migração, é necessário corresponder a versão para a qual você está atualizando com a versão processada pelo script.
- Aumente a compileSdkVersion do app para pelo menos 32.
- Faça upgrade do Gradle e do Plug-in do Android para Gradle do Android Studio para uma versão recente que funcione com as dependências atualizadas acima. Por exemplo:
  - Versão do Plug-in do Android para Gradle: 7.1.0
  - Versão do Gradle: 7.4
- Substitua todas as instruções de importação de caractere curinga que estejam usando um asterisco (*) e use instruções de importação totalmente qualificadas: exclua as instruções de importação de caractere curinga e use o Android Studio para importar as instruções totalmente qualificadas (F2 - Alt/Enter, F2 - Alt/Enter, ...).
- Migrar de com.google.android.exoplayer2.PlayerView para com.google.android.exoplayer2.StyledPlayerView. Isso é necessário porque não há um equivalente a com.google.android.exoplayer2.PlayerView no AndroidX Media3.

Migrar o ExoPlayer com suporte a script

O script facilita a mudança de com.google.android.exoplayer2 para a nova estrutura de pacote e módulo em androidx.media3. O script aplica algumas verificações de validação no projeto e mostra avisos se a validação falhar. Caso contrário, ele aplica os mapeamentos de classes e pacotes renomeados nos recursos de um projeto do Gradle para Android escrito em Java ou Kotlin.

usage: ./media3-migration.sh [-p|-c|-d|-v]|[-m|-l [-x <path>] [-f] PROJECT_ROOT]
 PROJECT_ROOT: path to your project root (location of 'gradlew')
 -p: list package mappings and then exit
 -c: list class mappings (precedence over package mappings) and then exit
 -d: list dependency mappings and then exit
 -l: list files that will be considered for rewrite and then exit
 -x: exclude the path from the list of file to be changed: 'app/src/test'
 -m: migrate packages, classes and dependencies to AndroidX Media3
 -f: force the action even when validation fails
 -v: print the exoplayer2/media3 version strings of this script
 -h, --help: show this help text

Como usar o script de migração

Faça o download do script de migração da tag do projeto do ExoPlayer no GitHub correspondente à versão para a qual você atualizou o app:
```
curl -o media3-migration.sh \
  "https://raw.githubusercontent.com/google/ExoPlayer/r2.19.1/media3-migration.sh"
```
Torne o script executável:
```
chmod 744 media3-migration.sh
```
Execute o script com --help para saber mais sobre as opções.
Execute o script com -l para listar o conjunto de arquivos selecionados para migração. Use -f para forçar a listagem sem avisos:
```
./media3-migration.sh -l -f /path/to/gradle/project/root
```
Execute o script com -m para mapear pacotes, classes e módulos para a Media3. A execução do script com a opção -m vai aplicar as mudanças aos arquivos selecionados.
- Parar no erro de validação sem fazer mudanças
```
./media3-migration.sh -m /path/to/gradle/project/root
```
- Execução forçada
Se o script encontrar uma violação dos pré-requisitos, a migração poderá ser forçada com a sinalização -f:
```
./media3-migration.sh -m -f /path/to/gradle/project/root
```

 # list files selected for migration when excluding paths
 ./media3-migration.sh -l -x "app/src/test/" -x "service/" /path/to/project/root
 # migrate the selected files
 ./media3-migration.sh -m -x "app/src/test/" -x "service/" /path/to/project/root

Siga estas etapas manuais depois de executar o script com a opção -m:

Confira como o script mudou seu código: use uma ferramenta de comparação e corrija possíveis problemas. Considere registrar um bug se você achar que o script tem um problema geral que foi introduzido sem transmitir a opção -f.
Crie o projeto: use ./gradlew clean build ou, no Android Studio, escolha File > Sync Project with Gradle Files, Build > Clean project e depois Build > Rebuild project. Monitore o build na guia "Build - Build Output" do Android Studio.

Etapas de acompanhamento recomendadas:

Resolva a ativação de erros relacionados ao uso de APIs instáveis.
Substituir chamadas de API descontinuadas: use a API de substituição sugerida. Mantenha o ponteiro do mouse sobre o aviso no Android Studio e consulte o JavaDoc do símbolo descontinuado para descobrir o que usar em vez de uma determinada chamada.
Classificar as instruções de importação: abra o projeto no Android Studio e clique com o botão direito do mouse em um nó da pasta de pacotes no visualizador do projeto e escolha Otimizar importações nos pacotes que contêm os arquivos de origem modificados.

Substitua `MediaSessionConnector` por `androidx.media3.session.MediaSession`.

No mundo MediaSessionCompat legado, o MediaSessionConnector era responsável por sincronizar o estado do player com o estado da sessão e receber comandos de controladores que precisavam de delegação para métodos adequados do player. Com o AndroidX Media3, isso é feito pelo MediaSession diretamente, sem precisar de um conector.

Remover todas as referências e o uso do MediaSessionConnector:se você usou o script automatizado para migrar classes e pacotes do ExoPlayer, ele provavelmente deixou seu código em um estado não combinável em relação aoMediaSessionConnector que não pode ser resolvido. O Android Studio vai mostrar o código corrompido quando você tentar criar ou iniciar o app.
No arquivo build.gradle em que você mantém suas dependências, adicione uma dependência de implementação ao módulo de sessão do AndroidX Media3 e remova a dependência legada:
```
implementation "androidx.media3:media3-session:1.4.1"
```
Substitua MediaSessionCompat por androidx.media3.session.MediaSession.
No site do código em que você criou o MediaSessionCompat legado, use androidx.media3.session.MediaSession.Builder para criar um MediaSession. Transmitir o player para criar o builder de sessão.

Observação: caso seu app esteja usando um player diferente de ExoPlayer, você precisa de uma implementação Player personalizada que possa ser transmitida para o MediaSession que está envolvendo o player. Vamos oferecer mais orientações sobre uma implementação mínima de Player que funcione com a implementação da sessão de mídia.
```
val player = ExoPlayer.Builder(context).build()
mediaSession = MediaSession.Builder(context, player)
    .setSessionCallback(MySessionCallback())
    .build()
```
Observação: é possível interceptar qualquer chamada de método para o Player envolvendo-o em um ForwardingPlayer(player).
Implemente MySessionCallback conforme necessário para o app. Isso é opcional. Se você quiser permitir que os controles adicionem itens de mídia ao player, implemente MediaSession.Callback.onAddMediaItems(). Ele serve vários métodos de API atuais e legados que adicionam itens de mídia ao player para reprodução de uma forma compatível com versões anteriores. Isso inclui os métodos MediaController.set/addMediaItems() do controlador Media3, bem como os métodos TransportControls.prepareFrom*/playFrom* da API legada. Um exemplo de implementação de onAddMediaItems pode ser encontrado no PlaybackService do app de demonstração da sessão.
Libere a sessão de mídia no site do código em que você destruiu a sessão antes da migração:
```
mediaSession?.run {
  player.release()
  release()
  mediaSession = null
}
```
Observação: é importante liberar a sessão de mídia antes de criar uma nova com o mesmo ID. O Media3 gera uma exceção se um app estiver vazando uma instância de sessão.

Funcionalidade `MediaSessionConnector` no Media3

A tabela abaixo mostra as APIs Media3 que processam a funcionalidade implementada anteriormente em MediaSessionConnector.

MediaSessionConnector	AndroidX Media3
`CustomActionProvider`	`MediaSession.Callback.onCustomCommand()/ MediaSession.setCustomLayout()`
`PlaybackPreparer`	`MediaSession.Callback.onAddMediaItems()` (`prepare()` é chamado internamente)
`QueueNavigator`	`ForwardingPlayer`
`QueueEditor`	`MediaSession.Callback.onAddMediaItems()`
`RatingCallback`	`MediaSession.Callback.onSetRating()`
`PlayerNotificationManager`	`DefaultMediaNotificationProvider/ MediaNotification.Provider`

Migre `MediaBrowserService` para `MediaLibraryService`

O AndroidX Media3 introduz MediaLibraryService, que substitui o MediaBrowserServiceCompat. O JavaDoc de MediaLibraryService e a superclasse MediaSessionService oferecem uma boa introdução à API e ao modelo de programação assíncrona do serviço.

O MediaLibraryService é compatível com o MediaBrowserService. Um app cliente que usa MediaBrowserCompat ou MediaControllerCompat continua funcionando sem mudanças de código ao se conectar a um MediaLibraryService. Para um cliente, é transparente se o app está usando um MediaLibraryService ou um MediaBrowserServiceCompat legado.

Diagrama de componentes do app com apps externos, de serviço e de atividade. — **Figura 1**: visão geral do componente do app de mídia

Para que a compatibilidade com versões anteriores funcione, é necessário registrar as duas interfaces de serviço com seu serviço no AndroidManifest.xml. Dessa forma, um cliente encontra seu serviço pela interface de serviço necessária:

<service android:name=".MusicService" android:exported="true">
    <intent-filter>
        <action android:name="androidx.media3.session.MediaLibraryService"/>
        <action android:name="android.media.browse.MediaBrowserService" />
    </intent-filter>
</service>

No arquivo build.gradle em que você mantém suas dependências, adicione uma dependência de implementação ao módulo de sessão do AndroidX Media3 e remova a dependência legada:
```
implementation "androidx.media3:media3-session:1.4.1"
```
Mudar o serviço para herdar de um MediaLibraryService em vez de MediaBrowserService Como dito anteriormente, o MediaLibraryService é compatível com o MediaBrowserService legado. Portanto, a API mais ampla que o serviço oferece aos clientes continua a mesma. Portanto, é provável que um app possa manter a maior parte da lógica necessária para implementar o MediaBrowserService e adaptá-lo ao novo MediaLibraryService.

As principais diferenças em relação ao MediaBrowserServiceCompat legado são as seguintes:
- Implementar os métodos de ciclo de vida do serviço:os métodos que precisam ser substituídos no próprio serviço são onCreate/onDestroy, em que um app aloca/libera a sessão da biblioteca, o player e outros recursos. Além dos métodos padrão do ciclo de vida do serviço, um app precisa substituir onGetSession(MediaSession.ControllerInfo) para retornar o MediaLibrarySession criado em onCreate.
- Implementar MediaLibraryService.MediaLibrarySessionCallback:criar uma sessão requer um MediaLibraryService.MediaLibrarySessionCallback que implemente os métodos de API do domínio real. Em vez de substituir os métodos da API do serviço legado, você vai substituir os métodos do MediaLibrarySession.Callback.
  
  O callback é usado para criar o MediaLibrarySession:
```
mediaLibrarySession =
      MediaLibrarySession.Builder(this, player, MySessionCallback())
         .build()
```
  Encontre a API completa do MediaLibrarySessionCallback na documentação da API.
- Implementar MediaSession.Callback.onAddMediaItems(): o callback onAddMediaItems(MediaSession, ControllerInfo, List<MediaItem>) serve vários métodos de API atuais e legados que adicionam itens de mídia ao player para reprodução de forma compatível com versões anteriores. Isso inclui os métodos MediaController.set/addMediaItems() do controle Media3, bem como os métodos TransportControls.prepareFrom*/playFrom* da API legada. Um exemplo de implementação do callback pode ser encontrado no PlaybackService do app de demonstração da sessão.
- O AndroidX Media3 usa androidx.media3.common.MediaItem em vez de MediaBrowserCompat.MediaItem e MediaMetadataCompat. Partes do código vinculadas às classes legados precisam ser alteradas de acordo ou mapeadas para o MediaItem do Media3.
- O modelo de programação assíncrona geral mudou para Futures, em contraste com a abordagem Result destacável do MediaBrowserServiceCompat. A implementação do serviço pode retornar um ListenableFuture assíncrono em vez de desacoplar um resultado ou retornar um Future imediato para retornar diretamente um valor.

Remoção do PlayerNotificationManager

O MediaLibraryService oferece suporte a notificações de mídia automaticamente, e o PlayerNotificationManager pode ser removido ao usar um MediaLibraryService ou MediaSessionService.

Um app pode personalizar a notificação definindo uma MediaNotification.Provider personalizada em onCreate() que substitui a DefaultMediaNotificationProvider. O MediaLibraryService cuida da inicialização do serviço em primeiro plano conforme necessário.

Ao substituir MediaLibraryService.updateNotification(), um app pode assumir a propriedade total de postar uma notificação e iniciar/parar o serviço em primeiro plano conforme necessário.

Migrar o código do cliente usando um MediaBrowser

Com o AndroidX Media3, um MediaBrowser implementa as interfaces MediaController/Player e pode ser usado para controlar a reprodução de mídia, além de navegar pela biblioteca de mídia. Se você tiver que criar um MediaBrowserCompat e um MediaControllerCompat no mundo legado, faça o mesmo usando MediaBrowser no Media3.

Um MediaBrowser pode ser criado e aguardar a conexão com o serviço ser estabelecida:

scope.launch {
    val sessionToken =
        SessionToken(context, ComponentName(context, MusicService::class.java)
    browser =
        MediaBrowser.Builder(context, sessionToken))
            .setListener(BrowserListener())
            .buildAsync()
            .await()
    // Get the library root to start browsing the library.
    root = browser.getLibraryRoot(/* params= */ null).await();
    // Add a MediaController.Listener to listen to player state events.
    browser.addListener(playerListener)
    playerView.setPlayer(browser)
}

Confira Controlar a reprodução na sessão de mídia para saber como criar um MediaController para controlar a reprodução em segundo plano.

Outras etapas e limpeza

Erros de API instáveis

Depois de migrar para o Media3, você pode encontrar erros de lint sobre usos de API instáveis. Essas APIs são seguras para uso, e os erros de lint são um subproduto das nossas novas garantias de compatibilidade binária. Se você não precisar de compatibilidade binária rígida, esses erros poderão ser suprimidos com segurança com uma anotação @OptIn.

Contexto

Nenhuma das versões do ExoPlayer v1 ou v2 fornecia garantias rigorosas sobre a compatibilidade binária da biblioteca entre as versões subsequentes. A API ExoPlayer é muito grande por design, para permitir que os apps personalizem quase todos os aspectos da reprodução. As versões posteriores do ExoPlayer ocasionalmente introduziam renomeações de símbolos ou outras mudanças importantes (por exemplo, novos métodos obrigatórios em interfaces). Na maioria dos casos, essas falhas foram mitigadas com a introdução do novo símbolo e a descontinuação do símbolo antigo em algumas versões, para que os desenvolvedores tivessem tempo para migrar o uso, mas nem sempre isso foi possível.

Essas mudanças radicais resultaram em dois problemas para os usuários das bibliotecas ExoPlayer v1 e v2:

Um upgrade para a versão do ExoPlayer pode fazer com que o código pare de ser compilado.
Um app que dependia do ExoPlayer diretamente e por uma biblioteca intermediária precisava garantir que ambas as dependências tivessem a mesma versão. Caso contrário, incompatibilidades binárias poderiam resultar em falhas de execução.

Melhorias na Media3

A Media3 garante a compatibilidade binária para um subconjunto da plataforma da API. As partes que não garantem a compatibilidade binária são marcadas com @UnstableApi. Para deixar essa distinção clara, o uso de símbolos de API instáveis gera um erro de lint, a menos que sejam anotados com @OptIn.

Depois de migrar do ExoPlayer v2 para o Media3, você pode encontrar muitos erros de lint de API instáveis. Isso pode fazer com que a Media3 pareça "menos estável" que o ExoPlayer v2. Esse não é o caso. As partes "instáveis" da API Media3 têm o mesmo nível de estabilidade que toda a superfície da API ExoPlayer v2, e as garantias da superfície estável da API Media3 não estão disponíveis no ExoPlayer v2. A diferença é que um erro do lint agora alerta sobre os diferentes níveis de estabilidade.

Processar erros de lint de API instáveis

Consulte a seção de solução de problemas sobre esses erros de lint para saber como anotar usos de APIs instáveis em Java e Kotlin com @OptIn.

APIs descontinuadas

As chamadas para APIs descontinuadas são riscadas no Android Studio. Recomendamos que você substitua essas chamadas pela alternativa adequada. Passe o cursor sobre o símbolo para ver o JavaDoc que informa qual API usar.

Captura de tela: como mostrar a JavaDoc com a alternativa do método descontinuado — **Figura 3**: a dica de ferramenta do JavaDoc no Android Studio sugere uma alternativa para qualquer símbolo descontinuado.

Exemplos de código e apps de demonstração

App de demonstração de sessão do AndroidX Media3 (dispositivos móveis e WearOS)
- Ações personalizadas
- Notificação da interface do sistema, MediaButton/BT
- Controle de mídia do Google Assistente
UAMP: Android Media Player (branch media3) (dispositivos móveis, AutomotiveOS)
- Notificação da interface do sistema, MediaButton/BT, retomada da reprodução
- Controle de reprodução do Google Assistente/Wear OS
- AutomotiveOS: comando personalizado e login