Acest mecanism este implementat folosind wakelock-uri și rolul lor este de a menține sistemul treaz.

Transcription

1 4. Aceasta este arhitectura Android-ului: Acesta rulează deasupra unui kernel de Linux vanilla, cu câteva modificări numite Androidisme (în mod informal). Userspace-ul nativ include procesul init, câțiva daemoni nativi, câteva sute de biblioteci native și Hardware Abstraction Layer (HAL). Bibliotecile native sunt implementate in C/C++ și funcționalitatea lor este expusă aplicațiilor prin API-ul framework-ului de Java (Java framework APIs) O mare parte din Android este implementată în Java și până la Android 5.0, runtime-ul implicit a fost Dalvik. De la Android 5.0, a fost integrat un runtime mai performant, numit ART. Bibliotecile de runtime Java (Java runtime libraries) sunt definite în pachetele java.* și javax.*, și sunt derivate din proiectul Apache Harmony (nu din Oracle/SUN, pentru a evita problemele de copyright și distribuție). Codul nativ poate fi apelat din Java prin Java Native Interface (JNI). O mare parte din funcționalitățile Android-ului este implementată în serviciile de system: display, touch, telefonie, conectivitate la rețea, etc. O parte dintre aceste servicii este implementată cod nativ, și cealalta parte în Java. Fiecare serviciu oferă o interfață care poate fi apelată din alte componente. Bibliotecile Android Framework (numite de obicei the framework ), includ clase pentru construirea aplicațiilor Android. Deasupra, avem aplicațiile stock, cele care vin odată cu telefonul. De asemenea, avem aplicațiile instalate de către utilizator Majoritatea distribuțiilor de Linux iau kernelul vanilla (din Linux Kernel Archives) și ii aplică propriile patch-uri pentru a rezolva bug-uri, a îmbunătăți performanța și a-i adăuga feature-uri specifice. Androidul face același lucru, ia kernelul vanilla și ii aplică câteva sute de patch-uri care aduc îmbunătățiri, rezolvări de bug-uri și feature-uri specifice pentru dispozitivele pe care rulează Androidul. Android Mainlining Project și mai nou Android Upstreaming Project s-au ocupat cu includerea acestor feature-uri in mainline. O bună parte din aceste Androidisme au fost deja integrate în mainline. Vom prezenta cele mai importante dintre aceste Androidisme: Wakelocks, Low Memory Killer, Binder, Anonymous Shared Memory, Alarm, RAM Console, Paranoid Networking. La desktop-uri și laptop-uri, în general utilizatorul decide când sistemul va intra în sleep și când se va trezi. În contrast, kernelul Androidizat va intra în sleep de fiecare dată când este posibil, cât mai des posibil. De aceea este nevoie de un mecanism care să forțeze sistemul să nu intre în sleep atunci când se fac procesări importante sau atunci când se așteaptă input-ul utilizatorului.

