Sistema de arquivos do dispositivo móvel: o que é, estrutura de diretórios e como funciona

O que é o sistema de arquivos de um dispositivo móvel?

O sistema de arquivos é um componente de software do sistema operacional que gerencia como os dados são escritos, lidos e organizados na mídia física. Em dispositivos móveis, o sistema de arquivos desempenha funções criticamente importantes: gerenciamento do espaço da memória flash, controle de acesso a arquivos com base em permissões, registro de alterações para recuperação após falhas e otimização de gravação considerando as especificidades da memória flash NAND.

Ao contrário dos sistemas operacionais de desktop, os sistemas de arquivos móveis são projetados considerando o número limitado de ciclos de regravação da memória flash. As células NAND suportam um número limitado de operações de apagamento — de 3.000 a 10.000 ciclos para memórias TLC e MLC, respectivamente. Para prolongar a vida útil do armazenamento, os sistemas de arquivos empregam mecanismos de wear leveling (nivelamento de desgaste) e comandos TRIM. O F2FS, desenvolvido pela Samsung especificamente para memória flash, leva em conta a geometria da matriz NAND e posiciona os dados de forma a minimizar a fragmentação e o número de operações de apagamento de blocos.

Dispositivos móveis modernos usam uma combinação de vários sistemas de arquivos. A memória interna (partição /data) é formatada como EXT4 ou F2FS no Android e APFS no iOS. Cartões SD tradicionalmente usam exFAT para arquivos maiores que 4 GB ou FAT32 para máxima compatibilidade. A partição /system no Android é frequentemente montada somente leitura e usa EXT4 ou EROFS (Enhanced Read-Only File System) — um sistema de arquivos compactado desenvolvido pela Huawei para reduzir o tamanho da partição do sistema.

Estrutura de diretórios no Android

A hierarquia de diretórios do Android é baseada na estrutura Linux com raiz em /. Cada partição tem seu próprio sistema de arquivos, permissões de acesso e propósito. Uma aplicação só pode acessar um conjunto limitado de diretórios — o restante é protegido por permissões root.

Partição /data e sandbox de aplicativos

A partição /data é a partição principal para armazenar dados do usuário, aplicativos instalados e suas configurações. Cada aplicativo recebe seu próprio diretório em /data/data/<package_name>/. Dentro deste diretório, o sistema cria automaticamente subdiretórios: files/ para arquivos do aplicativo, cache/ para arquivos temporários, databases/ para bancos de dados SQLite, shared_prefs/ para SharedPreferences. As permissões de acesso a este diretório são definidas ao instalar o aplicativo e não podem ser alteradas sem acesso root. A partição /data é formatada como F2FS na maioria dos dispositivos modernos, proporcionando até 40% mais velocidade de gravação aleatória em comparação com EXT4.

Partição /system e componentes do sistema

A partição /system contém o sistema operacional, aplicativos do sistema e bibliotecas. Esta partição é montada somente leitura para evitar modificação acidental ou maliciosa de arquivos do sistema. Em dispositivos com Android 10+ e Project Treble, a partição /system é dinâmica e pode ser atualizada via pacotes OTA sem necessidade de um flash completo. Para aplicativos, a partição /system é inacessível — qualquer tentativa de gravação lançará uma exceção SecurityException. No entanto, os aplicativos podem ler alguns arquivos do /system, como fontes do sistema e arquivos de configuração, se tiverem as permissões adequadas.

Ponto de montagem /sdcard

O ponto de montagem /sdcard é um link simbólico para a partição de armazenamento externo emulado ou físico. Em dispositivos sem cartão SD, /sdcard aponta para uma subpartição dentro de /data designada para acesso compartilhado. Esta partição é visível ao usuário quando o dispositivo está conectado a um computador via protocolo MTP. Os aplicativos acessam /sdcard por meio das permissões READ_EXTERNAL_STORAGE e WRITE_EXTERNAL_STORAGE e, a partir do Android 10, por meio do Scoped Storage usando a API MediaStore. O tamanho do /sdcard geralmente é de 60 a 80% da memória flash total, e o restante é reservado para a partição /data.

Estrutura de diretórios no iOS

