File system del dispositivo mobile: cos'è, struttura delle directory e come funziona

Cos'è il file system di un dispositivo mobile?

Il file system è un componente software del sistema operativo che gestisce come i dati vengono scritti, letti e organizzati sul supporto fisico. Sui dispositivi mobili, il file system svolge funzioni criticamente importanti: gestione dello spazio della memoria flash, controllo dell'accesso ai file basato sui permessi, registrazione delle modifiche per il recupero dopo i crash e ottimizzazione della scrittura considerando le specificità della memoria flash NAND.

A differenza dei sistemi operativi desktop, i file system mobili sono progettati considerando il numero limitato di cicli di riscrittura della memoria flash. Le celle NAND sopportano un numero limitato di operazioni di cancellazione — da 3.000 a 10.000 cicli rispettivamente per memorie TLC e MLC. Per prolungare la durata dell'archiviazione, i file system impiegano meccanismi di wear leveling (livellamento dell'usura) e comandi TRIM. F2FS, sviluppato da Samsung specificamente per la memoria flash, tiene conto della geometria dell'array NAND e posiziona i dati in modo da ridurre al minimo la frammentazione e il numero di operazioni di cancellazione dei blocchi.

I dispositivi mobili moderni utilizzano una combinazione di più file system. La memoria interna (partizione /data) è formattata come EXT4 o F2FS su Android e APFS su iOS. Le schede SD utilizzano tradizionalmente exFAT per file superiori a 4 GB o FAT32 per la massima compatibilità. La partizione /system su Android è spesso montata in sola lettura e utilizza EXT4 o EROFS (Enhanced Read-Only File System) — un file system compresso sviluppato da Huawei per ridurre le dimensioni della partizione di sistema.

Struttura delle directory su Android

La gerarchia delle directory di Android si basa sulla struttura Linux con radice in /. Ogni partizione ha il proprio file system, permessi di accesso e scopo. Un'applicazione può accedere solo a un insieme limitato di directory — il resto è protetto da permessi root.

Partizione /data e sandbox delle applicazioni

La partizione /data è la partizione principale per memorizzare i dati utente, le applicazioni installate e le loro impostazioni. Ogni applicazione riceve la propria directory in /data/data/<package_name>/. All'interno di questa directory, il sistema crea automaticamente sottodirectory: files/ per i file dell'applicazione, cache/ per i file temporanei, databases/ per i database SQLite, shared_prefs/ per SharedPreferences. I permessi di accesso a questa directory vengono impostati durante l'installazione dell'applicazione e non possono essere modificati senza accesso root. La partizione /data è formattata come F2FS sulla maggior parte dei dispositivi moderni, offrendo una velocità di scrittura casuale fino al 40% superiore rispetto a EXT4.

Partizione /system e componenti di sistema

La partizione /system contiene il sistema operativo, le applicazioni di sistema e le librerie. Questa partizione è montata in sola lettura per prevenire modifiche accidentali o dannose ai file di sistema. Sui dispositivi con Android 10+ e Project Treble, la partizione /system è dinamica e può essere aggiornata tramite pacchetti OTA senza bisogno di un reflash completo. Per le applicazioni, la partizione /system è inaccessibile — qualsiasi tentativo di scrittura genererà una SecurityException. Tuttavia, le applicazioni possono leggere alcuni file da /system, come font di sistema e file di configurazione, se dispongono dei permessi appropriati.

Punto di mount /sdcard

Il punto di mount /sdcard è un collegamento simbolico alla partizione di archiviazione esterna emulata o fisica. Sui dispositivi senza scheda SD, /sdcard punta a una sottopartizione all'interno di /data designata per l'accesso condiviso. Questa partizione è visibile all'utente quando il dispositivo è collegato a un computer tramite protocollo MTP. Le applicazioni accedono a /sdcard tramite i permessi READ_EXTERNAL_STORAGE e WRITE_EXTERNAL_STORAGE e, a partire da Android 10, tramite Scoped Storage utilizzando l'API MediaStore. La dimensione di /sdcard è tipicamente il 60–80% della memoria flash totale, mentre il resto è riservato per la partizione /data.

Struttura delle directory su iOS

