Cum funcționează un android. Electronice și aparate electrocasnice purtabile

27.04.2019 Erori

Cum funcționează Android

Întrebați despre oportunități ascunse sisteme software este posibil, după ce au înțeles principiul muncii lor. În unele cazuri, este dificil să faceți acest lucru, deoarece codul de sistem poate fi închis, dar în caz android putem studia întregul sistem în sus și în jos. În acest articol, nu voi vorbi despre toate nuanțele Android și mă voi concentra doar pe modul în care pornește sistemul de operare și ce evenimente au loc în intervalul dintre apăsarea butonului de pornire și apariția desktopului.

Pe parcurs, voi explica ce putem schimba în acest lanț de evenimente și modul în care dezvoltatorii de firmware personalizat folosesc aceste capabilități pentru a implementa lucruri precum reglarea parametrilor sistemului de operare, extinderea spațiului pentru stocarea aplicațiilor, schimbul de conectare, diverse personalizări și multe altele. Toate aceste informații pot fi folosite pentru a vă crea propriul firmware și pentru a implementa diverse hack-uri și modificări.

Primul pas. U-BOOT și masă de partiție

Totul începe cu bootloader-ul principal. După pornirea alimentării, sistemul execută codul de bootloader scris în memoria permanentă a dispozitivului. Cel mai adesea, rolul său este îndeplinit de versiune modificată u-boot bootloader cu suport fastboot încorporat, dar producătorul cipului mobil sau al smartphone-ului/tabletei are dreptul de a alege orice alt bootloader după gustul său. De exemplu, Rockchip folosește propriul său bootloader non-fastboot și trebuie să folosească instrumente proprietare pentru a-l reprograma și a-l gestiona.

Protocolul fastboot, la rândul său, este un sistem de control al bootloader-ului de pe un computer care vă permite să efectuați acțiuni precum deblocarea bootloader-ului, flash-ul unui nou kernel și recuperare, instalarea firmware-ului și multe altele. Rațiunea de a fi a fastboot este de a putea readuce smartphone-ul la starea inițială într-o situație în care toate celelalte mijloace nu funcționează. Fastboot va rămâne pe loc, chiar dacă, în urma experimentelor, ștergeți tot conținutul tuturor secțiunilor memoriei NAND de pe smartphone, pierzând accesul atât la Android, cât și la recuperare.

După ce a primit controlul, u-boot verifică tabelul de partiții și transferă controlul către kernel, care este flashat într-o partiție numită boot, după care nucleul preia imaginea RAM din aceeași partiție în memorie și începe să încarce fie Android, fie consola de recuperare. . Memoria NAND din dispozitivele Android este împărțită în șase secțiuni necesare condiționat:

boot - conține un nucleu și un disc RAM, de obicei de aproximativ 16 MB;
recuperare - consolă de recuperare, constă dintr-un nucleu, un set aplicații de consolăși fișier de setări, dimensiune 16 MB;
sistem - conține Android, în dispozitivele moderne are o dimensiune de minim 1 GB;
cache - destinat stocării datelor în cache, este folosit și pentru salvarea firmware-ului în timpul unei actualizări OTA și, prin urmare, are o dimensiune similară cu dimensiunea partiția sistemului;
userdata - conține setări, aplicații și date utilizator, tot spațiul de memorie NAND rămas îi este alocat;
misc - conține un steag care determină în ce mod ar trebui să pornească sistemul: Android sau recovery.

În terminologia Linux, un disc RAM este un fel de virtual hard un disc care există doar în RAM. La începutul fazei de pornire, nucleul extrage conținutul discului din imagine și îl montează ca sistem de fișiere rădăcină (rootfs).

Pe lângă acestea, pot exista și alte secțiuni, cu toate acestea, marcajul general este determinat în faza de proiectare a smartphone-ului și, în cazul u-boot, este cusut în codul bootloader-ului. Aceasta înseamnă că: 1) tabela de partiții nu poate fi ucisă, deoarece poate fi întotdeauna restaurată folosind comenzi fastboot format OEM; 2) pentru a schimba tabelul de partiții, va trebui să deblocați și să actualizați bootloader-ul cu noi parametri. Există, totuși, excepții de la această regulă. De exemplu, bootloader-ul aceluiași Rockchip stochează informații despre partiții în primul bloc de memorie NAND, așa că nu trebuie să flashiți bootloader-ul pentru a-l schimba.

De un interes deosebit este secțiunea diverse. Există speculații că a fost creat inițial pentru depozitare setări diferite indiferent de sistemul principal, dar în acest moment este folosit doar pentru un singur scop: pentru a spune bootloader-ului din ce partiție să încarce sistemul - boot sau recuperare. Această oportunitate, în special, este folosită de aplicație Manager ROM pentru repornire automată sisteme în recuperare cu instalarea automată a firmware-ului. Mecanismul este construit pe baza lui încărcare dublă Ubuntu Touch care coase Bootloader Ubuntu

în recuperare și vă permite să controlați ce sistem să porniți data viitoare. Ștergeți secțiunea diverse - Android este încărcat, plin de date - recuperarea se încarcă... adică Ubuntu Touch.

O parte a codului bootloader-ului care definește tabelul de partiții:

Partiții de partiție statică struct = (("-", 123), ("xloader", 128), ("bootloader", 256), / * partiția "misc" este necesară pentru recuperare * / ("diverse", 128), ("-", 384), ("efs", 16384), ("recuperare", 8 * 1024), ("boot", 8 * 1024), ("sistem", 512 * 1024), ("cache" , 256 * 1024), („date utilizator”, 0), (0, 0));

Pasul doi. Secțiunea de boot

Dacă secțiunea misc nu are un flag de boot în recuperare, u-boot transferă controlul către codul situat în secțiunea de boot. Nu este nimic mai mult decât nucleul Linux; este situat la începutul secțiunii și imediat urmat de o imagine de disc RAM comprimată cpio și gzip care conține directoarele necesare pentru ca Android să funcționeze, sistemul de inițializare și alte instrumente. Nu există niciun sistem de fișiere pe partiția de pornire, nucleul și discul RAM se succed. Conținutul discului RAM este următorul:

date - director pentru montarea partiției cu același nume;
dev - fișiere dispozitiv;
proc - procfs este montat aici;
sbin - un set de utilități și demoni auxiliare (adbd, de exemplu);
res - un set de imagini pentru încărcător (vezi mai jos);
sys - sysfs este montat aici;
sistem - director pentru montarea partiției de sistem;
încărcător - o aplicație pentru afișarea procesului de încărcare;
build.prop - setarile sistemului;
init - sistem init;
init.rc - init setările sistemului;
ueventd.rc - setări pentru demonul uventd inclus în init.

Acesta este, ca să spunem așa, scheletul sistemului: un set de directoare pentru conectarea sistemelor de fișiere din partițiile de memorie NAND și un sistem de inițializare care se va ocupa de restul muncii de încărcare a sistemului. Elementul central aici este aplicația init și configurația sa init.rc, despre care voi discuta în detaliu mai târziu. Între timp, vreau să vă atrag atenția asupra fișierelor charger și ueventd.rc, precum și a directoarelor sbin, proc și sys.

Fișierul încărcător este o aplicație mică al cărei unic scop este afișarea pictogramei bateriei. Nu are nicio legătură cu Android și este folosit când dispozitivul este conectat la încărcător în starea oprită. În acest caz, Android nu pornește, iar sistemul pur și simplu încarcă nucleul, conectează discul RAM și pornește încărcătorul. Acesta din urmă afișează o pictogramă a bateriei, a cărei imagine în toate stările posibile este stocată în fișiere PNG obișnuite în directorul res.

Fișierul ueventd.rc este o configurație care determină ce fișiere de dispozitiv din directorul sys ar trebui create la momentul pornirii. În baza de bază sisteme Linux Hardware-ul este accesat prin fișiere speciale din directorul dev, iar demonul ueventd, care face parte din init, este responsabil pentru crearea lor în Android. În mod normal, funcționează în modul automat, acceptând comenzi pentru a crea fișiere din nucleu, dar unele fișiere trebuie create singur. Ele sunt listate în ueventd.rc.

