middleware, este un set de biblioteci (Biblioteci), concepute pentru a rezolva sarcini tipice care necesită o eficiență ridicată. Adică, acest nivel este responsabil pentru furnizarea de algoritmi implementați pentru niveluri superioare, suportarea formatelor de fișiere, codarea și decodarea informațiilor (de exemplu, codecuri multimedia), redarea graficelor și multe altele. Bibliotecile sunt implementate în C/C++ și compilate pentru un anumit Hardware dispozitiv, cu care sunt furnizate de producător într-o formă preinstalată.

Iată câteva dintre bibliotecile de nivel scăzut:

1. Surface Manager - Android folosește un manager de ferestre compozit similar cu Compiz (Linux), dar mai primitiv. În loc să deseneze grafice direct în buffer-ul de afișare, sistemul trimite comenzi de desenare primite în buffer-ul offscreen, unde acestea sunt acumulate împreună cu altele, formând o compoziție și apoi afișate utilizatorului pe ecran. Acest lucru permite sistemului să creeze efecte interesante fără întreruperi, să realizeze transparența ferestrei și tranziții netede.
2. Media Framework - biblioteci implementate pe baza PacketVideo OpenCORE. Cu ajutorul lor, sistemul poate înregistra și reda date audio și video, precum și poate scoate imagini statice. Sunt acceptate multe formate populare, inclusiv MPEG4, H.264, MP3, AAC, AMR, JPG și PNG. În viitor, OpenCORE ar trebui să fie înlocuit cu un cadru Stagefright mai simplu.
3. SQLite este un motor de baze de date relaționale ușor și de înaltă performanță, utilizat de Android ca principal motor de bază de date.
4. Biblioteci 3D - utilizate pentru desenul extrem de optimizat al graficelor 3D, dacă este posibil accelerare hardware. Implementările lor se bazează pe API-ul OpenGL ES 1.0.
5. FreeType este o bibliotecă pentru lucrul cu hărți de biți, precum și pentru rasterizarea fonturilor și efectuarea de operațiuni asupra acestora. Acesta este un motor de înaltă calitate pentru fonturi și redarea textului.
6. LibWebCore - biblioteci ale celebrului motor de browser WebKit, folosite și pe desktop browsere Google Chrome și Apple Safari.
7. SGL (Skia Graphics Engine) este un motor deschis pentru lucrul cu grafica 2D. Biblioteca de grafică este un produs Google și este adesea folosită în celelalte programe ale acestora.
8. SSL - biblioteci pentru suportul protocolului criptografic cu același nume bazat pe OpenSSL.
9. libc este o bibliotecă standard în limbaj C similară cu glibc (GNU libc de la Linux) pentru dispozitive mici. Se numește Bionic.

Orez. 1.5.

La același nivel, se află Android Runtime - mediul de execuție a programului aplicației. Componentele sale cheie sunt un set de biblioteci standard și mașină virtuală Dalvik. Fiecare aplicație Android rulează în propria instanță mașină virtuală Dalvik. Astfel, toate procesele care rulează sunt izolate de sistem de operare si unul de altul. Arhitectura Android Runtime este de așa natură încât munca programelor se desfășoară strict în cadrul mediului de mașină virtuală. Datorită acestui fapt, nucleul sistemului de operare este protejat de posibile daune cauzate de celelalte componente ale sale. Prin urmare, codul buggy sau malware nu vor putea corupe sistemul de operare Android și dispozitivul bazat pe acesta. Astfel de functie de protectie, împreună cu execuția codului de program, este una dintre cheile Android Runtime.

Un strat de deasupra este Cadrul de aplicație, uneori denumit stratul de cadru de aplicație. Prin intermediul cadrelor de aplicație, dezvoltatorii obțin acces la API-urile furnizate de componentele de bază ale sistemului. În plus, datorită arhitecturii framework-ului, orice aplicație este prevăzută cu capabilitățile deja implementate ale altor aplicații care au voie să fie accesată. Setul de bază de servicii și sisteme care stau la baza fiecărei aplicații și care fac parte din cadru include:

