Dateisystem eines Mobilgeräts: Was es ist, Verzeichnisstruktur und wie es funktioniert

Was ist das Dateisystem eines Mobilgeräts?

Das Dateisystem ist eine Softwarekomponente des Betriebssystems, die verwaltet, wie Daten auf physischen Medien geschrieben, gelesen und organisiert werden. Auf mobilen Geräten erfüllt das Dateisystem kritisch wichtige Funktionen: Verwaltung des Flash-Speicherplatzes, dateibasierte Zugriffskontrolle basierend auf Berechtigungen, Journaling von Änderungen zur Wiederherstellung nach Abstürzen und Schreiboptimierung unter Berücksichtigung der Besonderheiten von NAND-Flash-Speicher.

Im Gegensatz zu Desktop-Betriebssystemen werden mobile Dateisysteme unter Berücksichtigung der begrenzten Anzahl von Überschreibzyklen des Flash-Speichers entwickelt. NAND-Zellen halten nur eine begrenzte Anzahl von Löschvorgängen aus — 3.000 bis 10.000 Zyklen für TLC- bzw. MLC-Speicher. Um die Lebensdauer des Speichers zu verlängern, verwenden Dateisysteme Wear-Leveling-Mechanismen und TRIM-Befehle. F2FS, das von Samsung speziell für Flash-Speicher entwickelt wurde, berücksichtigt die Geometrie des NAND-Arrays und platziert Daten so, dass Fragmentierung und die Anzahl der Blocklöschvorgänge minimiert werden.

Moderne Mobilgeräte verwenden eine Kombination aus mehreren Dateisystemen. Der interne Speicher (die /data-Partition) wird auf Android als EXT4 oder F2FS und auf iOS als APFS formatiert. SD-Karten verwenden traditionell exFAT für Dateien größer als 4 GB oder FAT32 für maximale Kompatibilität. Die /system-Partition auf Android wird oft schreibgeschützt eingehängt und verwendet EXT4 oder EROFS (Enhanced Read-Only File System) — ein komprimiertes Dateisystem, das von Huawei entwickelt wurde, um die Größe der Systempartition zu reduzieren.

Verzeichnisstruktur auf Android

Die Verzeichnishierarchie von Android basiert auf der Linux-Struktur mit dem Stammverzeichnis /. Jede Partition hat ihr eigenes Dateisystem, Zugriffsrechte und ihren eigenen Zweck. Eine Anwendung kann nur auf eine begrenzte Anzahl von Verzeichnissen zugreifen — der Rest ist durch Root-Berechtigungen geschützt.

/data-Partition und App-Sandbox

Die /data-Partition ist die Hauptpartition zum Speichern von Benutzerdaten, installierten Anwendungen und deren Einstellungen. Jede Anwendung erhält ihr eigenes Verzeichnis unter /data/data/<package_name>/. Innerhalb dieses Verzeichnisses erstellt das System automatisch Unterverzeichnisse: files/ für Anwendungsdateien, cache/ für temporäre Dateien, databases/ für SQLite-Datenbanken, shared_prefs/ für SharedPreferences. Die Zugriffsrechte auf dieses Verzeichnis werden bei der Installation der Anwendung festgelegt und können ohne Root-Zugriff nicht geändert werden. Die /data-Partition ist auf den meisten modernen Geräten als F2FS formatiert, was eine bis zu 40% höhere zufällige Schreibgeschwindigkeit im Vergleich zu EXT4 bietet.

/system-Partition und Systemkomponenten

Die /system-Partition enthält das Betriebssystem, Systemanwendungen und Bibliotheken. Diese Partition ist schreibgeschützt eingehängt, um unbeabsichtigte oder böswillige Änderungen an Systemdateien zu verhindern. Auf Geräten mit Android 10+ und Project Treble ist die /system-Partition dynamisch und kann über OTA-Pakete aktualisiert werden, ohne dass ein vollständiges Neuflashen erforderlich ist. Für Anwendungen ist die /system-Partition nicht zugänglich — ein Schreibversuch löst eine SecurityException aus. Anwendungen können jedoch einige Dateien aus /system lesen, wie Systemschriftarten und Konfigurationsdateien, wenn sie über die entsprechenden Berechtigungen verfügen.

