Universitatea Politehnica Bucuresti

Facultatea de Electronica Telecomunicatii si Tehnologia Informatiei

Specializarea Calaculatoare si Tehnologia Informatiei

Kernelul Linux si masina virtuala Dalvik la android

Mazilu Razvan si Popescu Mihai

432A

Cuprins

1.Introducere Kernel

2.Modificari ale kernelului de linux

3.Drivere

4.Power Management

Introducere Dalvik

Portarea

Structura interpretorului

Optimizari

Obtinerea fisierelor .DEX

Rularea aplicatiilor

Concluzii

Introducere Dalvik

Linux Kernel

1. Introducere

Arborele ce arata evolutia sistemelor unix[1]

Kernelul linux este un nucleu de sisteme de operare, folosit de familia linux sau sistemele de operare bazate pe unix.

Kernelul Linux a fost conceput de un student Finlandez, Linus Torvalds, in 1991. Initial a fost dezvoltat pentru calculatoarele personale bazate pe arhitectura X86. Linux a acumulat rapid dezvoltatori. La modificarea si imbunatatirea kernelul Linux contribuie o comunitate de mii de programatori. Pentru a avea o distributie de linux, pe langa kernel, mai este nevoie de compilatoare, librarii, programe programe ce permit deschiderea paginilor web, programe multimedia, etc. Astfel au aparut o multime de distributii, ce pornesc de la nucleul de linux, dar se diferentiaza prin aplicatiile instalate pe acesta.

Linux este o comunitate open source, unde oricine poate aduce modificari distrbiutiilor de linux dupa bunul plac.

Sistemul de operare pentru dispozitive mobile android a fost dezvoltat pe kernelul de linux versiunea 2.6.

2. Modificari ale kernelului de linux

Surprinzator sau nu, Android nu a modificat foarte mult nucleul Linux. Cele mai multe sisteme embedded care folosesc nucleul Linux, il modifica drastic.

Android face opusul: doar modificarile minime asupra nucleului, dar spatiul, este in intregime al utilizatorului, spre deosebire de alte sisteme Unix. De fapt, spatiul utilizatorului Android este atat de diferit fata de un sistem de operare Linux, astfel incat se poate spune usor ca Android nu este in niciun caz un sistem Linux, exceptie facand nucleul.

O lista cu modificarie aduse nucleului Linux de catre android:

Ashmem(Android Shared Memory) Binder, un sistem de comunicare inter-process (IPC – inter-process communication) si

apel de procedura de la distanta (RPC – remote procedure call) Logger, un mecanism de mare de logare in linux. Paranoid Netowrking, un mecanism ce restrictioneaza network I/O anumitor procese Pmem(Phisical Memory), un driver ce mapeaza “bucatile mari” de memorie fizica in

spatial utilizatorilor Viking Killer, a inlocuit OOM killer ce implementeaza “kill least recently used

process” logic in cazul in care memoria tinde sa se ocupe in totalitate Wavelocks, o solutie de gestionare a energiei, in care starea normala a dispozitivului

este sleep-ul si este necesara o actiune explicita pentru a preveni aceasta.

In continuare sunt prezentate, pe scurt fiecare din aceste modificari.

ashmem [2]

ashmem – Android shared memory. Implementarea se gaseste in mm/ashmem.c

Conform cu Kconfig help "The ashmem subsystem is a new shared memory allocator, similar to POSIX SHM but with different behavior and sporting a simpler file-based API."[3]

Aparent ashmem suporta mai bine dispozitivele cu putina memorie, deoarece se poate debarasa de unitatile de memorie partajata in cazul in care este nevoie.

Pentru a utiliza aceste programe, calea este /dev/ashmem, folositi mmap() si se pot executa unul sau mai multe ioctls(input output controls) din urmatoarele:

ASHMEM_SET_NAME ASHMEM_GET_NAME ASHMEM_SET_SIZE ASHMEM_GET_SIZE ASHMEM_SET_PROT_MASK ASHMEM_GET_PROT_MASK ASHMEM_PIN ASHMEM_UNPIN ASHMEM_GET_PIN_STATUS ASHMEM_PURGE_ALL_CACHES

binder [4]

