Externer Speicher wird durch eine Kombination aus dem Dienst vold
init und dem Systemdienst StorageManagerService
verwaltet. Das Mounten physischer externer Speichervolumes wird von vold
gehandhabt, das Staging-Vorgänge durchführt, um die Medien vorzubereiten, bevor sie Apps zugänglich gemacht werden.
Hinweis: In Android 8.0 wurde die Klasse MountService
in StorageManagerService
umbenannt.
Dateizuordnungen
Für Android 4.2.2 und früher definiert die gerätespezifische vold.fstab
-Konfigurationsdatei Zuordnungen von sysfs-Geräten zu Dateisystem-Einhängepunkten, und jede Zeile folgt diesem Format:
dev_mount <label> <mount_point> <partition> <sysfs_path> [flags]
-
label
: Label für das Volume. -
mount_point
: Dateisystempfad, wo das Volume gemountet werden soll. -
partition
: Partitionsnummer (basierend auf 1) oder „auto“ für die erste nutzbare Partition. -
sysfs_path
: Ein oder mehrere sysfs-Pfade zu Geräten, die diesen Einhängepunkt bereitstellen können. Durch Leerzeichen getrennt, und jede muss mit/
beginnen. -
flags
: Optionale kommagetrennte Liste von Flags, darf kein/
enthalten. Mögliche Werte sindnonremovable
undencryptable
.
Für Android-Versionen 4.3 und höher wurden die verschiedenen fstab-Dateien, die von init, vold und recovery verwendet werden, in der Datei /fstab.<device>
vereinheitlicht. Für externe Speichervolumes, die von vold
verwaltet werden, sollten die Einträge das folgende Format haben:
<src> <mnt_point> <type> <mnt_flags> <fs_mgr_flags>
-
src
: Ein Pfad unter sysfs (normalerweise unter /sys gemountet) zu dem Gerät, das den Einhängepunkt bereitstellen kann. Der Pfad muss mit/
beginnen. -
mount_point
: Dateisystempfad, wo das Volume gemountet werden soll. -
type
: Der Typ des Dateisystems auf dem Volume. Bei externen Karten ist dies normalerweisevfat
. -
mnt_flags
:Vold
ignoriert dieses Feld und es sollte auf diedefaults
gesetzt werden -
fs_mgr_flags
:Vold
ignoriert alle Zeilen in der vereinheitlichten fstab, die dasvoldmanaged=
nicht in diesem Feld enthalten. Auf dieses Flag muss ein Label folgen, das die Karte beschreibt, sowie eine Partitionsnummer oder das Wortauto
. Hier ist ein Beispiel:voldmanaged=sdcard:auto
. Andere mögliche Flags sindnonremovable
,encryptable=sdcard
,noemulatedsd
undencryptable=userdata
.
Konfigurationsdetails
Externe Speicherinteraktionen auf und über der Frameworkebene werden über StorageManagerService
abgewickelt. Aufgrund von Konfigurationsänderungen in Android 6.0 (wie das Entfernen des Ressourcen-Overlays storage_list.xml) werden die Konfigurationsdetails in zwei Kategorien unterteilt.
Android 5.x und früher
Die gerätespezifische Konfigurationsdatei „ storage_list.xml
“, die normalerweise über ein frameworks/base
Overlay bereitgestellt wird, definiert die Attribute und Einschränkungen von Speichergeräten. Das <StorageList>
-Element enthält ein oder mehrere <storage>
-Elemente, von denen genau eines als primär markiert werden sollte. Zu den <storage>
-Attributen gehören:
-
mountPoint
: Dateisystempfad dieses Mounts. -
storageDescription
: Zeichenfolgenressource, die diesen Mount beschreibt. -
primary
: true, wenn dieser Mount der primäre externe Speicher ist. -
removable
: true , wenn diese Halterung über Wechselmedien verfügt, z. B. eine physische SD-Karte. -
emulated
: true, wenn dieser Mount emuliert und durch internen Speicher unterstützt wird, möglicherweise unter Verwendung eines FUSE-Daemons. -
mtp-reserve
: Anzahl MB Speicher, die MTP für freien Speicherplatz reservieren soll. Wird nur verwendet, wenn Mount als emuliert markiert ist. -
allowMassStorage
: true, wenn dieser Mount über einen USB-Massenspeicher geteilt werden kann. -
maxFileSize
: maximale Dateigröße in MB.
Geräte können externen Speicher bereitstellen, indem sie ein genehmigungsloses Dateisystem emulieren, bei dem die Groß-/Kleinschreibung nicht beachtet wird und das durch internen Speicher unterstützt wird. Eine mögliche Implementierung bietet der FUSE-Daemon in system/core/sdcard
, der als gerätespezifischer init.rc
-Dienst hinzugefügt werden kann:
# virtual sdcard daemon running as media_rw (1023) service sdcard /system/bin/sdcard <source_path> <dest_path> 1023 1023 class late_start
Wobei source_path
der unterstützende interne Speicher und dest_path
der Ziel-Mount-Punkt ist.
Beim Konfigurieren eines gerätespezifischen init.rc
-Skripts muss die Umgebungsvariable EXTERNAL_STORAGE
als Pfad zum primären externen Speicher definiert werden. Der /sdcard
Pfad muss ebenfalls zum selben Speicherort aufgelöst werden, möglicherweise über einen symbolischen Link. Wenn ein Gerät den Speicherort des externen Speichers zwischen Plattformaktualisierungen anpasst, sollten Symlinks erstellt werden, damit alte Pfade weiterhin funktionieren.
Android 6.0
Die Konfiguration des Speichersubsystems ist jetzt in der gerätespezifischen fstab
-Datei konzentriert, und mehrere historische statische Konfigurationsdateien/-variablen wurden entfernt, um ein dynamischeres Verhalten zu unterstützen:
- Das Ressourcen-Overlay „
storage_list.xml
“ wurde entfernt und wird nicht mehr vom Framework verwendet. Speichergeräte werden jetzt dynamisch konfiguriert, wenn sie vonvold
erkannt werden. - Die Umgebungsvariablen
EMULATED_STORAGE_SOURCE/TARGET
wurden entfernt und werden von Zygote nicht mehr verwendet, um benutzerspezifische Einhängepunkte zu konfigurieren. Stattdessen wird die Benutzertrennung jetzt mit benutzerspezifischen GIDs erzwungen, und der primäre gemeinsam genutzte Speicher wird zur Laufzeit vonvold
.- Entwickler können je nach Anwendungsfall weiterhin Pfade dynamisch oder statisch erstellen. Das Einfügen der UUID in den Pfad identifiziert jede Karte, um den Standort für Entwickler klarer zu machen. (Zum Beispiel ist
/storage/ABCD-1234/report.txt
eindeutig eine andere Datei als/storage/DCBA-4321/report.txt
.)
- Entwickler können je nach Anwendungsfall weiterhin Pfade dynamisch oder statisch erstellen. Das Einfügen der UUID in den Pfad identifiziert jede Karte, um den Standort für Entwickler klarer zu machen. (Zum Beispiel ist
- Die fest codierten FUSE-Dienste wurden aus gerätespezifischen
init.rc
-Dateien entfernt und werden stattdessen bei Bedarf dynamisch vonvold
gegabelt.
Zusätzlich zu diesen Konfigurationsänderungen enthält Android 6.0 den Begriff des anpassbaren Speichers. Bei Android 6.0-Geräten werden alle physischen Medien, die nicht übernommen werden, als portabel angesehen.
Annehmbarer Speicher
Verwenden Sie das Attribut encryptable=userdata
im Feld fs_mgr_flags , um ein verwendbares Speichergerät in der fstab
fs_mgr_flags
. Hier ist eine typische Definition:
/devices/platform/mtk-msdc.1/mmc_host* auto auto defaults voldmanaged=sdcard1:auto,encryptable=userdata
Wenn ein Speichergerät angenommen wird, löscht die Plattform den Inhalt und schreibt eine GUID-Partitionstabelle, die zwei Partitionen definiert:
- eine kleine leere
android_meta
Partition, die für die zukünftige Verwendung reserviert ist. Die GUID des Partitionstyps lautet 19A710A2-B3CA-11E4-B026-10604B889DCF. - eine große
android_ext
-Partition, die mit dm-crypt verschlüsselt und je nach Kernel-Fähigkeiten entweder mitext4
oderf2fs
formatiert wird. Die GUID des Partitionstyps lautet 193D1EA4-B3CA-11E4-B075-10604B889DCF.
Tragbarer Speicher
In der fstab
gelten Speichergeräte mit dem Attribut voldmanaged
standardmäßig als portabel, sofern kein anderes Attribut wie encryptable=userdata
definiert ist. Hier ist zum Beispiel eine typische Definition für USB-OTG-Geräte:
/devices/*/xhci-hcd.0.auto/usb* auto auto defaults voldmanaged=usb:auto
Die Plattform verwendet blkid
, um Dateisystemtypen vor dem Mounten zu erkennen, und Benutzer können das Medium formatieren, wenn das Dateisystem nicht unterstützt wird.