Scoped Storage i Android Q tvingar utvecklare att använda SAF, vilket suger

Android Q förändrar i grunden hur lagring fungerar på din telefon. I varje version upp till Pie fungerade Androids lagring som en stationär dator: du kan använda vilken app du vill läsa eller skriva vilken fil som helst (om du ger en app behörighet att göra det). Med Q introducerar (och kräver) Google "Räckvidd förvaring", vilket gör att Android fungerar mer som en iPhone, där lagringen är isolerad till varje app. En app kan bara komma åt sina egna filer, och om den avinstalleras raderas alla dess filer.

Tack och lov behåller Android Q fortfarande en del av Androids ursprungliga beteende i ett centralt filsystem. Tyvärr är det nu besvärligt för användaren att konfigurera appar för att komma åt det och har avsevärt minskad prestanda och kapacitet. Och utvecklare kommer att behöva koda om appar avsevärt för att stödja det.

Appar som behöver allmän filsystemåtkomst, t.ex. en kontorssvit, bildredigerare eller filhanterare måste nu använda ett Android-API som kallas "

Storage Access Framework" (SAF), för alla filoperationer. SAF har varit tillgängligt sedan Android 5.0 Lollipop, men utvecklare tenderar att inte använda det om det inte krävs, eftersom det har en svår och dålig dokumenterat API, en dålig användarupplevelse, dålig prestanda och dålig tillförlitlighet (till stor del i form av enhetsleverantörsspecifik implementering frågor). Som ett resultat av svårigheten att gå över till SAF har Google beslutat att tillåta appar som ännu inte anger Android Q-stöd ska fungera som de brukade, men detta ändras när Play Butik kräver att alla appar stöder Q nästa år.

Den mest uppenbara förändringen för användarna med SAF är upplevelsen av att ge en app tillgång till lagring. För att en app ska få åtkomst gör den en begäran till operativsystemet, som sedan visar en katalogväljarskärm. På den här skärmen väljer användaren roten till en mapphierarki där den appen kommer att kunna läsa och skriva filer. Användaren måste gå igenom denna process för varje app som kräver åtkomst till lokala filer, eller två gånger per app om de också behöver ge den åtkomst till ett externt SD-kort.

Google förbättrade åtminstone denna process för Q beta 3, eftersom tidigare betaversioner inte tillät en app ens att föreslå en plats för användaren att välja, vilket krävde att användaren gjorde en hel del arbete för att faktiskt hitta enhetens primära lagringsutrymme.

Fil I/O-prestanda tar något av en träff under SAF, men det mest framstående problemet ligger i filen katalogoperationer, där det är ~25 till 50 gånger långsammare än den konventionella filåtkomst som är möjlig i Paj. När det gäller filhanterare betyder det att det kommer att ta storleksordningar längre tid att utföra sökningar och beräkningar av lagringsanvändning. En felrapport med en demonstrationsapp är tillgänglig här.

Ett ännu större prestandaproblem är att vissa appar måste kopiera filer till sitt lokala "avgränsade lagringsutrymme" innan de kan arbeta med dem. Detta kan vara problematiskt när sådana filer är flera gigabyte stora, t.ex. när det gäller videofiler eller komprimerade arkiv. Många Android-appar drar nytta av det fantastiska antalet Java-bibliotek med öppen källkod i utvecklargemenskapen, och dessa bibliotek kräver vanligtvis direkt filsystemåtkomst för att fungera. De är inte Android-specifika och skulle behöva skrivas om för att fungera med SAF. Ännu värre, många av Androids egna interna bibliotek fungerar inte med det, till exempel pakethanteraren eller zip API. Till exempel kommer en filhanterare inte ens att kunna visa ikonen för en APK-fil (med standard Android API) utan att först kopiera hela APK-filen till sitt eget lagringsområde. Buggrapport.

För tekniskt inställda människor är det för närvarande möjligt att inaktivera Android Q: s "Scoped Storage" per app via ADB med hjälp av ett appops-kommando. Rotanvändare kan utföra kommandona direkt på sin enhet utan en stationär dator. Sådana kommandon beskrivs i dokumentationen som utvecklarfunktioner och kan därför tas bort när som helst.

Aktivera allmän lagringsåtkomst för en app:

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

Inaktivera allmän lagringsåtkomst för en app:

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

Google talar om säkerhets- och integritetsfördelarna med denna förändring, men tekniskt sett finns det ingen förbättring. Appar har haft möjligheten att privat lagra filer sedan Android 1.0, och nästan alla appar använder sig av denna funktion. När du ger en app åtkomst till rotkatalogen för din lagring via SAF kan den läsa, skriva och skicka vilken fil som helst vill till sin skändliga utvecklare på exakt samma sätt som det kunde när du gav en app tillgång till lagring i Pie.

Den enda "säkerhetsförbättringen" kommer till stånd eftersom det nu är en mer mödosam process för en användare att göra detta. Såvida inte en app bara vill stjäla din mest personliga information, som foton och videor du har tagen, för vilken Google har lagt till en alternativ åtkomstlösning som använder en enkel popup-klick-ja-säkerhet dialog.

Det är inte känt vilka fördelar Google hoppas uppnå med denna förändring. Det officiella skälet i Android Q betadokumentation är att "ge användarna mer kontroll över sina filer och att begränsa filen röran." Omfattad lagring, i sin nuvarande form, är en ny begränsning av vad användaren får göra, inte en förlängning av deras kontrollera. Påståendet om att minska röran kan vara något giltigt, men bara för att förändringen minskar möjligheten att använda filer överhuvudtaget. Och "röran" ökar när du tänker på problemet med att vissa appar nu måste duplicera filer för att fungera med dem.

Om Google verkligen är oroad över att ge användarna mer kontroll över filer och röran, borde de skapa en lösning som direkt adresserar det, snarare än att felaktigt märka den nuvarande Android Q-designen som sådan förbättring. Det enklaste svaret skulle vara att låta användare bestämma om de vill att en app ska ha scoped eller generell filsystemåtkomst, med hjälp av den befintliga lagringsbehörighetsbegäran. Om det finns en särskild oro för användare som fattar dåliga beslut här, är det säkert möjligt att göra det göra den dialogrutan mer framträdande och kräva ytterligare användarinteraktion för att godkänna en app fullt ut tillgång.

Svaret på hur Android kan ge användarna mer kontroll över sina filer är att faktiskt ge användarna mer kontroll, inte att ta bort den och i grunden begränsa kapaciteten hos Android-plattformen.

---

Redaktörens anmärkning: Detta är en gästartikel skriven av XDA Senior Member tliebeck, mest känd för sitt arbete på FX File Explorer. Innehållet i den här artikeln återspeglar hans egen åsikt och analys av Android Q: s begränsningar för lagringsutrymme, med minimal input och redigering från Mishaal Rahman, chefredaktör för XDA-Developers. Vi kontaktade Google för att fråga dem om några av dessa problem men har inte hört något från företaget vid publiceringstidpunkten.