Cette section explique comment séparer une application de lecteur multimédia en un contrôleur multimédia (pour l'interface utilisateur) et en session multimédia (pour le lecteur lui-même). Il décrit deux architectures d'applications multimédias: une conception client/serveur qui fonctionne bien pour les applications audio et une conception à activité unique pour les lecteurs vidéo. Il montre également comment faire en sorte que les applications multimédias répondent aux commandes matérielles et coopèrent avec d'autres applications qui utilisent le flux de sortie audio.
Lecteur et UI
Une application multimédia qui lit du contenu audio ou vidéo se compose généralement de deux parties:
- Lecteur qui intègre des contenus multimédias numériques et les affiche sous forme vidéo et/ou audio
- Interface utilisateur avec des commandes de transport permettant d'exécuter le lecteur et d'afficher éventuellement son état
Dans Android, vous pouvez créer votre propre lecteur à partir de zéro ou choisir l'une des options suivantes:
- La classe MediaPlayer fournit les fonctionnalités de base d'un lecteur simple compatible avec les sources de données et formats audio/vidéo les plus courants.
- ExoPlayer est une bibliothèque Open Source basée sur des composants du framework multimédia de niveau inférieur tels que
MediaCodecetAudioTrack. ExoPlayer est compatible avec des fonctionnalités hautes performances telles que DASH, qui ne sont pas disponibles dansMediaPlayer. Vous pouvez personnaliser le code ExoPlayer, ce qui facilite l'ajout de nouveaux composants. ExoPlayer ne peut être utilisé qu'avec Android 4.1 ou version ultérieure.
Session multimédia et contrôleur multimédia
Bien que les API de l'interface utilisateur et du lecteur puissent être arbitraires, la nature de l'interaction entre les deux éléments est fondamentalement la même pour toutes les applications de lecteur multimédia. Le framework Android définit deux classes, une session multimédia et un contrôleur multimédia,qui imposent une structure bien définie pour la création d'une application de lecteur multimédia.
La session multimédia et le contrôleur multimédia communiquent entre eux à l'aide de rappels prédéfinis correspondant aux actions standards du lecteur (lecture, pause, arrêt, etc.), ainsi que d'appels personnalisés extensibles que vous utilisez pour définir des comportements spéciaux propres à votre application.
Session multimédia
La session multimédia est responsable de toutes les communications avec le lecteur. Elle masque l'API du lecteur pour le reste de votre application. Le lecteur n'est appelé qu'à partir de la session multimédia qui le contrôle.
La session conserve une représentation de l'état du lecteur (lecture/pause) et des informations sur ce qui est en cours de lecture. Une session peut recevoir des rappels d'un ou de plusieurs contrôleurs multimédias. Votre lecteur peut ainsi être contrôlé par l'interface utilisateur de votre application, ainsi que par les appareils associés exécutant Wear OS et Android Auto. La logique qui répond aux rappels doit être cohérente. La réponse à un rappel MediaSession doit être la même, quelle que soit l'application cliente qui a initié le rappel.
Contrôleur multimédia
Un contrôleur multimédia isole votre interface utilisateur. Votre code d'interface utilisateur ne communique qu'avec le contrôleur multimédia, pas avec le lecteur lui-même. Le contrôleur multimédia traduit les actions de commande de transport en rappels à la session multimédia. Il reçoit également des rappels de la session multimédia chaque fois que l'état de la session change. Cela fournit un mécanisme permettant de mettre à jour automatiquement l'interface utilisateur associée. Un contrôleur multimédia ne peut se connecter qu'à une seule session multimédia à la fois.
Lorsque vous utilisez un contrôleur multimédia et une session multimédia, vous pouvez déployer différentes interfaces et/ou lecteurs au moment de l'exécution. Vous pouvez modifier l'apparence et/ou les performances de votre application indépendamment en fonction des fonctionnalités de l'appareil sur lequel elle s'exécute.
Différences entre les applications vidéo et les applications audio
Lorsque vous regardez une vidéo, vous sollicitez vos yeux et vos oreilles. Lorsque vous lisez du contenu audio, vous écoutez bien, mais vous pouvez également travailler avec une autre application en même temps. Chaque cas d'utilisation est associé à une conception différente.
Application vidéo
Une application vidéo a besoin d'une fenêtre pour afficher le contenu. Pour cette raison, une application vidéo est généralement implémentée en tant qu'activité Android unique. L'écran sur lequel la vidéo apparaît fait partie de l'activité.
Application audio
Il n'est pas toujours nécessaire que l'interface utilisateur d'un lecteur audio soit visible. Une fois qu'il commence à lire du contenu audio, le lecteur peut s'exécuter en tant que tâche en arrière-plan. L'utilisateur peut basculer vers une autre application et travailler tout en continuant à écouter.
Pour implémenter cette conception dans Android, vous pouvez créer une application audio à l'aide de deux composants: une activité pour l'interface utilisateur et un service pour le lecteur. Si l'utilisateur passe à une autre application, le service peut s'exécuter en arrière-plan. En divisant les deux parties d'une application audio en composants distincts, chacune peut s'exécuter plus efficacement seule. Une UI est généralement de courte durée par rapport à un lecteur, qui peut fonctionner longtemps sans UI.
La bibliothèque Support fournit deux classes pour mettre en œuvre cette approche client/serveur: MediaBrowserService et MediaBrowser. Le composant de service est implémenté en tant que sous-classe de MediaBrowserService contenant la session multimédia et son lecteur. L'activité avec l'interface utilisateur et le contrôleur multimédia doit inclure un élément MediaBrowser, qui communique avec MediaBrowserService.
L'utilisation de MediaBrowserService permet aux appareils associés (tels qu'Android Auto et Wear) de découvrir votre application, de s'y connecter, de parcourir des contenus et de contrôler la lecture, sans avoir à accéder à l'activité de l'interface utilisateur de votre application. En fait, plusieurs applications peuvent être connectées au même MediaBrowserService en même temps, chacune ayant son propre MediaController. Une application qui propose un MediaBrowserService doit pouvoir gérer plusieurs connexions simultanées.
Applications multimédias et infrastructure audio Android
Une application multimédia bien conçue doit pouvoir fonctionner en synergie avec d'autres applications qui lisent du contenu audio. Il doit être prêt à partager le téléphone et à coopérer avec d'autres applications de votre appareil qui utilisent l'audio. Il doit également répondre aux commandes matérielles de l'appareil.
Tout ce comportement est décrit dans la section Contrôler la sortie audio.
Bibliothèque media-compat
La bibliothèque media-compat contient des classes utiles pour créer des applications qui lisent des contenus audio et vidéo. Ces classes sont compatibles avec les appareils équipés d'Android 2.3 (niveau d'API 9) ou version ultérieure. Ils fonctionnent également avec d'autres fonctionnalités Android pour créer une expérience Android confortable et familière.
L'implémentation recommandée des sessions multimédias et des contrôleurs multimédias est les classes MediaSessionCompat et MediaControllerCompat, qui sont définies dans la bibliothèque Support Media-compat. Elles remplacent les versions précédentes des classes MediaSession et MediaController introduites dans Android 5.0 (niveau d'API 21). Les classes de compatibilité offrent les mêmes fonctionnalités, mais facilitent le développement de votre application, car vous n'avez besoin d'écrire que dans une seule API. La bibliothèque se charge de la rétrocompatibilité en traduisant les méthodes de session multimédia par des méthodes équivalentes sur les anciennes versions de la plate-forme, le cas échéant.
Si vous disposez déjà d'une application fonctionnelle utilisant les anciennes classes, nous vous recommandons de passer aux classes compat. Lorsque vous utilisez les versions de compatibilité, vous pouvez supprimer tous les appels à registerMediaButtonReceiver() et toutes les méthodes de RemoteControlClient.
Évaluation des performances
Sous Android 8.0 (niveau d'API 26) et versions ultérieures, la méthode getMetrics() est disponible pour certaines classes multimédias. Elle renvoie un objet PersistableBundle contenant des informations de configuration et de performances, exprimées sous la forme d'une carte d'attributs et de valeurs.
La méthode getMetrics() est définie pour ces classes de contenus multimédias:
MediaPlayer.getMetrics()MediaRecorder.getMetrics()MediaCodec.getMetrics()MediaExtractor.getMetrics()
Les métriques sont collectées séparément pour chaque instance et sont conservées pendant toute la durée de vie de l'instance. Si aucune métrique n'est disponible, la méthode renvoie la valeur "null". Les métriques renvoyées dépendent de la classe.