binder este un sistem de comunicare inter-process si apel de procedura de la distanta.

Un proces Android poate chema o rutina a altui proces Android, folosind binder pentru a identifica metoda ce invoca trecerea argumentelor intre procese.

Implementarea binder este are sursa in kernel la: drivers/misc/binder.c care include fisierul:include/linux/binder.h

logger [5]

[6]Sistemul Android are o facilitate de logare care permite citirea informatiilor la nivel de sistem

de la aplicatii si componentele de sistem. Acesta este separat fata de propriul sistem de logare al kernelului de Linux, care este accesat folosind „dmesg” sau „/proc/kmsg”. Totusi, sistemul de logare nu stocheaza mesajele in bufferul kernelului.

Paranoid Netowrking

Paranoid network-ing

Android a adaugat optiunea „paranoid network” kernelului de linux, care restrictioneaza accesul unor caracteristici de retea in functie de grupul care executa procesul respectiv.

Lista grupurilor care au permis accesul la caracteristicilor de retea este in fisierul din sursa kernelului: /include/linux/android_aids.h

pmem

PMEM - Process memory allocator

Este implementat la: drivers/misc/pmem.c  ce include fisierul: include/linux/android_pmem.h

„The pmem driver is used to manage large (1-16+MB) physically contiguous regions of memory shared between userspace and kernel drivers (dsp, gpu, etc). It was written specifically to deal with hardware limitations of the MSM7201A , but could be used for other chipsets as well. For now, you're safe to turn it off on x86.”

Brian Swetland 

OOM handler

Informal cunoscut ca Viking killer, OOM handler omoara procesele cum memoria libera incepe sa se imputineze. Regulile urmarite pentru aceasta sunt furnizate de la spatiul utilizatorului in 2 cai:

Init scrie informatii despre nivelele de memorie si clasele asociate. Spatiul utilizatorului seteaza oom_adj proceselor pentru a le pune in clasa corecta

pentru operatia curenta. Acest lucru redefineste intelesul oom_adj care este folosit de catre OOM killer standard catre ceva care este mai agresiv si controlat.

Despre Wavelocks se va detalia la capitolul de power management.

3.Drivere

[7]

Sistemul de operare Android a fost initial conceput pentru dispozitive mobile, asa ca initial driverele pentru periferice au fost destul de limitate(Driver pentru display, Driverul pentru camera Foto, Driverul pentru memoria interna, Driverul pentru tastatura, Driverul audio, Driverul WiFi). Tendintele sunt de a integra cat mai multe din functiile unui PC clasic intr-un telefon/tableta. Asa ca a fost si este necesara scrierea unor drivere precum: drivere pentru Extinderea memoriei interne(HDD, Flash), drivere pentru imprimante, scannere, drivere pentru display-uri externe(videoproiector, SmartTV), etc.

4.Power management

wakelock

Prima versiune de android a utilizat un sistem, numit „wakelocks”, care consta intr-un set de pachete din kernelul de Linux, pentru a perminte uitilizatorului sa previna ca sistemul sa intre intr-un mod de consum redus de energie.

Fiecare wakelock este definit cu un name si un tip. Tipul este unul din urmatoarele:

WAKE_LOCK_IDLE, or WAKE_LOCK_SUSPEND.

Numele este un string ASCII.

Cand un wakelock de tipul „IDLE” este activat, sistemul nu intra in starea de idle, iar acest lucru ar trebui sa faca dispozitivul sa raspunda mai rapid. Nu este nevoit sa se trezeasca din starea iddle pentru a raspunde la intreruperi sau evenimente. Cand un wakelock de tipul „SUSPEND” este tinut, atunci sistemul nu intra in starea suspend, stare din care ar lua chiar mai mult timp sa isi revina.

.

Masina virtuala Dalvik

Introducere

Sistemul de operare Android este bazat pe java, insemnand ca pentru a rula el are nevoie de o masina virtuala java. Din mai multe motive, printre care optimizarea si problemele de licenta, compania Google impreuna cu Open Handset Alliance au hotarat sa isi creeze propria masina virtuala cu numele de Dalvik, nume ales de autorul initial, Dan Bornstein, alegand numele dupa un sat din Islanda. Pe dispozitivele Android, Dalvik ruleaza in framework-ul Android, dar poate fi rulata si separat ca orice alta masina virtuala pe propriul sistem desktop.