Directorul Sbin în stoc Android de obicei nu conține altceva decât adbd, adică demonul ADB care este responsabil pentru depanarea sistemului de pe PC. Este lansat într-o etapă incipientă a pornirii sistemului de operare și vă permite să identificați posibile probleme în etapa de inițializare a sistemului de operare. În firmware-urile personalizate din acest director puteți găsi o mulțime de alte fișiere, de exemplu mke2fs, care pot fi necesare dacă partițiile trebuie reformatate la ext3 / 4. De asemenea, modderii pun adesea acolo BusyBox, cu ajutorul căruia poți apela sute de comenzi Linux.

În timpul procesului de pornire, Android afișează trei ecrane de pornire diferite: primul apare imediat după apăsarea butonului de pornire și este afișat intermitent în nucleul Linux, al doilea este afișat în primele etape de inițializare și este scris în fișierul /initlogo.rle (aproape nefolosit astăzi), acesta din urmă este lansat folosind aplicația bootanimation și este conținut în fișierul /system/media/bootanimation.zip.

Directorul proc pentru Linux este standard, în etapele următoare de boot init se va atașa procfs, un sistem de fișiere virtual care oferă acces la informații despre toate procesele din sistem. Sistemul va conecta sysfs la directorul sys, care deschide accesul la informații despre hardware și setările acestuia. Folosind sysfs, puteți, de exemplu, să puneți dispozitivul în stare de repaus sau să schimbați algoritmul de economisire a energiei utilizat.

Fișierul build.prop este pentru stocarea la nivel scăzut setări Android... Mai târziu, sistemul va reseta aceste setări și le va suprascrie cu valorile din fișierul system / build.prop, care nu este încă disponibil.

Pasul doi, alternativă. Secția de recuperare

În cazul în care steag-ul de pornire de recuperare în secțiunea diverse este setat sau utilizatorul a pornit smartphone-ul cu tasta de reducere a volumului apăsată, u-boot va transfera controlul către codul situat la începutul secțiunii de recuperare. La fel ca partiția de pornire, conține nucleul și un disc RAM, care este decomprimat în memorie și devine rădăcina sistemului de fișiere. Cu toate acestea, conținutul discului RAM este oarecum diferit aici.

Spre deosebire de partiția de pornire acționând ca o legătură de tranziție între diferitele etape ale pornirii sistemului de operare, sectia de recuperare complet autonom și conține un sistem de operare în miniatură care nu are nimic de-a face cu Android. Recovery are propriul nucleu, propriul set de aplicații (comenzi) și propria interfață care permite utilizatorului să activeze funcții de serviciu.

În recuperarea standard (de stoc), există de obicei doar trei astfel de funcții: instalarea firmware-ului semnat cu cheia producătorului smartphone-ului, ștergerea și repornirea. Recuperarea modificată de la terți, cum ar fi ClockworkMod și TWRP, au multe mai multe funcții. Ei știu să formateze sisteme de fișiere, să instaleze firmware semnat cu orice cheie (a se citi: personalizat), să monteze sisteme de fișiere pe alte partiții (pentru depanarea sistemului de operare) și să includă suport pentru scripturi care automatizează procesul de firmware și multe alte funcții.

Folosind scripturi, de exemplu, vă puteți asigura că după încărcare, recuperarea se găsește automat pe cardul de memorie firmware-ul necesar, le-a instalat și le-a repornit în Android. Această caracteristică este utilizată de Managerul ROM, de instrumentele autoflasher, precum și de cea automată Actualizări CyanogenModși alte firmware-uri.

Recuperare personalizată acceptă, de asemenea, scripturi de rezervă situate în directorul /system/addon.d/. Față recuperare firmware verifică scripturile și le execută înainte de a clipi. Datorită unor astfel de scripturi, gapp-urile nu dispar după instalare versiune noua firmware.

Pasul trei. Inițializare

Deci, după ce a primit controlul, nucleul conectează discul RAM și, la finalizarea inițializării tuturor subsistemelor și driverelor sale, începe procesul de inițializare, de la care începe inițializarea Android. După cum am spus mai devreme, init are fișier de configurare init.rc, de la care procesul învață exact ce ar trebui să facă pentru a deschide sistemul. În smartphone-urile moderne, această configurație are o lungime impresionantă de câteva sute de linii și este, de asemenea, echipată cu o remorcă cu mai multe configurații copii care sunt conectate la cea principală folosind directiva de import. Cu toate acestea, formatul său este destul de simplu și, de fapt, este un set de comenzi, împărțit în blocuri.

Fiecare bloc definește o etapă de încărcare sau, în limbajul dezvoltatorilor Android, o acțiune. Blocurile sunt separate unul de celălalt printr-o directivă on urmată de un nume de acțiune, cum ar fi on early-init sau pe post-fs. Blocul de comandă va fi executat numai dacă este declanșat declanșatorul cu același nume. Pe măsură ce init pornește, va activa pe rând declanșatoarele early-init, init, early-fs, fs, post-fs, early-boot și boot, declanșând blocurile de comandă corespunzătoare.

Dacă fișierul de configurare mai trage câteva configurații enumerate la început (și acesta este aproape întotdeauna cazul), atunci blocurile de comandă cu același nume din interiorul lor vor fi combinate cu configurația principală, astfel încât atunci când declanșatorul este declanșat, init va executa comenzi din blocurile corespunzătoare tuturor fișierelor. Acest lucru se face pentru comoditatea generării fișierelor de configurare pentru mai multe dispozitive, atunci când configurația principală conține comenzi comune tuturor dispozitivelor și specifice pentru fiecare dispozitiv sunt scrise în fișiere separate.

Cea mai notabilă dintre configurațiile suplimentare este initrc.device_name.rc unde numele variabilei este determinat automat pe baza conținutului fișierului ro.hardware. Este un fișier de configurare specific platformei care conține blocuri de comandă specifice dispozitiv specific... Pe lângă comenzile responsabile pentru reglarea nucleului, conține și o comandă ca aceasta:

mount_all ./fstab.device_name

Aceasta înseamnă că init ar trebui să monteze acum toate sistemele de fișiere listate în. / Fstab.device_name, care are următoarea structură:

Device_name (partiție) mount_point file-system fs_options alte opțiuni

De obicei, conține instrucțiuni pentru conectarea sistemelor de fișiere de la partițiile interne NAND la directoarele / system (OS), / data (setările aplicației) și / cache (date în cache). Cu toate acestea, modificând ușor acest fișier, putem forța init să pornească sistemul de pe stick-ul de memorie. Pentru a face acest lucru, este suficient să împărțiți cardul de memorie în trei sau patru partiții: 1 GB / ext4, 2 GB / ext4, 1 GB / ext4 și spațiul fat32 rămas. Apoi, trebuie să determinați numele partițiilor cardului de memorie din directorul / dev (pentru diferite dispozitive sunt diferite) și înlocuiți-le nume originale dispozitivele din fișierul fstab.

La sfârșitul blocului de pornire, init va întâlni cel mai probabil comanda class_start default, care vă va informa că apoi ar trebui să porniți toate serviciile listate în config care sunt legate de clasa implicită. O descriere a serviciului începe cu o directivă de serviciu, urmată de numele serviciului și de comanda care trebuie executată pentru a-l porni. Spre deosebire de comenzile enumerate în blocuri, serviciile trebuie să ruleze tot timpul, astfel încât pe toată durata de viață a smartphone-ului, init se va bloca în fundal și îl va monitoriza.

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

Pasul patru. Zygote și App_process

La o anumită etapă de încărcare, init va întâlni un bloc ca acesta la sfârșitul configurației:

service zygote / system / bin / app_process -Xzygote / system / bin --zygote --start-system-server class default socket zygote stream 660 root system onrestart write / sys / android_power / request_state wake onrestart write / sys / power / state on onrstart restart media onrstart restart netd

