Die Scoped Storage-Änderungen in Android Q bereiten Kopfzerbrechen, da das Storage Access Framework derzeit einige Mängel aufweist.
Android Q verändert die Art und Weise, wie der Speicher auf Ihrem Telefon funktioniert, grundlegend. In allen Versionen bis hin zu Pie funktionierte der Speicher von Android wie ein Desktop-Computer: Sie können jede beliebige App verwenden, um jede beliebige Datei zu lesen oder zu schreiben (sofern Sie einer App die Berechtigung dazu erteilen). Mit Q führt (und fordert) Google „Bereichsgebundener Speicher„Dadurch funktioniert Android eher wie ein iPhone, bei dem der Speicher für jede App isoliert ist. Eine App kann nur auf ihre eigenen Dateien zugreifen. Wenn sie deinstalliert wird, werden alle ihre Dateien gelöscht.
Glücklicherweise behält Android Q immer noch einen Teil des ursprünglichen Android-Verhaltens eines zentralen Dateisystems bei. Leider ist es für den Benutzer jetzt umständlich, Apps für den Zugriff einzurichten, und die Leistung und Funktionalität ist erheblich eingeschränkt. Und Entwickler müssen Apps erheblich neu programmieren, um dies zu unterstützen.
Apps, die allgemeinen Dateisystemzugriff benötigen, z. B. Eine Office-Suite, ein Bildeditor oder ein Dateimanager muss jetzt eine Android-API namens „Speicherzugriffs-Framework" (SAF), für alle Dateioperationen. SAF ist seit Android 5.0 Lollipop verfügbar, aber Entwickler neigen dazu, es nur dann zu verwenden, wenn es erforderlich ist, da es schwierig und schlecht ist dokumentierte API, eine schlechte Benutzererfahrung, schlechte Leistung und schlechte Zuverlässigkeit (größtenteils in Form einer geräteherstellerspezifischen Implementierung). Probleme). Aufgrund der Schwierigkeiten bei der Umstellung auf SAF hat Google beschlossen, Apps zuzulassen, die dies noch nicht anzeigen Die Android-Q-Unterstützung funktioniert wie gewohnt, aber das wird sich ändern, wenn der Play Store verlangt, dass alle Apps Q unterstützen nächstes Jahr.
Die offensichtlichste benutzerseitige Änderung bei SAF ist die Erfahrung, einer App Zugriff auf den Speicher zu gewähren. Damit eine App Zugriff erhält, stellt sie eine Anfrage an das Betriebssystem, das dann einen Bildschirm zur Verzeichnisauswahl anzeigt. Auf diesem Bildschirm wählt der Benutzer den Stamm einer Ordnerhierarchie aus, in der diese App Dateien lesen und schreiben kann. Der Benutzer muss diesen Vorgang für jede App durchlaufen, die Zugriff auf lokale Dateien benötigt, oder zweimal pro App, wenn er ihr auch Zugriff auf eine externe SD-Karte gewähren muss.
Google hat diesen Prozess zumindest verbessert Q Beta 3, da frühere Betas es einer App nicht einmal erlaubten, dem Benutzer einen Ort zur Auswahl vorzuschlagen erforderte vom Benutzer einiges an Arbeit um tatsächlich den Primärspeicher ihres Geräts zu finden.
Die Datei-E/A-Leistung wird unter SAF etwas beeinträchtigt, aber das größte Problem liegt bei der Datei Verzeichnisoperationen, wo es etwa 25 bis 50 Mal langsamer ist als der herkömmliche Dateizugriff, der möglich ist Kuchen. Im Fall von Dateimanagern bedeutet das, dass die Durchführung von Suchvorgängen und Speichernutzungsberechnungen um Größenordnungen länger dauert. Ein Fehlerbericht mit einer Demonstrations-App ist hier verfügbar.
Ein noch größeres Leistungsproblem besteht darin, dass einige Apps Dateien in ihren lokalen „Scoped Storage“-Bereich kopieren müssen, bevor sie mit ihnen arbeiten können. Dies kann problematisch sein, wenn solche Dateien mehrere Gigabyte groß sind, z.B. im Fall von Videodateien oder komprimierten Archiven. Viele Android-Apps nutzen die erstaunliche Anzahl von Open-Source-Java-Bibliotheken in der Entwickler-Community, und diese Bibliotheken erfordern in der Regel direkten Zugriff auf das Dateisystem, um zu funktionieren. Sie sind nicht Android-spezifisch und müssten neu geschrieben werden, um mit SAF zu funktionieren. Schlimmer noch: Viele der internen Android-Bibliotheken funktionieren damit nicht, etwa der Paketmanager oder die Zip-API. Beispielsweise kann ein Dateimanager nicht einmal das Symbol für eine APK-Datei anzeigen (unter Verwendung der Standard-Android-API), ohne zuerst das gesamte APK in seinen eigenen Speicherbereich zu kopieren. Fehlerbericht.
Für technisch versierte Leute ist es derzeit möglich, den „Scoped Storage“ von Android Q auf App-Basis über ADB mit einem appops-Befehl zu deaktivieren. Root-Benutzer können die Befehle ohne Desktop-Computer direkt auf ihrem Gerät ausführen. Solche Befehle werden in der Dokumentation als Entwicklerfunktionen beschrieben und können daher jederzeit entfernt werden.
Aktivieren Sie den allgemeinen Speicherzugriff für eine App:
adb shell cmd appops set your-package-name android: legacy_storage allow && \adb shell am force-stop your-package-nameDeaktivieren Sie den allgemeinen Speicherzugriff für eine App:
adb shell cmd appops set your-package-name android: legacy_storage default && \adb shell am force-stop your-package-nameGoogle wirbt mit den Sicherheits- und Datenschutzvorteilen dieser Änderung, aber technisch gesehen gibt es keine Verbesserung. Apps haben seit Android 1.0 die Möglichkeit, Dateien privat zu speichern, und fast alle Apps nutzen diese Funktion. Wenn Sie einer App über SAF Zugriff auf das Stammverzeichnis Ihres Speichers gewähren, kann sie jede darin enthaltene Datei lesen, schreiben und senden möchte seinen ruchlosen Entwickler auf genau die gleiche Weise erreichen, wie er es könnte, wenn man einer App Zugriff auf den Speicher in Pie gewährt.
Die einzige „Sicherheitsverbesserung“ ergibt sich dadurch, dass dies für einen Benutzer jetzt ein schwierigerer Prozess ist. Es sei denn natürlich, eine App möchte nur Ihre persönlichsten Daten stehlen, etwa Ihre Fotos und Videos genommen, für die Google eine alternative Zugriffslösung hinzugefügt hat, die eine einfache Popup-Klick-Ja-Sicherheit verwendet Dialog.
Es ist nicht bekannt, welche Vorteile sich Google mit dieser Änderung erhofft. Der offiziell in der Beta-Dokumentation zu Android Q angegebene Grund besteht darin, „Benutzern mehr Kontrolle über ihre Dateien zu geben und die Dateigröße einzuschränken.“ Unordnung." Der bereichsbezogene Speicher stellt in seiner jetzigen Form eine neue Einschränkung dessen dar, was der Benutzer tun darf, und keine Erweiterung dessen Kontrolle. Die Behauptung, die Unordnung zu reduzieren, mag einigermaßen berechtigt sein, aber nur, weil die Änderung die Möglichkeit, Dateien überhaupt zu verwenden, einschränkt. Und die „Unordnung“ nimmt noch zu, wenn man bedenkt, dass einige Apps jetzt Dateien duplizieren müssen, um mit ihnen zu funktionieren.
Wenn es Google wirklich darum geht, den Nutzern mehr Kontrolle über Dateien und Unordnung zu geben, sollten sie eine entwickeln Lösung, die das direkt angeht, anstatt das aktuelle Android Q-Design fälschlicherweise als solches zu brandmarken Verbesserung. Die einfachste Antwort wäre, den Benutzern die Entscheidung zu überlassen, ob sie einer App eingeschränkten oder allgemeinen Dateisystemzugriff gewähren möchten, indem sie das Dialogfeld zur Anforderung vorhandener Speicherberechtigungen verwenden. Wenn hier besondere Bedenken bestehen, dass Benutzer schlechte Entscheidungen treffen, ist dies durchaus möglich Machen Sie diesen Dialog prominenter und erfordern Sie eine zusätzliche Benutzerinteraktion, um eine App vollständig zu genehmigen Zugang.
Die Antwort darauf, wie Android den Benutzern mehr Kontrolle über ihre Dateien geben kann, besteht darin, den Benutzern tatsächlich mehr Kontrolle zu geben, und nicht darin, sie wegzunehmen und die Funktionen der Android-Plattform grundlegend einzuschränken.
Anmerkung des Herausgebers: Dies ist ein Gastartikel, der von einem XDA-Senior-Mitglied verfasst wurde tliebeck, vor allem bekannt für seine Arbeit an FX-Datei-Explorer. Der Inhalt dieses Artikels spiegelt seine eigene Meinung und Analyse der Scoped Storage-Einschränkungen von Android Q wider, mit minimaler Eingabe und Bearbeitung durch Mishaal Rahman, Chefredakteur von XDA-Developers. Wir haben uns an Google gewandt, um sie zu einigen dieser Bedenken zu befragen, haben aber zum Zeitpunkt der Veröffentlichung noch keine Antwort vom Unternehmen erhalten.