Den gjennomsnittlige Android-brukeren har sannsynligvis for lengst sluttet å bry seg om Androids «fragmenteringsproblem». Men problemet hjemsøker fortsatt utviklere.
Fragmentering har vært et omstridt problem i Android bokstavelig talt siden mobiloperativsystemet ble annonsert.
Bortsett fra å være en kos for troll å bruke i online flammekriger, blir mangfoldet som følger med fragmentering nå i stor grad sett på som en netto positiv for forbrukerne av Android-enheter. Tross alt får vi så mye frihet i å velge typen enhet med den typen programvare vi ønsker at det er vanskelig for den gjennomsnittlige forbrukeren å bry seg om fragmentering. Å visualisere den utrolige variasjonen av Android-enheter produserer en vakker mosaikk av Androids mangfoldige representasjon.
Men maskinvare- og programvarefragmentering er ikke en lykkelig programvareutvikler. Faktisk tvert imot. Å utvikle en app på tvers av så mange forskjellige maskinvare- og programvarekonfigurasjoner kan vise seg å være en stor plage ved feilsøking. OEM-er kan gjøre store eller subtile endringer som må tas i betraktning når de utvikler en app, men det er egentlig ingen enkel måte for den enkelte utvikler å sikre at appen deres fungerer universelt. Mens den gjennomsnittlige forbrukeren for lengst har glemt fragmenteringsdebatten, hjemsøker problemet fortsatt Android apputviklere og det er tilsynelatende ingenting å gjøre med det, bortsett fra å suge det opp og håndtere feilene etter hvert som de vises.
The Sorry State of Fragmentation
Spesielt én OEM mottar en stor del av hat for hodepinen de forårsaker når de utvikler en app - Samsung. Utviklere har kranglet om Samsung i årevis nå, noen har til og med skrevet så skarpe stykker som "Det er et spesielt sted for Samsung i Android Hell" som beskriver en spesielt frustrerende feil som stammer fra Samsung-enheter og støtteappkompatbiblioteket. Jeg vil trekke oppmerksomheten til spesielt ett avsnitt fra Mr. Ambris rant, som utmerket skisserer hvorfor utviklere fortsatt bryr seg om fragmentering:
Hvis du er en Android-utvikler, er hatet ditt for Samsung-enheter sannsynligvis grenseløst. Mer enn en gjennomsnittlig bruker, som Samsung er synonymt med dumme Touchwiz og overdreven bloatware, du forakter Samsung fordi du ikke har noe valg. På grunn av Samsungs massiv markedsandel, kan du rett og slett ikke velge å ikke støtte Samsung-enheter. Og det er det som gjør mest vondt; det faktum at dette valget er tatt fra deg!
Dette er heller ikke noe tull fra de gamle årene av Androids eksistens – dette innlegget ble publisert i midten av desember i fjor. Jeg vil være på forhånd og si at jeg ikke er sikker på om dette problemet er offisielt løst ennå, men Mr. Ambri har gitt en løsning i innlegget sitt for alle som snubler over ranten hans via et Google-søk etter feil. Alt du trenger å gjøre er å bruke ProGuard med følgende enkle kodelinje:
# 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 er ikke så ille, er det nå? Problemet er imidlertid at denne løsningen ble fjernet fra Stack Overflow. Misforstå meg rett, Stack Overflow er et flott nettsted. Men det er egentlig ikke en ideell kilde for å finne rettelser for appene dine. Å finne noe på Stack Overflow innebærer ofte å dykke dypt gjennom lenker etter mange prøving-og-feilsøk på Google. Noen ganger vil du til og med finne en annen bruker som nevner den samme feilen du har hatt, men uten en løsning i sikte. Eller enda mer frustrerende er de gangene du finner en tråd der den originale plakaten har hevdet det har funnet en løsning, men de har for lengst forlatt tråden sin uten å instruere andre hvordan de skal fikse problemet utgave.
Et eksempel på et subtilt fragmenteringsproblem
Jeg er ikke en utvikler selv, men jeg er kjent nok med mulighetene til Android etter år med fiksing i Tasker til at jeg har begynt å pseudoprogrammere mine egne løsninger på problemer jeg har møtt. Og når jeg ikke finner ut av noe, Googler jeg det, akkurat som alle andre gjør. Mens jeg var i ferd med å skrive opp min forrige artikkel om grave rundt telefonens Innstillinger-app for skjulte aktiviteter, kom jeg over en ganske merkelig feil som jeg ikke kunne forklare. En feil som er unik for Huawei-enheter.
Hver gang jeg prøvde å starte visse aktiviteter (som "Testing"-menyen som inneholder appbruksstatistikk) i Innstillinger-appen, ble jeg alltid møtt med en tillatelsesfeil. Spesielt manglet appen jeg brukte for å starte aktiviteten tillatelsen huawei.android.permission. HW_SIGNATURE_OR_SYSTEM. Ingen annen enhet jeg testet krevde noen unike tillatelser for å starte disse Innstillingsaktivitetene, bare telefoner som kjører Huaweis versjon av Android (EMUI). En analyse av com.android.settings avslørte at visse aktiviteter i Innstillinger-appen faktisk var under et beskyttelsesnivå som krevde enten signatur eller systemtillatelse.
Dessverre for meg betyr dette at bare apper installert under /system eller apper signert med det samme signatur som Innstillinger-appen ville være i stand til å åpne disse aktivitetene ved å bruke metoden jeg var prøver. Da jeg Google søkte denne feilen etter et svar, kom jeg (du gjettet riktig) over en Stable overløpstråd. Utvikleren som la ut problemet sitt, kom over det samme problemet som jeg gjorde (selv om han faktisk var i ferd med å utvikle en app). Problemet hans oppsto da han forsøkte å kjøre følgende kode:
<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>Å dømme etter strengene i intensjonen og utviklerens nettside, prøvde han sannsynligvis å la brukeren velge en tredjepartsapp å spille noen medier i. Reparasjonen, levert av veteranutvikler CommonsWare, var ganske enkel: bruk Hensikt. CreateChooser i stedet for ACTION_PICK_ACTIVITY. Derimot, Hvorfor bør vi trenge å implementere denne løsningen? Hvorfor krever Huawei denne tillatelsen i utgangspunktet? Hvorfor trengte vi å finne et svar på StackOverflow ved å bruke et veldig spesifikt Google-søk?
Valgets paradoks
For å finne et svar, CommonsWare sendte inn en feilrapport på Android-feilsporeren og ber Google om å se på problemet. Spesielt ba utvikleren om at Google hindrer udokumenterte tillatelseskrav fra å hindre tredjepartsapper i å få tilgang til ACTION_PICK_ACTIVITY. Ved å skrive inn disse kravene i CTS, ville Huawei bli tvunget til å overholde disse endringene.
For å være ærlig, men denne feilen i seg selv er egentlig ikke en stor sak. Selv om ingen andre apper jeg har prøvd (som Tasker) klarte å omgå denne tillatelsen krav og starte visse aktiviteter i Innstillinger-appen, ble jeg ikke akkurat skuffet over Resultatet. Men da jeg husket ranet av Mr. Ambri, innså jeg at små endringer som disse må være veldig frustrerende å håndtere, spesielt fordi så små som de kan være, de utvilsomtlegge sammen, noen ganger nok til å forårsake hodepine. En liten endring i Innstillinger-appen kan resultere i en ufortjent negativ anmeldelse mot en utvikler. En liten endring som er ganske dårlig dokumentert og som krevde meg til å lete etter en Stack Overflow-tråd på Internett. Hvor mange andre små feil er det på andre enheter?
Økt konkurranse på mobilområdet har vist seg å være bra for forbrukeren, men etter å ha sett hvordan disse subtile endringene på tvers av så mange forskjellige produktlinjer kan påvirke utviklere, jeg har vokst til å sette pris på utviklerens syn på fragmentering. Det er ikke det at valget i seg selv er problemet, men snarere at samfunnet ikke gjør nok for å katalogisere disse problemene. Som Mr. Ambri foreslo i artikkelen sin, trenger kanskje Android-utviklere sin egen versjon av caniuse.com eller sdkcritic.com å samle alle de obskure feilene i én database. Det eneste andre alternativet er å få OEM-er til å enten dokumentere disse endringene ordentlig eller slutte å gjøre dem i utgangspunktet, men lykke til med det.
Kreditt for funksjonsbilder: OpenSignal