18 958
Tesztek Android Google Apple Microsoft Samsung Huawei Nokia Linux Biztonság Tudomány Facebook Videojáték Film
ga
https://lh3.googleusercontent.com/-pDtXp7xxYJA/UA7SmWL3mbI/AAAAAAAAIxs/6lVv5W-E3uI/s800/zte_blade.jpg

Adattárolás Androidon

2012.07.24. 18.38
https://lh3.googleusercontent.com/-pDtXp7xxYJA/UA7SmWL3mbI/AAAAAAAAIxs/6lVv5W-E3uI/s800/zte_blade.jpgEzen cikk elsősorban a ZTE Blade készülékhez íródott, azonban nagyon sok megoldás érvényes más androidos eszközök (okostelefonok, tabletek) esetében is. A legtöbb, nem ZTE Blade specifikus információ univerzális jellegű az Android világában. Ha szívesen megismernéd az androidos eszközök adattárolási sajátosságait, akkor ez az írás jó kiindulási alap lehet.

RAM vs. "ROM"

A ZTE Blade -- napjaink legtöbb androidos okostelefonjához hasonlóan -- 512 MiB RAM-mal rendelkezik (közvetlen hozzáférésű/operatív memória programkódnak és adatoknak), ebből az alkalmazások számára elérhető ~ 416 MiB. A készülék 4 Gbit ~= 512 MB-nyi belső memóriát (internal storage; a továbbiakban "ROM", a becenevével ellentétben írható-olvasható-, NAND-memória, háttértár, "lemez", mtd) tartalmaz (analóg a PC-k merevlemezével, a háttértár funkcióját tölti be); ebből ~ 467 MiB elérhető közvetlenül a rendszer számára (1 MB = 10^6 B, míg 1 MiB = 1024^2 B = 2^20 B). A leggyorsabb tárolóeszköz természetesen a RAM, elérési sebességben utána következik a ROM (~ HDD); a sor legvégén kullog az SD memóriakártya (~ flash tárolóeszköz, pendrive). (Megjegyezzük, hogy a "ROM" és a micro SD-kártyák ugyanazt a NAND chipet használják adattárolásra, ugyanúgy, ahogyan a pendrive-ok is.) Érthető, hogy érdemes alkalmazásainkat a belső memóriában (és nem az SD-n) tárolni, a gyors hozzáférés érdekében. (Megjegyezzük, hogy a sebességbeli eltérések ugyanazon NAND chip alapó memóriáknál az input/output (I/O) alrendszerek sajátosságai miatt lépnek fel.) Az érdeklődő olvasónak megjegyzem, hogy fizikailag egy házban (csomagban) került elhelyezésre a RAM és a ROM, lásd az első képet. Ez a megoldás viszonylag elterjedt a beágyazott eszközök körében.
Megjegyezzük, hogy a szakzsargonban a ROM szót többféle jelentésben is használhatjuk, a kontextusától függően: jelentheti a belső memóriát (ami az elnevezéssel ellentétben (újra)írható-olvasható, bár nem korlátlan alkalommal), és jelentheti a telepítendő zip fájlt is, sőt az angol nyelvben a (to) rom ige jelenheti a ROM telepítését is.



Felül: Samsung KA1000015M-AJTT (4 Gbit NAND + 4 Gbit Mobil DDR RAM),
alul: Qualcomm MSM7227 SoC chipset (CPU+GPU+DSP+Modem), avagy egy komplett RISC rendszer egy chipen