Su iOS, il file system è organizzato attraverso contenitori Sandbox di applicazioni. Ogni applicazione riceve una directory isolata il cui accesso è limitato a livello di kernel XNU. La partizione utente utilizza APFS (Apple File System), introdotto in iOS 10.3. APFS supporta snapshot, clonazione di file e crittografia a livello di file, rendendolo ottimale per i dispositivi mobili.

Directory standard del contenitore Sandbox

Un contenitore Sandbox iOS include quattro directory principali: Documents, Library, tmp e SystemData. Ogni directory ha la propria politica di backup, periodo di conservazione dei dati e livello di accesso. Documents viene automaticamente incluso nei backup di iCloud e iTunes. Library contiene le sottodirectory Caches (non sottoposta a backup), Preferences (sottoposta a backup) e Application Support (sottoposta a backup). La directory tmp è per file temporanei che iOS può eliminare quando lo spazio è scarso — non è inclusa nei backup. SystemData è utilizzata dal sistema stesso ed è inaccessibile alle applicazioni tramite le 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!

Ogni directory del contenitore Sandbox ha la propria classe di protezione. iOS supporta quattro classi: Protezione Completa (file inaccessibile quando il dispositivo è bloccato), Protetto a meno che aperto (file già aperti accessibili quando bloccato), Protetto fino al primo autenticazione utente (file accessibili dopo il primo sblocco) e Nessuna protezione (file sempre accessibili dopo l'avvio del dispositivo). Per impostazione predefinita, tutti i file in Documents e Library ricevono la classe Protezione Completa, garantendo la massima protezione dei dati utente. Quando si crea un file, è possibile specificare esplicitamente una classe di protezione diversa se un'applicazione in background deve accedere ai dati mentre il dispositivo è bloccato.

Permessi di accesso e sicurezza del file system

Il controllo degli accessi ai file sui dispositivi mobili è una differenza fondamentale tra Android e iOS. Android utilizza il classico modello di permessi Linux (lettura, scrittura, esecuzione) con estensioni per l'isolamento delle applicazioni. iOS utilizza un modello Sandbox più restrittivo, dove ogni applicazione viene eseguita in un contenitore isolato e non ha accesso ai file di altre applicazioni senza meccanismi speciali.

Permessi su Android

Su Android, ogni applicazione viene eseguita con un UID (User ID) separato. Tutti i file creati da un'applicazione nella sua sandbox appartengono a questo UID e sono invisibili ad altre applicazioni. Per accedere a directory condivise (archiviazione esterna), l'applicazione deve richiedere i permessi READ_EXTERNAL_STORAGE e WRITE_EXTERNAL_STORAGE. A partire da Android 11, i permessi devono essere richiesti in fase di esecuzione e un'applicazione con targetSdkVersion 30+ deve utilizzare SAF per accedere ai file di altre applicazioni. La violazione del modello di permessi comporta una SecurityException, gestita da un blocco try-catch standard. Google Play verifica automaticamente la conformità dell'applicazione con la politica dei permessi prima della pubblicazione.

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 e Keychain

La Sandbox iOS è implementata a livello di kernel XNU e non consente all'applicazione di uscire dal suo contenitore. Anche se l'applicazione ottiene l'accesso a un URI di file esterno tramite Document Picker, il sistema operativo crea una copia temporanea nel contenitore dell'applicazione anziché fornire accesso diretto all'originale. Per la condivisione di file tra applicazioni, iOS utilizza i meccanismi Share Sheet e UIActivityViewController, che copiano un file dal contenitore di un'applicazione a quello di un'altra. Per l'archiviazione sicura delle credenziali (token, password, chiavi), iOS fornisce Keychain — un archivio crittografato accessibile al sistema a livello di kernel. Keychain non fa parte del contenitore Sandbox ed è gestito da un demone securityd separato, fornendo un ulteriore livello di protezione anche in caso di compromissione dell'applicazione.

Caratteristiche dei file system: EXT4, APFS, F2FS

La scelta del file system influisce direttamente sulle prestazioni e sull'affidabilità dell'archiviazione. Ogni file system ha la propria architettura, ottimizzazioni e limitazioni. È utile per uno sviluppatore comprendere queste differenze per prevedere il comportamento dell'applicazione su dispositivi diversi.

• EXT4 — un file system Linux standard con journaling, che supporta file fino a 16 TB e volumi fino a 1 EB. Utilizzato su Android come file system principale prima dell'adozione di F2FS. Fornisce affidabilità grazie al journaling, ma è inferiore a F2FS nella velocità di scrittura casuale a causa della necessità di aggiornare inode e bitmap dei blocchi a ogni operazione
• F2FS — un file system sviluppato da Samsung nel 2012 specificamente per la memoria flash NAND. Tiene conto della geometria dell'array flash, utilizza un'architettura log-strutturata e offre prestazioni di scrittura casuale dal 25 al 40% superiori rispetto a EXT4. A partire da Android 11, Google raccomanda F2FS come file system principale per la partizione /data
• APFS — il file system di Apple introdotto nel 2017. Supporta snapshot, clonazione di file (copy-on-write), crittografia a livello di file e controllo rigoroso dell'integrità dei dati tramite checksum. APFS è ottimizzato per SSD e utilizza comandi TRIM per mantenere le prestazioni per tutta la durata dell'archiviazione
• exFAT — il file system di Microsoft utilizzato su schede SD e unità USB. Supporta file superiori a 4 GB e volumi fino a 128 PB. Non ha journaling, quindi un'improvvisa perdita di corrente può causare corruzione dei dati. Raccomandato per supporti rimovibili, ma non per partizioni di sistema

Quando si sviluppano applicazioni, tenere presente che diversi file system hanno limiti di lunghezza del nome file diversi (255 byte per EXT4 e F2FS, 255 caratteri Unicode per APFS), dimensione massima del file e supporto per caratteri speciali. Ad esempio, APFS consente caratteri Unicode nei nomi dei file, inclusi emoji, mentre EXT4 è limitato all'ASCII. Se l'applicazione crea file con nomi in lingue diverse, testare su tutti i dispositivi target — un nome file creato correttamente su APFS potrebbe essere troncato su EXT4.

Raccomandazioni per lavorare con il file system

Il lavoro affidabile con il file system del dispositivo mobile richiede il rispetto di diverse regole chiave. Esse si basano sull'analisi degli errori tipici degli sviluppatori e sulle raccomandazioni della documentazione ufficiale.

• Non utilizzare percorsi hard-coded per le directory. Ottenere sempre i percorsi tramite le API di sistema: context.filesDir su Android, NSSearchPathForDirectoriesInDomains su iOS. I percorsi hard-coded cambiano tra versioni del sistema operativo e dispositivi
• Gestire le eccezioni delle operazioni sui file: IOException, FileNotFoundException, SecurityException. Su iOS, tutte le operazioni di FileManager possono generare errori — racchiuderle in do-catch. Su Android, le operazioni con archiviazione esterna possono fallire a causa dell'assenza del supporto
• Verificare lo spazio disponibile prima di scrivere. Utilizzare File.getUsableSpace() su Android e URLResourceValues.volumeAvailableCapacityKey su iOS. Avvisare l'utente se lo spazio libero è insufficiente
• Evitare di archiviare file di grandi dimensioni in directory incluse nei backup. Su iOS, escludere la cache dal backup tramite isExcludedFromBackup. Su Android, preferire cacheDir per i file temporanei
• Testare il comportamento in caso di overflow dell'archiviazione e improvvisa perdita di corrente. Utilizzare la scrittura transazionale: scrivere in un file temporaneo, quindi rinominare atomicamente

Prestare particolare attenzione alle differenze multipiattaforma. I percorsi dei file su Android utilizzano barre (/data/data/.../files/), su iOS — schema URL (file:///var/mobile/.../Documents/). Se l'applicazione utilizza un framework multipiattaforma (Flutter, React Native, Kotlin Multiplatform), unificare le operazioni sui file tramite adattatori di piattaforma. Ad esempio, Flutter fornisce il pacchetto path_provider, che restituisce il percorso corretto a Documents o filesDir su entrambe le piattaforme senza scrivere codice specifico della piattaforma. Non concatenare mai i percorsi con operazioni sulle stringhe — utilizzare File.join() o URL.appendingPathComponent(), che gestiscono correttamente i separatori su diverse piattaforme.