Aceasta este o descriere a serviciului Zygote, o componentă cheie a oricărui sistem Android care este responsabil pentru inițializare, pornirea serviciilor de sistem, pornirea și oprirea aplicațiilor personalizate și multe alte sarcini. Zygote este lansat folosind o aplicație mică / sistem / bin / app_process, care este văzută foarte clar în configurația de mai sus. Sarcina app_proccess este să pornească mașina virtuală Dalvik, al cărei cod se află în biblioteca partajată /system/lib/libandroid_runtime.so, apoi să pornească Zygote deasupra acesteia.

Când toate acestea sunt făcute și Zygote deține controlul, începe să construiască runtime-ul Java prin încărcarea tuturor claselor Java ale cadrului (acum sunt peste 2000 dintre ele). Apoi pornește system_server, care include majoritatea serviciilor de sistem de nivel înalt (scrise în Java), inclusiv Window Manager, Status Bar, Package Manager și, cel mai important, Activity Manager, care în viitor va fi responsabil pentru primirea pornirii și opririi. semnale.aplicaţii.

După aceea, Zygote deschide socket-ul / dev / socket / zygote și intră în somn, așteptând date. În acest moment, Activity Manager lansat anterior trimite intenția de difuzare Intent.CATEGORY_HOME pentru a găsi aplicația responsabilă pentru crearea desktopului și îi dă numele lui Zygote prin intermediul soclului. Acesta din urmă, la rândul său, bifurcă și rulează aplicația pe deasupra mașină virtuală... Voila, avem un desktop pe ecran, găsit de Activity Manager și pornit de Zygote, și o bară de stare lansată de system_server ca parte a serviciului Status Bar. După atingerea pictogramei, desktopul va trimite o intenție cu numele acestei aplicații, aceasta va fi primită de Managerul de activități și va trimite comanda de pornire a aplicației către demonul Zygote.

Toate acestea pot părea puțin confuze, dar cel mai important lucru este să vă amintiți trei lucruri simple:

În multe privințe, Android este foarte diferit de alte sisteme de operare și nu vă puteți da seama imediat. Cu toate acestea, dacă înțelegeți cum funcționează totul, se deschid simplu posibilitati nelimitate... Spre deosebire de iOS și Windows Phone Sistemul de operare de la Google are o arhitectură foarte flexibilă care îți permite să-i schimbi serios comportamentul fără a fi nevoie să scrii cod. În cele mai multe cazuri, este suficient să corectați configurațiile și scripturile necesare.

][ 05.14

În spațiile deschise ale Runetului, este dificil să găsești informații constructive și bine prezentate despre dispozitivul sistemului de operare Android. În cea mai mare parte, informațiile sunt fragmentate și incomplete, nu există o parte introductivă cu Noțiuni de bază, ceea ce face dificilă înțelegerea și înțelegerea de către începători. Fără cunostinte de baza dispozitive și algoritmul sistemului de operare Android, este imposibil să depanați sau să personalizați firmware-ul, să îl dezvoltați pentru sistemul de operare Android. Acesta este ceea ce m-a determinat să scriu acest articol, în care voi încerca, cu obișnuitele și limbaj inteligibil, pentru a transmite lucruri „dificile”.

Materialul vizează în primul rând studiul utilizatorilor obișnuiți și este prezentat ca o excursie introductivă în lumea sistemelor de operare Android. Prin urmare, aici vor fi prezentate informații concise și superficiale fără depresiuni și nuanțe tehnice. Acest material va fi util tuturor celor care se ocupă de flash-ul și personalizarea firmware-ului, dezvoltarea pentru sistemul de operare Android, repararea dispozitivelor mobile sisteme informaticeși un utilizator obișnuit, pentru o mai bună înțelegere a principiilor de funcționare și a capabilităților Android-ului lor "a.

Partiții de memorie internă Android

Memoria internă a unui dispozitiv Android este împărțită în mai multe unități logice (partiții). Iată un aspect clasic al memoriei:

Bootloader- aici este un program (bootloader) care vă permite să rulați sistemul de operare Android, Recovery și alte moduri de serviciu.

Recuperare- după cum sugerează și numele, este instalat aici meniul de inginerie recuperare sau doar recuperare.

Boot- inima sistemului de operare Android, aici se află nucleul, driverele și setările pentru gestionarea procesorului și a memoriei.

Sistem- partiția de sistem, care conține toate fișierele necesare funcționării sistemului de operare Android, parcă folderul Windows pe unitatea dvs. C:\ (în continuare vă veți asocia cu sistemul de operare Windows)

Date- o secțiune pentru instalarea aplicațiilor și stocarea datelor acestora. (Fișiere de program)

Utilizator- acesta este un binecunoscut sdcard sau, mai simplu, un loc pentru fișierele utilizatorului (My Documents) Aici trebuie să facem o digresiune, pentru că plasarea acestei secțiuni are mai multe opțiuni:

Partiția lipsește din memoria internă și, în schimb, este folosită o unitate externă - cea mai populară opțiune. (fig. 1)
În dispozitivele cu memorie mare încorporată, aceasta sectiune văzut ca sdcard și card extern memoria este văzută ca sdcard2 sau extsd (pot exista și alte variante ale numelui). Se găsește de obicei pe dispozitivele cu Android 3.2. (Fig. 2 Opțiunea 1)
Această opțiune a fost înlocuită versiunea anterioara, împreună cu Android 4.0. Secțiunea Utilizator a fost înlocuită cu un folder media pe secțiunea Date, ceea ce a făcut posibilă utilizarea întregii memorie de care dispune utilizatorul pentru instalarea programelor și stocarea datelor, și nu suma pe care producătorul ne-a alocat-o. Cu alte cuvinte, sdcard și datele sunt una. (Fig. 2 Opțiunea 2)

Acum că știm ce și unde se află, să ne dăm seama pentru ce este și cum ne pot fi utile aceste informații.

Să începem cu Bootloader. Acesta este bootloader-ul care lansează Android, recuperare etc. Când apăsăm butonul de pornire, pornește bootloader-ul și dacă nu comenzi suplimentare(Tastele ținute apăsate), pornește boot boot. Dacă combinația de taste a fost apăsată (fiecare dispozitiv are propriul său), atunci pornește, în funcție de comandă, recovery, fastboot sau apx. Figura de mai jos arată clar ce lansează Bootloader și cum sunt interconectate secțiunile.

După cum puteți vedea din Figura 3, secțiunea Recuperare nu afectează încărcarea sistemului de operare Android, dar de ce este nevoie atunci? Să încercăm să ne dăm seama.

Recuperarea este în esență un mic utilitar bazat pe nucleul Linux care se încarcă independent de Android. Funcționalitatea sa standard nu este bogată: puteți reseta dispozitivul la setările din fabrică sau puteți actualiza firmware-ul (descărcat în avans pe cardul SD). Dar, mulțumită meșterilor populari, avem recuperarea modificată prin care puteți instala firmware modificat (personalizat), personaliza Android, crea backup și multe altele. Prezența sau absența recuperării, precum și versiunea acesteia, nu afectează performanța sistemului de operare Android (foarte întrebare frecventă pe forumuri).

Este posibil ca cititorii deosebit de atenți să fi observat un Fastboot în Figura 3. Aceasta este o interfață pentru lucrul direct cu partițiile memoriei interne folosind linia de comandă. Prin intermediul acestuia, puteți să flashați recuperarea, kernel-ul sau o nouă versiune a firmware-ului sau să formatați (ștergeți toate informațiile) această sau acea secțiune.

Întrucât vorbim de interfețe, vreau să vorbesc despre un alt, destul de cunoscut, adb (android debugbridge). Acesta este așa-numitul mod de depanare și se numește așa dintr-un motiv - prin intermediul acestuia puteți monitoriza funcționarea atât a sistemului ca întreg, cât și a aplicațiilor individuale. Dar asta nu e tot, cu adb ajutor poti sa o obtii acces complet la sistemul de fișiere al dispozitivului și modificați fișierele de sistem sau trageți Informații importante când dispozitivul este blocat la încărcare. Nu voi descrie toate funcțiile modului de depanare. scopul meu este să transmit informații generale, nu revizuire detaliată despre funcțiile acestui sau aceluia mod.

După ce ne-am ocupat de teorie, să începem sistemul de operare Android.

Apăsați butonul de pornire - Pornește bootloader-ul, care încarcă Kernel-ul (boot), acesta, la rândul său, pornește sistemul (Sistemul), bine și încarcă deja programe (date) și spațiu de utilizator (utilizator). (Fig. 3)

Acum să mergem la directorul rădăcină și să ne uităm la interiorul sistemului de operare Android în sine:

În această diagramă, am dat doar directoarele necesare cunoștințelor. De fapt, există mai multe dintre ele și este nevoie de un articol întreg pentru a revizui un singur folder de sistem.

Și așa, folderul de date. După cum ați putea ghici din nume, este cumva legat de date, dar cu ce date? Da, cu aproape toată lumea, acestea sunt date despre sincronizare și conturi, parole la punctele de acces wifi și setări vpn, etc. Printre altele, puteți găsi aplicația, folderele de date și dalvik-cache aici - luați în considerare scopul lor:

aplicație - programele și jocurile sunt instalate aici.
date - datele aplicației, setările acestora, salvările de joc și alte informații sunt stocate aici.
dalvik-cache - zona de program a memoriei cache pentru programe Dalvik... Dalvik este mașină virtuală Java, care este baza pentru lucrul programelor cu extensia * .apk.
Pentru a face lansarea programelor mai rapidă, se creează memoria cache a acestora.

Folderul System stochează datele de sistem și tot ceea ce este necesar pentru ca sistemul de operare să funcționeze. Să aruncăm o privire la câteva dintre aceste foldere:

aplicație - aplicații de sistem (sms, telefon, calendar, setări etc.), precum și aplicații instalate de producătorul dispozitivului (widget-uri de marcă, imagini de fundal animate etc.) se află aici.
fonturi - fonturi de sistem
media - conține tonuri de apel standard, notificări, alarme și sunete de interfață, precum și animație de pornire (bootanimation)
build.prop - Acest fișier este menționat, aproape primul, în conversații și articole despre reglarea fină a sistemului. Conține un număr mare de setări, cum ar fi densitatea ecranului, timpul de întârziere al senzorului de proximitate, control wifi, numele dispozitivului și producătorul și mulți alți parametri.

Drepturi de root în sistemul de operare Android

Ca în orice sistem asemănător Linux, în sistemul de operare Android, accesul la fișierele și directoarele de sistem se realizează cu drepturile superutilizatorului Root. În această secțiune, am decis să luăm în considerare modul în care funcționează drepturile de superutilizator Android OS, capacitatea de a edita fișiere de sistem sau partiții logice ale spațiului de fișiere dacă aveți drepturi de superutilizator Root.

- Să știi ce este în ce folder este bine, dar poți face ceva în privința asta?

- Da! Dar aveți nevoie de drepturi de superutilizator (root) sau, dacă facem o analogie cu Windows, drepturi de administrator. Inițial, toate dispozitivele Android rulează fără drepturi de root pentru Utilizator final, adică cumpărând un dispozitiv, nu suntem proprietari cu drepturi depline ai acestuia. Acest lucru se face pentru a proteja împotriva malwareși de la utilizatorul însuși - la urma urmei, în mâini inepte, accesul deplin la sistem poate duce la „moartea” sistemului de operare și la necesitatea ulterioară de a rescrie dispozitivul.

— Ei bine, la ce folosește un lucru atât de periculos?- tu intrebi.

Acum hai să vă spunem:

Capacitatea de a face copii de rezervă ale datelor și de a le restaura după intermitent sau ștergere accidentală.
Reglarea fină a sistemului manual sau folosind programe speciale.
Eliminarea aplicațiilor de sistem, tonurilor de apel, imagini de fundal etc.
Schimbarea aspect OS (de exemplu, afișarea încărcării bateriei ca procent)
Adăugarea de funcționalități (suport pentru rețele ad-hoc, de exemplu)

Această listă poate fi continuată mult timp, dar cred că aceste exemple vor fi suficiente pentru a înțelege posibilitățile și amploarea utilizării privilegiilor root.

- Toate acestea sunt grozave, dar acum orice program va putea accesa „inima” sistemului de operare și datele mele?

- Nu. Dumneavoastră decideți dacă permiteți primirea acestei sau acelea aplicații acces root, sau nu. Pentru aceasta, există programul Superuser sau sora sa avansată SuperSU. Nu este posibil să utilizați root fără acest program sau un program similar.

După cum puteți vedea, Android nu este atât de dificil. sistem de operare pentru a înțelege utilizatorul. Dacă ați avut anterior experiență cu sisteme de operare asemănătoare Linux, veți găsi multe asemănări cu sistemele Android, iar această similitudine este rezonabilă. Sistemul Android este derivat din și construit pe deasupra nucleului Linux. Sper că, după ce ați citit articolul, ați învățat ceva nou sau ați primit un răspuns la o întrebare de interes pentru o lungă perioadă de timp.

Fiecare smartphone este format din multe componente complexe și nu te vei gândi întotdeauna la ele înainte de a alege un model de dispozitiv. Dar, cu toate acestea, este important să știți ce hardware vă ajută smartphone-ul să funcționeze.

În acest articol, vom detalia principalele părți ale a ceea ce a devenit unul dintre cele mai importante dispozitive electronice de pe piață. Să luăm în considerare în ce constă un smartphone și pentru ce este aceasta sau acea componentă. Acum există multe modele diferite de smartphone-uri, modele diferite, cu caracteristici diferite, durata de viață a bateriei și așa mai departe. Dar dacă înțelegeți umplutura hardware a unui smartphone, atunci alegerea modelului potrivit va fi mult mai ușoară.

1. Afișare

Una dintre cele mai evidente componente ale unui smartphone este ecranul acestuia. Tot ceea ce vedeți pe ecran este procesat și controlat de componente interne. Există acum două tehnologii pentru realizarea de afișaje:

Ecrane cu cristale lichide, sunt realizate folosind tehnologia IPS sau TFT;
Ecrane LED realizate prin tehnologie AMOLED sau Super AMOLED.

Afișajul cu cristale lichide folosește o lumină de fundal pentru a produce o imagine. Lumina albă trece prin filtre și datorită capacității de a controla proprietățile cristalelor, puteți vedea Culori diferite... Lumina nu este creată de ecranul în sine, ci este creată de sursa de lumină din spatele lui.

Ecranul LED funcționează diferit. Fiecare pixel pe care îl vedeți pe ecran este un LED separat. Aici, ecranul în sine creează culori vibrante și colorate. Avantajul Super AMOLED față de IPS este că atunci când pixelul este oprit, vei vedea negru, nu consumă bateria. Prin urmare, smartphone-urile cu AMOLED sunt mai eficiente pentru durata de viață a bateriei. Dar Ecrane AMOLED mai scump decât IPS, așa că un smartphone cu un astfel de display va costa semnificativ mai mult.

2. Bateria

Smartphone-urile folosesc de obicei baterii litiu-ion și pot fi sau nu detașabile. Datorită acestei tehnologii, nu trebuie să calibrați sau să testați bateria, așa cum faceți cu bateriile pe bază de nichel. Cu toate acestea, aceste baterii au multe probleme proprii.

3. System-on-a-Chip (SoC)

SoC sau placa de baza cu un procesor este cea mai importantă componentă a smartphone-ului tău. Unii utilizatori ar putea crede că acesta este procesorul dispozitivului, dar există mai multe. SoC include nu numai procesorul, ci și GPU, modemul LTE, controler de ecran, adaptoare wireless și alte blocuri de siliciu care fac telefonul să funcționeze.

Există smartphone-uri care folosesc SoC-uri de la Qualcomm, MediaTek, Samsung, cipurile proprii Krirn, Apple, dar toate folosesc aceeași arhitectură - ARM. ARM nu numai că produce procesoare, ci și licenția arhitecturii acestora altor companii, astfel încât toată lumea să poată folosi aceeași tehnologie pentru a crea SoC-uri moderne și puternice.

Mai multe companii își lansează liniile de arhitectură care sunt compatibile cu ARM și pot fi utilizate în smartphone-uri. Un exemplu ar fi chipset-urile Apple care rulează pe procesoare Cyclone sau procesoare Kryo de la Qualcomm. SoC sunt principalele componente care alcătuiesc un smartphone.

4. Intern și RAM

Niciun smartphone nu poate funcționa fără RAM și stocarea sistemului... Majoritatea dispozitivelor folosesc RAM LPDDR3 sau LPDDR4, iar unele modele high-end vin cu LPDDR4X. Combinația de LP înseamnă Putere scăzută, tensiunea de alimentare a acestor microcircuite este redusă, iar acest lucru le face mai eficiente din punct de vedere al consumului de energie.

LPDDR4 este mai eficient decât LPDDR3, iar LPDDR4X este mai eficient și mai economic decât ambele. Există și o memorie și mai afectivă - LPDDR5.

În ceea ce privește stocarea internă, folosește memorie flash de la 32 la 256 GB. Cerințele utilizatorilor sunt în continuă creștere, iar volumele vor crește în conformitate cu acestea. Când porniți telefonul, veți vedea că dimensiunea de stocare este mai mică decât cea menționată. De exemplu, se spune că unitatea este de 64 GB, iar 53-55 GB sunt disponibile pentru înregistrare. Această memorie este ocupată de sistemul de operare și de aplicații.

5. Modemuri

Deoarece smartphone-urile sunt încă telefoane, au nevoie de componente de comunicare pentru a primi și a efectua apeluri, a trimite mesaje textși conexiuni la internet. Pentru asta sunt folosite modemurile. Fiecare producător de SoC are propria sa marcă de modemuri, acestea sunt Qualcomm, Samsung, Huawei și altele.

Fiecare dintre producători încearcă să lanseze cel mai rapid cip LTE. În prezent, cel mai rapid cip 9-LTE, dar nu are sens să îl luați dacă rețeaua dvs. celulară nu acceptă această viteză.

6. Camera foto

Toate smartphone-urile au camere frontale și frontale. Camerele sunt alcătuite din trei părți principale:

Senzor- detectează lumina;
Obiectiv- concentrează imaginea;
Procesor de imagine.

Numărul de megapixeli al camerei unui smartphone este încă un criteriu foarte important, dar acum este mult mai puțin important. Acum principalul factor limitator este senzorul camerei, precum și sensibilitatea acestuia atunci când lumina trece prin el.

Senzorul se poate comporta diferit în fiecare smartphone, astfel încât fotografia sau videoclipul va avea contrast, nuanță, saturație diferit față de alte smartphone-uri. Deoarece smartphone-urile au o dimensiune mică a senzorului, acestea tind să aibă performanțe slabe în condiții de lumină scăzută.

7. Senzori

Cele mai multe smartphone-uri moderne au încorporați cinci senzori principali care vă vor permite să vă folosiți smartphone-ul mai convenabil. Aici sunt ei:

Accelerometru- utilizat de aplicații pentru a determina orientarea dispozitivului și mișcările acestuia. De exemplu, vă permite să utilizați scuturarea smartphone-ului pentru a comuta muzica;
Giroscop- Funcționează cu un accelerometru pentru a detecta rotațiile telefonului. Util pentru jocuri de curse;
Busolă digitală- ajută la găsirea Nordului pentru orientare normală pe hărți;
Senzor de lumina- Acest senzor ajustează automat luminozitatea ecranului în funcție de lumina ambientală și ajută la prelungirea duratei de viață a bateriei.
Senzor de proximitate- în timpul unui apel, dacă dispozitivul se apropie de urechea ta, acest senzor blochează automat ecranul pentru a preveni atingerile nedorite.

Acestea au fost toate elementele principale ale unui smartphone, în diferite modele pot exista alți senzori, de exemplu, un senzor de ritm cardiac, presiune și temperatură, dar sunt mult mai puțin obișnuiți.

concluzii

Am examinat în ce constă un smartphone. Acum că ai mai multe informatii despre componentele complexe care alcătuiesc fiecare smartphone, vă puteți alege viitoarea achiziție comparând caracteristicile diferitelor componente. Acest lucru vă va ajuta să alegeți cel mai bun dispozitiv care se potrivește nevoilor dvs.

V-ați întrebat vreodată cum funcționează fastboot sau ADB? Sau de ce un smartphone Android este aproape imposibil de transformat într-o cărămidă? Sau poate că v-ați dorit de mult să știți unde se află magia cadrului Xposed și de ce sunt necesare scripturile de boot /system/etc/init.d? Ce zici de consola de recuperare? Este o parte din Android sau un lucru în sine și de ce recuperarea regulată nu este potrivită pentru instalarea firmware-ului terților? Veți găsi răspunsuri la toate aceste întrebări și multe alte întrebări în acest articol.

Cum funcționează Android

Puteți afla despre capacitățile ascunse ale sistemelor software, înțelegând cum funcționează acestea. În unele cazuri, este dificil să faceți acest lucru, deoarece codul de sistem poate fi închis, dar în cazul Android, putem examina întregul sistem în interior și în exterior. În acest articol, nu voi vorbi despre toate nuanțele Android și mă voi concentra doar pe modul în care pornește sistemul de operare și ce evenimente au loc în intervalul dintre apăsarea butonului de pornire și apariția desktopului.

Primul pas. ABOOT și tabel de partiții

Totul începe cu bootloader-ul principal. După pornirea alimentării, sistemul execută codul de bootloader scris în memoria permanentă a dispozitivului. Apoi transferă controlul către bootloader-ul aboot cu suport încorporat pentru protocolul fastboot, dar producătorul cipului mobil sau al smartphone-ului / tabletei are dreptul de a alege orice alt bootloader la alegere. De exemplu, Rockchip folosește propriul bootloader, care nu este compatibil cu fastboot, care trebuie reprogramat și gestionat folosind instrumente proprietare.

Protocolul fastboot, la rândul său, este un sistem de control al bootloader-ului de pe un computer care vă permite să efectuați acțiuni precum deblocarea bootloader-ului, flash-ul unui nou kernel și recuperare, instalarea firmware-ului și multe altele. Rațiunea de a fi a fastboot este de a putea readuce smartphone-ul la starea inițială într-o situație în care toate celelalte mijloace nu funcționează. Fastboot va rămâne pe loc, chiar dacă ștergeți experimental toate partițiile NAND care conțin Android și recuperați de pe smartphone.

După ce a primit controlul, aboot verifică tabelul de partiții și transferă controlul către kernel, care este cusat într-o partiție numită boot, după care nucleul preia imaginea RAM din aceeași partiție în memorie și începe să încarce Android sau consola de recuperare. Memoria NAND din dispozitivele Android este împărțită în șase secțiuni necesare condiționat:

boot - conține un nucleu și un disc RAM, de obicei de aproximativ 16 MB;
recovery - consola de recuperare, constă dintr-un nucleu, un set de aplicații de consolă și un fișier de setări, dimensiunea 16 MB;
sistem - conține Android, în dispozitivele moderne are o dimensiune de minim 1 GB;
cache - destinat stocării datelor din cache, este folosit și pentru salvarea firmware-ului în timpul unei actualizări OTA și, prin urmare, are o dimensiune similară cu dimensiunea partiției sistemului;
userdata - conține setări, aplicații și date utilizator, tot spațiul de memorie NAND rămas îi este alocat;
misc - conține un steag care determină în ce mod ar trebui să pornească sistemul: Android sau recovery.

Pe lângă acestea, pot exista și alte secțiuni, cu toate acestea, marcajul general este determinat în faza de proiectare a smartphone-ului și, în cazul aboot, este cusut în codul bootloader-ului. Aceasta înseamnă că: 1) tabela de partiții nu poate fi ucisă, deoarece poate fi întotdeauna restaurată folosind comanda fastboot oem format; 2) pentru a schimba tabelul de partiții, va trebui să deblocați și să actualizați bootloader-ul cu noi parametri. Există, totuși, excepții de la această regulă. De exemplu, bootloader-ul aceluiași Rockchip stochează informații despre partiții în primul bloc de memorie NAND, așa că nu trebuie să flashiți bootloader-ul pentru a-l schimba.

