Bestandssysteem van een mobiel apparaat: wat het is, mappenstructuur en hoe het werkt

Wat is het bestandssysteem van een mobiel apparaat?

Bestandssysteem is een softwarecomponent van het besturingssysteem die beheert hoe gegevens worden geschreven, gelezen en georganiseerd op de fysieke drager. Op mobiele apparaten vervult het bestandssysteem kritisch belangrijke functies: beheer van de flashgeheugenruimte, toegangscontrole tot bestanden op basis van rechten, het loggen van wijzigingen voor herstel na storingen en optimalisatie van schrijfbewerkingen rekening houdend met de kenmerken van NAND-flashgeheugen.

In tegenstelling tot desktopbesturingssystemen worden mobiele bestandssystemen ontworpen rekening houdend met de beperkte levensduur van flashgeheugen. NAND-cellen zijn bestand tegen een beperkt aantal wiscycli — van 3.000 tot 10.000 cycli voor respectievelijk TLC- en MLC-geheugen. Om de levensduur van de opslag te verlengen, passen bestandssystemen wear leveling-mechanismen (slijtage-egalisatie) en TRIM-opdrachten toe. F2FS, door Samsung speciaal voor flashgeheugen ontwikkeld, houdt rekening met de geometrie van de NAND-matrix en plaatst gegevens zodanig dat fragmentatie en het aantal blokwisbewerkingen worden geminimaliseerd.

Moderne mobiele apparaten gebruiken een combinatie van meerdere bestandssystemen. Het interne geheugen (partitie /data) wordt op Android geformatteerd in EXT4 of F2FS en op iOS in APFS. SD-kaarten gebruiken traditioneel exFAT voor ondersteuning van bestanden groter dan 4 GB of FAT32 voor maximale compatibiliteit. De /system-partitie op Android wordt vaak alleen-lezen gemount en gebruikt EXT4 of EROFS (Enhanced Read-Only File System) — een gecomprimeerd bestandssysteem ontwikkeld door Huawei om de grootte van de systeempartitie te verkleinen.

Mapstructuur op Android

Mappenhiërarchie van Android is gebaseerd op de Linux-structuur met root in /. Elke partitie heeft zijn eigen bestandssysteem, toegangsrechten en doel. Een app heeft alleen toegang tot een beperkte set mappen — de rest wordt beschermd door root-rechten.

Partitie /data en sandbox van apps

Partitie /data is de hoofdpartitie voor het opslaan van gebruikersgegevens, geïnstalleerde apps en hun instellingen. Elke app krijgt een eigen map op het pad /data/data/<package_name>/. Binnen deze map maakt het systeem automatisch submappen aan: files/ voor app-bestanden, cache/ voor tijdelijke bestanden, databases/ voor SQLite-databases, shared_prefs/ voor SharedPreferences. De toegangsrechten tot deze map worden ingesteld bij de installatie van de app en kunnen niet worden gewijzigd zonder root-toegang. De /data-partitie wordt op de meeste moderne apparaten geformatteerd in F2FS, wat tot 40% hogere willekeurige schrijfsnelheid biedt in vergelijking met EXT4.

Partitie /system en systeemcomponenten

Partitie /system bevat het besturingssysteem, systeem-apps en bibliotheken. Deze partitie wordt alleen-lezen gemount om accidentele of kwaadwillige wijziging van systeembestanden te voorkomen. Op apparaten met Android 10+ en Project Treble is de /system-partitie dynamisch en kan deze worden bijgewerkt via OTA-pakketten zonder volledige herflashing. Voor apps is de /system-partitie ontoegankelijk — een schrijfpoging veroorzaakt een SecurityException. Apps kunnen echter sommige bestanden uit /system lezen, zoals systeemlettertypen en configuratiebestanden, als ze de juiste rechten hebben.

Koppelpunt /sdcard

Het koppelpunt /sdcard is een symbolische link naar de partitie van geëmuleerde of fysieke externe opslag. Op apparaten zonder SD-kaart verwijst /sdcard naar een subpartitie binnen /data die is gereserveerd voor gedeelde toegang. Deze partitie is zichtbaar voor de gebruiker wanneer het apparaat via MTP-protocol met de computer wordt verbonden. Apps krijgen toegang tot /sdcard via de machtigingen READ_EXTERNAL_STORAGE en WRITE_EXTERNAL_STORAGE, en vanaf Android 10 via Scoped Storage met behulp van de MediaStore API. De grootte van /sdcard bedraagt meestal 60–80% van het totale flashgeheugenvolume van het apparaat, de rest is gereserveerd voor de /data-partitie.

Mapstructuur op iOS

