Toutes les directives pour la gestion des commandes de transport casque et Bluetooth AVRC dans Android 2.2

Question

J'essaie de comprendre quelle est la bonne (nouvelle) approche pour gérer Intent.ACTION_MEDIA_BUTTON dans Froyo. Au cours des 2,2 jours précédents, nous devions enregistrer un BroadcastReceiver (soit de manière permanente, soit au moment de l'exécution) et les événements Media Button arrivaient, tant qu'aucune autre application ne les interceptait et annulait l'émission. Froyo semble supporter encore un peu ce modèle (au moins pour le casque filaire), mais il introduit également les méthodes registerMediaButtonEventReceiver et unregisterMediaButtonEventReceiver qui semblent contrôler le "focus de transport" entre les applications. Pendant mes expériences, l'utilisation de registerMediaButtonEventReceiver fait que les pressions des boutons bluetooth et filaire sont routées vers le récepteur de diffusion de l'application (l'application obtient le "focus de transport"), mais cela ressemble à un changement dans le routage audio (par exemple, en débranchant le casque), le lecteur multimédia par défaut est réinitialisé.

Quelle est la logique derrière la mise en œuvre dans Android 2.2? Quelle est la bonne façon de gérer les commandes de transport? Devons-nous détecter le changement dans le routage audio et essayer de retrouver le focus? Ceci est un problème que tout lecteur multimédia tiers sur la plate-forme Android doit traiter, alors j'espère que quelqu'un (probablement un ingénieur Google) peut fournir des lignes directrices que nous pouvons tous suivre. Une approche standard peut rendre les contrôles des boutons du casque un peu plus prévisibles pour les utilisateurs finaux.

Stefan

Answer 1

Après quelques expériences, j'ai pu obtenir une solution de travail avec le nouveau transport et l'infrastructure de mise au point audio dans Android 2.2. Ce que je finis par faire demande à la fois l'Audio Focus (en utilisant AudioManager.requestAudioFocus) et le Focus Trasport (en utilisant AudioManagter.registerMediaButtonEventReceiver) chaque fois que mon application commence la lecture. RequestAudioFocus prend un rappel qui est appelé lorsque le focus audio est retiré de vous (par exemple le lecteur interne commence une lecture). Dans mon cas, je mets simplement en pause la lecture dans mon application si la mise au point est prise de façon permanente. Le même rappel vous indique également que la mise au point n'est que temporaire (par exemple, le système de navigation parle), ce qui vous permet de "réduire" la lecture. Réduisez le volume ou mettez en pause et reprenez après avoir fini de parler.

Le seul problème restant est que le Lecteur de musique intégré prend l'accent sur le transport chaque fois que vous connectez un casque Bluetooth. Cela a pour effet que la première pression sur le bouton Lecture du casque après la connexion démarre toujours la lecture dans le lecteur de musique par défaut.

Il existe probablement un moyen de détecter la connexion du casque et de "détourner" le focus de transport. Dans mon cas, j'ai décidé de ne pas "combattre" le lecteur par défaut, et d'obtenir le focus de transport lorsque l'utilisateur démarre manuellement la lecture dans mon application.

Si quelqu'un a plus de perspicacité ou connaît une meilleure façon de gérer le focus de transport/audio, s'il vous plaît partagez-le.

Answer 2

Google a publié un article de blog détaillé sur la mise en œuvre du nouveau récepteur d'événement de bouton média 2.2 AudioManager, tout en conservant une rétrocompatibilité avec les anciens appareils.

http://android-developers.blogspot.com/2010/06/allowing-applications-to-play-nicer.html

Answer 3

J'ai aussi ce même problème avec l'enregistrement bouton médias.

périodiquement l'Android retourne l'enregistrement bouton média pour le lecteur de musique par défaut. Je n'ai pas été capable de comprendre pourquoi. Cela peut arriver pendant que l'application joue activement et pendant que la lecture de l'application est en pause.

Après un certain nombre d'utilisateurs se sont plaints que leurs boutons de contrôle pause et la lecture Bluetooth arrêterait périodiquement travail pour contrôler mon application, je le code mis en œuvre qui réenregistre ma demande en appelant registerMediaButtonEventReceiver toutes les 2 secondes. Cela me permet d'obtenir l'enregistrement du bouton et évite la plupart du temps la fenêtre de temps où l'utilisateur appuie sur un bouton multimédia Bluetooth et le lecteur multimédia par défaut finit par répondre.

Mon application maintient la mise au point audio au cours de cette période entière, mais perd encore les événements de bouton Bluetooth périodiquement pendant qu'il a le focus audio. Mon application annule toujours l'enregistrement du récepteur d'événement de bouton multimédia s'il est appelé avec une notification qu'il perd le focus audio, puis s'enregistre à nouveau s'il est appelé ultérieurement lorsqu'une perte de focus audio temporaire renvoie le focus audio. Le travail pour garder la minuterie de 2 secondes en cours d'exécution et de réenregistrement a fonctionné, mais je voudrais me débarrasser de ce minuteur de 2 secondes si quelqu'un a trouvé un travail pour l'enregistrement du bouton média périodiquement revenir à le lecteur multimédia par défaut.