O parte a codului bootloader-ului care definește tabelul de partiții

De un interes deosebit este secțiunea diverse. Există o presupunere că a fost creat inițial pentru a stoca diferite setări, indiferent de sistemul principal, dar în prezent este folosit doar cu un singur scop: pentru a indica bootloader-ului din ce partiție ar trebui să fie încărcat sistemul - boot sau recuperare. Această caracteristică, în special, este utilizată de aplicația ROM Manager pentru a reporni automat sistemul în recuperare cu instalarea automată a firmware-ului. Pe baza sa, este construit mecanismul de pornire dublă Ubuntu Touch, care face ca bootloader-ul Ubuntu să fie restabilit și vă permite să controlați ce sistem să porniți data viitoare. Ștergeți secțiunea misc - încărcare Android, umplut-o cu date - încărcare recuperare ... adică Ubuntu Touch.

Pasul doi. Secțiunea de boot

Dacă secțiunea misc nu are un flag de boot în recuperare, aboot transferă controlul către codul situat în secțiunea de boot. Nu este nimic mai mult decât nucleul Linux; este situat la începutul secțiunii și imediat urmat de o imagine de disc RAM comprimată cpio și gzip care conține directoarele necesare pentru ca Android să funcționeze, sistemul de inițializare și alte instrumente. Nu există niciun sistem de fișiere pe partiția de pornire, nucleul și discul RAM se succed. Conținutul discului RAM este următorul:

date - director pentru montarea partiției cu același nume;
dev - fișiere dispozitiv;
proc - procfs este montat aici;
res - un set de imagini pentru încărcător (vezi mai jos);
sbin - un set de utilități și demoni auxiliare (adbd, de exemplu);
sys - sysfs este montat aici;
sistem - director pentru montarea partiției de sistem;
încărcător - o aplicație pentru afișarea procesului de încărcare;
build.prop - setările sistemului;
init - sistem init;
init.rc - init setările sistemului;
ueventd.rc - setări pentru demonul uventd inclus în init.

Fișierul ueventd.rc este o configurație care determină ce fișiere de dispozitiv din directorul sys ar trebui create la momentul pornirii. Pe sistemele bazate pe kernel Linux, hardware-ul este accesat prin fișiere speciale din directorul dev, iar demonul ueventd, care face parte din init, este responsabil pentru crearea acestora pe Android. În mod normal, funcționează în modul automat, acceptând comenzi pentru a crea fișiere din nucleu, dar unele fișiere trebuie create singur. Ele sunt listate în ueventd.rc.

Directorul sbin din stocul Android de obicei nu conține altceva decât adbd, adică demonul ADB care este responsabil pentru depanarea sistemului de pe PC. Este lansat într-o etapă incipientă a pornirii sistemului de operare și vă permite să identificați posibile probleme în etapa de inițializare a sistemului de operare. În firmware-urile personalizate din acest director puteți găsi o mulțime de alte fișiere, de exemplu mke2fs, care pot fi necesare dacă partițiile trebuie reformatate la ext3 / 4. De asemenea, modderii pun adesea acolo BusyBox, cu ajutorul căruia poți apela sute de comenzi Linux.

Fișierul build.prop este pentru stocarea setărilor Android de nivel scăzut. Mai târziu, sistemul va reseta aceste setări și le va suprascrie cu valorile din fișierul system / build.prop, care nu este încă disponibil.

Secțiunea rădăcină a cutiei TV OUYA

Pasul doi, alternativă. Secția de recuperare

În cazul în care steag-ul de pornire de recuperare în secțiunea diverse este setat sau utilizatorul a pornit smartphone-ul cu tasta de reducere a volumului apăsată, aboot va transfera controlul către codul situat la începutul secțiunii de recuperare. La fel ca partiția de pornire, conține nucleul și un disc RAM, care este decomprimat în memorie și devine rădăcina sistemului de fișiere. Cu toate acestea, conținutul discului RAM este oarecum diferit aici.

Spre deosebire de partiția de pornire, care acționează ca o legătură de tranziție între diferitele etape ale pornirii sistemului de operare, partiția de recuperare este complet autonomă și conține un sistem de operare în miniatură care nu are nimic de-a face cu Android. Recovery are propriul nucleu, propriul set de aplicații (comenzi) și propria interfață care permite utilizatorului să activeze funcții de serviciu.

Folosind scripturi, de exemplu, vă puteți asigura că după descărcare, recuperarea găsește automat firmware-ul necesar pe cardul de memorie, îl instalează și repornește în Android. Această caracteristică este utilizată de Managerul ROM, instrumentele de auto-flasher, precum și de mecanismul de actualizare automată pentru CyanogenMod și alte firmware-uri.

Recuperarea personalizată acceptă, de asemenea, scripturi de rezervă situate în directorul /system/addon.d/. Înainte de a intermite, recuperarea verifică scripturile și le execută înainte de a intermite. Datorită unor astfel de scripturi, gapp-urile nu dispar după instalarea unei noi versiuni de firmware.

Pasul trei. Inițializare

Deci, după ce a primit controlul, nucleul conectează discul RAM și, la finalizarea inițializării tuturor subsistemelor și driverelor sale, începe procesul de inițializare, de la care începe inițializarea Android. După cum am spus mai devreme, init are un fișier de configurare init.rc, din care procesul învață exact ce ar trebui să facă pentru a porni sistemul. În smartphone-urile moderne, această configurație are o lungime impresionantă de câteva sute de linii și este, de asemenea, echipată cu o remorcă cu mai multe configurații copii care sunt conectate la cea principală folosind directiva de import. Cu toate acestea, formatul său este destul de simplu și, de fapt, este un set de comenzi, împărțit în blocuri.

O parte din configurația init.rc de la CyanogenMod

Cea mai notabilă dintre configurațiile suplimentare este initrc.device_name.rc, unde numele dispozitivului este determinat automat pe baza conținutului variabilei de sistem ro.hardware. Este un fișier de configurare specific platformei care conține blocuri de comandă specifice dispozitivului. Pe lângă comenzile responsabile pentru reglarea nucleului, conține și o comandă ca aceasta:

Mount_all ./fstab.device_name

Aceasta înseamnă că init ar trebui să monteze acum toate sistemele de fișiere listate în. / Fstab.device_name, care are următoarea structură:

Device_name (partiție) mount_point file-system fs_options alte opțiuni

De obicei, conține instrucțiuni pentru conectarea sistemelor de fișiere de la partițiile interne NAND la directoarele / system (OS), / data (setările aplicației) și / cache (date în cache). Cu toate acestea, modificând ușor acest fișier, putem forța init să pornească sistemul de pe stick-ul de memorie. Pentru a face acest lucru, este suficient să împărțiți cardul de memorie în trei 4 partiții: 1 GB / ext4, 2 GB / ext4, 1 GB / ext4 și spațiul fat32 rămas. Apoi, trebuie să definiți numele partițiilor cardului de memorie în directorul / dev (diferă pentru diferite dispozitive) și să le înlocuiți cu numele originale ale dispozitivelor din fișierul fstab.

Conținutul tipic al fișierului fstab

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

Pasul patru. Zygote și app_process

La o anumită etapă de încărcare, init va întâlni un bloc ca acesta la sfârșitul configurației:

Service zygote / system / bin / app_process -Xzygote / system / bin --zygote --start-system-server class socket implicit zygote stream 660 root system onrestart write / sys / android_power / request_state wake onrestart write / sys / power / state on onrstart restart media onrstart restart netd

