Scoped Storage i Android Q tvinger utviklere til å bruke SAF, noe som suger

Android Q endrer fundamentalt måten lagring fungerer på telefonen din. I hver versjon opp til Pie fungerte Androids lagring som en stasjonær datamaskin: du kan bruke hvilken som helst app du vil lese eller skrive hvilken som helst fil (hvis du gir en app tillatelse til å gjøre det). Med Q introduserer (og krever) Google "Omfanget lagring," som gjør at Android fungerer mer som en iPhone, hvor lagring er isolert til hver app. En app har bare tilgang til sine egne filer, og hvis den avinstalleres, slettes alle filene.

Heldigvis beholder Android Q fortsatt noe av Androids opprinnelige oppførsel til et sentralt filsystem. Dessverre er det nå tungvint for brukeren å sette opp apper for å få tilgang til det og har betydelig redusert ytelse og kapasitet. Og utviklere må vesentlig omkode apper for å støtte det.

Apper som trenger generell filsystemtilgang, f.eks. en kontorpakke, bilderedigerer eller filbehandler, må nå bruke en Android API kalt "

Lagringstilgangsramme" (SAF), for alle filoperasjoner. SAF har vært tilgjengelig siden Android 5.0 Lollipop, men utviklere har en tendens til å ikke bruke det med mindre det er nødvendig, da det har en vanskelig og dårlig dokumentert API, en dårlig brukeropplevelse, dårlig ytelse og dårlig pålitelighet (stort sett i form av enhetsleverandørspesifikk implementering problemer). Som et resultat av vanskeligheten med å gå over til SAF, har Google besluttet å tillate apper som ennå ikke indikerer Android Q-støtte fungerer som før, men dette endres når Play-butikken krever at alle apper støtter Q neste år.

Den mest åpenbare brukervendte endringen med SAF er opplevelsen av å gi en app tilgang til lagring. For at en app skal få tilgang, sender den en forespørsel til operativsystemet, som deretter viser en katalogvelgerskjerm. På denne skjermen velger brukeren roten til et mappehierarki der den appen vil kunne lese og skrive filer. Brukeren må gå gjennom denne prosessen for hver app som krever tilgang til lokale filer, eller to ganger per app hvis de også må gi den tilgang til et eksternt SD-kort.

Google forbedret i det minste denne prosessen for Q beta 3, ettersom tidligere betaversjoner ikke tillot en app engang å foreslå en plassering for brukeren å velge, som krevde at brukeren gjorde ganske mye arbeid for å faktisk finne enhetens primære lagring.

Fil I/O-ytelse tar litt av en treff under SAF, men det mest utestående problemet ligger i filen katalogoperasjoner, der det er ~25 til 50 ganger tregere enn den konvensjonelle filtilgangen som er mulig i Pai. Når det gjelder filbehandlere, betyr det at det vil ta størrelsesorden lengre tid å utføre søk og beregninger av lagringsbruk. En feilrapport med en demonstrasjonsapp er tilgjengelig her.

Et enda større ytelsesproblem er at noen apper må kopiere filer til sitt lokale "omfangslagring"-område før de kan jobbe med dem. Dette kan være problematisk når slike filer er flere gigabyte store, f.eks. når det gjelder videofiler eller komprimerte arkiver. Mange Android-apper drar nytte av det utrolige antallet Java-biblioteker med åpen kildekode i utviklerfellesskapet, og disse bibliotekene krever vanligvis direkte filsystemtilgang for å fungere. De er ikke Android-spesifikke og vil kreve omskriving for å fungere med SAF. Enda verre, mange av Androids egne interne biblioteker vil ikke fungere med det, for eksempel pakkebehandleren eller zip API. For eksempel vil en filbehandler ikke engang kunne vise ikonet for en APK-fil (ved å bruke standard Android API) uten først å kopiere hele APK-en til sitt eget lagringsområde. Feilrapport.

For teknisk tilbøyelige folk er det for øyeblikket mulig å deaktivere Android Qs "Scoped Storage" på en per-app-basis via ADB ved å bruke en appops-kommando. Rootbrukere kan utføre kommandoene direkte på enheten sin uten en stasjonær datamaskin. Slike kommandoer er beskrevet i dokumentasjonen som utviklerfunksjoner og kan derfor fjernes når som helst.

Aktiver generell lagringstilgang for en app:

adb shell cmd appops set your-package-name android: legacy_storage allow && \adb shell am force-stop your-package-name

Deaktiver generell lagringstilgang for en app:

adb shell cmd appops set your-package-name android: legacy_storage default && \adb shell am force-stop your-package-name

Google antyder sikkerhets- og personvernfordelene ved denne endringen, men teknisk sett er det ingen forbedring. Apper har hatt muligheten til å lagre filer privat siden Android 1.0, og nesten alle apper benytter seg av denne muligheten. Når du gir en app tilgang til rotkatalogen til lagringen din via SAF, kan den lese, skrive og sende hvilken som helst fil den ønsker å sin ondskapsfulle utvikler på nøyaktig samme måte som den kunne da du ga en app tilgang til lagring i Pie.

Den eneste "sikkerhetsforbedringen" kommer fordi det nå er en mer krevende prosess for en bruker å gjøre dette. Med mindre selvfølgelig en app bare vil stjele din mest personlige informasjon, som bilder og videoer du har tatt, som Google har lagt til en alternativ tilgangsløsning som bruker en enkel popup-klikk-ja-sikkerhet dialog.

Det er ikke kjent hvilke fordeler Google håper å oppnå med denne endringen. Den offisielle grunnen i betadokumentasjonen for Android Q er å "gi brukerne mer kontroll over filene sine og begrense filene rot." Omfanget lagring, i sin nåværende form, er en ny begrensning av hva brukeren har lov til å gjøre, ikke en utvidelse av deres kontroll. Påstanden om å redusere rot kan være noe gyldig, men bare fordi endringen reduserer muligheten til å bruke filer i det hele tatt. Og "rot" øker når du vurderer problemet med at noen apper nå må duplisere filer for å fungere med dem.

Hvis Google virkelig er opptatt av å gi brukerne mer kontroll over filer og rot, bør de bygge en løsning som direkte adresserer det, i stedet for å feilaktig merke dagens Android Q-design som sådan forbedring. Det enkleste svaret ville være å la brukere bestemme om de vil at en app skal ha tilgang til et omfang eller generell filsystem, ved å bruke den eksisterende dialogboksen for forespørsel om lagringstillatelse. Hvis det er en spesiell bekymring for brukere som tar dårlige beslutninger her, er det absolutt mulig gjør den dialogen mer fremtredende og krever ekstra brukerinteraksjon for å godkjenne en app fullt ut adgang.

Svaret på hvordan Android kan gi brukerne mer kontroll over filene sine, er å faktisk gi brukerne mer kontroll, ikke å ta den bort og fundamentalt begrense mulighetene til Android-plattformen.

---

Redaktørens merknad: Dette er en gjesteartikkel skrevet av XDA Senior Member tliebeck, mest kjent for sitt arbeid med FX File Explorer. Innholdet i denne artikkelen gjenspeiler hans egen mening og analyse av Android Qs Scoped Storage-begrensninger, med minimalt med input og redigering fra Mishaal Rahman, sjefredaktør for XDA-Developers. Vi tok kontakt med Google for å spørre dem om noen av disse bekymringene, men har ikke hørt tilbake fra selskapet innen publiseringstidspunktet.