Det er det, jeg bruger på arbejde, hjemme, i sengen, i bruser og overalt derimellem for at holde mig fornuftig og glad. Musik gør mig bedre, og da musik er en så stor del af min Android-oplevelse, har der været en langsom tilbagegang, som jeg har været smerteligt opmærksom på i de sidste par år, og især de sidste par måneder.
Nogle gange tænder jeg for mine Bluetooth-hovedtelefoner, rammer afspilning, og der sker ikke noget. Og intet sker meget mere, end det plejede at gøre.
I mine tidlige Android-dage, med Soarin i lommen (ja, jeg navngav min Samsung Captivate Glide) og mine første par Kinivo Bluetooth-hovedtelefoner omkring halsen, behøvede jeg ikke at have Google Play Musik åben, jeg havde bare brug for at slå spille på mine hovedtelefoner. Faktisk tog jeg en Samsung Galaxy SII ud af en skuffe, startede den op for første gang i måneder, parrede Bluetooth-hovedtelefoner med den og ramte afspilningsknappen. Og musikken spillede.
Ikke så meget på de nuværende enheder i min stald.
HTC 10 skal bare ikke adlyde Bluetooth-kontroller nogle gange, vedvarende anmeldelse til musikappen eller ej. Det ville hellere ramme afspilning på min Moto 360 eller på selve telefonen. HTC A9 er lige så fin. Nexus 5X starter undertiden ikke musik med sikkerhedskopiering med den vedvarende anmeldelse, men kan undertiden gøre det uden en. Samsung S6-kanten vil afspille, men nogle gange i stedet for at afspille musikappen, der sidst er aktiv, vil den standard tilbage til den forudindlæste Music-app.
Der er et ord, der fortsat gentager sig her: undertiden. Det er fordi dette er et problem, der har en masse variabler: hvilken Android-enhed du bruger, hvilken Bluetooth-enhed du bruger, hvilken version af Android og Bluetooth dine enheder har, hvilken musik-app du prøver at spille igennem, hvilket miljø du er i osv. Det er en masse ting at bidrage til et tilsyneladende enkelt problem med knapper, der ikke fungerer hver gang du trykker på dem.
Så hvad sker der faktisk her? Nå, svaret bliver lidt - ok, meget - teknisk.
Når du trykker på knappen, fortolkes den af Android og sendes over systemet gennem KeyEvents. Den næste knap på dit headset fortolkes og leveres som KEYCODE_MEDIA_NEXT gennem et KeyEvent. Der er en lang række værdier, der kan trækkes op til forskellige knapper eller endda for den samme knap. Afspilningsknappen på de fleste headset er også pauseknappen, så tasten kunne returnere KEYCODE_MEDIA_PAUSE, KEYCODE_MEDIA_PLAY eller den meget mere sandsynlige KEYCODE_MEDIA_PLAY_PAUSE afhængigt af enheden og dens aktuelle tilstand. Forresten, hvis du nogensinde har ramt pause, og musikken startede et andet sted, mens det, du så / lytter pausede, er dette KeyEvent skylden, fordi det blev modtaget og handlet af to apps.
Når KeyEvents er blevet fortolket, skal de stadig høres af en musikapp, der lytter til medieknapper gennem en BroadcastReceiver-intention. Når alt kommer til alt kan en app ikke handle på et KeyEvent, hvis den ikke kan se den. Hvis noget forhindrer modtageren i en app i at modtage knaptryk, kan det ødelægge afspilningskontrollerne på flere måder, herunder det periodiske problem, jeg beskrev ovenfor. Hvis en app afregistrerer sin BroadcastReceiver for hurtigt, når den mister lydfokus (metoden, hvorigennem Android bestemmer, hvilke apps der kan afspille lyd på et givet tidspunkt), så når du sætter din musik på pause, kan den miste stop med at lytte og ikke høre knappen trykke fortælle det for at begynde at spille igen. Derfor er det vigtigt for medie-apps at håndtere både Audio Focus og deres BroadcastReceiver korrekt, så selv når en enhed har mistet førstnævnte, mister den ikke sidstnævnte.
Meget af dette kommer ned til, hvor godt din app er programmeret, og hvilke medieknapper, der udsendes af din enhed, når du trykker på en knap på dit headset. Dette betyder også, at selv hvis afspilningskontrollerne er ens, når du køber en enhed, kan de blive brudt af appopdateringer eller systemopdateringer, der ændrer, hvor hurtigt det holder op med at lytte.
I tilfælde af apps som Google Play Musik ser det ud til, at opdateringer, der bryder tingene, bliver mere og mere hyppige. Mens de fleste pauser hurtigt løses, kan det tage måneder at blive løst andre. Intermitterende problemer, såsom din musik, der ikke starter korrekt på Bluetooth, kan være svært at logge og identificere korrekt, hvilket yderligere bremser en mulig løsning.
Hvis musikapps ikke har lydfokus og ikke kører som forgrunds-tjenester (hvis den vedvarende anmeldelse til medieafspilleren ikke er der), er der en chance for at Android-systemet (mere specifikt Doze) eller den såkaldte "ressource -sparende "apps kan dræbe appen for at frigøre hukommelse til andre aktiviteter. Når det sker, kan det at ramme spil muligvis ikke gøre noget, fordi der ikke er nogen modtagere åbne og lytter til kommandoer.
Ligesom der er flere ting, der kan ødelægge dine afspilningskontroller, er der også muligheder for at prøve at løse det.
Den første løsning er en smule ekstrem, men en af de få, som brugerne kunne implementere på deres nuværende telefoner i dag uden rodændringer til softwaren. Ved hjælp af apps som Tasker og AutoInput kan vi registrere knappetryk, undertrykke den originale KeyEvent-handling og derefter udføre en mere specialiseret (og mere konsistent) kommando rettet direkte mod én app. I stedet for at play-knappen er en generisk play media-kommando, der kan samles eller ignoreres af snesevis af medietjenester, kunne vi omforme den som en play / pause for at skifte kommando, der er specifik for Google Play Musik, så andre apps ikke start i stedet.
Dette kan være kedeligt at programmere, og ved at undertrykke den oprindelige handling og udskifte den, bryder vi den indbyggede pauseknap, som vi måske ønsker at bruge i andre apps som YouTube eller Netflix. Kort sagt, det er ikke meget af en løsning for ikke-tekniske brugere eller brugere, der bruger en række medie-apps.
Mange telefoner inkluderer et væld af bevægelses- og knaphandlinger, som du kan slå til eller fra i Indstillinger, som dobbelttryk for at vågne eller dobbelt trykke på Hjem / strøm til kameraet. Mens tilføjelse af Bluetooth-kontroller til denne liste kan forlænge og komplicere den, hvis Android-systemet skulle anerkende og dirigere KeyEvent til en bestemt app snarere end at udsende et generisk signal til, hvad modtagere lytter (eller ikke), kunne vi sikre konsistens. Vi har set dette gjort på enheder før, for eksempel at åbne Moto Assist til at tænde for en udpeget musikapp, når den blev sluttet til din bils Bluetooth.
Ændring af måde, hvorpå Android håndterer medieknapper - og beskæftiger sig med knapindgange samlet, da Bluetooth-controllere og tastaturer løber ind i deres egne problemer - kunne skabe så mange nye problemer, som det løser, men i betragtning af antallet af steder ting kan - og gøre - gå forkert i det nuværende system, kan det være værd at bryde æggene for at lave en ny omelet.
I slutningen af dagen ønsker daglige brugere ikke at grave i nøglekommandoer, modtagere, og hvilken app der har lydfokus lige nu. Vi ønsker, at vores fokus skal være på selve musikken, og hvor den tager os. Og hvis jeg ikke kan tænde for musikken, der holder mig fornuftig på høje, overfyldte steder ved første forsøg, er jeg ikke en glad pige. Og jeg vil vædde på at jeg ikke er den eneste.
Vi tjener muligvis en provision for køb ved hjælp af vores links. Lær mere.