2 Acest mecanism este implementat folosind wakelock-uri și rolul lor este de a menține sistemul treaz. 9. O aplicație care vrea să ruleze fără ca sistemul să intre în sleep, va trebui să obțină un astfel de wakelock. În general dezvoltatorii nu au nevoie să ceară un wakelock direct, deoarece abstracțiile pe care le folosesc în aplicațiile lor vor gestiona în mod automat obiectele wakelock. Totuși, Aplicațiile de Android pot cere wakelock-uri în mod explicit de la serviciul numit Power Manager. În schimb, driverele de dispozitiv vor trebui să apeleze direct primitivele wakelock din kernel, pentru a obține și elibera un wakelock. În versiunea 3.5 de Linux, în 2012, un echivalent al wakelock-urilor și mecanismul corelat de early suspend au fost introduse în mainline. Înlocuitorul lui early suspend este numit autosleep iar wakelock-urile sunt înlocuite de noul flag pentru epoll() numite EPOLLWAKEUP Kernelul de Linux include Out of Memory killer (OOM), care se activează dacă nu mai există memorie disponibilă. In Android este foarte importantă tratarea situațiilor în care există puțină memorie disponibilă. De aceea s-a introdus acest Low Memory Killer care va rula înainte de Out of Memory (OOM) Killer-ul default din kernel. Scopul lui Low Memory Killer este de a preveni activarea OOM killer-ului, prin omorârea proceselor care au componente care nu au fost folosite de mult timp și nu au prioritate mare. Astfel sistemul nu va ajunge în situația în care să rămână fără memorie. Low-memory killer a fost inclus în mainline din Linux Low Memory Killer-ul se bazează pe mecanismul de ajustări OOM prin care putem avea priorități diferite pentru procese diferite. Aceste ajustări vor permite userspace-ului să controleze o parte din politicile de omorâre a proceselor din kernel. Politicile de userspace sunt aplicate de către procesul init la startup și pot fi reajustate și aplicate la runtime prin serviciul Activity Manager. Ajustările OOM sunt de la -17 la 15 iar o valoare mai mare înseamnă că acel proces este mai probabil să fie omorât de sistem dacă va rămâne fără memorie. Androidul va acorda un nivel de ajustare fiecărui tip de proces, în funcție de componentele care rulează și configurează killer-ul să aplice threshold-uri pentru fiecare tip de proces. Aici avem câteva tipuri de procese. Procesele vor fi omorâte atunci când acele threshold-uri au fost atinse.

3 Și astfel Low Memory Killer-ul va intra în acțiune înaintea OOM killer-ului, pentru că nu se va ajunge să se termine memoria Anonymous Shared Memory (numit pe scurt ashmem) este un mecanism IPC de memorie partajată. Este bazat pe fișiere și contoare de referință. Echipa Android este împotriva folosirii IPC-urilor de tip System V deoarece acestea pot duce la leak-uri de resurse în kernel și astfel pot permite aplicațiilor malițioase sau misbehaving să afecteze sistemul. Ashmem este similar cu memoria partajată Posix dar prezintă următoarele diferențe: Ashmem folosește un contor de referință pentru a distruge zonele de memorie atunci când toate procesele care au referit acele zone s-au terminat. De asemenea mecanismul va micșora zonele de memorie mapate atunci când sistemul are nevoie de mai multă memorie. Dacă o zonă este pinned, ea nu va putea fi micșorată, de aceea trebuie să fie unpinned înainte. Partajarea memoriei se face astfel: primul proces creează o zonă de memorie partajată folosind ashmem, apoi folosește Binderul pentru a partaja descriptorul de fișier asociat cu alte procese. Multe dintre componentele system server-ului se bazează pe ashmem, prin interfața IMemory și nu direct (exemple: Surface Flinger și Audio Flinger). Driverul pentru ashmem a fost inclus în staging tree din versiunea 3.3, dar nu a fost inclus în mainline. Driverul alarm se bazează pe funcționalitățile Real-Time Clock (RTC) și High Resolution Timers (HRT). setitimer() este un apel de sistem care determină generarea unui semnal atunci când expiră timpul. Acest apel de sistem se bazează, printre altele și pe timer-ul ITIMER_REAL care folosește HRT-ul din kernel. Totuși, acesta nu funcționează când sistemul este suspendat. Astfel, aplicația va primi semnalul abia când dispozitivul se va trezi. Înafară de asta mai există și driverul RTC accesibil prin /dev/rtc și se comunică cu el prin apeluri ioctl(). Dacă folosim RTC alerta va fi generată chiar dacă sistemul este suspendat deoarece dispozitivul RTC va rămâne activ chiar dacă restul sistemului este suspendat. Driverul pentru Android va combina ambele mecanisme. În mod implicit, driverul folosește HRT pentru a genera alerte, dar atunci când sistemul este pe cale de a se suspenda, se programează RTC pentru a trezi sistemul la momentul potrivit.

