De gemiddelde Android-gebruiker is waarschijnlijk al lang niet meer bezig met het 'fragmentatieprobleem' van Android. Maar het probleem achtervolgt ontwikkelaars nog steeds.
Fragmentatie is letterlijk een controversieel onderwerp geweest in Android sinds de aankondiging van het mobiele besturingssysteem.
Behalve dat het een knuppel is voor trollen om te gebruiken in online vlammenoorlogen, wordt de diversiteit die gepaard gaat met fragmentatie nu grotendeels gezien als een netto positief voor de consument van Android-apparaten. We krijgen tenslotte zoveel vrijheid bij het kiezen van het soort apparaat met het soort software dat we willen, dat het voor de gemiddelde consument moeilijk is om zich zorgen te maken over fragmentatie. Het visualiseren van de ongelooflijke verscheidenheid aan Android-apparaten levert een prachtig mozaïek op van de diverse representatie van Android.
Maar hardware- en softwarefragmentatie zorgt niet voor een gelukkige softwareontwikkelaar. In feite precies het tegenovergestelde. Het ontwikkelen van een app met zoveel verschillende hardware- en softwareconfiguraties kan een grote hindernis blijken te zijn bij het debuggen. OEM's kunnen grote of subtiele wijzigingen aanbrengen waarmee rekening moet worden gehouden bij het ontwikkelen van een app, maar er is echt geen gemakkelijke manier voor de individuele ontwikkelaar om ervoor te zorgen dat zijn app universeel werkt. Hoewel de gemiddelde consument het fragmentatiedebat allang is vergeten, achtervolgt het probleem Android nog steeds app-ontwikkelaars en er is schijnbaar niets aan te doen, behalve het opzuigen en omgaan met de fouten zoals zij verschijnen.
De droevige staat van fragmentatie
Vooral één OEM ontvangt een groot deel van de haat vanwege de kopzorgen die ze veroorzaken bij het ontwikkelen van een app: Samsung. Ontwikkelaars gaan al jaren tekeer over Samsung, sommigen schrijven zelfs vernietigende stukken als "Er is een speciale plaats voor Samsung in Android Hell" waarin een bijzonder frustrerende bug wordt beschreven die voortkomt uit Samsung-apparaten en de ondersteunende appcompat-bibliotheek. Ik zou in het bijzonder de aandacht willen vestigen op één paragraaf uit de tirade van de heer Ambri, die uitstekend schetst waarom ontwikkelaars zich nog steeds zorgen maken over fragmentatie:
Als u een Android-ontwikkelaar bent, is uw haat tegen Samsung-apparaten waarschijnlijk grenzeloos. Meer dan een gemiddelde gebruiker, waar Samsung synoniem voor staat domme Touchwiz En overmatige bloatware, je veracht Samsung omdat je geen keus hebt. Vanwege Samsung enorm marktaandeel, je kunt er eenvoudigweg niet voor kiezen om Samsung-apparaten niet te ondersteunen. En dat doet het meeste pijn; het feit dat deze keuze je wordt ontnomen!
Dit is ook geen tirade uit de oude jaren van het bestaan van Android: dit bericht werd medio december vorig jaar gepubliceerd. Ik zal eerlijk zijn en zeggen dat ik niet zeker weet of dit probleem al officieel is opgelost, maar meneer. Ambri heeft in zijn bericht een oplossing geboden voor iedereen die zijn tirade tegenkomt via een Google-zoekopdracht naar de beestje. Het enige wat u hoeft te doen is gebruiken ProGuard met de volgende enkele regel code:
# 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.** {*;}Dat is niet zo erg, toch? Het probleem is echter dat deze oplossing uit Stack Overflow is gehaald. Begrijp me niet verkeerd, Stack Overflow is een geweldige website. Maar het is niet echt een ideale bron voor het ontdekken van oplossingen voor uw apps. Als je iets op Stack Overflow wilt vinden, moet je vaak diep door links duiken na veel Google-zoekopdrachten met vallen en opstaan. Soms zul je zelfs merken dat een andere gebruiker dezelfde bug vermeldt die jij hebt, maar zonder dat er een oplossing in zicht is. Of nog frustrerender zijn de momenten waarop je een draad vindt waar de originele poster beweert te zijn hebben een oplossing gevonden, maar ze hebben hun draad al lang verlaten zonder anderen te instrueren hoe ze het probleem moeten oplossen probleem.
Een voorbeeld van een subtiel fragmentatieprobleem
Ik ben zelf geen ontwikkelaar, maar ik ben na jarenlang sleutelen in Tasker zo bekend met de mogelijkheden van Android dat ik ben begonnen met het pseudoprogrammeren van mijn eigen oplossingen voor de problemen waarmee ik te maken kreeg. En als ik iets niet kan achterhalen, google ik het, net als iedereen. Terwijl ik bezig was met het schrijven van mijn vorige artikel over in de app Instellingen van je telefoon zoeken naar verborgen activiteiten, kwam ik een nogal vreemde bug tegen die ik niet kon verklaren. Een bug die uniek is voor Huawei-apparaten.
Telkens wanneer ik bepaalde activiteiten probeerde te starten (zoals het menu "Testen" dat app-gebruiksstatistieken bevat) in de app Instellingen, kreeg ik altijd een toestemmingsfout te zien. Met name de app die ik gebruikte om de activiteit te starten, had geen toestemming huawei.android.toestemming. HW_SIGNATURE_OR_SYSTEEM. Geen enkel ander apparaat dat ik heb getest, had unieke machtigingen nodig om deze instellingenactiviteiten te starten, alleen telefoons met Huawei's versie van Android (EMUI). Een analyse van com.android.instellingen onthulde dat bepaalde activiteiten binnen de app Instellingen zich inderdaad onder een beschermingsniveau bevonden waarvoor de handtekening of systeemtoestemming.
Helaas voor mij betekent dit dat alleen apps zijn geïnstalleerd onder /system of apps die daarmee zijn ondertekend handtekening omdat de app Instellingen deze activiteiten zou kunnen openen met de methode die ik was proberen. Toen ik met Google deze fout zocht naar een antwoord, kwam ik (je raadt het al) een Stack Overflow-draad. De ontwikkelaar die zijn probleem postte, kwam hetzelfde probleem tegen als ik (hoewel hij bezig was met het ontwikkelen van een app). Zijn probleem ontstond toen hij probeerde de volgende code uit te voeren:
<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>Afgaande op de bepalingen in de intentie en de webpagina van de ontwikkelaar, probeerde hij waarschijnlijk de gebruiker toe te staan een app van derden te kiezen om bepaalde media in af te spelen. De oplossing, geleverd door een ervaren ontwikkelaar CommonsWare, was vrij eenvoudig: gebruiken Intentie. MaakKiezer in plaats van ACTION_PICK_ACTIVITY. Echter, Waarom Moeten we deze oplossing implementeren? Waarom Heeft Huawei deze toestemming überhaupt nodig? Waarom moesten we een antwoord vinden op StackOverflow door een zeer specifieke Google-zoekopdracht te gebruiken?
De paradox van keuze
Om een antwoord te vinden, CommonsWare heeft een bugrapport ingediend op de Android-bugtracker met het verzoek Google het probleem te onderzoeken. De ontwikkelaar verzocht Google met name om ongedocumenteerde toestemmingsvereisten te verbieden om apps van derden de toegang tot ACTION_PICK_ACTIVITY te ontzeggen. Door deze vereisten in te schrijven in CTSzou Huawei gedwongen zijn om aan deze veranderingen te voldoen.
Maar eerlijk gezegd is deze bug op zich niet zo erg. Hoewel geen enkele andere app die ik heb geprobeerd (zoals Tasker) deze toestemming kon omzeilen vereiste en bepaalde activiteiten startte in de app Instellingen, waar ik niet bepaald teleurgesteld door was de uitkomst. Maar toen ik me de tirade van de heer Ambri herinnerde, besefte ik dat kleine veranderingen als deze erg frustrerend moeten zijn om mee om te gaan, vooral want hoe klein ze ook mogen zijn, dat zijn ze ongetwijfeldoptellenSoms genoeg om hoofdpijn te veroorzaken. Eén kleine wijziging in de app Instellingen kan resulteren in een onverdiende negatieve recensie tegen een ontwikkelaar. Een kleine verandering die nogal slecht gedocumenteerd is en waardoor ik het internet moest afspeuren naar een Stack Overflow-thread. Hoeveel andere kleine bugs zijn er op andere apparaten?
De toegenomen concurrentie op mobiel gebied is geweldig gebleken voor de consument, maar nadat we hebben gezien hoe deze subtiele veranderingen optreden Omdat zoveel verschillende productlijnen ontwikkelaars kunnen beïnvloeden, ben ik de visie van de ontwikkelaar op dit gebied gaan waarderen fragmentatie. Het is niet zo dat de keuze zelf het probleem is, maar eerder dat de gemeenschap niet genoeg doet om deze kwesties in kaart te brengen. Zoals de heer Ambri in zijn artikel suggereerde, hebben Android-ontwikkelaars misschien hun eigen versie nodig caniuse.com of sdkcritic.com om alle obscure bugs in één database te verzamelen. Het enige andere alternatief is dat OEM's deze wijzigingen ofwel goed documenteren, ofwel überhaupt stoppen met het doorvoeren ervan succes daarmee.
Functieafbeeldingscredits: OpenSignaal