/sdcard-Mountpunkt

Der /sdcard-Mountpunkt ist ein symbolischer Link auf die emulierte oder physische externe Speicherpartition. Auf Geräten ohne SD-Karte verweist /sdcard auf eine Unterpartition innerhalb von /data, die für gemeinsamen Zugriff vorgesehen ist. Diese Partition ist für den Benutzer sichtbar, wenn das Gerät über das MTP-Protokoll mit einem Computer verbunden ist. Anwendungen greifen auf /sdcard über die Berechtigungen READ_EXTERNAL_STORAGE und WRITE_EXTERNAL_STORAGE zu und ab Android 10 über Scoped Storage mit der MediaStore-API. Die Größe von /sdcard beträgt typischerweise 60–80% des gesamten Flash-Speichers, der Rest ist für die /data-Partition reserviert.

Verzeichnisstruktur auf iOS

Unter iOS ist das Dateisystem über Sandbox-Container von Anwendungen organisiert. Jede Anwendung erhält ein isoliertes Verzeichnis, dessen Zugriff auf der Kernel-Ebene von XNU eingeschränkt ist. Die Benutzerpartition verwendet das APFS (Apple File System), das mit iOS 10.3 eingeführt wurde. APFS unterstützt Snapshots, Dateikloning und dateibasierte Verschlüsselung, was es optimal für mobile Geräte macht.

Standardverzeichnisse des Sandbox-Containers

Ein iOS-Sandbox-Container enthält vier Hauptverzeichnisse: Documents, Library, tmp und SystemData. Jedes Verzeichnis hat seine eigene Backup-Richtlinie, Datenaufbewahrungsdauer und Zugriffsebene. Documents wird automatisch in iCloud- und iTunes-Backups einbezogen. Library enthält die Unterverzeichnisse Caches (nicht gesichert), Preferences (gesichert) und Application Support (gesichert). Das tmp-Verzeichnis ist für temporäre Dateien gedacht, die iOS bei Speichermangel löschen kann — es wird nicht in Backups einbezogen. SystemData wird vom System selbst genutzt und ist für Anwendungen über die Standard-APIs nicht zugänglich.

let fm = FileManager.default

let documents = fm.urls(
    for: .documentDirectory,
    in: .userDomainMask
).first!

let caches = fm.urls(
    for: .cachesDirectory,
    in: .userDomainMask
).first!

let appSupport = fm.urls(
    for: .applicationSupportDirectory,
    in: .userDomainMask
).first!

Jedes Sandbox-Container-Verzeichnis hat seine eigene Schutzklasse. iOS unterstützt vier Klassen: Vollständiger Schutz (Datei bei gesperrtem Gerät nicht zugänglich), Geschützt außer bei geöffneten Dateien (bereits geöffnete Dateien sind bei Sperrung zugänglich), Geschützt bis zur ersten Benutzerauthentifizierung (Dateien nach dem ersten Entsperren zugänglich) und Kein Schutz (Dateien nach Gerätestart immer zugänglich). Standardmäßig erhalten alle Dateien in Documents und Library die Klasse Vollständiger Schutz, was maximalen Schutz der Benutzerdaten gewährleistet. Beim Erstellen einer Datei kann explizit eine andere Schutzklasse angegeben werden, wenn eine Hintergrundanwendung bei gesperrtem Gerät auf Daten zugreifen muss.

Zugriffsrechte und Sicherheit des Dateisystems

Die Zugriffskontrolle auf Dateien auf mobilen Geräten ist ein Hauptunterschied zwischen Android und iOS. Android verwendet das klassische Linux-Berechtigungsmodell (Lesen, Schreiben, Ausführen) mit Erweiterungen zur Anwendungsisolierung. iOS verwendet ein strengeres Sandbox-Modell, bei dem jede Anwendung in einem isolierten Container ausgeführt wird und ohne spezielle Mechanismen keinen Zugriff auf Dateien anderer Anwendungen hat.

