perspectivă informativă și practică în arhitectura Android

Cum Android

Aflați mai multe despre posibilitățile ascunse ale sistemelor software pot fi, știind modul în care acestea funcționează. În unele cazuri, face dificilă, deoarece codul de sistem poate fi închis, dar în cazul Android, putem studia întregul sistem interior și în exterior. În acest articol nu voi vorbi despre toate nuanțele de Android și se va concentra doar asupra modului în care lansarea sistemului de operare și ce evenimente au loc în intervalul dintre apăsarea butonului de alimentare și apariția desktop-ului.

Pe drum, voi explica faptul că putem schimba în acest lanț de evenimente și modul personalizat dezvoltatorii de firmware folosesc aceste caracteristici pentru a pune în aplicare lucruri cum ar fi parametrii de tuning OS, extinderea spațiului pentru stocarea aplicațiilor, schimb conectarea diferitelor personalizări și multe altele. Toate aceste informații pot fi folosite pentru a crea firmware personalizat și să pună în aplicare diverse hacks și modificări.

Pasul unu. tabel Aboot și partiții

După ce a primit de management, controalele Aboot tabelă de partiții și de control trece la kernel-ul, secțiunea cusute cu numele nu boot-, atunci nucleul preia memoria RAM-imaginea aceeași secțiune și începe de încărcare sau Android sau Consola de recuperare. NAND-memorie Android-dispozitive este împărțită în șase secțiuni necesare în mod condiționat:

• de boot - contine kernel-ul și RAM-disc, de obicei, are o dimensiune de aproximativ 16 MB;
• de recuperare - Consola de recuperare constă dintr-un set de bază de aplicații consolă, și dimensiunea fișierului setare de 16 MB;
• Sistemul - cuprinde Android, în devaysakh modernă are o dimensiune de cel puțin 1 GB;
• cache - proiectat pentru a stoca datele stocate în memoria cache este, de asemenea, utilizat pentru a stoca firmware-ul în OTA-upgrade-ul, și, prin urmare, are o dimensiune similară cu dimensiunea partiției sistemului;
• userdata - conține setări, aplicații și date de utilizator, el a scos tot spațiul NAND-memorie rămasă;
• misc - conține un steag, care determină ce mod sistemul trebuie să fie încărcat: Android sau de recuperare.

O parte din codul bootloader care determină tabela de partiții

Mai ales interesant este secțiunea misc. Există speculații că acesta a fost proiectat inițial pentru stocarea diferitelor setări independent de sistemul principal, dar în acest moment este folosit doar pentru un singur scop: pentru a specifica bootloader de la care să expedieze partiția de sistem - portbagaj sau de recuperare. Această posibilitate, în special, utilizează aplicația ROM Manager pentru a reporni automat sistemul în recuperare, cu instalarea automată a firmware-ului. Pe aceeași bază a construit mecanism pentru Ubuntu Touch Dual-boot Ubuntu bootloader care SEWS în recuperare și vă permite să controlați sistemul pentru a încărca data viitoare. Șterse secțiunea misc - încărcate Android, umplut cu date - încărcate de recuperare ... adică, Ubuntu Touch.

Pasul Doi. partiție de boot

În cazul în care secțiunea misc nu merita pavilion de descărcare în recuperare, aboot de control al transferurilor la cod aflat sub boot. Acest lucru este nimic ca nucleul Linux; este la începutul secțiunii, și imediat urmat de un pachet folosind gzip arhivator și imaginea cpio RAM-disk care conține directoarele necesare pentru Android, inițializarea sistemului de inițializare și alte instrumente. Nici un sistem de fișiere pe partiția de încărcare nu este prezent, kernel-ul și RAM-disk-ul trebuie doar să urmezi unul pe altul. Conținutul de RAM-disc este:

• date - director pentru secțiunea de montare cu același nume;
• dev - fișierele dispozitiv;
• proc - procfs montate aici;
• res - un set de imagini pentru încărcător (vezi mai jos).
• sbin - un set de instrumente și daemons auxiliare (adbd, de exemplu);
• SYS - sysfs montate aici;
• Sistem - pentru a monta partiția de sistem;
• încărcător - aplicație pentru afișarea procesului de încărcare;
• build.prop - setările de sistem;
• init - inițializarea sistemului;
• init.rc - stabilirea initializarea sistemului;
• ueventd.rc - stabilirea uventd demon, care face parte din init.

Este, ca să spunem așa, scheletul sistemului: un set de directoare pentru a conecta sistemul de fișiere al partiției NAND-memorie și inițializarea sistemului, care se va ocupa de restul lucrărilor privind sistemul este pornit. Elementul central aici - aplicația de inițializare și init.rc configurația sa, din care toate detaliile voi explica mai târziu. Între timp, vreau să atrag atenția asupra fișierelor și ueventd.rc încărcător, și directoarele sbin, proc și sys.

imagine încărcător - este o aplicație mică a cărei sarcină unică - pentru a afișa pictograma bateriei. El nu are nimic de-a face cu Android și este utilizat atunci când dispozitivul este conectat la încărcătorul oprit. În acest caz, download-uri Android nu se întâmplă, iar sistemul încarcă pur și simplu Monturile de nucleu RAM-disc și pornește încărcătorul. Ultimele afișează pictograma bateriei, imaginea care, în toate stările posibile sunt stocate într-o convenționale PNG-fișiere în interiorul res dosar.

fișier ueventd.rc este o configurație care definește ce trebuie să fie create fișierele dispozitiv în sys de pe sistemul este pornit. Bazat pe Linux, sistem de acces nucleu hardware prin fișiere speciale în cadrul dev director, și stabilirea lor în Android este daemon ueventd responsabil, care face parte din init. Într-o situație normală, este în modul automat, luând echipa pentru a crea fișiere de nucleu, dar unele dintre fișierele care aveți nevoie pentru a crea propriul. Acestea sunt enumerate în ueventd.rc.

directorul sbin în Android katabatic conține de obicei, nimic, dar adbd, adică ADB daemon, care este responsabil pentru depanare a sistemului cu un PC. A început devreme în sistemul de operare de încărcare și permite identificarea posibilelor probleme în etapa de inițializarea sistemului de operare. Firmware-ul personalizat în acest catalog, puteți găsi o grămadă de alte fișiere, cum ar fi mke2fs, care pot fi necesare în cazul în care trebuie să reformatați partiții ext3 / 4. De asemenea, de multe ori pus la modernizarea BusyBox, cu care poate aduce sute de Linux-comenzi.

Directorul Proc pentru Linux standard, etapele următoare de sarcină de inițializare conectat la acesta procfs, un sistem de fișiere virtual care oferă acces la informații cu privire la toate procesele de sistem. Produs de sistem Catalog SYS este conectat sysfs, deschizând accesul la informații despre hardware-ul și setările. Cu sysfs poate, de exemplu, pentru a trimite aparatul să doarmă sau să schimbe este utilizat algoritmul de economisire a energiei.

fișier build.prop este destinat pentru stocarea de setări Android de nivel scăzut. Mai târziu, sistemul va reseta setările și să le suprascrie cu valori de la inaccesibile până la sistemul de fișiere / build.prop.

Partiția rădăcină set-top OUYA

Autorizări din textul

Etapa a doua alternativă. partiție de recuperare

Spre deosebire de secțiune nu boot-eze, care acționează ca o legătură de tranziție între diferitele etape ale sistemului de operare este încărcat, partiție de recuperare este complet autonom și include un sistem de operare în miniatură, care nu are nimic de-a face cu Android. La baza recuperării sale, un set de aplicații (comenzi) și o interfață care permite utilizatorului să activeze funcția de serviciu.

Cu script-uri, de exemplu, puteți face recuperare după încărcarea găsit automat pe cartela de memorie firmware-ul dorit, instalați-le și reporniți în Android. Această caracteristică este folosit instrumente ROM Manager, auto-exhibitionist, și un mecanism de actualizare automată CyanogenMod și alte firmware.