No iOS, o sistema de arquivos é organizado por meio de contêineres Sandbox de aplicativos. Cada aplicativo recebe um diretório isolado cujo acesso é restrito no nível do kernel XNU. A partição do usuário usa o APFS (Apple File System), introduzido no iOS 10.3. O APFS oferece suporte a snapshots, clonagem de arquivos e criptografia em nível de arquivo, tornando-o ideal para dispositivos móveis.

Diretórios padrão do contêiner Sandbox

Um contêiner Sandbox do iOS inclui quatro diretórios principais: Documents, Library, tmp e SystemData. Cada diretório tem sua própria política de backup, período de retenção de dados e nível de acesso. Documents é incluído automaticamente nos backups do iCloud e iTunes. Library contém os subdiretórios Caches (sem backup), Preferences (com backup) e Application Support (com backup). O diretório tmp é para arquivos temporários que o iOS pode excluir quando o armazenamento está baixo — não é incluído nos backups. SystemData é usado pelo próprio sistema e é inacessível para aplicativos por meio das APIs padrão.

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!

Cada diretório do contêiner Sandbox tem sua própria classe de proteção. O iOS oferece suporte a quatro classes: Proteção Completa (arquivo inacessível quando o dispositivo está bloqueado), Protegido a Menos que Aberto (arquivos já abertos são acessíveis quando bloqueado), Protegido Até a Primeira Autenticação do Usuário (arquivos acessíveis após o primeiro desbloqueio) e Sem Proteção (arquivos sempre acessíveis após a inicialização do dispositivo). Por padrão, todos os arquivos em Documents e Library recebem a classe de Proteção Completa, garantindo a máxima proteção dos dados do usuário. Ao criar um arquivo, você pode especificar explicitamente uma classe de proteção diferente se um aplicativo em segundo plano precisar acessar os dados enquanto o dispositivo está bloqueado.

Permissões de acesso e segurança do sistema de arquivos

O controle de acesso a arquivos em dispositivos móveis é uma diferença fundamental entre Android e iOS. O Android usa o modelo clássico de permissões Linux (leitura, gravação, execução) com extensões para isolar aplicativos. O iOS usa um modelo Sandbox mais rigoroso, onde cada aplicativo é executado em um contêiner isolado e não tem acesso aos arquivos de outros aplicativos sem mecanismos especiais.

Permissões no Android

No Android, cada aplicativo é executado com um UID (User ID) separado. Todos os arquivos criados por um aplicativo em seu sandbox pertencem a este UID e são invisíveis para outros aplicativos. Para acessar diretórios compartilhados (armazenamento externo), o aplicativo deve solicitar as permissões READ_EXTERNAL_STORAGE e WRITE_EXTERNAL_STORAGE. A partir do Android 11, as permissões devem ser solicitadas em tempo de execução, e um aplicativo com targetSdkVersion 30+ deve usar SAF para acessar arquivos de outros aplicativos. A violação do modelo de permissões resulta em uma SecurityException, que é tratada por um bloco try-catch padrão. O Google Play verifica automaticamente a conformidade do aplicativo com a política de permissões antes da publicação.

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

Sandbox no iOS e Keychain

O Sandbox do iOS é implementado no nível do kernel XNU e não permite que o aplicativo saia de seu contêiner. Mesmo que o aplicativo obtenha acesso a um URI de arquivo externo por meio do Document Picker, o sistema operacional cria uma cópia temporária no contêiner do aplicativo em vez de fornecer acesso direto ao original. Para compartilhar arquivos entre aplicativos, o iOS usa os mecanismos Share Sheet e UIActivityViewController, que copiam um arquivo do contêiner de um aplicativo para o de outro. Para armazenamento seguro de credenciais (tokens, senhas, chaves), o iOS fornece o Keychain, um armazenamento criptografado acessível ao sistema no nível do kernel. O Keychain não faz parte do contêiner Sandbox e é gerenciado por um daemon securityd separado, fornecendo uma camada adicional de proteção mesmo em caso de comprometimento do aplicativo.

Características dos sistemas de arquivos: EXT4, APFS, F2FS

A escolha do sistema de arquivos afeta diretamente o desempenho e a confiabilidade do armazenamento. Cada sistema de arquivos tem sua própria arquitetura, otimizações e limitações. É útil para um desenvolvedor entender essas diferenças para prever o comportamento do aplicativo em diferentes dispositivos.

• EXT4 — um sistema de arquivos Linux padrão com journaling, suportando arquivos de até 16 TB e volumes de até 1 EB. Usado no Android como sistema primário antes da adoção do F2FS. Fornece confiabilidade através do journaling, mas é inferior ao F2FS em velocidade de gravação aleatória devido à necessidade de atualizar inodes e bitmaps de bloco em cada operação
• F2FS — um sistema de arquivos desenvolvido pela Samsung em 2012 especificamente para memória flash NAND. Leva em conta a geometria da matriz flash, usa uma arquitetura log-estruturada e fornece 25 a 40% mais desempenho de gravação aleatória em comparação com EXT4. A partir do Android 11, o Google recomenda o F2FS como sistema de arquivos principal para a partição /data
• APFS — o sistema de arquivos da Apple introduzido em 2017. Suporta snapshots, clonagem de arquivos (copy-on-write), criptografia em nível de arquivo e controle rigoroso de integridade de dados através de checksums. O APFS é otimizado para SSDs e usa comandos TRIM para manter o desempenho ao longo da vida útil do armazenamento
• exFAT — o sistema de arquivos da Microsoft usado em cartões SD e unidades USB. Suporta arquivos maiores que 4 GB e volumes de até 128 PB. Não tem journaling, portanto, uma queda repentina de energia pode causar corrupção de dados. Recomendado para mídia removível, mas não para partições do sistema

Ao desenvolver aplicativos, lembre-se de que diferentes sistemas de arquivos têm limites de comprimento de nome de arquivo diferentes (255 bytes para EXT4 e F2FS, 255 caracteres Unicode para APFS), tamanho máximo de arquivo e suporte a caracteres especiais. Por exemplo, o APFS permite caracteres Unicode em nomes de arquivos, incluindo emojis, enquanto o EXT4 é limitado a ASCII. Se seu aplicativo criar arquivos com nomes em diferentes idiomas, teste em todos os dispositivos alvo — um nome de arquivo criado corretamente no APFS pode ser truncado no EXT4.

Recomendações para trabalhar com o sistema de arquivos

O trabalho confiável com o sistema de arquivos do dispositivo móvel requer seguir várias regras principais. Elas são baseadas na análise de erros típicos de desenvolvedores e nas recomendações da documentação oficial.

• Não use caminhos codificados para diretórios. Sempre obtenha caminhos por meio das APIs do sistema: context.filesDir no Android, NSSearchPathForDirectoriesInDomains no iOS. Caminhos codificados mudam entre versões do SO e dispositivos
• Lide com exceções de operações de arquivo: IOException, FileNotFoundException, SecurityException. No iOS, todas as operações do FileManager podem lançar erros — envolva-as em do-catch. No Android, operações com armazenamento externo podem falhar devido à falta de mídia
• Verifique o espaço disponível antes de gravar. Use File.getUsableSpace() no Android e URLResourceValues.volumeAvailableCapacityKey no iOS. Avise o usuário se o espaço livre for insuficiente
• Evite armazenar arquivos grandes em diretórios que são incluídos em backups. No iOS, exclua o cache do backup usando isExcludedFromBackup. No Android, prefira cacheDir para arquivos temporários
• Teste o comportamento sob estouro de armazenamento e queda repentina de energia. Use gravação transacional: escreva em um arquivo temporário e depois renomeie atomicamente

Preste atenção especial às diferenças entre plataformas. Os caminhos de arquivo no Android usam barras (/data/data/.../files/), no iOS — esquema de URL (file:///var/mobile/.../Documents/). Se seu aplicativo usar um framework multiplataforma (Flutter, React Native, Kotlin Multiplatform), unifique as operações de arquivo por meio de adaptadores de plataforma. Por exemplo, o Flutter fornece o pacote path_provider, que retorna o caminho correto para Documents ou filesDir em ambas as plataformas sem escrever código dependente de plataforma. Nunca concatene caminhos com operações de string — use File.join() ou URL.appendingPathComponent(), que lidam corretamente com os separadores em diferentes plataformas.