4 Astfel, orice aplicație din userspace poate folosi acest driver pentru a genera o alertă indiferent dacă sistemul este treaz sau suspendat în acel moment. Driverul va putea fi accesat din userspace prin /dev/alarm care este un dispozitiv de tip caracter. Va permite resetarea alarmelor și configurarea timpului prin apeluri ioctl(). Multe componente cheie din AOSP se bazează pe acest driver. De exemplu, clasa SystemClock se bazează pe el pentru a obține și seta timpul. De asemenea AlarmManager îl folosește pentru a oferi servicii de alertă aplicațiilor. Atât driverul cât și AlarmManager vor folosi Wakelock-uri pentru a păstra consistența între alarme și restul sistemului. De exemplu, atunci când se generează o alarmă, aplicația va putea face operațiile necesare (va deține wakelock-ul) înainte ca sistemul să intre din nou în suspend. Acest driver a fost inclus in mainline din versiunea În general, pe Linux, toate procesele pot crea sockeți și accesa rețeaua. În Android, din motive de securitate, trebuie să decidem care aplicații vor avea acces la rețea. Mecanismul paranoind networking restricționează accesul la rețea în funcție de grupul din care face parte procesul apelant. Pentru a putea crea sockeți AF_INET și AF_INET6, un proces trebuie să aibă GID-ul suplimentar AID_INET. Dacă aplicația are permisiunea Internet atunci va avea GID-ul suplimentar AID_INET. Pentru a crea sockeți INET raw, un proces trebuie să aibă GID-ul suplimentar AID_NET_RAW. Apartenența la grupul AID_NET_ADMIN garantează capabilitatea CAP_NET_ADMIN, care permite configurarea interfețelor de rețea și a tabelelor de rutare. 20. Apartenența la grupul AID_NET_BT permite crearea sockeților Bluetooth (SCO, RFCOMM, L2CAP). Dacă aplicația are permisiunea Bluetooth, atunci va avea grupul suplimentar AID_NET_BT. Grupul AID_BT_ADMIN are abilitatea de a gestiona conexiunile BT. Dacă aplicația are permisiunea Bluetooth_admin, atunci va avea grupul suplimentar AID_BT_ADMIN. 21. Asocierile intre permisiuni și GID-uri se află în fișiserul /etc/permission/platform.xml de pe dispozitiv. Vedeți aici un fragment al acestui fișier, unde apar mapările intre permisiuni și GID-uri. 23. Binderul include un mecanism de Remote Procedure Call (RPC). A fost prima oară dezvoltat în cadrul BeOS care apoi a fost cumpărat de către Palm.

5 24. Apoi a fost pus la dispoziția dezvoltatorilor prin OpenBinder. Câțiva dintre dezvoltatorii care au lucrat la OpenBinder s-au mutat în echipa Android de la Google. Astfel Binderul de Android a fost inspirat din OpenBinder (oferă aceeași funcționalitate), dar nu deriva din codul acestuia, ci a fost scris de la zero. Astfel se poate folosi documentația de OpenBinder pentru a înțelege mecanismul general, deoarece nu prea există documentație despre Binderul de Android, lucru valabil pentru toate componentele interne Androidului. Driver-ul Binder a fost inclus în mainline din versiunea Binder-ul extinde funcționalitatea sistemului prin invocarea obiectelor remote. În loc de a crea un nou daemon pentru fiecare serviciu, se poate folosi un obiect remote implementat într-un anumit limbaj de programare (C, Java) care se află în același proces cu alte servicii sau într-un proces separat. Tot ce este nevoie este o interfață și o referință la aceasta pentru a putea invoca metode remote. Binderul este o componentă centrală a arhitecturii Androidului. El este folosit pentru a comunica cu serviciile de sistem sau serviciile aplicațiilor. Dezvoltatorii de aplicații nu vor folosi direct Binderul niciodată, ci vor folosi interfețe și stub-uri generate de utilitarul aidl. Chiar și atunci când comunică cu serviciile de sistem, API-ul public va apela în spate stub-uri care comunică prin Binder cu serviciile O bună parte din Binder este implementată în kernel într-un driver. Acest driver este accesibil printr-un dispozitiv caracter /dev/binder. Componentele care comunică prin Binder vor putea schimba date parcelate prin apeluri ioctl(). Framework-ul de Android rulează deasupra userspace-ului nativ și include o multitudine de componente: pachetele android.*, serviciile de sistem și runtime-ul de Android. Din punct de vedere al surselor, codul ce include framework-ul se află în directorul frameworks/ din AOSP. Framework-ul include câteva componente cheie, de bază: Service Manager, Zygote și Dalvik/ART. Serviciile de sistem din Android formează ceea ce am putea numi un sistem de operare orientat pe obiecte deasupra kernelului Linux. Principala componentă este System Server care rulează în procesul cu același nume: system_server, și conține un număr mare de servicii scrise în Java și 2 servicii scrise în C/C++. Aici avem implementate in Java: PowerManager, ActivityManager, PackageManager, LocationManager, etc.. Cele implementate in C/C++ sunt SurfaceFlinger și SensorService.