Ez a készülék 4 Gbit-es Samsung NAND chipet tartalmaz, az újabbakban Hynix chip van
(ZTE tárcsázó/dialer: *ZTE*CHIPINFO#)


A belső memória

A következőkben a ROM-ra fókuszálunk. A ROM teljes egészében több, egymással nem átfedő részre – partíciókra – felosztható. A Blade-nél 8 partíció található, ezek rendre a recovery, boot, splash, misc, cache, system, userdata, persist neveket viselik. A partíciókra tekinthetünk, mint különálló hardvereszközökre, meghajtókra (akár merevlemezekre). Ha nagy mennyiségű adatot, fájlokat szeretnénk a partícióinkon letárolni, azokat minden esetben meg kell formáznunk (strukturálnunk kell), azaz fel kell készíteni őket az adataink fogadására. A ZTE Blade esetében a 8 partíció közül csupán 4 rendelkezik fájlrendszerrel: ezek a system, userdata, cache, persist nevűek. Az egyes partíciók esetünkben jól definiált funkciókért felelős fájloknak adnak otthont; a recovery partíción találjuk a rendszer speciális, "vészvisszaállító" operációs rendszerét, a recovery-t. A boot partíción a rendszermag és egyes meghajtó programok vannak. A splash partíció tartalmazza a bekapcsoláskor elsőként megjelenített képet (logo-t). A system tartalmazza az Android operációs rendszer működéséhez szükséges szinte összes fájlt, így általában a legtöbb adatot (gyári állapotban). A userdata tartalmazza az általunk telepített alkalmazásokat és minden testreszabást, személyes adatokat, beállításokat. Fontos megjegyezni, hogy akár SD-kártyán is tárolhatjuk (telepíthetünk) Play Store-alkalmazásokat, továbbá itt (és csak itt) tárolhatunk tetszőleges fájlokat (dokumentumok, kép, hang, videó, stb.), akár egy pendrive-on. Elvileg tárolhatnánk fotóinkat akár a system vagy data partíciókon is, csak a telefon alkalmazásain keresztül nem, illetve PC-hez csatlakoztatás után csak ADB (Android Debug Bridge) használatával érhetnénk el azokat – tehát lehetőleg a telefon belső memóriáját ne használjuk közvetlenül adattárolásra –, erre a célra szolgál az SD-kártya. Azonban indokolt esetben módosíthatjuk közvetlenül a NAND tartalmát (most a system és userdata partíciókra gondoljunk), oda fájlokat másolhatunk. Az ilyen műveletekhez root jogkör szükséges, tehát az eszközt először rootolni kell.



Internal Memory (most: a userdata partíciót jelenti), microSD kártya, RAM

A partíciós tábla, Total Phone Transfer, generáció

Az eszközben a NAND-on kívül, PC-s analógiával élve amolyan CMOS/BIOS-ban (pontosabban: firmware-ben, szintén CMOS alapú megoldás) van letárolva a ROM partíciós táblája, azaz a partíciók elhelyezkedése (nevük (számuk), sorrendjük és hosszuk – röviden geometriának nevezhetjük). A partíciós tábla újraírásával (a "lemez" újrafelosztásával) elveszítünk minden, az egyes partíciókra jellemző struktúrát és adatokat (röviden törlődnek a partíciók és természetesen a teljes tartalmuk is, visszafordíthatatlanul). A partíciós tábla újraírható (a geometria átszerkeszthető) a fórumon "csudazip"-nek nevezett Total Phone Transfer (TPT) eljárás végrehajtásával. Ekkor az SD-kártya "image" mappájába másolt .mbn bináris fájlokban definiált módon újraoszthatjuk a partíciókat. Ezek az .mbn fájlok valójában a telefon firmwaré-t (~ CMOS/BIOS-át) módosítják, újraírják azt. Tehát a TPT alacsony szintű művelete automatikusan igen sok módosítást hajthat végre, minimális felhasználói közbeavatkozással (kiváló patchelésre, hibajavításra). Ugyanakkor kockázatos, mivel ha nem sikerül sikeresen újraírni a firmware-t, vagy annak egy részét, akkor a telefon nem lesz képes a jövőben automatikusan inicializálni saját firmware-nek frissítését (azaz egy rekonstruáló célú, újabb TPT-t), így "tégla" lett a készülékből, csak szakszervizben javítható, kelthető "életre". Fontos hangsúlyozni, hogy normál ROM telepítéssel szinte lehetetlen elrontani a telefont, ugyanis, ha esetleg megszakad, bármikor újrakezdhetjük. Azonban a TPT alacsonyszintű művelet, ha egyszer megszakadt, korántsem biztos, hogy újrakezdhetjük a folyamatot, ezért magában rejti a téglásítás lehetőségét is. A rendkívül hardverspecifikus TPT segítségével a hardverszinthez közeli (tehát a rendszermag, kernel szint alatti) módosítások végrehajthatók, például a RAM címtartomány beállítása, kijelző színhelyességének kalibrálása (kvázi hardver szinten), a partíciós tábla újraírása stb. A TPT ezen túl lehetővé teszi minden partícióra lemezképfájlok felírását. Tehát először létrejön a partíciós tábla, majd megfelelően formázásra kerülnek egyes partíciók, majd egyes partíciókra adatok (~ 100 MiB) íródnak; közben természetesen mély hardver közeli változtatások tucatjai mennek végbe -- mindezek néhány másodpercen belül, teljesen automatikusan az SD-n tárolt bináris konfigurációs fájlok (.mbn) és képfájlok (.img) alapján. Ezek után érthető, miért rendkívül kritikus a „csodazip”, „csudazip” alkalmazása előtt az md5 hash (fájlok sérülésmentességének, konzisztenciájának) ellenőrzése; továbbá az is világos, miért kerültek eltávolításra a fórumból a TPT fájlok linkjei. Továbbá felhívnám a figyelmet arra a tényre is, hogy vannak különböző generációjú firmware-ek Blade esetén (G1 és G2). TPT eljárással jelenleg csak G1-es firmware telepíthető, továbbá a G2-es firmware-állapot nem konvertálható G1-essé. Ezek alapján könnyen belátható, hogy a G1-es firmware-t telepítő TPT alkalmazása G2-es készülék esetén téglásodáshoz vezet(het) [a helyzet némileg megváltozott, az újabb fejleményekről egy későbbi cikkünkben beszámolunk]. A firmware generációjával kapcsolatban megjegyezzük, hogy 2011. április közepéig G1-es állapotú Blade-eket árusítottak Magyarországon, Android 2.1-es gyári operációs rendszerrel. Ezután kezdődött meg a G2-es készülékek árusítása, Android 2.2-es gyári operációs rendszerrel. Ugyan a G1-es készülékek G2-essé alakíthatóak, a konverziót jelenleg senkinek NEM javasoljuk (részben azért nem, mivel nem visszaállítható a G1-es állapot).
Továbbá a TPT módszerek („csodazip”, „csudazip”) általános alkalmazása mindenképpen kerülendő. Természetesen indokolt esetben, a szükséges információk birtokában, megfelelő körültekintéssel alkalmazható.



Mr Pigfish (ingyenes app) szerint ez első generációs (G1) készülék

Még egy flash fájlrendszer...

A partíciók tartalmának részletezése előtt ejtsünk néhány szót a ZTE Blade-nél használt fájlrendszerről. A NAND alapú memóriáknál elterjedt a YAFFS (Yet Another Flash File System – a Linux világában gyakoriak a rekurzív, vicces elnevezések) fájlrendszer (FS, File System) használata. A Blade esetében ennek továbbfejlesztett változatával, a YAFFS2-vel találkozunk néhány (fontosabb) partíció esetében. Ez egy, a beágyazott eszközök flash technológiájú adathordozói számára kifejlesztett speciális fájlrendszer formátum, a legtöbb Linux rendszer natívan nem támogatja. Bármely partíció komplett tartalma (bájtról-bájtra) kiolvasható, archiválható – így a teljes rendszerünkről biztonsági másolatot, pillanatképet (snapshotot) készíthetünk – célszerűen a készülék SD-kártyájára, amit aztán megbízhatóbb adattárolóra, pl. egy merevlemezre helyezhetünk. A Linux számára az egyes partíciók teljesen önálló blokkeszközök (speciális, nem pedig reguláris fájlok; kicsit hasonlítanak a mappa fogalmához, amelyeknek nincs méretük: speciális célfájlok). A blokkeszközök, mint fájlok neve a következő (általában több helyről is elérhetők a fájlrendszerből): /dev/block/mtdX, ahol X: 0-7 (8 darab), a partíciók neveit már fentebb felsoroltuk (számít a sorrendjük). Ezen blokkeszközök tartalma kiolvasható a "cat, dd" parancsokkal és közvetlenül egy fájlba írható a ">" redirect (átirányító) operátorral. Ezt a fájlt (lemez)képfájlnak nevezhetjük (kiterjesztése a konvenció szerint .img, ám ennek nincs jelentősége). A képfájl tehát az eredeti forrásfájlrendszer (itt pl. YAFFS2) egy másik fájlrendszerbe (pl. SD esetén FAT) van ágyazva, egyetlen fájl formájában. Felvetődik a kérdés, hogyan olvashatjuk el a manuálisan, vagy egyéb célszoftverrel (pl. Clockwork Recovery) készített lemezképfájljainkat, amelyek a legtöbb rendszer számára nem mások, mint értelmezhetetlen bináris adathalmazok? Hogyan szedhetjük ki például a telefonkönyvünket egy biztonsági másolatból? Kis trükkel felcsatolhatjuk (mountolhatjuk) a PC-nk Linux fájlrendszerébe a YAFFS2 formátumú képfájljainkat, vagy akár ki is bonthatjuk ("szétszedhetjük") őket, hozzáférve így a NAND adott partíciójának teljes mappastruktúrájához és összes fájljához. Itt az utóbbit ismertetném: töltsük le a unyaffs.h headerfájlt és unyaffs.c C-forráskódot, majd fordítsuk le őket. A keletkező bináris program képes YAFFS2 formátumú képfájlok kicsomagolására. Windowsra már lefordított binárist (unyaffs.exe) is letölthetünk. YAFFS2 fájlrendszerűek a következő partíciók: cache, system, userdata, persist. A többi partíció egyáltalán nem, vagy nem egy fájlrendszerrel rendelkezik. Az egyszerűség kedvéért az utóbbi esetre is mondhatjuk, hogy fájlrendszere "none" formátumú.



A felcsatolt (mountolt) partíciók

A partíciók



A következőkben a 8 partíció közül 6 tartalmát, felépítését részletezném. A partíciók tartalma kiolvasható és felülírható (PC-n fastboot, telefonon flash_image programmal). Azonban ne feledjük, hogy az egyes partíciók igen szigorúan meghatározott méretűek, felépítésűek, funkciójúak, és erősen eszköz/hardver specifikusak – ez különösen igaz a fájlrendszer nélküli partíciókra (none fs). Ezért .img fájlok partíciókra írásakor ("flash") különösen körültekintően kell eljárni. ZTE Blade-re csak ZTE Blade-hez készített img-ket (recovery, boot) írjunk, és lehetőleg ellenőrizzük itt is az md5 hash-eket – bár ez a TPT esetén sokkal fontosabb.



MTD-k (Memory Technology Device-ok, igen hasonlók a blokkeszközökhöz), azaz "partíciók" (hexadecimális értékek!)

Recovery, boot, avagy hol a kernel?

A recovery és a boot partíciók felépítése teljesen analóg, azonban tartalmuk teljesen eltérő. Ezeken a partíciókon nincs fájlrendszer, azonban felépítésük szigorúan meghatározott. A partíciókra egyenként egy ~ 4 - 8 MiB méretű bithalmazként gondolhatunk. A tartalmuk rendre: az első 2048 bájt az ún. kernel-header (rendszermag-fejléc, nincs különösebb funkciója, azért kell, hogy a bootloader megtalálja a kernelkód kezdetét), majd következik a Linux kernel (rendszermag) binárisa gzip-pelve (tömörítve; ez természetesen ARM architektúrára lefordított, optimalizált (statikusan csatolt) bináris kód, ember számára értelmezhetetlen; ZTE Blade-specifikus), majd az úgynevezett ramdiszk (RAM-lemezkép; szintén gzip-pelve, és még egy további eljárással (cpio) tovább "tömörítve", összefésülve; lásd még a következő elnevezésekkel: initramfs, initrd). Minden boot-nál a megfelelő partíció (recovery vagy boot) tartalma a headert leszámítva kicsomagolásra kerül, majd a RAM alsó tartományába betöltődik. Ez a kernel kommunikál a legalacsonyabb szinten a hardvereszközökkel (illesztőprogramokat is tartalmaz a ramdiszkben), elvégzi a futó folyamatok menedzselését (lásd: /proc, proc file system, proc fs, procfs), betölti/kilövi őket a RAM-ba/-ból, felszabadít memóriát, kiolvassa a szenzorok nyers adatait (merrefele gyorsul a készülék, mekkora a fényerősség, a mágneses mező az X-tengely mentén stb.), LED-eket kapcsol be, időzítőket (timereket) vezérel, beállítja a valós idejű órát (Real Time Clock, RTC), felébreszti az alvó rendszert bizonyos eszközök trigger eseményeire (lásd: wakelock) stb. Röviden a hardver és a szoftver közötti elsődleges, legfontosabb, nélkülözhetetlen híd szerepét tölti be. Nem meglepő, hogy a kernel erősen hardver specifikus, hemzseg speciális gyártói megoldásoktól, trükköktől, akár "patkolásoktól". A kernel forráskódja a legtöbb esetben, így a ZTE Blade esetében is publikus; C és C++ nyelvű, sok esetben igen hardver közeli programkód (mindig valamelyik stabil Linux kernelen alapszik, annak egy ún. forkja (elágazása), pl. 2.6.29, 2.6.32 verziójúakon alapulókat tette közzé a ZTE). A GNU licensz értelmében a gyártók kötelesek közzétenni a stabil kernel forrásában eszközölt változtatásaikat, akár a komplett kernel forrás, akár patch-ek, foltozások formájában! A ROM-főzők ezt (a forráskódot) kedvükre módosítják, patchelik (javíthatnak funkcionalitáson, vagy akár el is ronthatnak dolgokat).


A recovery és a boot partíciók utolsó része a legérdekesebb számunkra: ezek egyenként egy-egy mini fájlrendszert tartalmaznak, ramfs-nek, rootfs-nek is nevezhetjük. A boot után az egész rendszer alapmappájaként, gyökereként szolgáló / (root, gyökér, nem azonos a root felhasználóval!) mappa legtöbb almappáját (tehát a legfelső szintű mappákat) és fájljaikat tartalmazzák. Meg kell jegyeznünk, hogy a legtöbb fájl virtuális (ismerős lehet a fogalom, volt már szó mappa, blokkeszköz, MTD típusú speciális fájlokról), azaz nincs méretük (vagy folyamatosan változik a RAM-ban, de nem a ROM-ban), a tartalmuk bármikor megváltozhat, a rendszer üzenhet rajtuk keresztül a felhasználónak (pl. akár a partíciós táblát, LED-ek állapotát, a háttérvilágítás aktuális fényerejét is lekérdezhetjük, illetve szabályozhatjuk is (!) az utóbbi kettőt). A rootfs adja az aktuálisan futó Linux rendszer "gerincét", a legfontosabb mappákat, inicializációs és konfigurációs fájlokat. Megjegyezzük, hogy Linux alatt a legtöbb konfigurációs fájl ASCII formátumú szöveg, így a megfelelő szakértelemmel rendelkező felhasználók számára azok közvetlenül olvashatók, módosíthatók, átláthatók – ellentétben a Windows konfigurációs állományaival, amelyek bináris formátumúak; Linux alatt nincs bináris registry (regisztrációs-adatbázis), meg persze a vele járó sok negatívum sincs jelen. Ki kell emelnünk a rootfs-ből az /init.rc fájlt és az /etc/init.d mappát (az utóbbi opcionális kernel-komponens, mindkettő a ramdiszken van), amelyek az indításkor végrehajtandó rutinokat tartalmazzák (flash meghajtóeszközök (mtd-k) felmountolása, sok hardvereszköz inicializálása, folyamatok automatikus lefuttatása, jogosultságok beállítása, mivel a YAFFS2 és FAT nem őrzi meg/nem támogatja a jogosultságokat, szimbolikus linkek létrehozása stb.).
Az /etc mappában sok konfigurációs állományt találhatunk. Továbbá meglepően sok rootfs/initramfs-beli mappa üres, ezek nagyrészt vagy kompatibilitási célokból szerepelnek, vagy a boot után telnek meg fájlokkal (vagy virtuálisakkal, amelyeket automatikus rutinok generálnak, vagy nagyon is létező, NAND-ból beolvasottakkal, vagy belinkeltekkel). A recovery és boot nevű partíciók képesek önmagukban bootolásra (azaz külön-külön eltérő (ámde igen hasonló), teljes értékű kernelt, drivereket tartalmaznak). A recovery bootoltatható a Power+Hangerő le (+ esetleg Menü) billentyűkombinációval: ekkor, ha pl. Clockwork recovery-t írtunk előzőleg ezen partícióra, akkor az azon tárolt speciális (cél) Linux kernel (operációs rendszer) elindul néhány másodperc alatt (közben egy fejjel lefelé fordított A N D R O I D _ szöveget láthatunk felvillanni, mivel a ZTE mérnökei a kijelzőt fejjel lefelé tették be és utólag fordítják meg a képet a driverben -- de ekkor még nincs driver betöltve), majd megjelenik a Clockwork menüje. A gyári (nem módosított) eszközök is tartalmaznak recovery-t, azonban annak igen korlátozott -- azaz szinte nincs -- funkcionalitása a Clockwork-höz képest).
A boot partícióról bootol az eszköz normál bekapcsolással. Megjegyezzük, hogy a Power+Hangerő fel (+ esetleg Menü) billentyűkombinációval indított rendszer bootloader (download) módba kerül. Ekkor végrehajtható pl. a PC-n tárolt recovery lemezképfájl (.img) recovery partícióra történő felírása (fastboot-tal): ezután már használhatjuk a recovery-t biztonsági másolatok készítésére a rendszerről, azok visszaállítására, rom telepítésére, partíciók formázására, hibás mtd blokkok („szektorok”) keresésére, diagnosztikai információk kiolvasására, stb.