Masina virtuala Dalvik a fost conceputa cu ideea de a rula pe o varietate larga de platforme. Sistemul de baza este o varianta de UNIX, ruland compilatorul GNU C. Sistemele CPU little-endian au fost cea mai mare tinta, dar si o parte big-endian sunt evident suportate. Exista doua categorii de portare: portarea pe un sistem Linux cu o arhitectura CPU noua, si portarea pe un alt sistem de operare. Problema de portare pe procesoarele noi este de a instala kernerul de linux, cu driverele necesare, Dalvik ruland in majoritatea cazurilor fara nici o modificare a sa. Librariile de baza iau cod din alte proiecte, printre care OpenSSl, zlib si ICU. Acestea trebuiesc si ele portate pentru a rula masina virtuala.

Portarea

O mare parte din Dalvik este scrisa in portable C, singura componenta care este non-portabila fiind traducatorul(bridge) JNI(Java Native Interface), ce intr-un mod mai simplu transforma un sir de intregi in argumente pentru functii si diferite tipru de date. Acest lucru trebuie facut in concordanta cu conventiile C pentru acele platforme, si astfel necesita un lucru specific fiecarei platforme. Portarea JNI poate varia de la simpla incarcare a datelor intr-o stiva, pana la reguli complexe de stabilire a registrilor si ordine a stivei.[8]

Pentru a usura portarea pe platformele noi a fost creata libraria open-source FFI(Foreign Function Interface), care este folosita cand un traducator nu este disponibil. FFI este mai lenta decat implementarea nativa si de cele mai multe ori optimizarile de performanta pe care le ofera nu sunt folosite.

Dalvik runtime are doi interpretori indentificati „portable” si „fast”. Interpretorul este in mare contrinut de o singura functie C, si poate fi compilat de orice sistem ce suporta gcc. Interpretorul rapid („fast”) foloseste fragmente de cod assemble scrise manual. In caz ca nu exista cod scris manual pentru arhitectura folosita, sistemul de compilare va crea un

interpretor din „C stubs”. Interpretorul „all stubs” creat este putin mai incet ca cel portabil, facand interpretorul rapid dezavantajos in cazul in care nu exista cod scris pentru arhitectura folosita. El este activat by default, facand astfel necesar schimbul pe intrepretorul portabil.

Structura interpretorului

Scrierea nucleului interpretorului in cod masina poate duce la marirea semnificativa a performantei, folosint optimizari specifice arhitecturii pe care este portat. Cea mai simpla cale de a implementa un interpretor este de a avea o functie switch mare. Dupa ce a fost executata fiecare instructiune, interpretorul se intoarce, citeste(fetch) urmatoare instructiune si sare la eticheta specifica. O inbunatatire a acestei metode o reprezinta executare „threded”. Instructiunile de fetch si dispatch sunt incluse la finalui fiecarui handler de instructiune, facand interpretorul putin mai mare, dar astfel este ocolit saltul la inceputul functiei switch, care poate salva destul de mult timp.

Interpretorul Dalvik (prescurtat mtrep) face inca un pas, calculand adresa „goto” in loc sa o caute intr-un tabel. Cautand adresa intr-un tabel inseamna folosirea unui fetch pentru fiecare instructiune, ocupand mai multa memorie. Mtrep multiplica codul operatii cu o valoare fixa. Standard,fiecare handler are asociati 64 B, astfel exista handler-uri care nu incap in cei 64 B. Cei care nu au loc folosesc subrutine sau executa in spatiu aditioanl inafara spatiului acordat standard. Catev din aceste cazuri sunt rezolvate de Dalvik automat, dar nu exista nicio metoda protabila de a detectat un overflow ai celor 64B decat atunci cand masina virtuala incepe executia. Alegerea marimii de 64 este oarecum aleator aleasa , dar s-a practis s-a dovedit ca lucreaza destu lde bine cu arhitecturile ARM si x86.[8]

Optimizari

