Android Headset Klipsch S4A2

Android Headset-Steuerung – ein Buch mit sieben Siegeln?

Eigentlich hat ein gewöhnliches Android Headset nur eine Taste. Natürlich gibt es proprietäre Kopfhörer, die von den Hardwareherstellern mitgeliefert werden, mit mehreren Tasten wie laut/leiser und SmartButton(TM). Was diese Taste machen soll? So viel wie möglich! Anrufe annehmen, auflegen, Musik anhalten und Abspielen, langer Tastendruck, um die Google Sprachsuche zu starten, doppelter Tastendruck um einen Titel weiter zu springen und so weiter und so fort. Und eigentllich funktioniert das alles auch. Warum also dieser Beitrag?

Weil es nur eigentlich funktioniert! Und ich bekomme langsam das Gefühl, dass nur mir das auffällt. Weil ich aus dem iOS-Lager komme? Vermutlich. Egal in welcher Situation man unter iOS eine Taste auf dem Headset drückt, tut sie das, was sie soll. Unter Android nicht. Eine Beispielsituation: Man nehme einen Audioplayer, der nicht als Standard-Audioplayer im Gerät definiert ist. Spotify, PocketCasts, was auch immer. Also kein Google Play Music oder der Audioplayer des Geräts (wie die Walkman App bei den Xperias oder Musik bei Samsung-Geräten). Headset anschließen, Audio starten aus einer der Apps, genießen. Dann irgendwann per Headset-Remote pausieren, also Knopf drücken. Smartphone dabei in der Tasche lassen! Kein Bildschirm-Aufwecken, nichts. Gerät unangetastet lassen. Für mindestens 30 Sekunden. Dann wieder auf Headset-Knopf drücken. Und? Nichts passiert. Gar nichts. Probiert man weiter, passiert kurioses:

 

Die Fälle

Fall (a): Drückt man ungehalten direkt danach ein zweites Mal, wird ein Schnipsel abgespielt. Ganz kurz. Drückt man kurz danach noch einmal, wird Audio normal wieder abgespielt. Endlich. Fall (b): Wartet man hingegen, bevor man ein zweites Mal drückt, passiert zumeist wieder nichts. Manchmal, nicht reproduzierbar, startet die Musik aber auch wieder.

Das Internet bietet nicht sonderlich viel zu dieser Problematik, eigentlich gar nichts. Lediglich ein Bugreport zur App DoggCatcher enthält Hinweise darauf, dass jemand anders darauf gestoßen ist, es aber nicht richtig zuordnen konnte. Auch die Android Developer Dokumentation enthält nicht wirklich Hinweise darauf, wie ein Tastendruck vom Headset ins Betriebssystem transportiert und darin interpretiert wird (nur, dass man ihn verwenden kann). Wenn irgend jemand da draußen mehr dazu gefunden hat, oder mir sogar erklären kann, wie ein Tastendruck in Android genau abläuft, will ich gerne aufgeklärt werden! Bis dahin versuche ich mich an einer eigenen Analyse, die ich anhand mehrerer Android-Geräte durchgeführt hatte: Dem Samsung Galaxy S3, Nexus 4, HTC One, Xperia Z, Samsung Galaxy S4, Xperia Z1, Nexus 5, LG G2, Xperia Z1 Compact und Galaxy Note 3. Verschiedenste Hersteller sind also vertreten.

 

Die Analyse

Audio dekodieren und abspielen erfordert nicht viele Ressourcen. Wird das Display abgeschaltet, werden vermutlich möglichst viele Akkufresser deaktiviert und die CPU stark heruntergetaktet. und würde in Deep Sleep (Ein akkuschonender Schlafmodus) wechseln, wenn die Audio-App sie nicht im Wakelock halten würde (sie meldet der CPU sozusagen regelmäßig „Ich bin hier und brauche mal kurz deine Hilfe“). Anscheinend hat die App allerdings keinen Einfluss darauf, welcher Input insgesamt noch aktiv bleiben muss, das steuert Android selbst, besser gesagt dessen Kernel. Und das ist prinzipiell auch gut so. Allerdings liegt auch genau hier der Fehler: Während das Audiosignal astrein durch den Kopfhöreranschluss ausgeliefert wird, wird der Tastendruck hingegen nicht sauber interpretiert., wenn zuvor längere Zeit kein Audio abgespielt wurde. Einmal Drücken auf dem Headset weckt die CPU und macht sie wieder „befehlsbereit“, aber es wird kein weiteres Event ausgelöst. Stattdessen „parkt“ dieser „Pause/Unpause“-Befehl in einer Warteschlange.

Der zweite „Pause/Unpause“-Befehl, in Fall (a) gesendet, wird zwar erkannt, allerdings – und da liegt der Haken – wird er in die selbe Warteschlange eingereiht. Eine Fehlinterpretation ist die Folge: Der erste Tastendruck, der eigentlich nur die CPU für künftig eingehende Befehle aufgeweckt hatte, wird nun als „Pause/Unpause“ abgearbeitet, danach der zweite, ebenfalls „Pause/Unpause“. Resultat: Die Audio-Wiedergabe wird abgespielt und sofort wieder angehalten.

In Fall (b) ist vermutlich schlicht zu viel Zeit vergangen, nachdem der erste Tastendruck die CPU aufweckte. „Vermutlich“ deswegen, weil erneutes Drücken nach wenigen Sekunden wieder nichts passiert. Wiederholt man diese Prozedur mehrere Male, wird es sogar zum Geduldsspiel, überhaupt wieder Audio-Wiedergabe in den Kopfhörern zu haben.

 

Bluetooth ist zuverlässig

Anders sieht die Sache bei der Audio-Steuerung per Bluetooth aus: Keinerlei Probleme, sofern die Steuerung sauber programmiert wurde. Verwenden Bluetooth und Headset-Remote die gleiche Schnittstelle zur Audio-Kontrolle, liegt der Unterschied hier vermutlich darin, dass Bluetooth-Verbindungen nicht im Baseband aufrecht gehalten werden, und die CPU daher dadurch wach genug gehalten wird, um Befehle zu empfangen und umgehend abzuarbeiten. Außerdem enthält eine Bluetooth-Verbindung zusammen mit dem AVRCP einen konstanten Rückkanal, der Befehle zur Audiowiedergabe senden kann.

 

Bleibt nur eins

Einzig relevanter Fall für eine tiefere Fehlersuche bleibt also Fall (a). Wird der erste Tastendruck richtig erkannt und komplett interpretiert, ist die Sache gegessen, und Android-Headsets funktionieren tadellos. Nur noch darauf aufsetzende Software kann das dann noch vermiesen.

Es sei hier noch erwähnt, dass ich kein Android-Entwickler bin und dieser Bericht nur auf meinen Erfahrungen basiert. Wenn also meine Theorie zu der „Warteschlange“ und dem sukzessiven Abarbeiten dieser völliger Mumpitz sein sollte, lasse ich mich gerne belehren und aufklären!

Update:

Einem Tweet folgend habe ich eine App heruntergeladen, die die Steuerung über das Headset übernimmt (in diesem Fall die von Klipsch, weil meine aktuellen Kopfhörer von Klipsch sind). Danach direkt wieder deinstalliert, wie in dem Tweet vorgeschlagen. Und siehe da: Die Steuerung funktioniert nun! Auch wenn nach dem einmaligen Play drücken bis zu 30 Sekunden vergehen können, bis Audio wieder abgespielt wird, aber es funktioniert. Kurios, kurios! Danke für die Tipps!

0 Kommentare

Dein Kommentar

Want to join the discussion?
Feel free to contribute!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.