Android hat sich im Laufe der Zeit weiterentwickelt und unterstützt eine Vielzahl von Speichergerätetypen und -funktionen. Alle Android-Versionen unterstützen Geräte mit herkömmlichem Speicher , einschließlich tragbarem und emuliertem Speicher. Tragbarer Speicher kann durch physische Medien wie eine SD-Karte oder USB bereitgestellt werden, die für die vorübergehende Datenübertragung/Dateispeicherung dienen. Das physische Medium kann über einen längeren Zeitraum beim 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 Emulationsschicht verfügbar gemacht wird, und ist seit Android 3.0 verfügbar.
Ab Android 6.0 unterstützt Android anpassbaren Speicher , der durch physische Medien wie eine SD-Karte oder USB bereitgestellt wird, der verschlüsselt und formatiert ist, um sich wie interner Speicher zu verhalten. Adoptable Storage kann alle Arten von Anwendungsdaten speichern.
Berechtigungen
Der Zugriff auf externen Speicher ist durch verschiedene Android-Berechtigungen geschützt. Ab Android 1.0 ist der Schreibzugriff durch die Berechtigung WRITE_EXTERNAL_STORAGE geschützt. Ab Android 4.1 ist der Lesezugriff durch die Berechtigung READ_EXTERNAL_STORAGE geschützt.
Ab Android 4.4 werden Eigentümer, Gruppe und Modus von Dateien auf externen Speichergeräten nun basierend auf der Verzeichnisstruktur synthetisiert. Dadurch können Apps ihre paketspezifischen Verzeichnisse im externen Speicher verwalten, ohne dass sie über die umfassende Berechtigung WRITE_EXTERNAL_STORAGE verfügen müssen. 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 durch die Einbindung von Rohspeichergeräten in einen FUSE-Daemon erreicht.
Ab Android 10 verwenden Apps, die auf Android 9 und niedriger abzielen, standardmäßig den Legacy-Speicher und können sich für isolierten Speicher entscheiden . Apps, die auf Android 10 abzielen und standardmäßig isolierten Speicher verwenden, können dies vorübergehend deaktivieren . Verwenden Sie das Manifestattribut requestLegacyExternalStorage , das das Speichermodell steuert, um den Standardstatus zu ändern.
Da sowohl die Berechtigungen READ_EXTERNAL_STORAGE als auch WRITE_EXTERNAL_STORAGE weich eingeschränkt sind und das Installationsprogramm die App nicht auf die Whitelist gesetzt hat, steuert die Berechtigung nur den Zugriff auf die akustischen und visuellen Sammlungen und keinen Zugriff auf die SD-Karte. 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 im Legacy-Modus ausgeführte App das nichtisolierte 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 den isolierten Speicher entscheidet, oder wenn sie auf Android 10 abzielt und sich abmeldet.
Der Whitelist-Status kann nur zum Zeitpunkt der Installation angegeben und nicht geändert werden, bis die App installiert wurde.
Weitere Informationen zum Festlegen der READ_EXTERNAL_STORAGE Berechtigung finden Sie unter setWhitelistedRestrictedPermissions() in der PackageInstaller.SessionParams- Klasse.
Android 13 führt granulare Medienberechtigungen ein, um Apps zu unterstützen, die auf Mediendateien zugreifen, die von anderen Apps erstellt wurden. Apps müssen eine oder mehrere der unter Granulare Medienberechtigungen aufgeführten granularen Medienberechtigungen anstelle der READ_EXTERNAL_STORAGE Berechtigung anfordern.
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 umfasst, muss die Plattform dynamisch Speicherzugriff gewähren, ohne bereits laufende Apps zu beenden oder neu zu starten. Dies geschieht durch die Beibehaltung von drei unterschiedlichen Ansichten aller bereitgestellten Speichergeräte:
-
/mnt/runtime/defaultwird Apps ohne besondere Speicherberechtigungen und dem Root-Namespace angezeigt, in dem sichadbdund andere Systemkomponenten befinden. -
/mnt/runtime/readwird Apps mitREAD_EXTERNAL_STORAGEangezeigt (Setzen SieLEGACY_STORAGEfür Android 10 ein) -
/mnt/runtime/writewird Apps mitWRITE_EXTERNAL_STORAGEangezeigt
Zum Zeitpunkt des Zygote-Forks erstellen wir einen Mount-Namespace für jede laufende App und binden den Mount an die entsprechende Anfangsansicht. Später, wenn Laufzeitberechtigungen erteilt werden, springt vold in den Mount-Namespace bereits laufender Apps und bind mountet die aktualisierte Ansicht an Ort und Stelle. Beachten Sie, dass eine Herabstufung der Berechtigung immer dazu führt, 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 zurückportiert. Der CTS-Test PermissionsHostTest kann verwendet werden, um das korrekte Kernelverhalten zu überprüfen.