După aceea, Zygote deschide socket-ul / dev / socket / zygote și intră în somn, așteptând date. În acest moment, Activity Manager lansat anterior trimite intenția de difuzare Intent.CATEGORY_HOME pentru a găsi aplicația responsabilă pentru crearea desktopului și îi dă numele lui Zygote prin intermediul soclului. Acesta din urmă, la rândul său, bifurcă și rulează aplicația deasupra mașinii virtuale. Voila, avem un desktop pe ecran, găsit de Activity Manager și pornit de Zygote, și o bară de stare lansată de system_server ca parte a serviciului Status Bar. După atingerea pictogramei, desktopul va trimite o intenție cu numele acestei aplicații, aceasta va fi primită de Managerul de activități și va trimite comanda de pornire a aplicației către demonul Zygote

Toate acestea pot părea puțin confuze, dar cel mai important lucru este să vă amintiți trei lucruri simple:

Servicii de sistem și fire de nucleu

concluzii

În multe privințe, Android este foarte diferit de alte sisteme de operare și nu vă puteți da seama imediat. Cu toate acestea, dacă înțelegeți cum funcționează totul, există pur și simplu posibilități nesfârșite. Spre deosebire de iOS și Windows Phone, sistemul de operare Google are o arhitectură foarte flexibilă care îți permite să-i schimbi serios comportamentul fără a fi nevoie să scrii cod. În cele mai multe cazuri, este suficient să corectați configurațiile și scripturile necesare.

Utilizatorii iPhone de lungă durată știu cum au funcționat primele zile versiunea iOS... De fapt, era un sistem de operare cu o singură sarcină care îți permitea să lucrezi în fundal sau să întrerupi munca. aplicatia curenta numai aplicații preinstalate: citiți o carte, ei vă sună - cititorul de cărți este minimizat, iar pe ecran apare o fereastră de apel. Si aici operare inversă imposibil: cititorul de cărți nu numai că nu poate întrerupe activitatea altor aplicații, dar va fi și ucis imediat după minimizare.

Rațiunea de a fi a unui astfel de sistem este, desigur, de a economisi procesorul, memoria RAM și durata de viață a bateriei. Datorită ei (dar nu numai), iPhone-ul a putut funcționa rapid în condiții de resurse limitate și a fost foarte atent la baterie.

Cum funcționează sistemul de operare Android

Android a funcționat întotdeauna diferit. Aici puteți rula multe aplicații diferite și toate vor rămâne în memorie și pot funcționa chiar în fundal. Deschideți browserul, introduceți adresa și, în timp ce pagina se încarcă, lansați clientul de e-mail și citiți scrisorile. Totul este ca pe un desktop, cu excepția faptului că nu trebuie să vă faceți griji cu privire la închiderea aplicațiilor, sistemul o va face singur atunci când va fi operațional. memoria va face până la sfârșit sau nu va fi suficient să găzduiești aplicația care se lansează (desigur că aplicațiile rar folosite vor fi consumate în primul rând). Acest mecanism se numește lowmemorykiller.

Ca root, setările lowmemorykiller pot fi ajustate direct sau folosind aplicații speciale

Un element important al sistemului multitasking au fost serviciile. Acestea sunt componente speciale ale aplicațiilor care ar putea funcționa în fundal în absolut orice condiții: pe sau în afara ecranului, aplicare minimizată sau implementate, serviciilor nici nu le pasă dacă rulează aplicația părinteîn general. S-a spus doar „Hei Android, am nevoie de resurse CPU, vreau să fac niște calcule” și a primit acele resurse. În terminologia Android, o astfel de solicitare către sistem este numită wakelock(sau mai precis, wakelock-ul procesorului).

Cu toate acestea, susținerea unui instrument atât de puternic și util a făcut o glumă crudă pe Google. A apărut un număr mare de aplicații care produceau servicii pentru fiecare strănut, făceau în mod constant un fel de muncă și nu lăsau smartphone-ul să doarmă. După ce a instalat o sută de aplicații pe un smartphone, utilizatorul a primit câteva zeci de servicii, fiecare dintre ele făcând periodic ceva (actualizarea fluxului Twitter în timp ce telefonul doarme este atât de importantă).

Lucrurile au fost atât de deplorabile încât producătorii chinezi, nu împovărați cu sarcina de a menține compatibilitatea cu Android original(acest lucru este necesar dacă doriți să instalați pe dvs Joacă smartphone-uri Store), pur și simplu a dezactivat mecanismele de menținere a ciclului de viață al serviciilor pentru aplicațiile non-sistem din smartphone-urile lor.

Utilizatorii avansați au mers pe direcția inversă: au obținut privilegii de root și au instalat aplicația Greenify, care le-a permis să înghețe serviciile aplicațiilor selectate, astfel încât nimeni să nu le poată trezi. Au existat și opțiuni mai radicale, de exemplu, de a demola tot software-ul pe care îl folosești mai puțin de o dată pe zi.

Google însuși a luat, de asemenea, măsuri pentru a combate serviciile otrăvitoare. Un mare pas în această direcție a fost făcut în Android 4.4, unde a apărut un mecanism inteligent care a determinat dacă un serviciu rulează prea mult timp și dacă supraîncărca procesorul și, dacă s-a dovedit a fi așa, l-a pus în cuie și a împiedicat-o să pornească. Chiar și la o privire superficială, această versiune a sistemului a trăit pe baterie mult mai mult decât precedentele.

În Android 6.0, Google a mers și mai departe și l-a echipat cu un mecanism Aţipi, care după un anumit timp de inactivitate a smartphone-ului (aproximativ o oră) l-a tradus într-o specială Modul de economisire a energiei... Una dintre caracteristicile acestui mod este interzicerea wakelock-ului, adică nici aplicațiile, nici serviciile nu pot pur și simplu trezi smartphone-ul pentru a face vreo treabă. Ochi, Android 6.0 nu a trăit mai mult, așa că nu se știe dacă acest mecanism a funcționat deloc.

Doze bar de lucru

În cele din urmă, în Android 8.0, Google a făcut un pas radical - interzicerea muncii servicii de fundal... Dar cu două excepții:

Aplicația în unele cazuri, de exemplu, atunci când este pe ecran, poate porni servicii, dar Android le va omorî după ce aplicația intră în stare de repaus.
Serviciile vizibile de utilizator sunt încă permise. Acesta este așa-numitul serviciu de prim plan, un serviciu care este vizibil în panoul de notificări și are o pictogramă în bara de stare.

S-ar părea, da, serviciile sunt rele, dar acum cum pot fi aplicații precum antifurt, care ar trebui să funcționeze invizibil în fundal? Sau același client de e-mail? Din cauza necesității de a vă verifica periodic e-mailurile, ar trebui să se blocheze în bara de notificări?

Nu chiar. Google se îndreaptă spre interzicerea serviciilor încă din versiunea 5.0, unde așa-numitul JobScheduler... Acesta este un subsistem special care permite aplicațiilor să solicite Android să facă o anumită treabă la un anumit moment sau când are loc un astfel de eveniment (o conexiune la Internet, de exemplu). Și da, JobScheduler seamănă foarte mult cu o funcție similară de la iOS.

Liant

Contrar credinței populare, Android a folosit sandbox-uri pentru a izola aplicațiile încă de la cele mai vechi versiuni. Și au fost implementate într-un mod foarte interesant. Fiecare aplicație a fost lansată separat utilizator Linuxși astfel avea acces doar la directorul său din interiorul / data / data.

Aplicațiile ar putea comunica între ele și cu sistemul de operare numai prin mecanismul IPC Liant, care necesita autorizare pentru a efectua o acțiune. Același mecanism a fost folosit în mai multe alte scopuri: cu ajutorul său, sistemul notifică aplicațiile despre evenimentele din sistem, cum ar fi un apel primit, un SMS primit, conectarea unei taxe și așa mai departe. Aplicațiile au primit mesaje și le-au putut răspunde.

Binder este furnizat de un driver în kernel-ul Linux și Service Manager