1. Un set bogat și extensibil de vizualizări (Vizualizări) care poate fi folosit pentru a crea componente vizuale ale aplicației, cum ar fi liste, câmpuri de text, tabele, butoane sau chiar un browser web încorporat.
2. Furnizori de conținut, care gestionează datele pe care o aplicație le expune alteia, astfel încât să le poată folosi pentru munca lor.
3. Manager de resurse, care oferă acces la resurse care nu poartă cod, cum ar fi date șiruri, grafice, fișiere și altele.
4. Notification Manager, prin care toate aplicațiile își pot afișa propriile notificări pentru utilizator în bara de stare.
5. Managerul de activități, care gestionează ciclurile de viață ale aplicațiilor, stochează datele din istoricul activității și oferă un sistem de navigare pentru acestea.
6. Manager de locație, care permite aplicațiilor să primească periodic actualizări privind locația geografică curentă a dispozitivului.

În partea de sus a stivei de software Android se află stratul Aplicații. Acesta include un set de aplicații de bază care este preinstalat pe sistemul de operare Android. De exemplu, include un browser, client de mail, program pentru trimiterea de SMS-uri, hărți, calendar, manager de contacte și multe altele. Lista aplicațiilor integrate poate varia în funcție de modelul dispozitivului și versiuni Android. Și pe lângă acest set de bază, stratul de aplicații include toate aplicațiile de aplicație pentru platforma Android, inclusiv cele instalate de utilizator.

De regulă, aplicațiile pentru Android sunt scrise în Java, dar este posibil să se dezvolte programe în C / C ++ (folosind Native Development Kit). Exoticele pot fi numite utilizarea Basic (folosind Simplu) și alte limbi. Puteți, de asemenea, să vă creați propriile programe folosind creatori de aplicații, cum ar fi App Inventor.

1.6. Caracteristicile kernelului

Nucleul este cea mai importantă parte a sistemului de operare Linux și, spre deosebire de celelalte părți ale sale, a fost portat aproape complet pe sistemul de operare Android. Cu toate acestea, aproximativ 250 de patch-uri au fost aplicate pe nucleu în timpul procesului de portare.

În nucleul sistemului de operare Android, s-a decis să se abandoneze facilitățile de comunicare între procese ale sistemului de operare Linux și să se creeze un singur mecanism numit Binder. Binder permite ca metodele unui proces să fie apelate din interiorul altui proces, transmițându-le argumente și obținând un rezultat, similar modului în care sunt apelate metodele în cadrul aceluiași proces. Binder face această treabă cu o utilizare minimă a memoriei.

Pentru a asigura depanarea pe dispozitive mici, informațiile de depanare au fost adăugate la kernel în port serial și a implementat suport pentru comanda logcat.

Schimbări mari au atins munca cu memorie. Tradiționalul Linux shared memory shmem a fost înlocuit cu ashmem. Aceeași problemă, dar la nivel de memorie fizică, este rezolvată folosind driverul pmem. S-a adăugat un handler special în afara memoriei numit Viking Killer, în cel mai simplu caz, doar oprește procesul, dar pot fi specificate reguli mai complexe.

Noi setări de securitate au fost adăugate la stiva de rețea, suport pentru Sistemul de fișiere pentru media flash, YAFFS2 este inclus în nucleu.

1.7. Mașină Java Dalvik

Dalvik Virtual Machine face parte din mobil Platforme Android. Acest mașină virtuală de Dan Bronstein. Se răspândește ca software gratuit sub licența Apache 2.0 compatibilă cu BSD. În mare măsură, acest fapt a jucat un rol în Soluție Google drop JME (Java Micro Edition), care ar trebui să fie licențiat de la Sun. Prin urmare, o corporație al cărei scop a fost să creeze un sistem de operare deschis și-a dezvoltat propria mașină virtuală.

Spre deosebire de majoritatea mașinilor virtuale (aceeași mașină virtuală Java), care sunt orientate spre stivă, Dalvik este orientat pe cazuri, ceea ce nu poate fi numit o soluție standard. Pe de altă parte, este foarte potrivit pentru a lucra pe procesoare cu arhitectură RISC, care includ procesoare ARM, care sunt utilizate pe scară largă în dispozitivele mobile.

