Den gennemsnitlige Android-bruger er formentlig for længst holdt op med at bekymre sig om Androids "fragmenteringsproblem". Men problemet forfølger stadig udviklere.
Fragmentering har været et omstridt problem i Android bogstaveligt talt siden det mobile operativsystem blev annonceret.
Ud over at være en knus for trolde at bruge i online flammekrige, ses den mangfoldighed, der følger med fragmentering nu i vid udstrækning som en netto positiv for forbrugerne af Android-enheder. Når alt kommer til alt, får vi så meget frihed i at vælge den slags enhed med den slags software, vi ønsker, at det er svært for den gennemsnitlige forbruger at bekymre sig om fragmentering. Visualisering af det utrolige udvalg af Android-enheder giver en smuk mosaik af Androids mangfoldige repræsentation.
Men hardware- og softwarefragmentering er ikke en glad softwareudvikler. Faktisk tværtimod. At udvikle en app på tværs af så mange forskellige hardware- og softwarekonfigurationer kan vise sig at være en stor gene ved fejlretning. OEM'er kan foretage store eller subtile ændringer, der skal tages højde for, når de udvikler en app, men der er virkelig ingen nem måde for den enkelte udvikler at sikre, at deres app vil fungere universelt. Mens den gennemsnitlige forbruger for længst har glemt fragmenteringsdebatten, hjemsøger problemet stadig Android app-udviklere, og der er tilsyneladende intet at gøre ved det, bortset fra at suge det op og håndtere fejlene, efterhånden som de komme til syne.
Den beklagede tilstand af fragmentering
Især én OEM modtager en stor portion had for den hovedpine, de forårsager, når de udvikler en app - Samsung. Udviklere har skældt om Samsung i årevis nu, nogle har endda skrevet så skarpe stykker som "Der er et særligt sted for Samsung i Android Hell" som beskriver en særlig frustrerende fejl, der stammer fra Samsung-enheder og support-appcompat-biblioteket. Jeg vil gerne henlede opmærksomheden på især et afsnit fra hr. Ambris rant, som glimrende beskriver, hvorfor udviklere stadig bekymrer sig om fragmentering:
Hvis du er en Android-udvikler, er dit had til Samsung-enheder sandsynligvis grænseløst. Mere end en gennemsnitlig bruger, som Samsung er synonymt med fjollet Touchwiz og overdreven bloatware, du foragter Samsung, fordi du ikke har et valg. På grund af Samsungs massiv markedsandel, kan du simpelthen ikke vælge ikke at understøtte Samsung-enheder. Og det er det, der gør mest ondt; det faktum, at dette valg er taget fra dig!
Dette er heller ikke en rædsel fra de gamle år af Androids eksistens – dette indlæg blev offentliggjort i midten af december sidste år. Jeg vil være på forhånd og sige, at jeg ikke er sikker på, om dette problem er blevet officielt løst endnu, men hr. Ambri har givet en rettelse i sit indlæg til enhver, der falder over hans rant via en Google-søgning efter insekt. Alt du skal gøre er at bruge ProGuard med følgende enkelte 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å slemt, er det nu? Problemet er dog, at denne rettelse blev trukket ud af Stack Overflow. Misforstå mig ikke, Stack Overflow er en fantastisk hjemmeside. Men det er ikke rigtig en ideel kilde til at finde rettelser til dine apps. At finde noget på Stack Overflow involverer ofte at dykke dybt gennem links efter mange prøve-og-fejl-søgninger på Google. Nogle gange vil du endda finde en anden bruger, der nævner den samme fejl, du har haft, men uden en rettelse i sigte. Eller endnu mere frustrerende er de tidspunkter, hvor du finder en tråd, hvor den originale plakat har gjort krav på har fundet en løsning, men de har for længst forladt deres tråd uden at instruere andre i, hvordan de skal løse problemet problem.
Et eksempel på et subtilt fragmenteringsproblem
Jeg er ikke selv en udvikler, men jeg kender nok Androids muligheder efter mange års fifling i Tasker til, at jeg er begyndt at pseudoprogrammere mine egne løsninger på problemer, jeg har stået over for. Og når jeg ikke kan finde ud af noget, googler jeg det, ligesom alle andre gør. Mens jeg var i gang med at skrive min tidligere artikel om graver rundt i telefonens Indstillinger-app for skjulte aktiviteter, Jeg stødte på en ret mærkelig fejl, som jeg ikke kunne forklare. En fejl, der er unik for Huawei-enheder.
Når jeg forsøgte at starte visse aktiviteter (såsom menuen "Test", der indeholder statistik over appbrug) i appen Indstillinger, ville jeg altid blive mødt med en tilladelsesfejl. Især den app, jeg brugte til at starte aktiviteten, manglede tilladelsen huawei.android.permission. HW_SIGNATURE_OR_SYSTEM. Ingen anden enhed, jeg testede, krævede nogen unikke tilladelser for at starte disse Indstillinger-aktiviteter, kun telefoner, der kører Huaweis version af Android (EMUI). En analyse af com.android.settings afslørede, at visse aktiviteter i appen Indstillinger faktisk var under et beskyttelsesniveau, der krævede enten signatur eller systemtilladelse.
Desværre for mig betyder det, at kun apps installeret under /system eller apps, der er signeret med samme signatur, da Indstillinger-appen ville være i stand til at åbne disse aktiviteter ved hjælp af den metode, jeg var forsøger. Da jeg Google søgte denne fejl efter et svar, stødte jeg (du gættede rigtigt) på en Stak overløbstråd. Udvikleren, der postede sit problem, stødte på det samme problem, som jeg gjorde (selvom han var i gang med faktisk at udvikle en app). Hans problem opstod, da han forsøgte at kø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>At dømme efter strengene i hensigten og udviklerens webside, forsøgte han sandsynligvis at give brugeren mulighed for at vælge en tredjepartsapp at afspille nogle medier i. Rettelsen, leveret af veteranudvikler CommonsWare, var ret simpelt: brug Hensigt. Opret Vælger i stedet for ACTION_PICK_ACTIVITY. Imidlertid, hvorfor skal vi implementere denne rettelse? Hvorfor kræver Huawei denne tilladelse i første omgang? Hvorfor skulle vi finde et svar på StackOverflow ved at bruge en meget specifik Google-søgning?
Valgets paradoks
For at finde et svar, CommonsWare indsendte en fejlrapport på Android-fejlsporingen og anmoder Google om at undersøge problemet. Især anmodede udvikleren om, at Google forhindrede udokumenterede tilladelseskrav i at forhindre tredjepartsapps i at få adgang til ACTION_PICK_ACTIVITY. Ved at skrive disse krav i CTS, ville Huawei være tvunget til at overholde disse ændringer.
For at være ærlig er denne fejl i sig selv virkelig ikke en big deal. Selvom ingen anden app, jeg har prøvet (såsom Tasker), var i stand til at omgå denne tilladelse krav og starte visse aktiviteter i Indstillinger-appen, var jeg ikke ligefrem skuffet over resultatet. Men da jeg huskede hr. Ambris skænderi, indså jeg, at små ændringer som disse må være meget frustrerende at håndtere, især fordi lige så små som de måtte være, så er de uden tvivllægge sammen, nogle gange nok til at forårsage hovedpine. En lille ændring af appen Indstillinger kan resultere i en ufortjent negativ anmeldelse mod en udvikler. En lille ændring, der er ret dårligt dokumenteret og krævede, at jeg gennemsøgte internettet efter en Stack Overflow-tråd. Hvor mange andre små fejl er der på andre enheder?
Øget konkurrence på mobilområdet har vist sig at være fantastisk for forbrugeren, men efter at have set, hvordan disse subtile ændringer på tværs af så mange forskellige produktlinjer kan påvirke udviklere, er jeg vokset til at værdsætte udviklerens syn på fragmentering. Det er ikke, at valget i sig selv er problemet, men snarere, at samfundet ikke gør nok for at katalogisere disse problemer. Som hr. Ambri foreslog i sin artikel, har Android-udviklere måske brug for deres egen version af caniuse.com eller sdkcritic.com at samle alle de obskure fejl i én database. Det eneste andet alternativ er at få OEM'er til enten at dokumentere disse ændringer ordentligt eller stoppe med at lave dem i første omgang, men held og lykke med det.
Kreditering af featurebilleder: OpenSignal