Op iOS is het bestandssysteem georganiseerd via Sandbox-containers van apps. Elke app krijgt een geïsoleerde map waarvan de toegang is beperkt op het niveau van de XNU-kernel. De gebruikerspartitie gebruikt het bestandssysteem APFS (Apple File System), geïntroduceerd in iOS 10.3. APFS ondersteunt snapshots, bestandsklonen en versleuteling op bestandsniveau, wat het optimaal maakt voor mobiele apparaten.

Standaardmappen van de Sandbox-container

De Sandbox-container van iOS bevat vier hoofdmappen: Documents, Library, tmp en SystemData. Elke map heeft zijn eigen back-upbeleid, bewaartermijn van gegevens en toegangsniveau. Documents wordt automatisch opgenomen in iCloud- en iTunes-back-ups. Library bevat submappen Caches (geen back-up), Preferences (wel back-up) en Application Support (wel back-up). De tmp-map is bedoeld voor tijdelijke bestanden — iOS kan deze verwijderen bij ruimtegebrek en wordt niet opgenomen in back-ups. SystemData wordt door het systeem zelf gebruikt en is niet toegankelijk voor de app via standaard API's.

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!

Elke map van de Sandbox-container heeft zijn eigen beveiligingsklasse (protection class). iOS ondersteunt vier klassen: Complete Protection (bestand ontoegankelijk bij vergrendeld apparaat), Protected Unless Open (reeds geopende bestanden toegankelijk bij vergrendeling), Protected Until First User Authentication (bestanden toegankelijk na eerste ontgrendeling) en No Protection (bestanden altijd toegankelijk na opstarten van het apparaat). Standaard krijgen alle bestanden in Documents en Library de klasse Complete Protection, wat maximale bescherming van gebruikersgegevens garandeert. Bij het aanmaken van een bestand kan expliciet een andere beveiligingsklasse worden opgegeven als een achtergrondapp toegang tot gegevens moet hebben wanneer het apparaat is vergrendeld.

Toegangsrechten en beveiliging van het bestandssysteem

Toegangsbeheer tot bestanden op mobiele apparaten is een belangrijk verschil tussen Android en iOS. Android gebruikt het klassieke Linux-model van toegangsrechten (lezen, schrijven, uitvoeren) met uitbreidingen voor app-isolatie. iOS past een strikter Sandbox-model toe, waarbij elke app in een geïsoleerde container draait en zonder speciale mechanismen geen toegang heeft tot bestanden van andere apps.

Machtigingen op Android

Op Android wordt elke app gestart met een aparte UID (User ID). Alle bestanden die door de app in zijn sandbox worden gemaakt, zijn eigendom van deze UID en zijn niet zichtbaar voor andere apps. Voor toegang tot gedeelde mappen (externe opslag) moet de app de machtigingen READ_EXTERNAL_STORAGE en WRITE_EXTERNAL_STORAGE aanvragen. Vanaf Android 11 moeten machtigingen tijdens runtime worden aangevraagd en een app met targetSdkVersion 30+ moet SAF gebruiken voor toegang tot bestanden van andere apps. Overtreding van het machtigingsmodel leidt tot een SecurityException, die wordt afgehandeld door een standaard try-catch-blok. Google Play controleert automatisch de naleving van het machtigingsbeleid door de app vóór publicatie.

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

Sandbox op iOS en Keychain

iOS Sandbox is geïmplementeerd op het niveau van de XNU-kernel en staat de app niet toe buiten zijn container te komen. Zelfs als de app via Document Picker toegang krijgt tot de URI van een extern bestand, maakt het besturingssysteem een tijdelijke kopie in de container van de app in plaats van directe toegang tot het origineel te bieden. Voor het delen van bestanden tussen apps gebruikt iOS de mechanismen Share Sheet en UIActivityViewController, die het bestand kopiëren van de container van de ene app naar de container van de andere. Voor veilige opslag van inloggegevens (tokens, wachtwoorden, sleutels) biedt iOS Keychain — een versleutelde opslag die toegankelijk is voor het systeem op kernelniveau. Keychain maakt geen deel uit van de Sandbox-container en wordt beheerd door een aparte securityd-daemon, wat een extra beveiligingslaag biedt, zelfs in het geval van compromittering van de app.

Kenmerken van bestandssystemen: EXT4, APFS, F2FS

De keuze van het bestandssysteem heeft directe invloed op de prestaties en betrouwbaarheid van gegevensopslag. Elk bestandssysteem heeft zijn eigen architectuur, optimalisaties en beperkingen. Het is nuttig voor een ontwikkelaar om deze verschillen te begrijpen om het gedrag van de app op verschillende apparaten te voorspellen.

• EXT4 — het standaard Linux-bestandssysteem met journaling, ondersteuning voor bestanden tot 16 TB en volumes tot 1 EB. Wordt op Android gebruikt als het belangrijkste systeem vóór de introductie van F2FS. Biedt betrouwbaarheid dankzij de journal, maar is inferieur aan F2FS wat betreft willekeurige schrijfsnelheid vanwege de noodzaak om inodes en blokbitmaps bij elke bewerking bij te werken
• F2FS — bestandssysteem ontwikkeld door Samsung in 2012 speciaal voor NAND-flashgeheugen. Houdt rekening met de geometrie van de flash-matrix, gebruikt een log-gestructureerde architectuur en biedt 25–40% hogere willekeurige schrijfprestaties in vergelijking met EXT4. Vanaf Android 11 wordt F2FS door Google aanbevolen als het primaire bestandssysteem voor de /data-partitie
• APFS — het bestandssysteem van Apple, geïntroduceerd in 2017. Ondersteunt snapshots, bestandsklonen (copy-on-write), versleuteling op bestandsniveau en strikte integriteitscontrole via controlesommen. APFS is geoptimaliseerd voor SSD's en gebruikt TRIM-opdrachten om de prestaties gedurende de hele levensduur van de opslag te behouden
• exFAT — het bestandssysteem van Microsoft, gebruikt op SD-kaarten en USB-schijven. Ondersteunt bestanden groter dan 4 GB en volumes tot 128 PB. Heeft geen journaling, dus een plotselinge stroomuitval kan leiden tot gegevensbeschadiging. Aanbevolen voor verwisselbare media, maar niet voor systeempartities

Houd bij het ontwikkelen van apps rekening met de verschillende beperkingen van de bestandsnaamlengte (255 bytes voor EXT4 en F2FS, 255 Unicode-tekens voor APFS), maximale bestandsgrootte en ondersteuning voor speciale tekens. APFS staat bijvoorbeeld Unicode-tekens toe in bestandsnamen, inclusief emoji's, terwijl EXT4 beperkt is tot ASCII. Als de app bestanden maakt met namen in verschillende talen, test dan de werking op alle doelapparaten — een bestandsnaam die correct is aangemaakt op APFS kan worden afgekapt op EXT4.

Aanbevelingen voor het werken met het bestandssysteem

Betrouwbaar werken met het bestandssysteem van een mobiel apparaat vereist het naleven van een aantal belangrijke regels. Deze zijn gebaseerd op analyse van typische fouten van ontwikkelaars en aanbevelingen uit de officiële documentatie.

• Gebruik geen hardgecodeerde paden naar mappen. Verkrijg paden altijd via systeem-API's: context.filesDir op Android, NSSearchPathForDirectoriesInDomains op iOS. Harde paden veranderen tussen versies van het besturingssysteem en apparaten
• Vang uitzonderingen af van bestandsbewerkingen: IOException, FileNotFoundException, SecurityException. Op iOS kunnen alle FileManager-bewerkingen fouten genereren — omhul ze met do-catch. Op Android kunnen bewerkingen met externe opslag mislukken door afwezigheid van de drager
• Controleer de beschikbare ruimte vóór het schrijven. Gebruik File.getUsableSpace() op Android en URLResourceValues.volumeAvailableCapacityKey op iOS. Waarschuw de gebruiker als er onvoldoende vrije ruimte is
• Vermijd het opslaan van grote bestanden in mappen die in back-ups worden opgenomen. Sluit op iOS de cache uit van back-up via isExcludedFromBackup. Geef op Android de voorkeur aan cacheDir voor tijdelijke bestanden
• Test het gedrag bij volle opslag en plotselinge stroomuitval. Gebruik transactioneel schrijven: schrijf naar een tijdelijk bestand en hernoem vervolgens atomair

Besteed speciale aandacht aan cross-platform verschillen. Bestandspaden op Android worden opgebouwd met een schuine streep (/data/data/.../files/), op iOS — via een URL-schema (file:///var/mobile/.../Documents/). Als uw app een multi-platformframework gebruikt (Flutter, React Native, Kotlin Multiplatform), uniformeer dan bestandsbewerkingen via platformadapters. Flutter biedt bijvoorbeeld het pakket path_provider, dat het juiste pad naar Documents of filesDir op beide platformen retourneert zonder platformspecifieke code te schrijven. Concateneer nooit paden met stringbewerkingen — gebruik File.join() of URL.appendingPathComponent(), die scheidingstekens op verschillende platformen correct afhandelen.