Dalvik a fost conceput special pentru platforma Android. S-a luat în considerare faptul că platforma construiește toate procesele ca fiind izolate, fiecare rulând în propriul spațiu de adrese. Mașină virtuală optimizat pentru consum redus de memorie și lucru pe hardware mobil. Începând cu Android 2.2., Dalvik folosește compilarea JIT (just-in-time). Ca urmare a acestor caracteristici, un rapid și productiv mașină virtuală, care nu poate decât să afecteze funcționarea aplicațiilor în general.

Dalvik folosește propriul bytecode. Când se dezvoltă aplicații pentru Android, acestea sunt traduse de compilator într-un cod special de nivel scăzut, independent de mașină. Când este executat pe o platformă, Dalvik este cel care interpretează și execută un astfel de program.

În plus, Dalvik este capabil să traducă codurile de octet Java în coduri în format nativ și, de asemenea, să le execute în propriile sale mediu virtual. Cod program scris în Java, iar după compilare, totul. Fișierele de clasă sunt convertite în format .dex (potrivit pentru interpretare de către Dalvik) folosind utilitarul special dx inclus cu Android SDK.

1.8. Bionic

Bionic este o bibliotecă de apeluri standard C distribuită sub licența Berkeley Software Distribution (BSD). softwareîn codurile sursă, creat pentru schimbul de experiență între instituțiile de învățământ) și dezvoltat de Google pentru Android. Bionic nu are unele funcții POSIX non-Android disponibile în implementarea completă a glibc.

Principalele diferențe ale bionicului:

1. Licențe BSD: Android folosește nucleul Linux, care se află sub Licența publică generală GNU (GPL), dar Google a ales să izoleze aplicațiile Android de efectele GPL. Libc-ul GNU care este utilizat în mod obișnuit cu nucleul Linux este licențiat sub GNU LGPL ca alternativă la uClibc.
2. dimensiune mică: codul obiect bionic este mult mai mic (de aproximativ 2 ori) decât glibc și ceva mai mic decât uclibc.
3. bionic este destinat procesoarelor cu viteze de ceas relativ mici.
4. o implementare trunchiată, dar eficientă a firelor de execuție POSIX.

1.9. Prezentare generală a interfețelor de programare a aplicațiilor Java

Pentru programatorul de aplicații Android, un set de interfețe în limbajul Java. Să vedem cum este organizat. Setul se bazează pe pachete incluse în standardul limbajului Java, cum ar fi java.util, java.lang, java.io . Sunt disponibile pe orice platformă unde aplicațiile java pot fi rulate și nu sunt specifice Android. Acestea sunt alăturate de extensii care nu sunt incluse în standardul lingvistic, dar au fost standard de facto de mult timp - pachetele javax.net , javax.xml .

De asemenea, în Android sunt incluse extensii Java mai puțin obișnuite - pachetul org.apache.http, cea mai solidă implementare a protocolului HTTP. Pachetul org.json este responsabil pentru serializarea obiectelor JavaScript și pentru suportul tehnologiei AJAX. Pachetul org.w3c.dom oferă model obiect document

Este posibil ca anumite modele de tablete Android să nu aibă unele dintre elementele enumerate mai sus.

Toate tabletele „android” sunt controlate de una dintre versiunile sistemului de operare mobil de la Google. Cu toate acestea, este posibil ca versiunile mai vechi să nu accepte unele dintre aplicațiile moderne.

Toate versiunile celui mai popular sistem de operare mobil au o bază comună. Ne putem gândi la sistemul de operare Android ca la o structură stratificată. Inginerii informatici o numesc stiva de software. Elementele din partea de sus a stivei sunt ceea ce vede utilizatorul în timpul interacțiunii sale cu sistemul de operare. În „partea de jos” a stivei se află acele părți ale sistemului de operare care interacționează direct cu hardware-ul dispozitivului.

Deci, la cel mai de jos nivel se află componentele hardware în sine: procesoare, senzori, fire și plăci de circuite imprimate. Următorul strat este nucleul sistemului de operare. Nucleul este uneori denumit și software încorporat (sau proprietar). Definiția engleză a „firmware” este mai cunoscută. Acest software controlează resursele hardware ale dispozitivului, le gestionează și le distribuie.

Această parte a sistemului de operare „traduce” în limba componentelor hardware acele comenzi pe care utilizatorul le dă printr-un mod convenabil. GUI. Sistemul de operare Linux 2.6 open source a devenit exemplul de nucleu pentru Android.

Deasupra nucleului sistemului de operare se află bibliotecile Android. Sunt seturi de instrucțiuni pe care dispozitivul le urmează în timpul procesării. tipuri variate date. Un exemplu este Biblioteca de orientare 3D. Conține toate instrucțiunile de care are nevoie un dispozitiv Android pentru a recunoaște și a răspunde la modificările poziției sale în spațiu.

La același nivel al stivei de software se află bibliotecile rădăcină necesare pentru a susține aplicațiile scrise în limbajul Java. Java este un limbaj de programare de la Sun Microsystems. Până de curând, telefoanele cu suport pentru aplicații Java erau foarte comune. În zilele noastre, acestea sunt din ce în ce mai mult înlocuite de smartphone-uri.

Mașina virtuală Android se află la același nivel al stivei de software a sistemului de operare. Această bucată de software se ocupă cu crearea unui mediu de operare virtual, altfel cunoscut ca mediu de operare virtual. O mașină virtuală simulează un dispozitiv fizic cu un sistem de operare separat. Google a proiectat acest strat astfel încât fiecare aplicație care rulează pe sistemul de operare Android să funcționeze ca un proces separat. În acest fel, dacă unul dintre procesele care rulează eșuează, restul va rămâne neafectat. Mașina virtuală joacă, de asemenea, rolul unui manager de memorie.

Următorul strat este cadrul de aplicare. Este baza pentru toate aplicațiile dispozitivului „android”. Infrastructura aplicațiilor este legătura dintre aplicații și restul sistemului de operare.

Google încurajează dezvoltatorii să creeze aplicații care interacționează cu acest nivel în cadrul interfeței de programare a aplicațiilor (API) a sistemului de operare dezvoltat de gigantul căutării. Dezvoltatorii trebuie doar să se familiarizeze cu aceste reguli legate de API. Ei nu trebuie să se gândească specificatii tehnice fiecare tabletă „android”.

Cel mai nivel superior Stiva de software conține interfața cu utilizatorul și toate aplicațiile tabletei „android”. Este această parte a sistemului de operare pe care utilizatorul o vede constant în fața lui. Dar în spatele acestui strat atractiv și colorat se află o mulțime de cod plictisitor și interesant doar pentru specialiști.

Ca orice alt sistem de operare și alte resurse hardware pentru tabletă.

Sursă de la computer.howstuffworks.com

#fapte | Cum este organizat Android? Oleg Dovbnya

Te-ai întrebat vreodată cum funcționează fastboot sau ADB? Sau de ce smartphone-ul este sub Control Android 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 pornire /system/etc/init.d? Ce zici de consola de recuperare? Este această parte din Android sau un lucru în sine și de ce recuperarea obișnuită 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

Invata despre oportunități ascunse sisteme software Puteți înțelege cum funcționează. În unele cazuri, acest lucru este dificil de făcut, deoarece codul de sistem poate fi închis, dar în carcasa Android putem studia întregul sistem în interior și în exterior. În acest articol nu voi vorbi despre toate nuanțele lucru 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 caracteristici pentru a implementa lucruri precum reglarea parametrilor sistemului de operare, extinderea spațiului de stocare a aplicațiilor, activarea schimbului, 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. ABOOT și tabel de partiții

Totul începe cu bootloader-ul principal. După ce alimentarea este pornită, sistemul execută codul bootloader-ului stocat î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 său, incompatibil bootloader fastboot, pentru reprogramare și gestionare a cărora trebuie să utilizați instrumente proprietare.

Protocolul fastboot, la rândul său, este un sistem de gestionare a 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. Scopul fastboot-ului este de a putea restabili smartphone-ul la starea inițială într-o situație în care toate celelalte mijloace eșuează. Fastboot va rămâne pe loc chiar dacă, în urma experimentelor, ștergeți toate secțiunile memoriei 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-ul flash în partiția numită boot, după care nucleul extrage 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 obligatorii condiționate:

• boot - conține nucleul și discul RAM, de obicei în jur de 16 MB;
• recovery - consola de recuperare, constă dintr-un nucleu, un set de aplicații 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 - conceput pentru a stoca date în cache, folosit și pentru a salva firmware-ul î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ție în primul bloc al memoriei NAND, așa că nu este necesară flasharea bootloader-ului pentru a-l schimba.

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

Deosebit de interesantă este secțiunea diverse. Există o presupunere că a fost creat inițial pentru a stoca diverse setari indiferent de sistemul principal, dar în momentul de față este folosit doar pentru un singur scop: pentru a spune bootloader-ului din ce partiție ar trebui să fie încărcat sistemul - boot sau recuperare. Această posibilitate, în special, utilizează aplicația Manager ROM pentru repornire automată sisteme în recuperare cu instalare automată de firmware. Pe baza sa, este construit mecanismul Ubuntu Touch dual boot, care clipește Bootloader Ubuntuîn recuperare și vă permite să controlați ce sistem să porniți în continuare. Ștergeți partiția misc - Android este încărcat, umplut cu date - recuperarea este încărcată ... adică Ubuntu Touch.

Pasul doi. partiția de pornire

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

• 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ări de sistem;
• init - sistem de initializare;
• init.rc - setarile sistemului de initializare;
• 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 lucrărilor de pornire a sistemului. Elementul central aici este aplicația init și configurația sa init.rc, pe care le voi trata mai detaliat mai târziu. Între timp, vreau să fiu atent la fișierele încărcător și ueventd.rc, precum și directoarele sbin, proc și sys.

Fișierul încărcător este o aplicație mică a cărei unică sarcină este să afișeze pictograma 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 pornește nucleul, conectează discul RAM și pornește încărcătorul. Acesta din urmă afișează pictograma 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 definește ce fișiere de dispozitiv din directorul sys ar trebui create în etapa de pornire a sistemului. În baza nucleului 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 circumstanțe normale, funcționează în mod automat, acceptând comenzi pentru a crea fișiere din nucleu, dar unele fișiere trebuie create de dvs. Acestea sunt listate în ueventd.rc.

directorul sbin stoc Android de obicei nu conține decât adbd, adică demonul ADB, care este responsabil pentru depanarea sistemului de pe PC. Începe într-un stadiu incipient al pornirii sistemului de operare și vă permite să identificați posibile problemeîn timpul inițializării OS. ÎN firmware personalizatîn acest director puteți găsi o grămadă de alte fișiere, cum ar fi mke2fs, care pot fi necesare dacă partițiile trebuie reformatate la ext3/4. De asemenea, modderii pun adesea acolo un BusyBox, cu care poți apela sute de comenzi Linux.

Directorul proc pentru Linux este standard, în următorii pași de boot init va conecta procfs la el, 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. Cu 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 destinat să stocheze la nivel scăzut setări Android. Mai târziu, sistemul va reseta aceste setări și le va suprascrie cu valori din fișierul system/build.prop, care nu este încă disponibil.

OUYA TV Box Root Partition​

Pasul doi, alternativă. sectia de recuperare

În cazul în care este setat indicatorul de pornire de recuperare în secțiunea diverse sau utilizatorul a pornit smartphone-ul în timp ce ține apăsată tasta de reducere a volumului, 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 boot, care acționează ca o legătură de tranziție între diferitele etape de pornire a 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. Recuperarea are propriul său nucleu, propriul set de aplicații (comenzi) și propria interfață care permite utilizatorului să activeze funcții utilitare.

Într-o recuperare 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. În recuperarea modificată de la terți, cum ar fi ClockworkMod și TWRP, există mult mai multe funcții. Pot formata sisteme de fișiere, pot instala firmware semnat cu orice cheie (a se citi: personalizat), pot monta sisteme de fișiere pe alte partiții (pentru depanarea sistemului de operare) și pot include suport pentru scripturi care vă permite să automatizați procesul de firmware și multe alte funcții.

Cu ajutorul scripturilor, de exemplu, puteți face astfel încât după încărcare recuperare să găsească automat pe cardul de memorie firmware-ul necesar, le-a instalat și le-a repornit în Android. Această caracteristică este utilizată de Managerul ROM, instrumentele de auto-flash și actualizare automata CyanogenMod și alt firmware.

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ă instalare versiune noua firmware.

Pasul trei. Inițializare

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

Fiecare bloc definește stadiul de încărcare sau, în limbaj dezvoltatori Android, 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 comenzi va fi executat numai dacă se declanșează declanșatorul cu același nume. Pe măsură ce pornește, init va declanșa pe rând declanșatoarele early-init, init, early-fs, fs, post-fs, early-boot și boot, rulând astfel blocurile de comandă corespunzătoare.

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

Dacă fișierul de configurare trage mai multe configurații enumerate la început (și acesta este aproape întotdeauna cazul), atunci blocurile de comandă cu același nume din interiorul lor vor fi îmbinate cu configurația principală, astfel încât atunci când declanșează declanșatorul, init se 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, iar comenzile specifice pentru fiecare dispozitiv sunt scrise în fișiere separate.

Cea mai notabilă dintre configurațiile suplimentare este initrc.devicename.rc, unde numele dispozitivului este determinat automat pe baza conținutului variabilei de sistem ro.hardware. Acesta 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 ceva de genul acesta:

mount_all ./fstab.devicename

Înseamnă că init ar trebui să monteze acum toate sistemele de fișiere listate în fișierul ./fstab.devicename, 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 secțiuni: 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 cu ele numele originale ale dispozitivelor din fișierul fstab.

Conținutul tipic al unui fișier fstab​

La sfârșitul blocului de pornire, init va întâlni cel mai probabil comanda implicită class_start, care vă va spune să porniți toate serviciile listate în config care sunt legate de clasa implicită. Descrierile serviciilor încep 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, așa că pe toată durata de viață a smartphone-ului, init va rămâne în fundal și va monitoriza acest lucru.

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
implicit de clasă
socket zygote stream 660 sistem rădăcină
onrestart scrie /sys/android_power/request_state wake
onrestart scrie /sys/power/state on
repornire repornire media
onrestart restart netd

Aceasta este o descriere a serviciului Zygote, o componentă cheie a oricărui sistem Android care este responsabil pentru inițializare, pornire. servicii de sistem, porniți și opriți aplicațiile personalizate și multe alte sarcini. Zygote este lansat folosind o aplicație mică /system/bin/app_process, care este foarte clar vizibilă în partea de configurare 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 și apoi să ruleze Zygote deasupra acesteia.

Când toate acestea sunt făcute și Zygote are controlul, începe să construiască mediul de rulare Java prin încărcarea tuturor claselor Java ale cadrului (în prezent peste 2000). Apoi pornește system_server, care include majoritatea serviciilor de sistem de nivel înalt (scrise în Java), inclusiv Managerul de ferestre, Bara de stare, Managerul de pachete și, cel mai important, Managerul de activități, care în viitor va fi responsabil pentru primirea aplicațiilor semnalelor de pornire și de sfârșit.

După aceea, Zygote deschide socket-ul /dev/socket/zygote și intră în somn, așteptând date. În acest moment, Activity Manager lansat anterior difuzează intenția Intent.CATEGORY_HOME de a găsi aplicația responsabilă pentru crearea desktopului și îi dă numele lui Zygote peste socket. Acesta din urmă, la rândul său, bifurcă și rulează aplicația deasupra mașinii virtuale. Voila, avem un desktop găsit pe ecran de Activity Manager și lansat de Zygote și o bară de stare lansată de system_server ca parte a serviciului Status Bar. După ce atingeți pictograma, desktopul va trimite o intenție cu numele acestei aplicații, aceasta va fi acceptată de Managerul de activități și va transmite comanda de pornire a aplicației demonului 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 dintr-o lovitură. Cu toate acestea, dacă înțelegeți cum funcționează totul, posibilitățile sunt pur și simplu 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.

Sistem de fișiere OS Android