A boot és recovery partíciók felépítése, ezekben lakik egy-egy kernel is, jól betömörítve



A recovery (a képen a Clockwormod Recovery) egy egyszerű Linux rendszer;
a gyári recovery ("FTM mód"-nak becézik) csak speciális PC-s (sőt, windowsos, sajnos zárt forráskódú) programmal áll szóba, a felhasználóval nem


Splash, avagy a zöld robot

Ezután következik a splash partíció, amelynek szintén nincs fájlrendszere. A splash valójában nem más, mint egyetlen, jól definiált méretű és színmélységű, továbbá kódolású (R5 G6 B5) bitkép fájl. Ez jelenik meg néhány másodpercre közvetlenül a Power gomb hosszú lenyomását követően. Megjegyezzük, hogy főleg kompatibilitási okokból kifolyólag a boot partíció ramdiszkje is tartalmaz egy bitképet (elindított rendszeren a /logo.bmp helyen találjuk). A ZTE Blade-en azonban csak a splash-beli kép jelenik meg. Mérete közel van az 1 MiB-hoz, azonban a bitkép mérete jól definiáltan 768 070 bájt (felbontása: 800x480, színmélysége 16 bit, nélkülözni kell a futáshossz kódoláson (ZRLE) alapuló és egyéb tömörítéseket, és a megadott színprofilt kell használni). Legegyszerűbben a GIMP képszerkesztő programban hozhatjuk létre az előírt formátumú .bmp fájlt.