6 Un alt set de servicii este inclus în Media Service care rulează în procesul cu același nume: mediaservice. Aceste servicii sunt scrise în C/C++ și se ocupă de audio, video și camera. De exemplu: AudioFlinger, MediaPlayerService, CameraService. Dalvik este runtime-ul default inainte de Android 5.0. Este o mașină virtuală de Java optimizată special pentru dispozitivele mobile, prin urmare ca avea un footprint de memorie mult mai scăzut. Lucrează cu fișiere.dex, care sunt cu 50% mai mici decât fișierele.jar cu aceleași clase. Spre deosebire de mașina virtuală Java originală care este bazată pe stivă, Dalvik este o arhitectură bazată pe registre. Astfel, va lucra cu un număr finit de registre care rețin o valoare întreagă pozitivă. Dalvik nu poate rula bytecode Java original. Dar acesta poate fi convertit în bytecode de Dalvik folosind comanda dx care construiește fișierul dex. Bytecode-ul de Java lucrează cu instrucțiuni pe 8 biți specifice pentru stivă. Asta înseamnă că variabilele locale trebuie copiate pe stivă înainte de a fi folosite. În schimb Dalvik lucrează cu instrucțiuni pe 16 biți și accesează direct variabilele locale. Rezultă mai puține instrucțiuni și o viteză mai mare. De la versiunea 2.2, Dalvik include compilatorul Just in Time pentru ARM. Apoi a fost disponibil și pentru x86 și MIPS. Acesta va traduce bytecode-ul de Dalvik în instrucțiuni mașină care vor rula nativ pe CPU-ul dispozitivului în loc să fie interpretate instrucțiune cu instrucțiune de către mașina virtuală. Această conversie este făcută o singură dată și apoi stocată pentru rulările viitoare. Astfel, aplicațiile se vor încărca un pic mai greu prima oară, dar apoi vor rula mult mai repede. Restul bytecode-ului va fi interpretat de MV Dalvik. Execuția nativă a trace-urilor aduce îmbunătățiri de performanță. ART este disponibil din Android 4.4, dar a devenit runtime-ul default din Android 5.0. Android Runtime (pe scurt ART) vine să înlocuiască Dalvik, aducând o serie de îmbunătățiri. ART, la fel ca și Dalvik, rulează executabile Dalvik (fișiere dex), din motive de compatibilitate. Să vedem care sunt avantajele aduse de ART. În primul rând oferă compilare Ahead-of-Time (AoT), ceea ce poate îmbunătăți performanța aplicațiilor.la instalare, ART folosește tool-ul dex2oat pentru a transforma fișierul dex într-un executabil pentru dispozitivul respectiv. Deci întreaga aplicație va rula în mod nativ direct pe procesorul dispozitivului, deci AOT înlocuiește compilarea JIT și interpretarea Dalvik. În plus face o verificare mai strictă a aplicațiilor la instalare. Dezavantajele AOT sunt: executabilele ocupă spațiu de stocare adițional, instalarea aplicațiilor durează mai mult.