Berechtigungen auf Android

Unter Android wird jede Anwendung unter einer separaten UID (Benutzer-ID) ausgeführt. Alle von einer Anwendung in ihrer Sandbox erstellten Dateien gehören zu dieser UID und sind für andere Anwendungen unsichtbar. Für den Zugriff auf gemeinsame Verzeichnisse (externer Speicher) muss die Anwendung die Berechtigungen READ_EXTERNAL_STORAGE und WRITE_EXTERNAL_STORAGE anfordern. Ab Android 11 müssen Berechtigungen zur Laufzeit angefordert werden, und eine Anwendung mit targetSdkVersion 30+ muss SAF verwenden, um auf Dateien anderer Anwendungen zuzugreifen. Ein Verstoß gegen das Berechtigungsmodell führt zu einer SecurityException, die mit einem standardmäßigen try-catch-Block behandelt wird. Google Play überprüft automatisch die Einhaltung der Berechtigungsrichtlinien durch die Anwendung vor der Veröffentlichung.

if (ContextCompat.checkSelfPermission(
    context,
    Manifest.permission.READ_EXTERNAL_STORAGE
) != PackageManager.PERMISSION_GRANTED) {
    ActivityCompat.requestPermissions(
        activity,
        arrayOf(Manifest.permission.READ_EXTERNAL_STORAGE),
        REQUEST_CODE
    )
}

iOS-Sandbox und Keychain

Die iOS-Sandbox ist auf der XNU-Kernel-Ebene implementiert und erlaubt der Anwendung nicht, ihren Container zu verlassen. Selbst wenn eine Anwendung über den Document Picker Zugriff auf einen externen Datei-URI erhält, erstellt das Betriebssystem eine temporäre Kopie im Container der Anwendung, anstatt direkten Zugriff auf das Original zu gewähren. Zum Teilen von Dateien zwischen Anwendungen verwendet iOS die Mechanismen Share Sheet und UIActivityViewController, die eine Datei aus dem Container einer Anwendung in den einer anderen kopieren. Für die sichere Aufbewahrung von Anmeldeinformationen (Tokens, Passwörter, Schlüssel) bietet iOS die Keychain — einen verschlüsselten Speicher, der für das System auf Kernel-Ebene zugänglich ist. Die Keychain ist kein Teil des Sandbox-Containers und wird von einem separaten securityd-Daemon verwaltet, was selbst bei Kompromittierung der Anwendung eine zusätzliche Schutzebene bietet.

Eigenschaften von Dateisystemen: EXT4, APFS, F2FS

Die Wahl des Dateisystems wirkt sich direkt auf die Speicherleistung und -zuverlässigkeit aus. Jedes Dateisystem hat seine eigene Architektur, Optimierungen und Einschränkungen. Für einen Entwickler ist es hilfreich, diese Unterschiede zu verstehen, um das Verhalten der Anwendung auf verschiedenen Geräten vorherzusagen.

• EXT4 — ein standardmäßiges Linux-Dateisystem mit Journaling, das Dateien bis zu 16 TB und Volumes bis zu 1 EB unterstützt. Wird auf Android als primäres Dateisystem vor der Einführung von F2FS verwendet. Bietet Zuverlässigkeit durch Journaling, ist aber bei zufälliger Schreibgeschwindigkeit aufgrund der Notwendigkeit, Inodes und Blockbitmaps bei jedem Vorgang zu aktualisieren, F2FS unterlegen
• F2FS — ein von Samsung 2012 speziell für NAND-Flash-Speicher entwickeltes Dateisystem. Berücksichtigt die Geometrie des Flash-Arrays, verwendet eine logstrukturierte Architektur und bietet eine um 25–40% höhere zufällige Schreibleistung im Vergleich zu EXT4. Ab Android 11 empfiehlt Google F2FS als primäres Dateisystem für die /data-Partition
• APFS — das 2017 eingeführte Dateisystem von Apple. Unterstützt Snapshots, Dateikloning (Copy-on-Write), dateibasierte Verschlüsselung und strenge Datenintegritätskontrolle durch Prüfsummen. APFS ist für SSDs optimiert und verwendet TRIM-Befehle, um die Leistung während der gesamten Lebensdauer des Speichers zu erhalten
• exFAT — das von Microsoft verwendete Dateisystem auf SD-Karten und USB-Laufwerken. Unterstützt Dateien größer als 4 GB und Volumes bis zu 128 PB. Hat kein Journaling, daher kann ein plötzlicher Stromausfall zu Datenbeschädigung führen. Wird für Wechselmedien empfohlen, jedoch nicht für Systempartitionen

