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 nivelurile superioare, susținând formate de fișiere, implementarea de codare și decodare a informațiilor (un exemplu sunt codecurile 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 dispozitive mobile Oh.

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 de limbă, 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 de 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 procesul de prelucrare a diferitelor tipuri de 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 strat în cadrul interfeței de programare a aplicațiilor () dezvoltată de sistemul de operare al gigantului de căutare. Dezvoltatorii trebuie doar să se familiarizeze cu aceste reguli legate de API. 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 independent de sistemul principal, dar în acest moment este folosit doar pentru un singur scop: pentru a spune bootloader-ului din ce partiție să pornească 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ările sistemului;
• 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 muncii 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 acestora î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. Ele 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-urile 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 pentru copii 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 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 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 cu 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 poți să-ți dai 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 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 „Ștergeți datele”. 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

• Traducere

În acest articol, ne vom uita la arhitectura aplicațiilor Android.

Sincer să fiu, nu mi se pare de ajutor Google oficial pe acest subiect. În timp ce răspunde la întrebarea „cum” în detaliu, nu explică deloc „ce” și „de ce”. Așa că iată versiunea mea și sper că va aduce puțină claritate. Apropo, aprob total citirea articolelor Google așa cum le conțin Informatii utile pe care nu am de gând să-l repet.

Arhitectura sistemului de operare Android - un pic de istorie

Așa cum este adesea cazul în IT, multe lucruri nu pot fi explicate izolat de istoria unui anumit software. De aceea trebuie să ne întoarcem la originile sistemului de operare Android.

Dezvoltarea sistemului de operare Android a fost începută în 2003 de o companie tânără numită Android Inc. În 2005, această companie a fost cumpărată de Google. Consider că principalele caracteristici ale arhitecturii Android au fost definite în această perioadă. Acesta nu este doar meritul Android Inc; conceptele arhitecturale și resursele financiare ale Google au avut o influență decisivă asupra arhitecturii Android. În continuare, voi da câteva exemple.

Dacă vă amintiți, anii 2003-2005 au fost marcați de o atenție sporită acordată aplicațiilor AJAX. Cred că acest lucru a avut un impact fundamental asupra arhitecturii Android: în multe privințe este mai aproape de arhitectura unei aplicații tipice AJAX decât de o aplicație desktop GUI scrisă în Java, C#, C++, VB etc.

Nu știu de ce sa întâmplat. Bănuiesc că cineva de la Google a venit cu asta într-un moment în care Rich Internet Applications (RIA) era în sensul documente Google sau Gmail au fost considerate soluția tuturor problemelor. Nu cred că această idee este bună sau rea. Nu uitați că aplicațiile Android sunt foarte diferite de aplicațiile desktop.

Influența filozofiei arhitecturale Eclipse este vizibilă în alegerea principiului implementării GUI, care seamănă mai mult cu SWT decât Swing.

Standardele de proiectare a codului Android includ „notația maghiară”, născută între zidurile MS. Se poate presupune că persoana care a scris aceste standarde a dezvoltat anterior sub Windows.

Niveluri arhitecturale Android

Sistemul de operare Android are trei straturi foarte diferite și foarte separate:

1. Se bazează pe o versiune modificată și redusă de Linux, așa cum am menționat într-unul dintre articolele mele anterioare.
2. Deasupra stratului Linux se află stratul de infrastructură a aplicațiilor, care conține mașina virtuală Dalvik, browser web, baza de date SQLite, câteva „cârje” de infrastructură și API-ul Java.
3. Și, în sfârșit, nivelul scris în Google Android Apps. În general, ele reprezintă o extensie a stratului de infrastructură, deoarece dezvoltatorul poate folosi aceste aplicații sau părți ale acestora ca blocuri de construcție pentru propriile dezvoltări.

Să ne uităm la aceste straturi unul câte unul și mai detaliat.

nivelul Linux

Imaginează-ți că ești arhitect într-o companie tânără. Trebuie să dezvoltați un sistem de operare pentru un nou tip de dispozitiv. Ceea ce ai de gând să faci?

În linii mari, ai două moduri: să-ți implementezi propriile idei, pornind de la zero, sau să folosești un sistem de operare existent și să-l adaptezi la dispozitivele tale.

Implementarea de la zero sună întotdeauna interesantă pentru programatori. În aceste momente, cu toții credem că de data aceasta vom face totul mai bine decât fac alții și chiar mai bine decât am făcut noi înșine înainte.

Cu toate acestea, acest lucru nu este întotdeauna practic. De exemplu, utilizarea nucleului Linux a redus semnificativ costul de dezvoltare (poate undeva deja excesiv de mare). De acord, dacă cineva decide să creeze ceva care să semene cu nucleul Linux în starea sa actuală, va avea nevoie de câteva milioane de dolari.

Dacă rulați Android Inc, atunci prin definiție nu puteți avea atât de mulți bani. Dacă rulați Google, atunci aveți astfel de bani, dar cel mai probabil vă veți gândi de două ori înainte de a-i cheltui pentru a vă crea propriul sistem de operare. De asemenea, vă va dura câțiva ani pentru a ajunge unde este Linux astăzi; câțiva ani de întârziere poate fi prea târziu pentru a intra pe piață.

Într-o asemenea situație Compania Apple a decis să construiască Mac OS bazat pe FreeBSD. Android Inc a luat decizia de a folosi Linux ca bază pentru Android. Atât sursele FreeBSD, cât și Linux sunt disponibile gratuit și oferă o bază bună pentru orice dezvoltare, fie că este Apple sau Google.

Dar la acel moment nu era posibil să rulezi Linux standard pe un dispozitiv mobil (nu mai este cazul). Dispozitivele aveau prea puțină memorie RAM și memorie non volatila. Procesoarele au fost semnificativ mai lente în comparație cu procesoarele computerelor în care Linux este folosit în mod obișnuit. Ca rezultat, dezvoltatori Android a decis să minimizeze Cerințe de sistem linux.

Dacă te uiți la Linux la un nivel înalt, atunci este o combinație a nucleului (de care nu te poți lipsi) și multe alte părți opționale. Puteți rula chiar și un nucleu, fără nimic altceva. Deci, oricum, Google este forțat să folosească nucleul Linux ca parte a sistemului de operare Android. În plus, au fost luate în considerare piese opționale și dintre acestea au fost selectate cele mai necesare. De exemplu, firewall-ul de rețea IPTables și shell-ul Ash au fost adăugate. Este curios că a fost adăugat Ash, și nu Bash, în ciuda faptului că acesta din urmă este cu un ordin de mărime mai puternic; această decizie s-a bazat probabil pe faptul că Ash este mai puțin pretențios cu resurse.

Dezvoltatorii Android au modificat nucleul Linux pentru a adăuga suport pentru hardware-ul folosit în dispozitivele mobile și, de cele mai multe ori, nu este disponibil pe computere.

Alegerea Linux ca fundație a avut un impact uriaș asupra fiecărui aspect al sistemului de operare Android. Construirea Android este în esență o variație a procesului build-uri Linux. Cod Android este gestionat de git (un instrument conceput pentru a gestiona codul Linux). etc.

Deși toate acestea sunt interesante, cel mai probabil nu veți atinge niciodată toate aceste puncte specifice decât dacă scopul dvs. este pur și simplu să dezvoltați aplicații Android. Singura excepție este să răsfoiți sistemul de fișiere folosind comenzi ash. Principalul lucru pe care trebuie să-l știți atunci când dezvoltați aplicații Android este stratul de infrastructură a aplicațiilor.

Vă puteți întreba, ce se întâmplă dacă aveți nevoie să dezvoltați o aplicație nativă pentru Android? Google descurajează ferm acest lucru. Din punct de vedere tehnic, desigur, acest lucru este posibil, dar în viitor nu veți putea distribui această aplicație într-un mod normal. Deci, gândiți-vă de două ori înainte de a începe dezvoltarea nativă Android, cu excepția cazului în care, desigur, lucrați la Android Open Source Project (AOSP), adică. sistemul de operare Android în sine.

Stratul de infrastructură a aplicațiilor

În ciuda unor asemănări Apple iOSși Android OS, există diferențe semnificative între soluțiile arhitecturale la nivelul infrastructurii ambelor OS.

Apple a decis să folosească Objective-C ca limbaj de programare și timp de rulare aplicații iOS. Objective-C arată ca o alegere mai mult sau mai puțin naturală pentru un sistem de operare bazat pe FreeBSD. Vă puteți gândi la Objective-C ca un C++ simplu cu un preprocesor personalizat care adaugă câteva constructe lingvistice specifice. De ce nu poți folosi standardul C++ în care este scris FreeBSD? Mi se pare că motivul este că Apple încearcă să facă totul în stilul său, „Apple”.

Ideea de bază este că aplicațiile iOS sunt scrise mai mult sau mai puțin în aceeași limbă cu sistemul de operare din spatele lor.

Aplicațiile Android sunt foarte diferite în acest sens. Sunt scrise în Java, care este o tehnologie complet diferită de C++ (deși sintaxa este moștenită din C++).

Cred că motivul principal este necesitatea ca aceeași aplicație să ruleze pe hardware diferit. Această problemă este doar pentru sistemul de operare Android; Băieții de la Apple nu au această problemă. iOS rulează doar pe propriul hardware, iar Apple are control deplin asupra întregului proces. Pentru Android, este adevărat invers: Google nu controlează producătorii de hardware. De exemplu, sistemul de operare Android rulează pe procesoare x86, ARM și Atom (comentariile sugerează că x86 include Atom, iar Android rulează pe x86, ARM, PPC și MIPS - nota traducătorului). La nivel binar, aceste arhitecturi sunt incompatibile.

Dacă arhitecții Android ar urma aceeași cale ca și arhitecții de la Apple, dezvoltatorii de aplicații Android ar fi forțați să distribuie mai multe versiuni ale aceleiași aplicații în același timp. Aceasta ar fi o problemă serioasă care ar putea duce la prăbușirea întregului proiect Android.

Pentru ca aceeași aplicație să ruleze pe hardware diferit, Google a folosit o arhitectură bazată pe container. Într-o astfel de arhitectură, codul binar este executat de un container software și izolat de detaliile hardware specifice. Exemplele sunt familiare tuturor - Java și C#. În ambele limbi, codul binar este independent de hardware și este executat de o mașină virtuală.

Desigur, există o altă modalitate de a obține independența hardware la nivel binar. O opțiune este utilizarea unui emulator hardware, cunoscut și sub numele de QEMU. Vă permite să emulați, de exemplu, un dispozitiv cu procesor ARM pe platforma x86 și așa mai departe. Google ar putea folosi C++ ca limbaj pentru dezvoltarea aplicațiilor în interiorul emulatorilor. Într-adevăr, Google utilizează această abordare în cadrul său Emulatori Android, care sunt construite deasupra QEMU.

Este foarte bine că nu au mers pe acea cale, pentru că atunci cineva ar trebui să ruleze sistemul de operare pe un emulator care necesită mult mai multe resurse și, ca urmare, viteza de lucru ar scădea. Pentru a obține cele mai bune performanțe, emularea a fost lăsată doar acolo unde nu a putut fi evitată, în cazul nostru - în aplicațiile Android.

Oricum ar fi, Google a luat decizia de a utiliza Java ca principal limbaj de dezvoltare a aplicațiilor și mediu de rulare.

Cred că a fost o decizie arhitecturală critică care a diferențiat Android de restul sistemelor de operare mobile bazate pe Linux care sunt introduse în prezent. Din câte știu, niciunul dintre ele nu are compatibilitate binară la nivel de aplicație. Să luăm MeeGo ca exemplu. Utilizează C++ și framework-ul Qt; în ciuda faptului că Qt este multiplatformă, necesitatea de a face diferite build-uri pentru diferite platforme nu dispare.

După ce am ales Java, a trebuit să decideți ce mașină virtuală (JVM) să utilizați. Din cauza resurselor limitate, utilizarea JVM-ului standard a fost dificilă. Singura alegere posibilă a fost utilizarea unui Java ME JVM conceput pentru dispozitive mobile. Cu toate acestea, fericirea Google nu ar fi completă fără dezvoltarea propriei mașini virtuale și a apărut Dalvik VM.

Dalvik VM diferă de alte mașini virtuale Java în următoarele moduri:

• Utilizează un format special DEX pentru a stoca coduri binare, spre deosebire de formate JARși Pack200, care sunt standardul pentru alte JVM-uri. Google a declarat că binarele DEX sunt mai mici decât JAR-urile. Cred că ar putea la fel de bine să folosească Pack200, dar au decis să meargă pe drumul lor.
• Dalvik VM este optimizat pentru a rula mai multe procese în același timp.
• VM-ul Dalvik folosește o arhitectură bazată pe registru față de arhitectura bazată pe stivă în alte JVM-uri, rezultând o execuție mai rapidă și binare mai mici.
• Folosește propriul set de instrucțiuni (mai degrabă decât bytecode JVM standard)
• Este posibil să rulați (dacă este necesar) mai multe aplicații independente Android într-un singur proces
• Execuția aplicației poate acoperi mai multe procese Dalvik VM „în mod natural” (vom discuta despre ce înseamnă aceasta mai târziu). Adăugat pentru a sprijini acest lucru:
  • Un mecanism special de serializare a obiectelor bazat pe clasele Parcel și Parcelable. Din punct de vedere funcțional, servește același scop ca și Java Serializable, dar rezultatul sunt date mai mici și, potențial, mai tolerante la versiunea de clasă.
  • O modalitate specială de a efectua apeluri între procese (apeluri între procese, IPC), bazată pe Android Interface Definition Language (AIDL).
• Înainte de Android 2.2, Dalvik VM nu accepta compilarea JIT, ceea ce a fost un impact serios de performanță. Începând cu versiunea 2.2, viteza de execuție a aplicațiilor frecvent utilizate