Rekaveri sprijini, de asemenea script-uri personalizate de backup, care sunt situate în directorul /system/addon.d/. Înainte de a intermitent de recuperare controale script-uri si sa le execute înainte de a lua firmware-ul. Cu aceste script-uri nu gapps dispar după instalarea noului firmware.

comandă fastboot

Ecranul va afișa numele dispozitivului. Alte comenzi disponibile:

• fatsboot deblocare oem - debloca bootloader pe Nexus;
• fayl.zip actualizare - instalarea firmware-ului;
• boot.img boot flash - imagine firmware de boot-secțiune;
• flash de recuperare recovery.img - firmware secțiunea de recuperare a imaginii;
• Sistem bliț system.img - firmware imagine de sistem;
• recovery.img de boot - de recuperare a imaginii de descărcare, fără firmware-ul;
• Formatul oem - restabili tabelul de partiții deteriorate;
• reboot - repornire.

Pasul trei. iniţializarea

Fiecare unitate determină stadiul de încărcare sau în limbajul de Android dezvoltatori de acțiune. Blocurile sunt separate una de alta directivă privind, urmată de numele acțiunii, de exemplu, la începutul anului-inițializare sau post-fs. comanda Block este executată doar în cazul în care lucrarea intitulată de declanșare. Ca init de boot va la rândul lor activează declanșează precoce-urile de inițializare, init, primii-fs, fs, post-fs, timpuriu de boot boot, declanșând astfel blocurile corespunzătoare de comenzi.

Partea de configurare init.rc de CyanogenMod

Dacă fișierul de configurare trage câteva mai multe fișiere de configurare enumerate la începutul (care este aproape întotdeauna cazul), comenzile care bloc cu același nume în cadrul acestora vor fi îmbinate cu fișierul de configurare principal, astfel încât atunci când are loc declanșatorul de inițializare a executa comenzi de la blocurile respective ale tuturor fișierelor. Acest lucru se face pentru comoditatea de formare a fișierelor de configurare pentru mai multe dispozitive atunci când config principal conține generală pentru toate dispozitivele de echipa, și specifice pentru fiecare dispozitiv este salvat în fișiere separate.

Cel mai important dintre config suplimentar este numit initrc.imya_ustroystva.rc în cazul în care numele dispozitivului este determinat automat în funcție de sistemul de conținut ro.hardware variabil. Acest fișier de configurare specifică platformei, care conține blocuri de comenzi care sunt specifice pentru un anumit dispozitiv. In plus comenzile responsabile pentru reglarea nucleului, acesta cuprinde, de asemenea, aproximativ următoarea comandă:

Acum înseamnă că init ar trebui să se conecteze toate sistemele de fișiere listate în ./fstab.imya_ustroystva fișier care are următoarea structură:

De obicei, acesta conține instrucțiuni pentru conectarea sistemului de fișiere de interne NAND-secțiuni ale directoarelor / sistem (OS), / date (setările aplicației) și / cache (date stocate în memoria cache). Cu toate acestea, modificarea ușor acest fișier, putem obține de inițializare pentru a porni sistemul de pe un card de memorie. Este suficient pentru a rupe cartela de memorie 4 în trei secțiuni: 1 Gb / Ext4, 2 GB / Ext4, 1 Gb / ext4 și FAT32 spațiul rămas. În continuare, trebuie să determinați cartela de memorie nume de partiții în directorul / dev (pentru diferite dispozitive care sunt diferite) și înlocuiți-le numele originale ale dispozitivelor în fișierul fstab.

Un conținut tipic fstab fișier

Modern Android include zeci de servicii, dar două dintre ele au un statut special și de a determina întregul ciclu de viață al sistemului.

echipa init.rc

Procesul de inițializare a construit un set de comenzi, dintre care multe se repetă un set standard de comenzi Linux. Cel mai important dintre ele:

