System plików urządzenia mobilnego: co to jest, struktura katalogów i jak działa

Co to jest system plików urządzenia mobilnego?

System plików to komponent programowy systemu operacyjnego, który zarządza tym, jak dane są zapisywane, odczytywane i organizowane na nośniku fizycznym. Na urządzeniach mobilnych system plików pełni krytycznie ważne funkcje: zarządzanie przestrzenią pamięci flash, kontrolę dostępu do plików na podstawie uprawnień, rejestrowanie zmian w celu odzyskiwania po awariach oraz optymalizację zapisu z uwzględnieniem cech pamięci NAND flash.

W przeciwieństwie do systemów desktopowych, mobilne systemy plików projektowane są z uwzględnieniem ograniczonego zasobu cykli nadpisywania pamięci flash. Komórki NAND wytrzymują ograniczoną liczbę operacji kasowania — od 3 000 do 10 000 cykli dla pamięci TLC i MLC odpowiednio. Aby wydłużyć żywotność nośnika, systemy plików stosują mechanizmy wear leveling (wyrównywanie zużycia) i polecenia TRIM. F2FS, opracowana przez Samsung specjalnie dla pamięci flash, uwzględnia geometrię układu NAND i rozmieszcza dane w taki sposób, aby zminimalizować fragmentację i liczbę operacji kasowania bloków.

Nowoczesne urządzenia mobilne używają kombinacji kilku systemów plików. Pamięć wewnętrzna (partycja /data) jest formatowana w EXT4 lub F2FS na Androidzie i APFS na iOS. Karty SD tradycyjnie używają exFAT do obsługi plików większych niż 4 GB lub FAT32 dla maksymalnej zgodności. Partycja /system na Androidzie jest często montowana tylko do odczytu i używa EXT4 lub EROFS (Enhanced Read-Only File System) — skompresowanego systemu plików opracowanego przez Huawei w celu zmniejszenia rozmiaru partycji systemowej.

Struktura katalogów na Androidzie

Hierarchia katalogów Androida opiera się na strukturze Linux z korzeniem w /. Każda partycja ma własny system plików, prawa dostępu i przeznaczenie. Aplikacja może uzyskać dostęp tylko do ograniczonego zestawu katalogów — pozostałe są chronione prawami root.

Partycja /data i sandbox aplikacji

Partycja /data to główna partycja do przechowywania danych użytkownika, zainstalowanych aplikacji i ich ustawień. Każda aplikacja otrzymuje własny katalog pod ścieżką /data/data/<package_name>/. Wewnątrz tego katalogu system automatycznie tworzy podkatalogi: files/ dla plików aplikacji, cache/ dla plików tymczasowych, databases/ dla baz danych SQLite, shared_prefs/ dla SharedPreferences. Prawa dostępu do tego katalogu są ustawiane podczas instalacji aplikacji i nie mogą być zmienione bez dostępu root. Partycja /data jest formatowana w F2FS na większości nowoczesnych urządzeń, co zapewnia do 40% wyższą prędkość zapisu losowego w porównaniu z EXT4.

Partycja /system i komponenty systemowe

Partycja /system zawiera system operacyjny, aplikacje systemowe i biblioteki. Ta partycja jest montowana tylko do odczytu, aby zapobiec przypadkowej lub złośliwej modyfikacji plików systemowych. Na urządzeniach z Android 10+ i Project Treble partycja /system jest dynamiczna i może być aktualizowana przez pakiety OTA bez konieczności pełnego flashowania. Dla aplikacji partycja /system jest niedostępna — próba zapisu spowoduje wyjątek SecurityException. Jednak aplikacje mogą odczytywać niektóre pliki z /system, na przykład czcionki systemowe i pliki konfiguracyjne, jeśli mają odpowiednie uprawnienia.

Punkt montowania /sdcard

Punkt montowania /sdcard to dowiązanie symboliczne do partycji emulowanego lub fizycznego magazynu zewnętrznego. Na urządzeniach bez karty SD /sdcard wskazuje na podpartycję wewnątrz /data, która jest przeznaczona do współdzielonego dostępu. Ta partycja jest widoczna dla użytkownika po podłączeniu urządzenia do komputera przez protokół MTP. Aplikacje uzyskują dostęp do /sdcard przez uprawnienia READ_EXTERNAL_STORAGE i WRITE_EXTERNAL_STORAGE, a od Androida 10 — przez Scoped Storage z użyciem MediaStore API. Rozmiar /sdcard zwykle wynosi 60–80% całkowitej objętości pamięci flash urządzenia, a reszta jest zarezerwowana dla partycji /data.

Struktura katalogów na iOS

