Den genomsnittlige Android-användaren har förmodligen för länge sedan slutat bry sig om Androids "fragmenteringsproblem". Men problemet förföljer fortfarande utvecklare.
Fragmentering har varit ett kontroversiellt problem i Android bokstavligen sedan det mobila operativsystemet tillkännagavs.
Förutom att vara en gos för troll att använda i online-flame-war, ses den mångfald som kommer med fragmentering nu till stor del som en nettopositivt för konsumenterna av Android-enheter. När allt kommer omkring får vi så stor frihet att välja den typ av enhet med den typ av programvara vi vill ha att det är svårt för den genomsnittliga konsumenten att bry sig om fragmentering. Att visualisera den otroliga variationen av Android-enheter ger en vacker mosaik av Androids mångsidiga representation.
Men fragmentering av hårdvara och mjukvara gör inte en glad mjukvaruutvecklare. Faktiskt tvärtom. Att utveckla en app för så många olika hårdvaru- och mjukvarukonfigurationer kan visa sig vara en stor olägenhet vid felsökning. OEM-tillverkare kan göra stora eller subtila förändringar som måste beaktas när de utvecklar en app, men det finns egentligen inget enkelt sätt för den enskilda utvecklaren att säkerställa att deras app kommer att fungera universellt. Medan den genomsnittliga konsumenten för länge sedan har glömt bort fragmenteringsdebatten, spökar problemet fortfarande Android apputvecklare och det verkar inte finnas något att göra åt det förutom att suga upp det och hantera felen när de dyka upp.
Det ledsna tillståndet av fragmentering
En OEM i synnerhet får en stor del av hat för huvudvärken de orsakar när de utvecklar en app - Samsung. Utvecklare har tjatat om Samsung i flera år nu, vissa har till och med skrivit så svidande stycken som "Det finns en speciell plats för Samsung i Android Hell" som beskriver en särskilt frustrerande bugg som härrör från Samsung-enheter och supportappkompatbiblioteket. Jag skulle vilja fästa uppmärksamheten på ett stycke i synnerhet från Ambris uttalande, som utmärkt beskriver varför utvecklare fortfarande bryr sig om fragmentering:
Om du är en Android-utvecklare är ditt hat för Samsung-enheter förmodligen gränslöst. Mer än en genomsnittlig användare, för vilken Samsung är synonymt med dumma Touchwiz och överdriven bloatware, du föraktar Samsung för att du inte har något val. På grund av Samsungs massiva marknadsandelar, du kan helt enkelt inte välja att inte stödja Samsung-enheter. Och det är det som gör mest ont; det faktum att detta val tas ifrån dig!
Detta är inte heller ett gnäll från de gamla åren av Androids existens – det här inlägget publicerades i mitten av december förra året. Jag kommer att vara i förväg och säga att jag inte är säker på om det här problemet har åtgärdats officiellt ännu, men Mr. Ambri har tillhandahållit en lösning i sitt inlägg för alla som snubblar över hans rant via en Google-sökning efter insekt. Allt du behöver göra är att använda ProGuard med följande enstaka kodrad:
# Samsung ruining all nice things-keep class !android.support.v7.view.menu.**, !android.support.design.internal.NavigationMenu, !android.support.design.internal.NavigationMenuPresenter, !android.support.design.internal.NavigationSubMenu, android.support.** {*;}Det är inte så illa, eller hur? Problemet är dock att denna fix togs bort från Stack Overflow. Missförstå mig inte, Stack Overflow är en fantastisk webbplats. Men det är inte riktigt en idealisk källa för att upptäcka korrigeringar för dina appar. Att hitta något på Stack Overflow innebär ofta att du dyker djupt igenom länkar efter många försök och misstag på Google. Ibland hittar du till och med en annan användare som nämner samma bugg som du har haft, men utan en fix i sikte. Eller ännu mer frustrerande är de tillfällen då du hittar en tråd där den ursprungliga affischen har gjort anspråk på har hittat en fix men de har för länge sedan övergett sin tråd utan att instruera andra hur man fixar det problem.
Ett exempel på ett subtilt fragmenteringsproblem
Jag är inte en utvecklare själv, men jag är tillräckligt bekant med funktionerna hos Android efter år av pysslande i Tasker att jag har börjat pseudoprogrammera mina egna lösningar på problem jag har ställts inför. Och när jag inte kan komma på något så googlar jag det, precis som alla andra gör. Medan jag höll på att skriva upp min tidigare artikel om gräva runt i telefonens Inställningar-app för dolda aktiviteter, Jag stötte på en ganska udda bugg som jag inte kunde förklara. En bugg som är unik för Huawei-enheter.
När jag försökte starta vissa aktiviteter (som menyn "Testning" som innehåller statistik över appanvändning) i appen Inställningar möttes jag alltid av ett behörighetsfel. I synnerhet saknade appen jag använde för att starta aktiviteten behörighet huawei.android.permission. HW_SIGNATURE_OR_SYSTEM. Ingen annan enhet som jag testade krävde några unika behörigheter för att starta dessa Inställningar, bara telefoner som kör Huaweis version av Android (EMUI). En analys av com.android.settings avslöjade att vissa aktiviteter inom appen Inställningar verkligen var under en skyddsnivå som krävde antingen signatur eller systemtillstånd.
Tyvärr för mig betyder detta att endast appar installerade under /system eller appar signerade med detsamma signatur eftersom appen Inställningar skulle kunna öppna dessa aktiviteter med den metod jag var försöker. När jag på Google sökte efter ett svar på det här felet, stötte jag (du gissade rätt) på ett Stack Overflow tråd. Utvecklaren som publicerade sitt problem stötte på samma problem som jag gjorde (även om han faktiskt var i färd med att utveckla en app). Hans problem uppstod när han försökte köra följande kod:
<span >Intentspan><span > mainIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_MAINspan><span >,span><span >nullspan><span >);span><span >mainIntentspan><span >.span><span >addCategoryspan><span >(span><span >Intentspan><span >.span><span >CATEGORY_LAUNCHERspan><span >);span><span >Intentspan><span > pickIntent span><span >=span><span >newspan><span >Intentspan><span >(span><span >Intentspan><span >.span><span >ACTION_PICK_ACTIVITYspan><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_TITLEspan><span >,span><span >"Pick App to Play in"span><span >);span><span >pickIntentspan><span >.span><span >putExtraspan><span >(span><span >Intentspan><span >.span><span >EXTRA_INTENTspan><span >,span><span > mainIntentspan><span >);span><span >thisspan><span >.span><span >startActivityForResultspan><span >(span><span >pickIntentspan><span >,span><span > REQUEST_PICK_APPLICATIONspan><span >);span>Att döma av strängarna i avsikten och utvecklarens webbsida försökte han troligen tillåta användaren att välja en tredjepartsapp att spela upp media i. Fixningen, tillhandahållen av veteranutvecklare CommonsWare, var ganska enkelt: använd Avsikt. Skapa Väljare istället för ACTION_PICK_ACTIVITY. Dock, Varför ska vi behöva implementera denna korrigering? Varför kräver Huawei detta tillstånd i första hand? Varför behövde vi hitta ett svar på StackOverflow genom att använda en mycket specifik Google-sökning?
Valets paradox
För att hitta ett svar, CommonsWare har lämnat in en felrapport på Android buggspåraren och begär att Google undersöker problemet. Utvecklaren begärde särskilt att Google skulle hindra odokumenterade behörighetskrav från att hindra tredjepartsappar från att komma åt ACTION_PICK_ACTIVITY. Genom att skriva in dessa krav i CTS, skulle Huawei tvingas följa dessa ändringar.
För att vara ärlig, men den här buggen i sig är verkligen ingen stor sak. Även om ingen annan app jag har provat (som Tasker) kunde komma runt denna behörighet krav och starta vissa aktiviteter inom appen Inställningar, blev jag inte direkt besviken över resultatet. Men när jag kom ihåg gnället av herr Ambri insåg jag att små förändringar som dessa måste vara väldigt frustrerande att hantera, särskilt för så små som de kan vara, de utan tvekanLägg till, ibland tillräckligt för att orsaka huvudvärk. En liten ändring av appen Inställningar kan resultera i en oförtjänt negativ recension mot en utvecklare. En liten förändring som är ganska dåligt dokumenterad och som krävde att jag letade igenom Internet efter en Stack Overflow-tråd. Hur många andra små buggar finns det på andra enheter?
Ökad konkurrens i det mobila utrymmet har visat sig vara bra för konsumenten, men efter att ha sett hur dessa subtila förändringar över så många olika produktlinjer kan påverka utvecklare, jag har vuxit till att uppskatta utvecklarens syn på splittring. Det är inte så att valet i sig är problemet, utan snarare att samhället inte gör tillräckligt för att katalogisera dessa frågor. Som Mr Ambri föreslog i sin artikel, kanske Android-utvecklare behöver sin egen version av caniuse.com eller sdkcritic.com att samla alla obskyra buggar i en databas. Det enda andra alternativet är att få OEM-tillverkare att antingen dokumentera dessa ändringar ordentligt eller sluta göra dem i första hand, men lycka till med det.
Feature Image Credits: OpenSignal