Az mtd2-ben lakik a zöld robot, tömörítés nélkül


A system partíció, mint Ubuntu Live CD

A system partíció tartalmazza az Android operációs rendszer szinte összes fontos rendszerfájlját, leszámítva a kernelt, amely a boot partíción foglal helyet, speciális formátumba csomagolva. Rom "felrakásakor" az ideális esetben előzőleg formázott system és boot partíciókba íródik az SD-kártyára előzőleg felmásolt, általában digitálisan aláírt zip fájl tartalma. Tehát a rom telepítés nem más, mint a .zip-ben lévő boot.img képfájl kiírása bájtról-bájtra a boot nevű partícióra és a zip system mappájának tartalmának felírása az ideális esetben YAFFS2-re formázott system partícióra. A system partíció tartalma ezután nem változik, mérete konstans – normál felhasználás során futó rendszeren nem írható, mivel ro-ként (read-only, csak olvasható) van csatolva a RAM-ba betöltött ramfs /system nevű csatolási helyére (mountpoint, az /init.rc csatolja a ramfs-ről). Ennek ellenére természetesen futó rendszeren is módosítható a system tartalma, miután azt újramountoltuk (R/W-ként; írhatóként; természetesen rootolt rendszer szükséges ehhez). Tehát a boot és a system nevű partíciók tartalmaznak minden, a rendszer elindításához szükséges információt, továbbá minden rendszeralkalmazást (~ "gyárilag" telepített programokat (/system/app helyen); amelyek közül törölhetünk is, ám legyünk óvatosak: egyes .apk-k törlése bizonyos funkciók működési zavaraihoz vezet). "Ideális" esetben a boot és system partíciók tartalma a gyárban feltöltésre kerül, ezután, mint egy CD-ROM vannak kezelve, azaz csak olvasható háttértárolóként érhetők el. A helyzet hasonló egy Ubuntu Live CD-ről indított PC rendszerhez. Tehát leegyszerűsítve, a futó rendszert egyrészt a RAM-ba betöltött kernel és ramdiszk, másrészt a system partíció jelenti, ahonnan – mint egy CD-ről – alkalmasint betölthetünk a RAM-ba alkalmazásokat (leegyszerűsítve ezek a folyamatok, processzusok -- egy-egy app általában nagyon sok processzust és démont, azaz szolgáltatást jelent). Itt hívnám fel a figyelmet az Android rendszerek memóriakezelésének egy fontos sajátosságára: NEM kell bezárni az alkalmazásokat, mivel a rendszer felszabadít memóriát, ha szükséges (a legtöbb felhasználó Windows rendszeren "szocializálódott", ahhoz képest azonban más elvek szerint működik a Linux kernel memóriamenedzsmentje, jóval intelligensebben). Az alkalmazások bezárogatása az akkumulátor merüléséhez vezethet, tehát elérhetjük azt, amit próbáltunk elkerülni! Továbbá a task killerek alkalmazásával a rendszer válaszideje megnőhet, így kerüljük azok használatát. Tehát ne feledjük, hogy az Android memóriakezelése (a Linux kernelnek köszönhetően) igen sok tekintetben intelligensebb a Windows Mobile-okénál, ezért ne használjunk automatizált task killereket, mert a legtöbb esetben többet árt, mint használ.
A ZTE Blade-nél a system partíció mérete alapesetben ~ 207 MiB. Azonban ha a rom-unk 100 MiB-ot foglal, akkor parlagon fog heverni, kihasználatlanul ~ 100 MiB a belső memóriából. Most válik világossá az újrapartícionálás létjogosultsága.
Kérdés, hogy a személyes, saját adataink: pl. letöltött (később eltávolítható) Play Store alkalmazásaink, beállításaink, nem SIM-kártyán tárolt telefonszámaink és SMS-eink, csengőhang hangerő értékünk, stb. hol kerül tárolásra?