Na iOS system plików jest zorganizowany przez kontenery Sandbox aplikacji. Każda aplikacja otrzymuje izolowany katalog, do którego dostęp jest ograniczony na poziomie jądra XNU. Partycja użytkownika używa systemu plików APFS (Apple File System), wprowadzonego w iOS 10.3. APFS obsługuje snapshoty, klonowanie plików i szyfrowanie na poziomie plików, co czyni go optymalnym dla urządzeń mobilnych.

Standardowe katalogi kontenera Sandbox

Kontener Sandbox iOS zawiera cztery główne katalogi: Documents, Library, tmp i SystemData. Każdy katalog ma własną politykę kopii zapasowej, okres przechowywania danych i poziom dostępu. Documents jest automatycznie uwzględniany w kopii zapasowej iCloud i iTunes. Library zawiera podkatalogi Caches (nie jest archiwizowany), Preferences (archiwizowany) i Application Support (archiwizowany). Katalog tmp jest przeznaczony dla plików tymczasowych, które iOS może usunąć przy braku miejsca — nie jest uwzględniany w kopii zapasowej. SystemData jest używany przez sam system i jest niedostępny dla aplikacji przez standardowe 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żdy katalog kontenera Sandbox ma własny identyfikator ochrony (protection class). iOS obsługuje cztery klasy: Complete Protection (plik niedostępny przy zablokowanym urządzeniu), Protected Unless Open (już otwarte pliki są dostępne przy blokadzie), Protected Until First User Authentication (pliki dostępne po pierwszym odblokowaniu) i No Protection (pliki dostępne zawsze po uruchomieniu urządzenia). Domyślnie wszystkie pliki w Documents i Library otrzymują klasę Complete Protection, co gwarantuje maksymalną ochronę danych użytkownika. Podczas tworzenia pliku można jawnie określić inną klasę ochrony, jeśli aplikacja działająca w tle musi mieć dostęp do danych przy zablokowanym urządzeniu.

Prawa dostępu i bezpieczeństwo systemu plików

Zarządzanie dostępem do plików na urządzeniach mobilnych to kluczowa różnica między Androidem a iOS. Android używa klasycznego modelu praw dostępu Linux (odczyt, zapis, wykonanie) z rozszerzeniami do izolacji aplikacji. iOS stosuje bardziej rygorystyczny model Sandbox, gdzie każda aplikacja działa w izolowanym kontenerze i nie ma dostępu do plików innych aplikacji bez specjalnych mechanizmów.

Uprawnienia na Androidzie

Na Androidzie każda aplikacja uruchamiana jest z osobnym UID (User ID). Wszystkie pliki utworzone przez aplikację w jej sandboxie należą do tego UID i nie są widoczne dla innych aplikacji. Aby uzyskać dostęp do katalogów współdzielonych (magazyn zewnętrzny), aplikacja musi poprosić o uprawnienia READ_EXTERNAL_STORAGE i WRITE_EXTERNAL_STORAGE. Od Androida 11 uprawnienia muszą być żądane w czasie wykonania, a aplikacja z targetSdkVersion 30+ do dostępu do plików innych aplikacji musi używać SAF. Naruszenie modelu uprawnień prowadzi do SecurityException, który jest obsługiwany przez standardowy blok try-catch. Google Play automatycznie sprawdza zgodność aplikacji z polityką uprawnień przed publikacją.

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

iOS Sandbox jest zaimplementowany na poziomie jądra XNU i nie pozwala aplikacji wyjść poza swój kontener. Nawet jeśli aplikacja uzyska dostęp do URI zewnętrznego pliku przez Document Picker, system operacyjny tworzy tymczasową kopię w kontenerze aplikacji, zamiast zapewniać bezpośredni dostęp do oryginału. Do wymiany plików między aplikacjami iOS używa mechanizmów Share Sheet i UIActivityViewController, które kopiują plik z kontenera jednej aplikacji do kontenera drugiej. Do bezpiecznego przechowywania danych uwierzytelniających (tokeny, hasła, klucze) iOS udostępnia Keychain — zaszyfrowane repozytorium dostępne dla systemu na poziomie jądra. Keychain nie jest częścią kontenera Sandbox i jest zarządzany przez osobny demon securityd, co zapewnia dodatkowy poziom ochrony nawet w przypadku naruszenia bezpieczeństwa aplikacji.

Charakterystyka systemów plików: EXT4, APFS, F2FS

Wybór systemu plików bezpośrednio wpływa na wydajność i niezawodność przechowywania danych. Każdy system plików ma własną architekturę, optymalizacje i ograniczenia. Deweloperowi przydaje się zrozumienie tych różnic, aby przewidywać zachowanie aplikacji na różnych urządzeniach.