Bei der Entwicklung von Anwendungen beachten Sie, dass verschiedene Dateisysteme unterschiedliche Beschränkungen der Dateinamenlänge (255 Byte für EXT4 und F2FS, 255 Unicode-Zeichen für APFS), maximale Dateigröße und Unterstützung für Sonderzeichen haben. Beispielsweise erlaubt APFS Unicode-Zeichen in Dateinamen, einschließlich Emojis, während EXT4 auf ASCII beschränkt ist. Wenn Ihre Anwendung Dateien mit Namen in verschiedenen Sprachen erstellt, testen Sie auf allen Zielgeräten — ein auf APFS korrekt erstellter Dateiname kann auf EXT4 abgeschnitten werden.

Empfehlungen für die Arbeit mit dem Dateisystem

Die zuverlässige Arbeit mit dem Dateisystem eines Mobilgeräts erfordert die Einhaltung mehrerer Schlüsselregeln. Sie basieren auf der Analyse typischer Entwicklerfehler und Empfehlungen der offiziellen Dokumentation.

• Verwenden Sie keine fest codierten Pfade zu Verzeichnissen. Holen Sie Pfade immer über System-APIs ein: context.filesDir auf Android, NSSearchPathForDirectoriesInDomains auf iOS. Fest codierte Pfade ändern sich zwischen OS-Versionen und Geräten
• Behandeln Sie Ausnahmen von Dateioperationen: IOException, FileNotFoundException, SecurityException. Auf iOS können alle FileManager-Operationen Fehler auslösen — umschließen Sie sie mit do-catch. Auf Android können Operationen mit externem Speicher aufgrund fehlender Medien fehlschlagen
• Überprüfen Sie den verfügbaren Speicherplatz vor dem Schreiben. Verwenden Sie File.getUsableSpace() auf Android und URLResourceValues.volumeAvailableCapacityKey auf iOS. Warnen Sie den Benutzer, wenn nicht genügend freier Speicherplatz vorhanden ist
• Vermeiden Sie die Speicherung großer Dateien in Verzeichnissen, die in Backups einbezogen werden. Schließen Sie auf iOS den Cache mit isExcludedFromBackup vom Backup aus. Bevorzugen Sie auf Android cacheDir für temporäre Dateien
• Testen Sie das Verhalten bei Speicherüberlauf und plötzlichem Stromausfall. Verwenden Sie transaktionales Schreiben: Schreiben Sie in eine temporäre Datei und benennen Sie sie dann atomar um

Achten Sie besonders auf plattformübergreifende Unterschiede. Dateipfade auf Android verwenden Schrägstriche (/data/data/.../files/), auf iOS — URL-Schema (file:///var/mobile/.../Documents/). Wenn Ihre Anwendung ein plattformübergreifendes Framework (Flutter, React Native, Kotlin Multiplatform) verwendet, vereinheitlichen Sie Dateioperationen über Plattformadapter. Beispielsweise stellt Flutter das Paket path_provider bereit, das den korrekten Pfad zu Documents oder filesDir auf beiden Plattformen zurückgibt, ohne plattformspezifischen Code zu schreiben. Verketten Sie Pfade niemals mit String-Operationen — verwenden Sie File.join() oder URL.appendingPathComponent(), die Trennzeichen auf verschiedenen Plattformen korrekt behandeln.