așa că în acest articol, după cum probabil ați ghicit din titlu, vom vorbi despre structura de ansamblu sistem de fișiere Android. Descrierea directoarelor principale, metode de formatare, backup etc.. articolul se adreseaza in principal incepatorilor. Sper că și altora le va face plăcere să o citească.
structura sistemului de fișiere linux

în Android nu există discuri familiare pentru mulți - cum ar fi c sau e. Avem rădăcina sistemului de fișiere: "". toate celelalte directoare sunt atașate la directorul rădăcină. Să luăm în considerare câteva dintre ele:

sistem- după nume puteți deja ghici că fișierele de sistem se află aici (ceva așa cum putem vedea în viespi de la Microsoft c: Windows). Fișierele din acest folder sunt imuabile în mod implicit. Sunt destinate funcționării sistemului de operare. De asemenea, aici sunt aplicații încorporate în sistemul de operare. Dacă obținem drepturi de root, putem face modificările în acest director. Cu toate acestea, acest lucru trebuie făcut cu atenție deoarece fișiere șterse iar folderele nu se vor recupera de la sine. În acest caz, doar intermiterea sau backupul ne va ajuta. Ceva interesant poate fi găsit în folder systemmedia. Arhivat bootanimation.zip Există imagini care alcătuiesc animația atunci când dispozitivul este pornit. Chiar și la rădăcina folderului de sistem, puteți găsi fișierul construi.prop care conține multe setări, de la descrierea dispozitivului până la densitatea ecranului (sunt multe aplicații terță parte).ecran

Date- spre deosebire de sisteme, acestea sunt stocate aici fișiere mutabile. În subcategorie aplicația doar depozitat apk instalat programele noi. ecran

Dacă avem nevoie de fișierul apk al oricărei aplicații, atunci îl putem găsi cu ușurință acolo. Si in date aceste programe instalate.
Mnt-memoria utilizatorului este montată în această secțiune (dacă, de exemplu, este instalată un card flash). Astfel, dacă punem fișierul nostru txt în rădăcina cardului flash, atunci calea completă va arăta astfel: mntsdcard file.txt". Discul încorporat este montat și aici pentru smartphone-uri fără suport pentru carduri de memorie. ecran

Cum să ștergeți (resetarea din fabrică) pe Android

Există mai multe moduri de formatare. Despre câteva dintre ele mai jos.
1. resetați prin setări. Accesați setări >> restaurare și resetare >> resetare din fabrică. Resetează toate setările și elimină software-ul instalat. Înainte de aceasta, puteți face backup pentru unele setări bifând elementul corespunzător. După repornire, dispozitivul va întreba dacă să restabilească aceste date.
ecran

2. resetare prin recuperare. Util în situația în care dispozitivul nu pornește. Veți avea nevoie de acces root și de o recuperare instalată în consecință. Depinzând de recuperare instalată locațiile pot varia. Am acest articol cu ​​ștergere avansată. Contine:
cache dalvik- formatarea cache-ului mașinii virtuale dalvik.
Sistem- formatarea partiției de sistem.
Date– ștergerea tuturor aplicațiilor terță parte din memoria dispozitivului, precum și a setărilor utilizatorului.
cache - șterge memoria cache
formatați cardul sd– Formatați cardul de memorie. Ștergeți totul de pe cardul de memorie.
format sd-ext– formatarea unei partiții ext pe cardul de memorie (dacă a fost creată o astfel de partiție. De exemplu, pentru a monta scriptul aplicației de referință la instalarea pe card).
3. formatare cu un cod de serviciu. Dacă formați * 2767 * 3855 # . imediat după apelare, acesta va fi resetat. Ai grija.
De exemplu, ștergerea conținutului unui folder date vom șterge setările și datele aplicației, dar nu și aplicațiile în sine. Acest lucru se poate face și din setările aplicației „Ștergere date”. Când ștergeți un folder, data va fi ștearsă aplicații instalate.
Dorințe, amendamente, completări la articol, vă rog să lăsați în comentarii sau pe mine într-un personal. articolul va fi actualizat. Mulțumesc cititorilor, mult succes.
-----------------
Puteți lăsa comentarii în secțiunea Catalog de articole