Google is committed to advancing racial equity for Black communities. See how.
Diese Seite wurde von der Cloud Translation API übersetzt.
Switch to English

Lager

HAL-Symbol für externen Android-Speicher

Android hat sich im Laufe der Zeit weiterentwickelt, um eine Vielzahl von Speichergerätetypen und -funktionen zu unterstützen. Alle Versionen von Android unterstützen Geräte mit herkömmlichem Speicher , einschließlich tragbarem und emuliertem Speicher. Der tragbare Speicher kann über physische Medien wie eine SD-Karte oder USB bereitgestellt werden, dh für die temporäre Datenübertragung / Dateispeicherung. Das physische Medium kann über einen längeren Zeitraum im Gerät verbleiben, ist jedoch nicht an das Gerät gebunden und kann entfernt werden. SD-Karten sind seit Android 1.0 als tragbarer Speicher verfügbar. Android 6.0 hat USB-Unterstützung hinzugefügt. Emulierter Speicher wird bereitgestellt, indem ein Teil des internen Speichers über eine Emulationsebene verfügbar gemacht wird. Er ist seit Android 3.0 verfügbar.

Ab Android 6.0 unterstützt Android einen akzeptablen Speicher , der von physischen Medien wie einer SD-Karte oder USB bereitgestellt wird, die verschlüsselt und formatiert sind, um sich wie interner Speicher zu verhalten. Der anwendbare Speicher kann alle Arten von Anwendungsdaten speichern.

Berechtigungen

Der Zugriff auf externen Speicher wird durch verschiedene Android-Berechtigungen geschützt. Ab Android 1.0 ist der Schreibzugriff mit der WRITE_EXTERNAL_STORAGE geschützt. Ab Android 4.1 ist der Lesezugriff mit der READ_EXTERNAL_STORAGE geschützt.

Ab Android 4.4 werden Eigentümer, Gruppe und Modi von Dateien auf externen Speichergeräten jetzt basierend auf der Verzeichnisstruktur synthetisiert. Auf diese Weise können Apps ihre WRITE_EXTERNAL_STORAGE Verzeichnisse auf einem externen Speicher verwalten, ohne dass sie über die umfassende WRITE_EXTERNAL_STORAGE . Beispielsweise kann die App mit dem Paketnamen com.example.foo jetzt ohne Berechtigungen frei auf Android/data/com.example.foo/ auf externen Speichergeräten zugreifen. Diese synthetisierten Berechtigungen werden erreicht, indem Raw-Speichergeräte in einen FUSE-Daemon eingeschlossen werden.

Ab Android 10 können Apps, die auf Android 9 und niedriger abzielen, standardmäßig Legacy-Speicher verwenden und sich für isolierten Speicher entscheiden. Apps, die auf Android 10 abzielen und standardmäßig isolierten Speicher verwenden, können diesen vorübergehend deaktivieren . Verwenden Sie das Manifestattribut requestLegacyExternalStorage , das das Speichermodell steuert, um den Standardstatus zu ändern.

Da sowohl die READ_EXTERNAL_STORAGE als auch WRITE_EXTERNAL_STORAGE nur eingeschränkt verfügbar sind, steuert die Berechtigung den Zugriff auf die akustischen und visuellen Sammlungen ohne Zugriff auf die SD-Karte, wenn das Installationsprogramm die App nicht auf die Whitelist gesetzt hat. Dies gilt auch dann, wenn die App Legacy-Speicher anfordert. Weitere Informationen zu harten und weichen Einschränkungen finden Sie unter Harte und weiche Einschränkungen in Android 10 .

Wenn das Installationsprogramm die Berechtigung auf die Whitelist gesetzt hat, erhält eine App, die im Legacy-Modus ausgeführt wird, das nicht isolierte Berechtigungsverhalten. Die Berechtigung steuert den Zugriff auf die SD-Karte sowie die akustischen und visuellen Sammlungen. Dies geschieht, wenn die App entweder auf Android 9 oder niedriger abzielt und sich nicht für isolierten Speicher entscheidet, oder wenn sie auf Android 10 abzielt und sich abmeldet.

Der Whitelist-Status kann nur zur Installationszeit angegeben und erst geändert werden, wenn die App installiert wurde.

Weitere Informationen zum Festlegen der READ_EXTERNAL_STORAGE Berechtigung finden Sie unter setWhitelistedRestrictedPermissions() in der PackageInstaller.SessionParams- Klasse.

Laufzeitberechtigungen

Android 6.0 führt ein neues Laufzeitberechtigungsmodell ein , bei dem Apps bei Bedarf zur Laufzeit Funktionen anfordern. Da das neue Modell die Berechtigungen READ/WRITE_EXTERNAL_STORAGE , muss die Plattform dynamisch Speicherzugriff gewähren, ohne bereits ausgeführte Apps zu READ/WRITE_EXTERNAL_STORAGE oder neu zu starten. Dazu werden drei unterschiedliche Ansichten aller bereitgestellten Speichergeräte beibehalten:

  • /mnt/runtime/default wird Apps ohne spezielle Speicherberechtigungen und dem Root-Namespace adbd in dem sich adbd und andere Systemkomponenten befinden.
  • /mnt/runtime/read wird Apps mit READ_EXTERNAL_STORAGE ( LEGACY_STORAGE für Android 10 LEGACY_STORAGE )
  • /mnt/runtime/write wird Apps mit WRITE_EXTERNAL_STORAGE

Zur Zygote-Fork-Zeit erstellen wir für jede laufende App einen Mount-Namespace und binden Mount die entsprechende Anfangsansicht an ihren Platz. Später, wenn Laufzeitberechtigungen erteilt werden, springt vold in den Mount-Namespace bereits laufender Apps und bindet die aktualisierte Ansicht. Beachten Sie, dass Berechtigungs-Downgrades immer dazu führen, dass die App beendet wird.

Die zur Implementierung dieser Funktion verwendete setns() -Funktionalität erfordert mindestens Linux 3.8, Patches wurden jedoch erfolgreich auf Linux 3.4 setns() . Der PermissionsHostTest CTS-Test kann verwendet werden, um das korrekte Kernelverhalten zu überprüfen.