Masina Virtuala Dalvik a fost conceputa specific pentru platforma Android. Dispozitivele tinta au putin RAM, salveaza datele pe memorii flash cu viteza de transfer mic, si au in general performantele unor computere cu o decada mai vechi.Conform Google, 64MB RAM sunt suficienti pentru a rula sistemul android,dintre care 24 MB pentru initializarea si pornirea sistemului si inca 20 pentru serviciile de nivel inalt. Sistemel ruleaza Linux, ce ofera memorie virtuala, procese si threaduri, cand si un mecanism de securitate.

Aceste limtari au dus la cateva artificii, modificari, de functionare a sistemului:

-pentru a minimiza memoria utilizata informatiile din clase trebuiesc folosite simultan de mai multe procese

-deschiderea unei aplicatii noi necesita minimizarea celorlante pentru a nu bloca dispozitivul

-salvarea informatiilor din clase in fisiere individuale duce la o reduntanta mare, mai ales cand sunt folosite string-uri, astfel pentru salvarea memoriei acest lucru trebuie eleiminat

-parsarea de campuri claselor prelungeste fara motiv incarcarea claselor, accesarea valorilor (integer,string,...) este facuta direct cu ajutorul tipurilor de date C.

-verificarea bytcode este necesara, dar inceata, astfel se doreste cat mai mult o verificare in afara executiei aplicatiei

-optimizarea bytcode (instructiuni mai rapide, scurtarea metodelor) este foarte importat pentru viteza si minimizarea consumului

-din motive de securitate procesele nu au dreptul de a editat codul pus in comun

In general o masina viretuala decompreseaza clasele individuale dintr-o arhiva si le salveaza in heap. Acest lucru implica o copie separata a fiecarei clase in fiecare proces, lucru ce incetineste pronirea unei aplicatii, fiind nevoie de o decompresie mai intai. In schimb avant bytcode in memoria heap locala duce la o rescriesre usoara a instructiunilor, facilitand o serie de optimizari. Astfel au fost luate o serie de decizii fundamentale:

-mai multe clase sunt agregate intr-un singur fisier „DEX” (Dalvik executable), ce seaman cu „jar” folosit de java

- fisiere DEX sunt read-only si sunt comune mai multor procese

-ordonarea byte si word estte modificata pentru a servi cel mai bine sistemul

-verificarea bytecode este obligatorie pentru toate clasele, insa este de dorit sa se pre-verifice cat mai mult

-optimizarea ce are nevoie rescriere bytecode trebuie facuta cat mai devreme[9]

Obtinearea fisierelor .DEX

Imaginea urmatoare ilustreaza obtinerea unui singur fisier .dex din mai multe fisiere .class folosint o unealta oferita de Android si DVM:

[10]

Exista si Optimized DEX (ODEX), ce la prima aparenta nu pare a fi un lucru bun, fisierele fiind in general de 1-4 ori mai mari ca originalul. Optimizarile sunt:

-ajustarea ordininii bitilor pentru toate camnpurile (LITTLE_ENDIAN)

-verificarea tuturor claselor

-optimizarea unor parti specifice din clase si a unor operatii din metode

Optimizarea permite deschiderea aplicatiilor mai repede (viteza fiind cea mai mare problema a sistemelor mobile).[11]

Aplicatiile Android vin sub format .apk ce contin in ele un fisier .dex, care este extras si incarcat in cache. Aplicatiile ce sunt optimizate vin cu un fisier .odex care vine separat de fisierul .apk si inlocuieste fisierul .dex. Versiunile de sisteme de operare Android oficiale vin cu aplicatiile de sistem(apel, telefon, camera,ceas...) optimizate pentru anumite terminale. In schimb fiind un sistem de operare open-source exista multe versiuni deodexed ce permit portarea de aplicatii specifice unor terminale, si pe altele , in care in mod oficial nu ar functiona, tocmai din cauza fisierului .odex.

In imaginile de mai jos se face vizibila dransformarea in .dex din .class. DEX este un format mult mai greu de urmarit pentru oameni, dar prezinta avantaje in sistemele limitate.

[10]

[10]

La randul lor, fisierele .dex, sunt incluse in fisierele .apk, dupa modelul din imagine:

[10]

