Interioarele de Android (ne dezvăluie robot) - (Gentry)

Interioarele de Android (ne dezvăluie robot) - (Gentry)

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. U-BOOT, și tabela de partiții

După ce a primit de control, u-boot verifică tabela de partiții și transferă controlul kernel-ul, secțiunea cusute cu numele nu boot-eze, apoi extractele kernel în imagine RAM-memorie de 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.

Î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).

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 - recuperare încărcate. adică Ubuntu Touch.

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

Pasul Doi. partiție de boot

Dacă secțiunea misc nu este necesară pentru a descărca de pavilion în recuperarea, u-boot trece de control pentru 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;
  • sbin - un set de instrumente și daemons auxiliare (adbd, de exemplu);
  • res - un set de imagini pentru încărcător (vezi mai jos).
  • 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ărui unică sarcină este de 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.

Î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.

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.

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, autoflasher, precum și mecanismul 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.

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.

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 variabilei este determinat automat în funcție de conținutul fișierului ro.hardware. 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 în trei sau patru secțiuni: 1 GB / Ext4, 2GB / Ext4, 1GB / Ext4, iar spațiul rămas este FAT32. Î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.

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

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 bucată de confit lui Dumnezeu 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.

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

Î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.