Foglalt és szabad lemezterület, partíciónkénti bontásban

Userdata, avagy hol vannak az adataim?

A válasz az előbbi költői kérdésre a userdata partíció (gyakran data-nak rövidítik). Ugyanis ezen /data helyre felcsatolt partíció hordozza MINDEN személyes adatunkat (természetesen az SD-kártyával együtt). A data partíció az első boot során "népesedik be" fájlokkal, majd a telefon használata során monoton csökken a szabad hely rajta, mígnem el nem fogy –, ha sok száz alkalmazást telepítünk. Azonban ekkor jön a képbe az újrapartícionálás: felhasználhatjuk a system kihasználatlan ~ 100 MiB-ját, azaz hozzátapaszthatjuk a data-hoz (amelynek mérete alapesetben ~= (közelítőleg egyenlő) a system méretével, azaz ~ 200 MiB), hogy másfélszer annyi helyünk legyen az alkalmazásainknak. A rendszer folyamatosan írja a userdata partíciót a normál használat során, ellentétben a system-mel. Ezen partíció fő funkciója könnyen kitalálható: a letöltött Play Store alkalmazásainkat és azok járulékos adatait (testreszabását, saját beállításainkat) tárolja. Tehát a futó rendszer a /-ből (gyökérből) és egyéb, a RAM-ba betöltött rootfs-beli mappákból és fájlokból, továbbá a /system helyen felcsatolt, alapesetben csak olvasható (R/O) és a /data helyen felmountolt, írható-olvasható (R/W), megfelelő nevű partíciókból áll.



