16 576
Tesztek Android Google Apple Microsoft Samsung Huawei Linux Okostelefon Biztonság Tudomány Facebook Videojáték Film
16 576
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  ➜

Az Androbit technológiai és tudományos magazinnál hiszünk abban, hogy az információ mindenkit megillet. Hosszú évek munkájával megszerzett hírnevünknek köszönhetően megadatott számunkra az a lehetőség, hogy műszaki témájú médiumként is elérhessünk minden internetező korosztályt. Tesszük ezt olyan hírekkel és cikkekkel, amik között egyaránt szerepel nagyobb tömegeket és kisebb szakmai csoportokat érintő tartalom is.

A témák gondos összeválogatásának és a cikkek minőségi kidolgozottságának hála mára Magyarország egyik legnépszerűbb technológiai és tudományos információforrásává váltunk – fejlesztéseinkkel és kutatásainkkal pedig igyekszünk mindig egy lépéssel a versenytársak előtt járni.

A weboldalunkon található, szerkesztőségünk által készített tartalmakra vonatkozó összes felhasználási jogot az Androbit technológiai és tudományos magazin birtokolja. A tartalmak egyes részleteinek felhasználását kizárólag látványos (vagy jól hallható) forrásmegjelöléssel engedélyezzük. A feltételek megszegésének jogi következményei lehetnek. A feltételektől eltérő tartalomfelhasználás kizárólag megegyezés útján lehetséges.
Copyright © 2007-2016 – Makay József (makay@androbit.net)
A technológia segít a mentális egészség fenntartásában
A Windows Mobile piaci részesedése 0,1 százalékra csökkenhet
A Samsung Galaxy Note 5 is megkapja az Android 7.0 Nougat frissítést
Ezek a Huawei‑készülékek kapják meg az Android 7.0 Nougat frissítést
Ezek a különbségek az iPhone‑ és Android‑felhasználók között
Feltörték az Apple Aktiválási zár funkcióját
Felkapott témák
Ezek a különbségek az iPhone- és Android-felhasználók között
Ezek a jelenleg kapható legerősebb okostelefonok
Microsoft Surface Phone - Számítógép és okostelefon egy készülékben
Ezek a Huawei-készülékek kapják meg az Android 7.0 Nougat frissítést
Ingyenes nCore regisztráció - Újabb csalók próbálkoznak
Egy alkalmazás bitcoin-terminált csinál a telefonunkból
Állásajánlatok
C++ Qt Developer
Marketing asszisztens
C++ fejlesztő
Functional Specialist, Business Process Automation
Technical developer
Szoftvertesztelő Budapest
Junior Frontend Java Developer