Această caracteristică a oferit Android capabilități foarte bogate de automatizare despre care știm din aplicații precum Tasker, Automate sau Locale. Toate aceste aplicații sunt disponibile și pentru Android 8, cu excepția faptului că unele funcții periculoase, cum ar fi activarea/dezactivarea modului avion, sunt acum interzise din aplicațiile normale.

Sistemul de avertizare se bazează pe intentie, un mecanism special implementat peste Binder și conceput pentru a face schimb de informații între aplicații (sau OS și aplicații), precum și pentru a lansa componente ale aplicației. Folosind intentii, puteți notifica aplicațiilor despre evenimente, puteți cere sistemului să deschidă o aplicație pentru a procesa anumite tipuri de date (de exemplu, pentru a deschide o anumită paginăîn browser, este suficient să trimiteți o intenție de difuzare cu un link către pagină, iar toate aplicațiile capabile să afișeze pagini web vor răspunde la aceasta, sau doar browserul implicit) sau pur și simplu lansați o componentă a unei aplicații. De exemplu, aplicațiile din Android sunt lansate nu direct, ci folosind intenții.

Din păcate, ca și serviciile, intențiile au devenit o problemă pentru utilizatorii Google și Android. Faptul este că intențiile de difuzare folosite pentru a notifica aplicațiile despre evenimente ajung imediat la toate aplicațiile care au declarat că sunt capabile să răspundă la ele. Și pentru ca aplicația să poată reacționa la intenție, trebuie lansată. Imaginea arată astfel: există douăzeci de aplicații pe un smartphone care pot răspunde intenției android.net.conn.CONNECTIVITY_CHANGE și de fiecare dată când vă conectați la rețea și vă deconectați de la ea, sistemul lansează aceste aplicații astfel încât să poată răspunde la intentie. Cum afectează acest lucru consumul de energie - imaginați-vă.

Google a corectat din nou această neînțelegere în Android 8.0. Aplicațiile pot înregistra acum gestionanții de intenții de difuzare numai în timp ce rulează (cu câteva excepții).

servicii Google

Google îi place să etaleze că Android este un sistem de operare open source. Acest lucru, desigur, nu este în întregime adevărat. Pe de o parte, cod Android cu adevărat deschis și de aceea avem acces la atât de multe firmware-uri personalizate diferite. Pe de altă parte, construind Android din surse oficiale, obțineți un sistem fără câteva componente importante: 1) drivere individuale, al căror cod sursă este ascuns de producător ca secret comercial, 2) servicii Google, care sunt necesare în primul rând pentru a obține acces la contul dvs., lansați Google playși backup în cloud.

Serviciile Google Mobile sunt, de asemenea, responsabile pentru multe alte lucruri, inclusiv suport pentru notificări push, aplicații instantanee, Hărți Google, acces la calendar, determinarea locației prin turnuri celulare și routere Wi-Fi, mecanism Smart Lock, permițându-vă să deblocați dispozitivul în funcție de anumite condiții.

V versiuni moderne Servicii Android Google și-a asumat atât de mult din muncă încât viața fără ele se dovedește a fi, deși posibil, foarte problematică. Și nici cu ei nu este distractiv: versiunea minimă a pachetului GApps (care conține doar servicii Google și Google Play) cântărește mai mult de 120 MB, iar serviciile în sine sunt renumite pentru dragostea lor pentru RAM și puterea bateriei. Și sunt și ele închise, adică doar Google însuși știe ce pot face.

Descărcați pachetul cu servicii și Aplicatii Google pentru firmware personalizat, puteți de pe site-ul web opengapps.org (cuvântul deschis nu înseamnă că sunt deschise)

De aceea a luat naștere proiectul microG, a cărui sarcină este să recreeze cea mai importantă funcționalitate a serviciilor Google în open source. Deja, microG vă permite să vă accesați contul, să activați notificările push, să accesați hărțile Google și să determinați locația prin turnuri celulare. Și toate acestea la o dimensiune de patru mega și aproape absență completă Cerințe de memorie RAM și baterie.

Proiectul are propriul ansamblu de firmware LineageOS, care include microG și toate modificările necesare funcționării sale.

Nucleul Linux și timpul de rulare

Android se bazează pe nucleul Linux. Nucleul gestionează resursele smartphone-ului, inclusiv accesul la hardware, gestionarea memoriei RAM și a memoriei numai în citire, pornirea, oprirea și transferul proceselor între nucleele procesorului și multe alte sarcini. Ca și în cazul oricărui sistem de operare, nucleul este inima Androidului, nucleul fără de care totul s-ar prăbuși.

Layer Pie Android

Prezența unui nucleu Linux, precum și a unui mediu de rulare parțial compatibil cu POSIX (în primul rând o bibliotecă bionică bazată pe implementare bibliotecă standard Limbajul C de la OpenBSD) face Android compatibil cu aplicațiile Linux. De exemplu, sistemul de autentificare wpa_supplicant utilizat pentru a se conecta la rețelele Wi-Fi este exact același ca în orice distribuție Linux... V versiuni timpurii Android a folosit stiva standard de bluetooth Linux numită bluez (înlocuită ulterior de implementarea Qualcomm numită Bluedroid). Are chiar și propria sa consolă cu un set de comenzi standard UNIX / Linux implementate în setul Toybox, creat inițial pentru sistemele Linux încorporate.

Cele mai multe aplicații de consolă scrise pentru Linux pot fi portate pe Android prin recompilare simplă folosind un compilator încrucișat (principalul este să utilizați compilarea statică pentru a nu obține un conflict de bibliotecă), iar având drepturi de root, puteți rula un program complet. unul pe un dispozitiv Android fără probleme. Un avertisment - va fi posibil să-l accesați fie numai prin consolă, fie folosind o conexiune VNC. Există, de asemenea, un proiect Maru OS care vă permite să vă folosiți smartphone-ul ca PC bazat pe Debian atunci când este conectat la un monitor. Aceeași funcție promite atunci când vă conectați smartphone-urile la monitor folosind stația de andocare DeX.

Mc vechi bun care rulează în Android

Începând cu versiunea 4.4, Android este capabil să utilizeze sistemul de control al accesului forțat SELinux pentru a se proteja împotriva hackingului și a obținerii drepturi root... SELinux este dezvoltat de Agenția Națională de Securitate din SUA și, fără a intra în detalii, vă permite să restricționați aplicațiile (inclusiv componentele de sistem de nivel scăzut) în capabilități. Și nu este vorba despre permisiunile pe care utilizatorul le acordă aplicațiilor, ci despre lucruri precum apelurile de sistem și accesul la anumite fișiere, indiferent de permisiunile standard UNIX.

O serie de vulnerabilități Stagefright care au lovit Android în urmă cu câțiva ani au făcut posibilă obținerea controlului asupra dispozitivului, forțând pur și simplu utilizatorul să deschidă MMS-ul primit sau fișierul special în browser. Problema a fost cu cadrul multimedia Stagefright care conținea mai multe vulnerabilități de depășire a memoriei tampon. La deschiderea unui fișier multimedia pregătit special, exploit-ul a exploatat vulnerabilitatea și a rulat codul pe dispozitiv în numele Stagefright (care a funcționat sub rădăcină).

Google a închis cu succes toate aceste erori și a lucrat, de asemenea, la modularizarea codului cadru și lansarea acestuia în domenii speciale SELinux. Aceste domenii împiedică componentele media să folosească majoritatea apelurilor de sistem Linux, inclusiv apelurile de sistem de grup execve care au fost implicate în rularea codului rău intenționat.

SELinux este folosit astăzi pentru a proteja aproape toată lumea componentele sistemului Android. Și acesta a fost motivul pentru o scădere bruscă a numărului de erori găsite în Android. Dar a condus la concentrarea crackerilor asupra nucleului, sau mai degrabă acei drivere foarte închise, al căror cod nu a fost auditat și a căror securitate nu a fost garantată (și, după cum s-a dovedit, este într-o stare deplorabilă).

(1 estimări, medie: 5,00 din 5)