Egy alkalmazás által tárolt adatok (userdata és cache partíciókon)

Cache és egyéb meglepetések

A fenti konklúziót árnyalja a cache, misc és persist partíciók jelenléte. A cache átmeneti adatokat tárol, bizonyos értelemben hasonló a Linux rendszereken ismert swap-hez, amelynek azonban a ZTE Blade esetén nincs létjogosultsága (ugyanis relatíve sok RAM-ot tartalmaz) -- funkciója a rendszer gyorsítása, lényegében gyorsítótár. A cache és persist a normál használat során fel vannak csatolva a telefon fájlrendszerére, ami ugye a RAM-ba gyökerezik. A cache-ben átmenetileg tárolódhatnak személyes adatok. Komplett rendszer backup esetén a mentése fontos, mivel a rendszerünk konzisztenciája megsérülhet, ha egy alkalmasint végrehajtott teljes visszaállítás esetén nem rekonstruáljuk a mentéskori állapotra. A misc partíció nem használ fájlrendszert, adattartalma nem releváns a szempontunkból, ahogyan a YAFFS2 formátumú persist-é sem. Csupán annyit jegyzünk meg, hogy a persist csatolva van futó rendszeren (egyébként diagnosztikai adatokat és azonosítókat tárol). A cache partíció mérete 41 MiB. Az összes többi partíció mérete együttesen kitesz ~ 1-2 MiB-ot. Ha összesítjük a partíciók kapacitásait, meglepő következtetésre juthatunk: 4 (recovery) + 4 (boot) + 1 (splash) + 41 (cache) + 207 (system) + 208 (data) + 2 (misc, persist) (MiB) = 467 MiB. Ez bizony elmarad az 512 MB ~= 488 MiB-tól! Hova lett ~ 20 MiB-nyi kapacitás? A kérdés megválaszolását a kedves olvasóra bízzuk.*

