Système de fichiers d'un appareil mobile : définition, structure des répertoires et fonctionnement

Qu'est-ce que le système de fichiers d'un appareil mobile ?

Le système de fichiers est un composant logiciel du système d'exploitation qui gère la façon dont les données sont écrites, lues et organisées sur le support physique. Sur les appareils mobiles, le système de fichiers remplit des fonctions cruciales : gestion de l'espace mémoire flash, contrôle d'accès aux fichiers basé sur les autorisations, journalisation des modifications pour la récupération après panne et optimisation des écritures tenant compte des spécificités de la mémoire flash NAND.

Contrairement aux systèmes d'exploitation de bureau, les systèmes de fichiers mobiles sont conçus en tenant compte du nombre limité de cycles de réécriture de la mémoire flash. Les cellules NAND supportent un nombre limité d'opérations d'effacement — de 3 000 à 10 000 cycles pour les mémoires TLC et MLC respectivement. Pour prolonger la durée de vie du stockage, les systèmes de fichiers utilisent des mécanismes d'usure uniforme (wear leveling) et des commandes TRIM. F2FS, développé par Samsung spécifiquement pour la mémoire flash, prend en compte la géométrie de la matrice NAND et place les données de manière à minimiser la fragmentation et le nombre d'opérations d'effacement de blocs.

Les appareils mobiles modernes utilisent une combinaison de plusieurs systèmes de fichiers. La mémoire interne (partition /data) est formatée en EXT4 ou F2FS sur Android et en APFS sur iOS. Les cartes SD utilisent traditionnellement exFAT pour les fichiers de plus de 4 Go ou FAT32 pour une compatibilité maximale. La partition /system sur Android est souvent montée en lecture seule et utilise EXT4 ou EROFS (Enhanced Read-Only File System) — un système de fichiers compressé développé par Huawei pour réduire la taille de la partition système.

Structure des répertoires sur Android

La hiérarchie des répertoires d'Android est basée sur la structure Linux avec la racine à /. Chaque partition a son propre système de fichiers, ses droits d'accès et son objectif. Une application ne peut accéder qu'à un ensemble limité de répertoires — le reste est protégé par les droits root.

Partition /data et bac à sable des applications

La partition /data est la partition principale pour stocker les données utilisateur, les applications installées et leurs paramètres. Chaque application reçoit son propre répertoire à l'adresse /data/data/<package_name>/. Dans ce répertoire, le système crée automatiquement des sous-répertoires : files/ pour les fichiers de l'application, cache/ pour les fichiers temporaires, databases/ pour les bases de données SQLite, shared_prefs/ pour SharedPreferences. Les droits d'accès à ce répertoire sont définis lors de l'installation de l'application et ne peuvent pas être modifiés sans accès root. La partition /data est formatée en F2FS sur la plupart des appareils modernes, offrant une vitesse d'écriture aléatoire jusqu'à 40% supérieure à celle de l'EXT4.

Partition /system et composants système

La partition /system contient le système d'exploitation, les applications système et les bibliothèques. Cette partition est montée en lecture seule pour empêcher toute modification accidentelle ou malveillante des fichiers système. Sur les appareils avec Android 10+ et Project Treble, la partition /system est dynamique et peut être mise à jour via des paquets OTA sans nécessiter de reflashage complet. Pour les applications, la partition /system est inaccessible — toute tentative d'écriture déclenchera une SecurityException. Cependant, les applications peuvent lire certains fichiers de /system, comme les polices système et les fichiers de configuration, si elles disposent des autorisations appropriées.

Point de montage /sdcard

Le point de montage /sdcard est un lien symbolique vers la partition de stockage externe émulée ou physique. Sur les appareils sans carte SD, /sdcard pointe vers une sous-partition dans /data désignée pour l'accès partagé. Cette partition est visible pour l'utilisateur lorsque l'appareil est connecté à un ordinateur via le protocole MTP. Les applications accèdent à /sdcard via les autorisations READ_EXTERNAL_STORAGE et WRITE_EXTERNAL_STORAGE, et à partir d'Android 10, via Scoped Storage à l'aide de l'API MediaStore. La taille de /sdcard représente généralement 60 à 80% de la mémoire flash totale, le reste étant réservé à la partition /data.

Structure des répertoires sur iOS

Sous iOS, le système de fichiers est organisé via des conteneurs Sandbox d'applications. Chaque application reçoit un répertoire isolé dont l'accès est restreint au niveau du noyau XNU. La partition utilisateur utilise l'APFS (Apple File System), introduit dans iOS 10.3. L'APFS prend en charge les instantanés, le clonage de fichiers et le chiffrement au niveau fichier, ce qui le rend optimal pour les appareils mobiles.

Répertoires standards du conteneur Sandbox

Un conteneur Sandbox iOS comprend quatre répertoires principaux : Documents, Library, tmp et SystemData. Chaque répertoire a sa propre politique de sauvegarde, sa durée de conservation des données et son niveau d'accès. Documents est automatiquement inclus dans les sauvegardes iCloud et iTunes. Library contient les sous-répertoires Caches (non sauvegardé), Preferences (sauvegardé) et Application Support (sauvegardé). Le répertoire tmp est destiné aux fichiers temporaires qu'iOS peut supprimer en cas de manque d'espace — il n'est pas inclus dans les sauvegardes. SystemData est utilisé par le système lui-même et est inaccessible aux applications via les API standard.

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!

Chaque répertoire du conteneur Sandbox a sa propre classe de protection. iOS prend en charge quatre classes : Protection complète (fichier inaccessible lorsque l'appareil est verrouillé), Protégé sauf si ouvert (fichiers déjà ouverts accessibles lors du verrouillage), Protégé jusqu'à la première authentification utilisateur (fichiers accessibles après le premier déverrouillage) et Aucune protection (fichiers toujours accessibles après le démarrage de l'appareil). Par défaut, tous les fichiers dans Documents et Library reçoivent la classe Protection complète, garantissant une protection maximale des données utilisateur. Lors de la création d'un fichier, vous pouvez spécifier explicitement une classe de protection différente si une application en arrière-plan doit accéder aux données pendant que l'appareil est verrouillé.

Droits d'accès et sécurité du système de fichiers

Le contrôle d'accès aux fichiers sur les appareils mobiles est une différence clé entre Android et iOS. Android utilise le modèle classique de permissions Linux (lecture, écriture, exécution) avec des extensions pour l'isolation des applications. iOS utilise un modèle Sandbox plus strict, où chaque application s'exécute dans un conteneur isolé et n'a pas accès aux fichiers des autres applications sans mécanismes spéciaux.

Permissions sur Android

Sous Android, chaque application s'exécute avec un UID (User ID) distinct. Tous les fichiers créés par une application dans son bac à sable appartiennent à cet UID et sont invisibles pour les autres applications. Pour accéder aux répertoires partagés (stockage externe), l'application doit demander les autorisations READ_EXTERNAL_STORAGE et WRITE_EXTERNAL_STORAGE. À partir d'Android 11, les autorisations doivent être demandées à l'exécution, et une application avec targetSdkVersion 30+ doit utiliser SAF pour accéder aux fichiers d'autres applications. La violation du modèle d'autorisation entraîne une SecurityException, qui est gérée par un bloc try-catch standard. Google Play vérifie automatiquement la conformité de l'application à la politique d'autorisations avant la publication.

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

Sandbox iOS et Keychain

Le Sandbox iOS est implémenté au niveau du noyau XNU et ne permet pas à l'application de quitter son conteneur. Même si l'application obtient un accès à un URI de fichier externe via Document Picker, le système d'exploitation crée une copie temporaire dans le conteneur de l'application plutôt que de fournir un accès direct à l'original. Pour le partage de fichiers entre applications, iOS utilise les mécanismes Share Sheet et UIActivityViewController, qui copient un fichier du conteneur d'une application vers celui d'une autre. Pour le stockage sécurisé des identifiants (jetons, mots de passe, clés), iOS fournit Keychain — un stockage chiffré accessible au système au niveau du noyau. Keychain ne fait pas partie du conteneur Sandbox et est géré par un démon securityd distinct, offrant une couche de protection supplémentaire même en cas de compromission de l'application.

Caractéristiques des systèmes de fichiers : EXT4, APFS, F2FS

Le choix du système de fichiers affecte directement les performances et la fiabilité du stockage. Chaque système de fichiers a sa propre architecture, ses optimisations et ses limites. Il est utile pour un développeur de comprendre ces différences afin de prédire le comportement de l'application sur différents appareils.

• EXT4 — un système de fichiers Linux standard avec journalisation, prenant en charge des fichiers jusqu'à 16 To et des volumes jusqu'à 1 Eo. Utilisé sur Android comme système principal avant l'adoption de F2FS. Offre une fiabilité grâce à la journalisation, mais est inférieur à F2FS en vitesse d'écriture aléatoire en raison de la nécessité de mettre à jour les inodes et les bitmaps de blocs à chaque opération
• F2FS — un système de fichiers développé par Samsung en 2012 spécifiquement pour la mémoire flash NAND. Prend en compte la géométrie de la matrice flash, utilise une architecture structurée en journal et offre des performances d'écriture aléatoire 25 à 40% supérieures à celles d'EXT4. À partir d'Android 11, Google recommande F2FS comme système de fichiers principal pour la partition /data
• APFS — le système de fichiers d'Apple introduit en 2017. Prend en charge les instantanés, le clonage de fichiers (copie sur écriture), le chiffrement au niveau fichier et un contrôle strict de l'intégrité des données via des sommes de contrôle. APFS est optimisé pour les SSD et utilise des commandes TRIM pour maintenir les performances tout au long de la durée de vie du stockage
• exFAT — le système de fichiers de Microsoft utilisé sur les cartes SD et les clés USB. Prend en charge les fichiers de plus de 4 Go et les volumes jusqu'à 128 Po. N'a pas de journalisation, donc une coupure soudaine de courant peut entraîner une corruption des données. Recommandé pour les supports amovibles, mais pas pour les partitions système

Lors du développement d'applications, gardez à l'esprit que différents systèmes de fichiers ont des limites de longueur de nom de fichier différentes (255 octets pour EXT4 et F2FS, 255 caractères Unicode pour APFS), une taille de fichier maximale et une prise en charge des caractères spéciaux. Par exemple, APFS autorise les caractères Unicode dans les noms de fichiers, y compris les emojis, tandis qu'EXT4 est limité à l'ASCII. Si votre application crée des fichiers avec des noms dans différentes langues, testez sur tous les appareils cibles — un nom de fichier correctement créé sur APFS peut être tronqué sur EXT4.

Recommandations pour travailler avec le système de fichiers

Un travail fiable avec le système de fichiers de l'appareil mobile nécessite de suivre plusieurs règles clés. Elles sont basées sur l'analyse des erreurs typiques des développeurs et les recommandations de la documentation officielle.

• N'utilisez pas de chemins codés en dur vers les répertoires. Obtenez toujours les chemins via les API système : context.filesDir sur Android, NSSearchPathForDirectoriesInDomains sur iOS. Les chemins codés en dur changent entre les versions d'OS et les appareils
• Gérez les exceptions des opérations sur les fichiers : IOException, FileNotFoundException, SecurityException. Sous iOS, toutes les opérations FileManager peuvent générer des erreurs — enveloppez-les dans un bloc do-catch. Sous Android, les opérations avec le stockage externe peuvent échouer en raison de l'absence de support
• Vérifiez l'espace disponible avant d'écrire. Utilisez File.getUsableSpace() sur Android et URLResourceValues.volumeAvailableCapacityKey sur iOS. Avertissez l'utilisateur si l'espace libre est insuffisant
• Évitez de stocker de gros fichiers dans les répertoires inclus dans les sauvegardes. Sous iOS, excluez le cache de la sauvegarde via isExcludedFromBackup. Sous Android, préférez cacheDir pour les fichiers temporaires
• Testez le comportement en cas de débordement de stockage et de coupure soudaine de courant. Utilisez l'écriture transactionnelle : écrivez dans un fichier temporaire, puis renommez atomiquement

Portez une attention particulière aux différences multiplateformes. Les chemins de fichiers sur Android utilisent des barres obliques (/data/data/.../files/), sur iOS — un schéma d'URL (file:///var/mobile/.../Documents/). Si votre application utilise un framework multiplateforme (Flutter, React Native, Kotlin Multiplatform), unifiez les opérations sur les fichiers via des adaptateurs de plateforme. Par exemple, Flutter fournit le package path_provider, qui renvoie le chemin correct vers Documents ou filesDir sur les deux plateformes sans écrire de code spécifique à la plateforme. Ne concaténez jamais les chemins avec des opérations de chaîne — utilisez File.join() ou URL.appendingPathComponent(), qui gèrent correctement les séparateurs sur différentes plateformes.