7 De asemenea, ART oferă un process de garbage collection mult mai eficient Ofer[ suport pentru un sampling profiler dedicat care generează informații precise despre execuția aplicațiilor fără a afecta performanța. Oferă un număr de opțiuni noi de debugging, mai ales legate de monitorizare și garbage collection. În plus, ART va genera mai multe detalii și informații legate de context atunci când are loc o excepție la runtime. Zygote este un daemon folosit pentru a porni aplicații și este activ doar în momentul în care trebuie pornită o aplicație. Este practic părintele tuturor proceselor în Android. La început, Zygote va pre-încărca toate clasele Java și resursele de care aplicațiile ar putea avea nevoie în RAM pentru a realiza o pornire mai rapidă a aplicațiilor. Apoi Zygote va asculta pentru a primi conexiuni pe socket pe /dev/socket/zygote cu cereri de pornire a aplicațiilor. Atunci când primește o astfel de cerere, își va face fork și va porni aplicația în noul proces. Avantajul de a avea toate aplicațiile fork-uite din Zygote este că avem toate clasele și resursele încărcate în memorie și aplicațiile își pot începe direct execuția. Acest lucru se întâmplă din cauza mecanismului Copy on Write (CoW) din kernelul Linux. Atunci când se crează un nou proces cu fork, el este o copie a părintelui și va avea mapate paginile de memorie fără a fi necesară copierea acestora. Doar atunci când se scrie într-o pagină, ea va fi întâi copiată. După cum clasele și resursele nu sunt modificate niciodată, toate aplicațiile vor avea acces la cele încărcate inițial de Zygote fără a fi necesară o copie. Deci va fi folosită o singură variantă a claselor și resurselor în RAM. Există un singur proces pe care Zygote îl pornește în mod explicit (fără nici o cerere) - system server - este primul proces pornit de către Zygote. Dacă dăm ps, se poate observa că PID-ul lui Zygote este PPID-ul tuturor aplicațiilor + al procesului system server. 35. Aveți aici un output de ps. Se vede ca init are PID-ul 1, el crează zygote care are PID-ul 3279 în acest caz. Care mai departe crează celelalte aplicații și servicii (unele de sistem - ne uitam la user). Vede aici și pe system_server care este creat explicit de către Zygote. 36. Din Android 5.0, Android-ul are un mecanism de logging nou bazat pe daemon-ul logd. Acesta are comportamentul unui logger centralizat de user-space. Logd adresează dezavantajele folosirii bufferelor circulare, folosite de mecanismul Logger anterior (dimensiunea mică și nevoia de a fi rezidente în memorie).

8 Logd poate fi integrat cu SELinux, prin înregistrarea lui ca auditd, pentru a primi mesajele SELinux din kernel prin netlink. Logd folosește 4 sockeți: /dev/socket/logd, care este socketul ce oferă interfața de control /dev/socket/logdw, care un socket write-only folosit doar pentru scrierea logurilor /dev/socket/logdr, care este un socket read-only, folosit doar pentru citirea logurilor Un socket netlink fara nume folosit pentru integrarea logd cu SELinux Sockeții aceștia nu sunt accesați în mod direct, ci doar prin biblioteca liblog. Deci aplicațiile folosesc clasa Log (sau EventLog) pentru scrierea logurilor, care în schimb apelează biblioteca nativă liblog prin JNI, care deschide socket-ul /dev/socket/logdw pentru a scrie mesajul Pentru citirea logurilor, logcat va apela biblioteca liblog care se va conecta la /dev/socket/logdr (prin LogReader) O componentă importantă în framework este Service Manager. Acesta este responsabil cu identificarea serviciilor de sistem (operația numită lookup). Este un fel de Pagini Aurii a tuturor serviciilor de sistem. Un serviciu care nu s-a înregistrat la Service Manager nu poate fi accesat, deci nu există. Orice serviciu care se vrea a fi accesibil, trebuie să se înregistreze întai la Service Manager. Acest manager este pornit de către init înainte oricărui alt serviciu. Când pornește, accesează /dev/binder și folosește un apel ioctl() pentru a se face pe sine Context Manager-ul Binder-ului. De ce face acest lucru? Pentru a deveni obiectul magic (Binder ID 0). Orice proces care va comunica cu Binder ID 0 (obiectul magic, sau magic Binder) va comunica de fapt cu Service Manager prin Binder (chiar în cod este numit magic object). Fiecare serviciu de sistem se va înregistra la Service Manager (tot printr-un apel prin Binder). Manager-ul va păstra o listă de servicii disponibile. Atunci când o aplicație vrea să comunice cu un serviciu de sistem, va cere (prin getsystemservice()) de la Service Manager un handle către acel serviciu apoi va apela metodele serviciului folosind acel handle (tot prin Binder - toate operațiile se fac prin Binder). Acest mecanism este valabil doar pentru serviciile de sistem, el nu va fi folosit atunci când se accesează serviciul unei aplicații (apelul va trece direct prin Binder fără a fi căutat în Service Manager). De asemenea, managerul este folosit de către o serie de utilitare cum este dumpsys care face dump la statusul unui serviciu sau a tuturor serviciilor de sistem. Întâi va cere o listă cu toate serviciile, apoi va cere handle-ul pentru fiecare și va apela funcția dump din serviciul respectiv.

9 În continuare vom aborda trei manageri importanți: Activity Manager, Package Manager și Power Manager. Activity Manager este unul dintre cele mai importante servicii din System Server și este responsabil cu realizarea ciclului de viață a activităților. Acest serviciu va porni activități și servicii în aplicații, va obține content provideri și va face broadcast la intenturi. Dialog-ul Application Not Responing (ANR) este generat tot de Activity Manager. De asemenea, este implicat în multe task-uri adiacente - verifică permisiuni, ajută la calculul ajustărilor OOM pentru Low Memory Killer, face task management. Activity Manager este cel care pornește launcher-ul cu un intent de tipul CATEGORY_HOME. Să vedem ce se întâmplă atunci când o aplicație este pornită din Launcher: Se apelează callback-ul onclick() din Launcher. In acest callback se va apela prin Binder metoda startactivity din Activity Manager. Serviciul va apela metoda startviazygote() care va deschide o conexiune prin socket cu Zygote și îi va cere să pornească un nou proces cu activitatea respectivă. În linia de comandă avem utilitarul am pentru a da comenzi către Activity Manager. Putem porni o activitate, un serviciu, trimite un intent, porni profilling-ul sau a face debugging. 45. Package Manager este acel serviciu care gestionează fișierele de tip apk. Mai exact, el oferă posibilitatea instalării, dezinstalării și upgradării de pachete. PackageManager lucrează cu câteva fișiere din /data/system, cele mai importante fiind: packages.xml care conține toate permisiunile și informații despre pachetele instalate packages.list care conține toate pachetele instalate, UID-ul lor și directorul de date Rulează în cadrul system_server dar se folosește de installd pentru a efectua majoritatea operațiilor (pentru că installd are permisiuni suficiente - root) Tot Package Manager ajută la rezolvarea intent-urilor, mai exact la identificarea componentei care trebuie să primească intent-ul. El va primi o cerere de rezolvare și va folosi informația din fișierul manifest pentru a identifica componenta cea mai potrivită. În linia de comandă, avem utilitarul pm pentru a da comenzi către Package Manager. Vom putea lista pachetele instalate, vizualiza permisiunile cerute de o aplicație, instala, dezinstala pachete, afișa folderul aplicației, dezactiva un pachet, și altele. Power Manager este responsabil cu controlul consumului de putere al dispozitivului. Aici este locul din AOSP unde sunt gestionate wakelock-urile. Serviciul include clasa WakeLock cu metodele aferente aquire și release. Aplicațiile vor cere Wakelock-uri de la Power Manager.

10 48. Gestiunea consumului de putere este implementată în kernel, dar toate apelurile trebuie să treacă mai întâi prin Package Manager. Printre operațiile pe care le poate face acest serviciu este forțarea dispozitivului să intre în sleep și configurarea luminozității ecranului.