* Egy kis segítség: gondoljunk arra, hogy a telefonunk egy embedded (beágyazott) rendszer; és az internal storage != (nem egyenlő) merevlemez, hanem "több" puszta háttértárnál. Tehát bizonyosan a RAM és a "ROM" kapacitásának egy része a hardvereszközök számára van kizárólagosan fenntartva, így számunkra (pontosabban az alkalmazások számára) nem látható.

Az érdeklődő olvasók számára megjegyzem, hogy vannak rejtett "partíciók" is: olyan lemezrészek, amelyeken a rendszer tárolja a lemez geometriáját; ezek mbn formátumú bináris állományok. Tehát a NAND-ban tárolódik a firmware egy része is.

A firmware tartalmazza az elsődleges és másodlagos bootloader rutinokat, a GSM/UMTS-rádió/modem vezérléséhez szükséges kódokat, további chipek vezérlőrutinjait (köztük a NAND, a HW-billentyűk, a digitizer (érintésre érzékeny kapacitív panel a kijelző felett) és LCD drivereket (lásd az első Blade-eket érintő színhibát/gradiens hibát, ami firmware eredetű volt, de már javították)), egyes egyedi azonosító kódokat, a rejtett és látható partíciók geometriáját, applikáció drivereket, RAM-térképet (RAM map) (lásd az első Blade-eket érintő hibát, amely miatt az 512 MB RAM-ból csak 256 MB volt elérhető, a probléma firmware eredetű volt, de már javították a gradiens hibával együtt), firmware frissítést inicializáló rutinokat (lásd: bootloader, fastboot, esetleg download mode, TPT), egyéb alacsony-szintű (low-level) diagnosztikai (debug)/szerviz módok vezérlőrutinjait.