Sagetile reprezinta utilitatile ce fac transformarile fisierelor. Descrierea AndroidManifest.xml si a fisierelor java tine de Android API, care poate fi gasit pe siteul oficial http://developer.android.com/reference/packages.html

Putem decompila fisierele .dex in fisiere .smali ce reprezinta decompilarea fisierelor .dex in dalvik opcodes. Mai jos avem codul .smali pentru activitatea programuli HelloWorld:

.class public Lcom/example/android/helloactivity/HelloActivity;

.super Landroid/app/Activity;

.source "HelloActivity.java"

# direct methods.method public constructor <init>()V .registers 1

.prologue .line 27 invoke-direct {p0}, Landroid/app/Activity;-><init>()V

.line 28 return-void.end method

# virtual methods.method public onCreate(Landroid/os/Bundle;)V .registers 3 .parameter "savedInstanceState"

.prologue .line 35 invoke-super {p0, p1}, Landroid/app/Activity;->onCreate(Landroid/os/Bundle;)V

.line 39 const/high16 v0, 0x7f02

invoke-virtual {p0, v0}, Lcom/example/android/helloactivity/HelloActivity;->setContentView(I)V

.line 40 return-void.end method

Rularea aplicatiilor

Pentru a rula o aplicatie sistemul dezarhiveaza fisierele .dex, le optimizeaza si le incarca in memoria chache (sub formatul .dey). Intr-un final sunt interpretate de masina virtuala Dalvik si impreuna cu resursele(imagini, string, sunete..) ce sunt in fisierul .APK ruleaza aplicatia.

[10]

In cazul in care exista .odex, se sare peste extragerea .dex din .apk si este fisierul oferit in locul lui. Daca pachetul (package din java) nu este schimbat fisierul .dey ramane in memorie( chiar daca este inchisa aplicatia) pana in momentul in care nu mai exista loc. Memoria este tot timpul tinuta cat mai plina, spatiul din ea fiind alocat ca intr-o coada, cea mai veche aplicatie utilizata fiind stearsa din memorie pentru a face loc uneia noi.[12]

Concluzii

In momentul de fata Android este cel mai utilizat sistem de operare mobil, fiind folosit de la masini de spalat si frigidere pana la telefoane mobile de utlioma generatie si chiar autoturisme. Succesul sau este dat de eforturile puse in portabilitate si alegerea de a calca pe urmele sistemului de operare Linux, fiind open-source.

El a evoluat mult de la primele versiuni care erau lente, dar datorita succesului a reusit sa mareasca mult viteza, incepand de la versiunea 4.0 (ICS) el fiind concurent la viteza cu IOS, sistem de operare scris in C si optimizat pentru dispozitivele pe care ruleaza.

Lansarea unor noi dispozitive ce combina Rasberry Pi si Arduino(si ele open-source), capabile sa ruleze Android, face ca momentan puterea open-source sa se apropie de un apogeu, oferind posibilitati software si hardware de un nivel nemaiintalnit utilizatorilor.

Bibliografie

Robert Love, Software Engineer at Google, What Are The Major Changes That Android Made To The Linux Kernel?

https://en.wikipedia.org/wiki/Android_(operating_system)

https://www.google.ro/search?q=unix+history&tbm=isch&tbo=u&source=univ&sa=X&ei=cqKxUbydHYy4hAe9ooHgCw&ved=0CDcQsAQ&biw=1920&bih=974#facrc=_&imgrc=VkNMkCgGmz6o6M%3A%3BlfW2oDkzPEQnIM%3Bhttp%253A%252F%252Fazhen.ru%252Fimages%252Fstories%252Fclanky%252Funix-history.png%3Bhttp%253A%252F%252Fazhen.ru%252Fclanky%252Frozhovory%252F74-linus-torvalds-10-otazok-pre-linusa%3B502%3B544 [1]

http://elinux.org/Android_Kernel_Features [2][3]

http://elinux.org/Android_Binder [4 ]

http://elinux.org/Android_Logging_System [5][6] http://elinux.org/Android_Architecture

[7]

Rose, John (2008-05-31). "with Android and Dalvik at Google I/O". Retrieved 2008-06-08.

[8]

http://www.ophonesdn.com [9]

https://android.googlesource.com/ [10]

http://elinux.org [11]

http://developer.android.com [12]