• exec / calea / spre / comanda - pentru a executa o comandă externă;
• ifup interfață - alege o interfață de rețea;
• class_start class_name - că serviciile legate de clasa specificată;
• class_name class_stop - stop;
• insmod / calea / spre / modul - încărca un modul kernel;
• FS mount director dispozitiv - conectați sistemul de fișiere;
• nume de valoare setprop - pentru a seta variabila de sistem;
• SERVICENAME începe - executa serviciul specificat;
• nume de declanșare - comutator de declanșare (executați unitatea de comandă specificată);
• scrie / calea / spre / șir de fișiere - șirul de a scrie la dosar.

Pasul Patru. Zigot și app_process

La un anumit stadiu de încărcare de inițializare întâlni aproximativ la sfârșitul unui astfel de configurare bloc:

Acest serviciu Zigotul descriere, o componentă cheie a oricărui sistem Android, care este responsabil pentru inițializarea, începând cu serviciile de sistem, porni și opri aplicații de utilizator, și multe alte sarcini. Zigotul este condus de o mică aplicație / sistem / bin / app_process, care este foarte clar văzut în piesa de configurare de mai sus. Sarcina app_proccess - rula mașina virtuală Dalvik, care este codul într-o bibliotecă partajată /system/lib/libandroid_runtime.so, și apoi rula pe partea de sus a acesteia zigotului.

După aceea se deschide Zigotul un soclu / dev / soclu / zigot și merge la culcare, așteaptă date. În acest moment Managerul de activități pentru emisiunile lansate anterior intenția Intent.CATEGORY_HOME, pentru a găsi aplicația care este responsabilă pentru formarea desktop, și îi dă numele de soclu zigotului. Acesta din urmă, la rândul său, forkan și rulează o aplicație pe partea de sus a unei mașini virtuale. Voila, am afișat pe desktop, găsit activitate Manager și zigotului rulează, și un system_server care rulează bara de stare în bara de stare de serviciu. După Tapa pe intenția de pictograma de pe desktop va trimite numele acestei cereri, se va lua Managerul de activități și să dea comanda pentru a porni aplicația demon zigotului

În Linux, terminologia RAM-disc - un fel de hard disk virtual care există numai în memorie. nucleu de pornire timpurie extrage conținutul imaginii pe disc și montează-l ca sistemul de fișiere rădăcină (rootfs).

În timp ce descărcarea Android afișează trei alt ecran de boot: mai întâi apare imediat după apăsarea butonului de alimentare și cusute în kernel-ul Linux, a doua apare în primele etape ale initializare și salvate într-un /initlogo.rle fișier (azi folosit aproape niciodată), ultima a început folosind bootanimation app și este conținută în fișierul /system/media/bootanimation.zip.

Printre altele, Managerul de activități este, de asemenea, implicat în uciderea aplicațiilor care rulează în fundal de memorie. Valorile pragurilor de memorie libere conținute în fișierul / sys / modul / lowmemorykiller / parametri / minfree.

Toate acestea pot părea oarecum neclare, dar cel mai important - amintiți-vă trei lucruri simple:

• init.rc oficială de documentare în Android sursa: goo.gl/QciYVW
• Descriere fișier Format / sys / modul / lowmemorykiller / parametri / minfree: goo.gl/gKdGPT
• Android Structura cataloqgue: goo.gl/363Sq6
• Descrierea serviciilor de fond: goo.gl/rtmGgf

În multe feluri, Android este foarte diferit de alte sisteme de operare, și năpusti nu înțelege. Cu toate acestea, dacă înțelegeți cum funcționează, pur și simplu deschide posibilități infinite. Spre deosebire de iOS și Windows Phone, de la sistemul de operare Google are o arhitectură flexibilă, care vă permite să modificați serios comportamentul său, fără a fi nevoie să scrie cod. În cele mai multe cazuri, corectați configurările și script-uri necesare.

Arată acest articol unui prieten: