Souborový systém mobilního zařízení: co to je, struktura adresářů a jak funguje

Co je souborový systém mobilního zařízení?

Souborový systém je softwarová komponenta operačního systému, která řídí, jak jsou data zapisována, čtena a organizována na fyzickém médiu. Na mobilních zařízeních plní souborový systém kriticky důležité funkce: správu prostoru flash paměti, kontrolu přístupu k souborům na základě oprávnění, protokolování změn pro obnovu po selháních a optimalizaci zápisu s ohledem na vlastnosti NAND flash paměti.

Na rozdíl od desktopových operačních systémů jsou mobilní souborové systémy navrhovány s ohledem na omezený zdroj cyklů přepisování flash paměti. Buňky NAND vydrží omezený počet operací mazání — od 3 000 do 10 000 cyklů pro paměť TLC a MLC. Pro prodloužení životnosti úložiště používají souborové systémy mechanismy wear leveling (vyrovnávání opotřebení) a příkazy TRIM. F2FS, vyvinutý společností Samsung speciálně pro flash paměť, zohledňuje geometrii pole NAND a umisťuje data tak, aby minimalizoval fragmentaci a počet operací mazání bloků.

Moderní mobilní zařízení používají kombinaci několika souborových systémů. Vnitřní paměť (oddíl /data) je formátována v EXT4 nebo F2FS na Androidu a APFS na iOS. SD karty tradičně používají exFAT pro podporu souborů větších než 4 GB nebo FAT32 pro maximální kompatibilitu. Oddíl /system na Androidu je často připojen pouze pro čtení a používá EXT4 nebo EROFS (Enhanced Read-Only File System) — komprimovaný souborový systém vyvinutý společností Huawei pro zmenšení velikosti systémového oddílu.

Struktura adresářů na Androidu

Hierarchie adresářů Androidu je založena na struktuře Linux s kořenem v /. Každý oddíl má svůj vlastní souborový systém, přístupová práva a účel. Aplikace má přístup pouze k omezené sadě adresářů — ostatní jsou chráněna právy root.

Oddíl /data a sandbox aplikací

Oddíl /data je hlavní oddíl pro ukládání uživatelských dat, nainstalovaných aplikací a jejich nastavení. Každá aplikace získá vlastní adresář na cestě /data/data/<package_name>/. Uvnitř tohoto adresáře systém automaticky vytváří podadresáře: files/ pro soubory aplikace, cache/ pro dočasné soubory, databases/ pro databáze SQLite, shared_prefs/ pro SharedPreferences. Přístupová práva k tomuto adresáři se nastavují při instalaci aplikace a nelze je změnit bez přístupu root. Oddíl /data je formátován v F2FS na většině moderních zařízení, což poskytuje až o 40% vyšší rychlost náhodného zápisu ve srovnání s EXT4.

Oddíl /system a systémové komponenty

Oddíl /system obsahuje operační systém, systémové aplikace a knihovny. Tento oddíl je připojen pouze pro čtení, aby se zabránilo náhodné nebo škodlivé změně systémových souborů. Na zařízeních s Android 10+ a Project Treble je oddíl /system dynamický a lze jej aktualizovat pomocí OTA balíčků bez nutnosti úplného přeflashování. Pro aplikace je oddíl /system nepřístupný — pokus o zápis vyvolá výjimku SecurityException. Aplikace však mohou číst některé soubory z /system, například systémová písma a konfigurační soubory, pokud mají příslušná oprávnění.

Připojovací bod /sdcard

Připojovací bod /sdcard je symbolický odkaz na oddíl emulovaného nebo fyzického externího úložiště. Na zařízeních bez SD karty /sdcard ukazuje na pododdíl uvnitř /data, který je vyhrazen pro sdílený přístup. Tento oddíl je viditelný uživateli při připojení zařízení k počítači pomocí protokolu MTP. Aplikace získávají přístup k /sdcard prostřednictvím oprávnění READ_EXTERNAL_STORAGE a WRITE_EXTERNAL_STORAGE a od Androidu 10 — prostřednictvím Scoped Storage pomocí MediaStore API. Velikost /sdcard obvykle tvoří 60–80% celkového objemu flash paměti zařízení a zbytek je vyhrazen pro oddíl /data.

Struktura adresářů na iOS