• EXT4 — standardowy system plików Linux z journalingiem, obsługą plików do 16 TB i woluminów do 1 EB. Używany na Androidzie jako główny przed wprowadzeniem F2FS. Zapewnia niezawodność dzięki dziennikowi, ale ustępuje F2FS pod względem szybkości zapisu losowego z powodu konieczności aktualizacji i-węzłów i bitmap bloków przy każdej operacji
• F2FS — system plików opracowany przez Samsung w 2012 roku specjalnie dla pamięci NAND flash. Uwzględnia geometrię układu flash, używa architektury log-strukturalnej i zapewnia o 25–40% wyższą wydajność zapisu losowego w porównaniu z EXT4. Od Androida 11 F2FS jest zalecany przez Google jako główny system plików dla partycji /data
• APFS — system plików Apple, wprowadzony w 2017 roku. Obsługuje snapshoty, klonowanie plików (copy-on-write), szyfrowanie na poziomie plików i ścisłą kontrolę integralności danych przez sumy kontrolne. APFS jest zoptymalizowany pod SSD i używa poleceń TRIM do utrzymania wydajności przez cały okres eksploatacji nośnika
• exFAT — system plików Microsoft, używany na kartach SD i dyskach USB. Obsługuje pliki większe niż 4 GB i woluminy do 128 PB. Nie ma journalingu, więc nagłe odłączenie zasilania może prowadzić do uszkodzenia danych. Zalecany dla nośników wymiennych, ale nie dla partycji systemowych

Podczas tworzenia aplikacji uwzględnij, że różne systemy plików mają różne ograniczenia długości nazwy pliku (255 bajtów dla EXT4 i F2FS, 255 znaków Unicode dla APFS), maksymalny rozmiar pliku i obsługę znaków specjalnych. Na przykład APFS dopuszcza znaki Unicode w nazwach plików, w tym emoji, podczas gdy EXT4 jest ograniczony do ASCII. Jeśli aplikacja tworzy pliki z nazwami w różnych językach, testuj działanie na wszystkich docelowych urządzeniach — nazwa pliku poprawnie utworzona na APFS może zostać obcięta na EXT4.

Zalecenia dotyczące pracy z systemem plików

Niezawodna praca z systemem plików urządzenia mobilnego wymaga przestrzegania kilku kluczowych zasad. Opierają się one na analizie typowych błędów programistów i zaleceniach oficjalnej dokumentacji.

• Nie używaj zakodowanych na sztywno ścieżek do katalogów. Zawsze pobieraj ścieżki przez systemowe API: context.filesDir na Androidzie, NSSearchPathForDirectoriesInDomains na iOS. Sztywne ścieżki zmieniają się między wersjami systemu operacyjnego i urządzeniami
• Obsługuj wyjątki operacji plikowych: IOException, FileNotFoundException, SecurityException. Na iOS wszystkie operacje FileManager mogą zgłaszać błędy — opakowuj je w do-catch. Na Androidzie operacje na magazynie zewnętrznym mogą kończyć się błędem z powodu braku nośnika
• Sprawdzaj dostępne miejsce przed zapisem. Użyj File.getUsableSpace() na Androidzie i URLResourceValues.volumeAvailableCapacityKey na iOS. Ostrzegaj użytkownika, jeśli wolnego miejsca jest za mało
• Unikaj przechowywania dużych plików w katalogach objętych kopią zapasową. Na iOS wykluczaj cache z kopii zapasowej przez isExcludedFromBackup. Na Androidzie preferuj cacheDir dla plików tymczasowych
• Testuj zachowanie przy przepełnieniu magazynu i nagłym odłączeniu zasilania. Używaj zapisu transakcyjnego: zapisuj do pliku tymczasowego, a następnie atomowo zmieniaj nazwę

Szczególną uwagę zwróć na różnice międzyplatformowe. Ścieżki do plików na Androidzie budowane są przez ukośnik prosty (/data/data/.../files/), na iOS — przez schemat URL (file:///var/mobile/.../Documents/). Jeśli Twoja aplikacja używa frameworka wieloplatformowego (Flutter, React Native, Kotlin Multiplatform), ujednolicaj operacje plikowe przez adaptery platformowe. Na przykład Flutter udostępnia pakiet path_provider, który zwraca poprawną ścieżkę do Documents lub filesDir na obu platformach bez pisania kodu zależnego od platformy. Nigdy nie łącz ścieżek operacjami na stringach — używaj File.join() lub URL.appendingPathComponent(), które poprawnie obsługują separatory na różnych platformach.