De Scoped Storage-wijzigingen in Android Q zijn lastig om mee om te gaan, omdat het Storage Access Framework op dit moment een paar tekortkomingen heeft.
Android Q verandert fundamenteel de manier waarop opslag op je telefoon werkt. In elke versie tot aan Pie werkte de opslag van Android als een desktopcomputer: je kunt elke app gebruiken die je wilt lezen of elk bestand schrijven (als je een app daarvoor toestemming geeft). Met Q introduceert (en vereist) Google "Omvangrijke opslag", waardoor Android meer als een iPhone werkt, waarbij de opslag voor elke app is geïsoleerd. Een app heeft alleen toegang tot zijn eigen bestanden, en als de app wordt verwijderd, worden alle bestanden verwijderd.
Gelukkig behoudt Android Q nog steeds een deel van Android's oorspronkelijke gedrag van een centraal bestandssysteem. Helaas is het nu omslachtig voor de gebruiker om apps in te stellen om er toegang toe te krijgen, waardoor de prestaties en mogelijkheden aanzienlijk zijn verminderd. En ontwikkelaars zullen apps aanzienlijk moeten hercoderen om dit te ondersteunen.
Apps die algemene toegang tot het bestandssysteem nodig hebben, b.v. een kantoorpakket, afbeeldingseditor of bestandsbeheerder zal nu een Android API moeten gebruiken genaamd de "Kader voor opslagtoegang" (SAF), voor alle bestandsbewerkingen. SAF is beschikbaar sinds Android 5.0 Lollipop, maar ontwikkelaars gebruiken het meestal niet tenzij dit nodig is, omdat het een moeilijke en slechte gedocumenteerde API, een slechte gebruikerservaring, slechte prestaties en slechte betrouwbaarheid (grotendeels in de vorm van leverancierspecifieke implementatie van het apparaat problemen). Als gevolg van de moeilijkheid bij de overstap naar SAF heeft Google besloten apps toe te staan die dat nog niet aangeven Android Q-ondersteuning werkt zoals vroeger, maar dit zal veranderen wanneer de Play Store vereist dat alle apps Q ondersteunen volgend jaar.
De meest voor de hand liggende verandering voor de gebruiker met SAF is de ervaring van het verlenen van toegang aan een app tot opslag. Om toegang te krijgen tot een app, wordt er een verzoek ingediend bij het besturingssysteem, dat vervolgens een mapkiezerscherm weergeeft. Op dit scherm selecteert de gebruiker de hoofdmap van een maphiërarchie waarin die app bestanden kan lezen en schrijven. De gebruiker moet dit proces doorlopen voor elke app die toegang nodig heeft tot lokale bestanden, of twee keer per app als hij deze ook toegang moet verlenen tot een externe SD-kaart.
Google heeft dit proces in ieder geval verbeterd Q bèta 3, omdat bij eerdere bètaversies een app niet eens een locatie kon voorstellen die de gebruiker kon selecteren vereiste dat de gebruiker behoorlijk wat werk moest verzetten om daadwerkelijk de primaire opslag van hun apparaat te vinden.
De I/O-prestaties van bestanden worden onder SAF enigszins aangetast, maar het meest opvallende probleem ligt bij de bestanden directorybewerkingen, waarbij het ~25 tot 50 keer langzamer is dan de conventionele bestandstoegang die mogelijk is in Taart. In het geval van bestandsbeheerders betekent dit dat het een orde van grootte langer zal duren om zoekopdrachten uit te voeren en berekeningen voor het opslaggebruik uit te voeren. Een bugrapport met een demonstratie-app is beschikbaar Hier.
Een nog groter prestatieprobleem is dat sommige apps bestanden naar hun lokale "scoped storage" -gebied moeten kopiëren voordat ze ermee kunnen werken. Dit kan problematisch zijn als dergelijke bestanden meerdere gigabytes groot zijn, b.v. in het geval van videobestanden of gecomprimeerde archieven. Veel Android-apps profiteren van het verbazingwekkende aantal open-source Java-bibliotheken in de ontwikkelaarsgemeenschap, en deze bibliotheken hebben doorgaans directe toegang tot het bestandssysteem nodig om te kunnen werken. Ze zijn niet Android-specifiek en vereisen herschrijving om met SAF te kunnen werken. Erger nog, veel van de interne bibliotheken van Android zullen er niet mee werken, zoals de pakketbeheerder of de zip-API. Een bestandsbeheerder kan bijvoorbeeld niet eens het pictogram voor een APK-bestand weergeven (met behulp van de standaard Android API) zonder eerst de volledige APK naar zijn eigen opslagruimte te kopiëren. Bug report.
Voor technisch onderlegde mensen is het momenteel mogelijk om de "Scoped Storage" van Android Q per app uit te schakelen via ADB met behulp van een appops-opdracht. Root-gebruikers kunnen de opdrachten rechtstreeks op hun apparaat uitvoeren, zonder een desktopcomputer. Dergelijke opdrachten worden in de documentatie beschreven als ontwikkelaarsfuncties en kunnen daarom op elk moment worden verwijderd.
Algemene opslagtoegang voor een app inschakelen:
adb shell cmd appops set your-package-name android: legacy_storage allow && \adb shell am force-stop your-package-nameAlgemene opslagtoegang voor een app uitschakelen:
adb shell cmd appops set your-package-name android: legacy_storage default && \adb shell am force-stop your-package-nameGoogle prijst de beveiligings- en privacyvoordelen van deze wijziging, maar technisch gezien is er geen verbetering. Sinds Android 1.0 hebben apps de mogelijkheid om bestanden privé op te slaan, en bijna alle apps maken gebruik van deze mogelijkheid. Wanneer u een app via SAF toegang verleent tot de hoofdmap van uw opslag, kan deze elk bestand lezen, schrijven en verzenden wil zijn snode ontwikkelaar op precies dezelfde manier benaderen als wanneer je een app toegang verleende tot opslag in Pie.
De enige "beveiligingsverbetering" komt tot stand omdat het voor een gebruiker nu een moeilijker proces is om dit te doen. Tenzij een app natuurlijk alleen je meest persoonlijke gegevens wil stelen, zoals foto's en video's die je hebt genomen, waarvoor Google een alternatieve toegangsoplossing heeft toegevoegd die gebruik maakt van een eenvoudige pop-up klik-ja-beveiliging dialoog.
Het is niet bekend welke voordelen Google met deze wijziging hoopt te bereiken. De officieel genoemde reden in de bètadocumentatie van Android Q is om “gebruikers meer controle over hun bestanden te geven en het bestand te beperken ophoping." Scoped storage is in zijn huidige vorm een nieuwe beperking van wat de gebruiker mag doen, en geen uitbreiding daarvan controle. De claim dat er minder rommel ontstaat, kan enigszins terecht zijn, maar alleen omdat de verandering de mogelijkheid om bestanden überhaupt te gebruiken vermindert. En de “rommel” wordt groter als je bedenkt dat sommige apps nu bestanden moeten dupliceren om ermee te kunnen werken.
Als Google zich echt zorgen wil maken over het geven van meer controle aan gebruikers over bestanden en rommel, moeten ze een oplossing die daar rechtstreeks op inspeelt, in plaats van het huidige Android Q-ontwerp ten onrechte als zodanig te bestempelen verbetering. Het eenvoudigste antwoord zou zijn om gebruikers te laten beslissen of ze willen dat een app toegang heeft tot het bestandssysteem of algemene toegang tot het bestandssysteem, met behulp van het bestaande dialoogvenster voor het aanvragen van opslagrechten. Als er bijzondere zorg bestaat dat gebruikers op dit gebied slechte beslissingen nemen, is dat zeker mogelijk maken dat dialoogvenster prominenter en vereisen extra gebruikersinteractie om een app volledig goed te keuren toegang.
Het antwoord op de vraag hoe Android gebruikers meer controle over hun bestanden kan geven, is door gebruikers daadwerkelijk meer controle te geven, niet door deze weg te nemen en de mogelijkheden van het Android-platform fundamenteel te beperken.
Noot van de redactie: dit is een gastartikel geschreven door XDA Senior Member tliebeck, vooral bekend van zijn werk aan FX-bestandsverkenner. De inhoud van dit artikel weerspiegelt zijn eigen mening en analyse van de Scoped Storage-beperkingen van Android Q, met minimale input en bewerking door Mishaal Rahman, hoofdredacteur van XDA-Developers. We hebben contact opgenomen met Google om hen te vragen naar enkele van deze zorgen, maar op het moment van publicatie hebben we nog niets van het bedrijf gehoord.