Na iOS je souborový systém organizován prostřednictvím Sandbox kontejnerů aplikací. Každá aplikace získá izolovaný adresář, jehož přístup je omezen na úrovni jádra XNU. Uživatelský oddíl používá souborový systém APFS (Apple File System), představený v iOS 10.3. APFS podporuje snímky, klonování souborů a šifrování na úrovni souborů, což jej činí optimálním pro mobilní zařízení.

Standardní adresáře Sandbox kontejneru

Sandbox kontejner iOS obsahuje čtyři hlavní adresáře: Documents, Library, tmp a SystemData. Každý adresář má vlastní politiku zálohování, dobu uchovávání dat a úroveň přístupu. Documents je automaticky zahrnut do záloh iCloud a iTunes. Library obsahuje podadresáře Caches (nezálohuje se), Preferences (zálohuje se) a Application Support (zálohuje se). Adresář tmp je určen pro dočasné soubory — iOS je může smazat při nedostatku místa a není zahrnut do zálohy. SystemData je používán samotným systémem a není pro aplikaci přístupný prostřednictvím standardních API.

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!

Každý adresář Sandbox kontejneru má vlastní třídu ochrany (protection class). iOS podporuje čtyři třídy: Complete Protection (soubor je nepřístupný při zamknutém zařízení), Protected Unless Open (již otevřené soubory jsou přístupné při zamknutí), Protected Until First User Authentication (soubory jsou přístupné po prvním odemknutí) a No Protection (soubory jsou vždy přístupné po spuštění zařízení). Ve výchozím nastavení všechny soubory v Documents a Library získávají třídu Complete Protection, což zaručuje maximální ochranu uživatelských dat. Při vytváření souboru lze explicitně nastavit jinou třídu ochrany, pokud aplikace na pozadí musí mít přístup k datům při zamknutém zařízení.

Přístupová práva a bezpečnost souborového systému

Správa přístupu k souborům na mobilních zařízeních je klíčový rozdíl mezi Androidem a iOS. Android používá klasický model přístupových práv Linux (čtení, zápis, spuštění) s rozšířeními pro izolaci aplikací. iOS uplatňuje přísnější model Sandbox, kde každá aplikace běží v izolovaném kontejneru a bez speciálních mechanismů nemá přístup k souborům jiných aplikací.

Oprávnění na Androidu

Na Androidu je každá aplikace spouštěna s samostatným UID (User ID). Všechny soubory vytvořené aplikací v jejím sandboxu patří tomuto UID a nejsou viditelné pro jiné aplikace. Pro přístup ke sdíleným adresářům (externí úložiště) musí aplikace požádat o oprávnění READ_EXTERNAL_STORAGE a WRITE_EXTERNAL_STORAGE. Od Androidu 11 musí být oprávnění vyžadována za běhu a aplikace s targetSdkVersion 30+ musí pro přístup k souborům jiných aplikací používat SAF. Porušení modelu oprávnění vede k SecurityException, která je zpracována standardním blokem try-catch. Google Play automaticky kontroluje soulad aplikace s politikou oprávnění před publikováním.

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

Sandbox na iOS a Keychain

iOS Sandbox je implementován na úrovni jádra XNU a neumožňuje aplikaci opustit svůj kontejner. I když aplikace získá přístup k URI externího souboru prostřednictvím Document Picker, operační systém vytvoří dočasnou kopii v kontejneru aplikace, místo aby poskytl přímý přístup k originálu. Pro sdílení souborů mezi aplikacemi iOS používá mechanismy Share Sheet a UIActivityViewController, které kopírují soubor z kontejneru jedné aplikace do kontejneru druhé. Pro bezpečné ukládání přihlašovacích údajů (tokeny, hesla, klíče) iOS poskytuje Keychain — šifrované úložiště přístupné systému na úrovni jádra. Keychain není součástí Sandbox kontejneru a je spravován samostatným démonem securityd, což poskytuje dodatečnou úroveň ochrany i v případě kompromitace aplikace.

Vlastnosti souborových systémů: EXT4, APFS, F2FS

Výběr souborového systému přímo ovlivňuje výkon a spolehlivost ukládání dat. Každý souborový systém má svou vlastní architekturu, optimalizace a omezení. Pro vývojáře je užitečné porozumět těmto rozdílům, aby mohl předvídat chování aplikace na různých zařízeních.

• EXT4 — standardní souborový systém Linux s žurnálováním, podporou souborů do 16 TB a svazků do 1 EB. Používá se na Androidu jako hlavní před zavedením F2FS. Poskytuje spolehlivost díky žurnálu, ale je horší než F2FS v rychlosti náhodného zápisu kvůli nutnosti aktualizace inodů a bitmap bloků při každé operaci
• F2FS — souborový systém vyvinutý společností Samsung v roce 2012 speciálně pro NAND flash paměť. Zohledňuje geometrii flash pole, používá log-strukturovanou architekturu a poskytuje o 25–40% vyšší výkon náhodného zápisu ve srovnání s EXT4. Od Androidu 11 je F2FS doporučován společností Google jako hlavní souborový systém pro oddíl /data
• APFS — souborový systém společnosti Apple, představený v roce 2017. Podporuje snímky, klonování souborů (copy-on-write), šifrování na úrovni souborů a přísnou kontrolu integrity dat pomocí kontrolních součtů. APFS je optimalizován pro SSD a používá příkazy TRIM k udržení výkonu po celou dobu životnosti úložiště
• exFAT — souborový systém společnosti Microsoft, používaný na SD kartách a USB discích. Podporuje soubory větší než 4 GB a svazky do 128 PB. Nemá žurnálování, takže náhlý výpadek napájení může vést k poškození dat. Doporučuje se pro vyměnitelná média, ale ne pro systémové oddíly

Při vývoji aplikací berte v úvahu, že různé souborové systémy mají různá omezení délky názvu souboru (255 bajtů pro EXT4 a F2FS, 255 znaků Unicode pro APFS), maximální velikost souboru a podporu speciálních znaků. Například APFS povoluje znaky Unicode v názvech souborů, včetně emotikonů, zatímco EXT4 je omezen na ASCII. Pokud aplikace vytváří soubory s názvy v různých jazycích, testujte provoz na všech cílových zařízeních — název souboru správně vytvořený na APFS může být na EXT4 zkrácen.

Doporučení pro práci se souborovým systémem

Spolehlivá práce se souborovým systémem mobilního zařízení vyžaduje dodržování několika klíčových pravidel. Ta jsou založena na analýze typických chyb vývojářů a doporučeních oficiální dokumentace.

• Nepoužívejte pevně zakódované cesty k adresářům. Cesty vždy získávejte prostřednictvím systémových API: context.filesDir na Androidu, NSSearchPathForDirectoriesInDomains na iOS. Pevné cesty se mění mezi verzemi operačního systému a zařízeními
• Zpracovávejte výjimky souborových operací: IOException, FileNotFoundException, SecurityException. Na iOS mohou všechny operace FileManager vyvolat chybu — obalte je do do-catch. Na Androidu mohou operace s externím úložištěm selhat kvůli chybějícímu médiu
• Kontrolujte dostupné místo před zápisem. Použijte File.getUsableSpace() na Androidu a URLResourceValues.volumeAvailableCapacityKey na iOS. Upozorněte uživatele, pokud je volného místa nedostatek
• Vyhněte se ukládání velkých souborů do adresářů, které jsou zahrnuty do zálohy. Na iOS vylučte mezipaměť ze zálohy pomocí isExcludedFromBackup. Na Androidu preferujte cacheDir pro dočasné soubory
• Testujte chování při zaplnění úložiště a náhlém výpadku napájení. Používejte transakční zápis: zapisujte do dočasného souboru, poté atomicky přejmenujte

Zvláštní pozornost věnujte mezipalformním rozdílům. Cesty k souborům na Androidu se vytvářejí lomítkem (/data/data/.../files/), na iOS — pomocí schématu URL (file:///var/mobile/.../Documents/). Pokud vaše aplikace používá multiplatformní framework (Flutter, React Native, Kotlin Multiplatform), sjednoťte souborové operace prostřednictvím platformních adaptérů. Například Flutter poskytuje balíček path_provider, který vrací správnou cestu k Documents nebo filesDir na obou platformách bez psaní kódu závislého na platformě. Nikdy nespojujte cesty řetězcovými operacemi — používejte File.join() nebo URL.appendingPathComponent(), které správně zpracovávají oddělovače na různých platformách.