A NAND-ban lévő firmware ún. rejtett partíciókban van tárolva.
A rejtett partíciók nevei (első generációs készülék esetén, sorrendben, zárójelben a megfelelő mbn/img bináris fájl):
MIBIB (???.mbn), QCSBL (qcsbl.mbn), OEMSBL1 (oemsbl.mbn), OEMSBL2 (oemsblhd.mbn ???), AMSS (amss.mbn), APPSBL (appsboot.mbn ???), FOTA (???.mbn), EFS2 (cefs.mbn), APPS (appsboothd.mbn ???), FTL (???.mbn), EFS2APPS (???.mbn).

A firmware iránt érdeklődő Olvasók a hamarosan megjelenő cikkünkből további érdekes részleteket ismerhetnek meg.
Kattints ide  ➜

Elég jónak ígérkezik a Transformers 5
Caseable – Egyedi tokok szemétből
Tilix – Frissítették a Terminix parancssort
Az Apple válaszolt a WikiLeaks által kiszivárogtatott lehallgatási botrányra
Itt a Samsung Galaxy S8 „számítógépes” dokkolója
Újabb Android 8.0 újdonságok szivárogtak ki
Felkapott témák
Elképesztően drága az Apple iPhone 7+ Retro
Osszad meg, és adunk egy iPhone-t!
Megérkezett és letölthető az Android 8.0
Mintha a Google kicsit túltolná a megfigyelést
Újabb Android 8.0 újdonságok szivárogtak ki
Ez volt 2016 legnépszerűbb okostelefonja
Állásajánlatok
Hardver és szoftver integrátor
Statement Service Data Specialist
Czech Speaking Service Desk Agent
Network Administrator Debrecen
Cyber Security Assurance Specialist with ERP/SAP focus 16001218
Vezető - Személyügyi marketing
Technológiafejlesztő mérnök Trainee