proiect soa android kit katstst.elia.pub.ro/news/soa/teme_soa_13_14/androidkitkat... · 2014. 1....
TRANSCRIPT
Proiect SOA
– Android Kit Kat –
Profesor coordonator: Student:
Stăncescu Ștefan Bajura George Andrei
Master IISC
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
2
Contents
1. Prezentare Generală ................................................................................................................................. 3
1.1 Scurt istoric ......................................................................................................................................... 3
1.2 Caracteristici ale sistemului Android .................................................................................................. 4
1.3 SDK-ul oferit de Android ..................................................................................................................... 5
1.4 Versiuni Android ................................................................................................................................. 6
2. Arhitectura Android OS ............................................................................................................................. 7
2.1. Kernel, librarii ..................................................................................................................................... 7
2.1.1 Linux Kernel 2.6 .......................................................................................................................... 10
2.2. Procese, fire de executie (threads) .................................................................................................. 15
2.2.1. Executia proceselor ................................................................................................................... 15
2.2.2 Realizarea firelor de executie(threads) ...................................................................................... 17
2.3 Modalitatea de stocare a datelor ..................................................................................................... 18
2.3.1 Baza de date ............................................................................................................................... 19
2.3.2 Tipuri de fisiere si preferences ................................................................................................... 19
2.3.3 Network ..................................................................................................................................... 19
3. Avantajele/Imbunatatirile aduse de noua versiune ............................................................................... 20
3.1. Diminuarea cerintelor hardware ..................................................................................................... 20
3.2 Noi capabilitati NFC prin intermediul HCE (host card emulation) .................................................... 20
3.3 Framework pentru imprimare .......................................................................................................... 21
3.4 Framework pentru accesul la mediile de stocare ............................................................................. 22
3.5 Senzori de joasa putere..................................................................................................................... 22
3.5.1 Gruparea senzorilor ................................................................................................................... 22
3.5.2 Detectia si contorizarea pasilor ................................................................................................. 23
3.6 Noi capabilitati media ....................................................................................................................... 23
3.6.1 Inregistrarea continutului afisat pe ecran.................................................................................. 23
3.6.2 Monitorizare audio .................................................................................................................... 23
3.7 Capacitati de randare imbunatatite .................................................................................................. 24
3.7.1 Îmbunătățiri de performanță (live) ............................................................................................ 24
3.7.2 Accelerarea GPU ........................................................................................................................ 24
Bibliografie .................................................................................................................................................. 25
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
3
1. Prezentare Generală
1.1 Scurt istoric
Android este o platformă software și un sistem de operare pentru dispozitive și
telefoane mobile bazată pe nucleul Linux, dezvoltată inițial de Google, iar mai târziu de
consorțiul comercial Open Handset Alliance. Android permite dezvoltatorilor să scrie cod
gestionat în limbajul Java, controlând dispozitivul prin intermediul API-ului dezvoltat de Google.
Lansarea platformei Android la 5 noiembrie 2007 a fost anunțată prin fondarea Open
Handset Alliance, un consorțiu de 48 de companii de hardware, software și de telecomunicații,
consacrat dezvoltării de standarde deschise pentru dispozitive mobile. Google a lansat cea mai
mare parte a codului Android sub licența Apache, o licență de tip free-software și open source.
La 5 noiembrie 2007 a fost făcut public Open Handset Alliance, un consorțiu incluzând Google,
HTC, Intel, Motorola, Qualcomm, T-Mobile, Sprint Nextel și Nvidia, cu scopul de a dezvolta
standarde deschise pentru dispozitive mobile. Odată cu formarea Open Handset Alliance, OHA
a dezvăluit de asemenea primul său produs, Android, o platformă pentru dispozitive mobile
construită pe nucleul Linux, versiunea 2.6.
La 9 decembrie 2008, a fost anunțat că 14 noi membri au aderat la proiectul Android, incluzând:
Sony Ericsson, Vodafone Group Plc, ARM Holdings Plc, Asustek Computer Inc, Toshiba Corp și
Garmin Ltd.
Începând cu 21 octombrie 2008, Android a fost disponibil ca Open Source. Google a
deschis întregul cod sursă (inclusiv suportul pentru rețea și telefonie), care anterior era
indisponibil, sub licența Apache. Sub licența Apache producătorii sunt liberi să adauge extensii
proprietare, fără a le face disponibile comunității open source. În timp ce contribuțiile Google la
această platformă se așteaptă să rămână open source, numărul versiunilor derivate ar putea
exploda, folosind o varietate de licențe.
Fiind un sistem de operare open source foarte flexibil si permisiv, ofera posibilitatea
unei distributii libere si totodata, a imbunatatirii lui , atat de catre utilizatori de telefoane
mobile inteligente, cat si de producatorii de astfel de device-uri(tablete, smartphone-uri).
Acesti factori au permis ca Android sa devina una dintre cele mai utilizate platforme
astazi, de catre smartphone-uri, fiind una dintre alegerile preferate in ceea ce priveste
software-ul, de companiile ce au nevoie de un sistem de operare low-cost , customizabil, si usor
de folosit pentru dispozitivele high-tech pe care acestea le dezvoltă.
Ca rezultat, în ciuda faptului că a fost proiectat că în primul rând pentru telefoane și
tablete , au fost dezvoltate aplicații suplimentare pe televizoare, console de jocuri și alte
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
4
electronice. Caracterul deschis al Android-ului a încurajat o mare comunitate de dezvoltatori sa
utilizeze codul sursă pentru a dezvolta proiecte, la care se adauga noi caracteristici pentru
utilizatorii avansați sau sa utilizeze Android pe dispozitive care au beneficiat initial de alte
sisteme de operare. [1]
1.2 Caracteristici ale sistemului Android
Configurații dispozitive: Platforma este adaptabilă la configurații mai mari, VGA, biblioteci grafice
2D, biblioteci grafice 3D bazate pe specificația OpenGL ES 1.0 și configurații
tradiționale smartphone.
Stocare de date Software-ul de baze de date SQLite este utilizat în scopul stocării datelor
Conectivitate Android suportă tehnologii de conectivitate incluzând GSM/EDGE, CDMA,
EV-DO, UMTS, Bluetooth și Wi-Fi.
Mesagerie instant SMS și MMS sunt formele de mesagerie instant disponibile, inclusiv
conversații de mesaje text.
Navigatorul de web Navigatorul de web disponibil în Android este bazat pe platforma de
aplicații open source WebKit.
Mașina virtuală Dalvik Software-ul scris în Java poate fi compilat în cod mașină Dalvik și executat
de mașina virtuală Dalvik, care este o implementare specializată de mașină
virtuală concepută pentru utilizarea în dispozitivele mobile, deși teoretic nu
este o Mașină Virtuală Java standard.
Suport media Android acceptă următoarele formate media audio/video/imagine: MPEG-
4, H.264, MP3, AAC, OGG, AMR, JPEG, PNG, GIF.
Suport hardware
adițional
Android poate utiliza camere video/foto, touchscreen, GPS, accelerometru,
și grafică accelerată 3D.
Mediu de dezvoltare Include un emulator de dispozitive, unelte de depanare, profilare de
memorie și de performanță, un plug-in pentru mediul de dezvoltare Eclipse.
Piața Android Similar cu App Store-ul de pe iPhone, Piața Android este un catalog de
aplicații care pot fi descărcate și instalate pe hardware-ul țintă prin
comunicație fără fir, fără a se utiliza un PC. Inițial au fost acceptate doar
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
5
aplicații gratuite. Aplicații contra cost sunt disponibile pe Piața Android
începând cu 19 februarie 2009
Multi-touch Android are suport nativ pentru multi-touch, dar această funcționalitate
este dezactivată (posibil pentru a se evita încălcarea brevetelor Apple pe
tehnologia touch-screen).O modificare neoficială, care permite multi-touch
a fost dezvoltată
1.3 SDK-ul oferit de Android
SDK-ul Android include un set complet de instrumente de dezvoltare. Acestea includ un
program de depanare, biblioteci, un emulator de dispozitiv , documentație, mostre de cod și
tutoriale. Platformele de dezvoltare sprijinite în prezent includ calculatoare bazate pe x86 care
rulează Linux (orice distribuție Linux desktop modernă), Mac OS X 10.4.8 sau mai recent,
Windows XP ,Vista, 7 sau 8. Cerințele includ, de asemenea, Java Development Kit, Apache Ant,
și Python 2.2 sau o versiune ulterioară.
Mediul de dezvoltare (IDE) suportat oficial este Eclipse (3.2 sau mai recent), utilizând
plug-in-ul Android Development Tools (ADT), deși dezvoltatorii pot folosi orice editor de text
pentru a edita fișiere XML și Java și apoi să utilizeze unelte din linia de comandă pentru a crea,
să construi și depana aplicații Android.
La 18 august 2008, a fost lansat Android SDK 0.9 beta. Această versiune oferă un API
actualizată și extinsă, instrumente de dezvoltare îmbunătățite și un design actualizat pentru
ecranul de bază. Instrucțiuni detaliate pentru actualizare sunt disponibile pentru cei care
lucrează deja cu o versiune anterioară.
La 23 septembrie 2008 a fost lansat SDK-ul Android 1.0 . Conform documentației de
lansare, includea "în principal remedii pentru probleme, deși au fost adaugate unele capabilități
mai puțin semnificative". Includea, de asemenea, câteva modificări ale API-ului față de
versiunea 0.9. 5
Pe 9 martie 2009, Google a lansat versiunea 1.1 pentru telefonul Android Dev. Deși
există câteva actualizări estetice, câteva actualizări cruciale includ suport pentru "căutare prin
voce, aplicații contra cost, remedii pentru ceasul cu alarmă, remediu pentru blocarea la
trimiterea gmail, notificări de poștă electronică și intervale de împrospătare, iar acum hartile
afișează evaluări de firme". Un alt update important este că telefoanele Dev pot acum accesa
aplicații plătite și dezvoltatorii le pot vedea acum pe Piața Android.
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
6
1.4 Versiuni Android
Versiunile Android in ordine cronologica inversă:
Versiune Pseudonim Data lansarii Nivel API Rata de utilizare
4.4 KitKat October 31, 2013 19 1.1%
4.3.x
Jelly Bean
July 24, 2013 18 4.2%
4.2.x November 13, 2012 17 12.9%
4.1.x July 9, 2012 16 37.4%
4.0.3–4.0.4 Ice Cream Sandwich December 16, 2011 15 18.6%
3.2 Honeycomb July 15, 2011 13 0.1%
2.3.3–2.3.7 Gingerbread February 9, 2011 10 24.1%
2.2 Froyo May 20, 2010 8 1.6%
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
7
2. Arhitectura Android OS
2.1. Kernel, librarii
Arhitectura Android poate fi observata in figura urmatoare:
Cand vorbim de arhitectura Android OS , ne gandim la faptul ca acest sistem de operare
este o stiva software de layere(straturi),unde fiecare layer este un grup alcatuit din mai multe
componente de program.Pentru a intelege mai bine aceasta arhitectura,ea trebuie parcursa de
la baza catre varf.[2]
Practic,arhitecura cuprinde urmatoarele straturi:
Applications layer(aplicații scrise în Java, executate în Dalvik)
Framework services and libraries layer(scris cea mai mare parte în Java)
Applications and most framework code executed in a virtual machine layer
Native libraries, daemons and services layer(scrise în C sau C + +)
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
8
Kernel-ul Linux, care include drivere pentru hardware, retea, accesul la de fișierul de
sistem și comunicarea inter-proces.[2]
Kernel
Android constă dintr-un strat ce are ca baza kernel-ul Linux 2.6 și Linux Kernel 3.x ( pt
varianta Android 4.0 ), cu middleware, biblioteci și API-uri scrise în C și aplicații software ce
rulează pe un application framework, care include biblioteci Java bazate pe Apache Harmony.
Întregul sistem de operare Android este construit deasupra stratului de bazaLinux Kernel 2.6, cu
unele modificări suplimentare arhitecturale efectuate de către Google.[3]
Nucleul Linux include multitasking real, memorie virtuală, biblioteci partajate, demand
loading, executabile partajate copy-on-write, gestiunea memoriei corectă, și rețele TCP/IP.
Astăzi, Linux este un nucleu monolitic cu încărcare de module. Device drivere și extensii de
nucleu rulează tipic în inelul 0, cu acces total la hardware, deși unele rulează în spațiul utilizator.
Spre deosebire de nucleele monolitice standard, device driver-ele se configurează ușor ca
module, și se încarcă sau se descarcă în timpul rulării sistemului. Tot spre deosebire de nucleele
monolitice standard, device driver-ele pot fi pre-empted în anumite condiții. Acest din urmă
feature a fost adăugat pentru a trata întreruperile hardware corect, și pentru a îmbunătăți
suportul pentru multiprocesare simetrică. Procesul de pre-empty ameliorează latența, crescând
viteza de răspuns și făcând Linux mai potrivit pentru aplicații de timp real.[3]
Acest OS folosește mașina virtuală Dalvik ce beneficiaza de compilator just-in-time,
pentru a rula Dalvik DEX-cod (Dalvik executabil), care este de obicei tradus din Java
bytecode.[3]
Principala platforma hardware utilizata de Android este arhitectura ARM.
Cea mai noua varianta 3.3 este prezenta pe device-urile ce folosesc Android 4.0, respectiv 4.1,
kernelul fiind imbunatatit in principal pentru bug-fixing.Cele mai importante schimbari fata de
versiunile anterioare sunt:
Btrfs
Suport pentru restriping între diferite niveluri RAID, echilibrarea îmbunătățită și instrumente de
depanare.
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
9
Open vSwitch
Implementarea avansata a unui switch de rețea, cu suport specializat complet, pentru mediul
virtual.
Teaming network interface
Inlocuirea bonding-driverului, ce oferă conexiune de rețea rapidă și stabilă.
Byte Queue Limits and Per-cgroup TCP buffer limits
Limitele configurabile pentru buffere pentru a preveni problemele de latență excesive.
Network priority control group
Interfata Administrator pentru stabilirea priorității traficului in aplicații.
Enhanced ext4 online resizing
Redimensionarea Ioctl mai rapidă și mai flexibilă, astefl incat Kernelul poate efectua toate
activitățile de resizing.
Support for Texas Instruments C6X architecture
Suport pentru cele mai recente multi-core-uri DSP Texas Instruments.
EFI boot support
Stub-ul de boot poate fi acum executate direct de către EFI firmware-ul.
Librarii
In materie de librarii, Android include un set de biblioteci C / C + + utilizate de diferitele
componente ale sistemului. Acestea sunt expuse dezvoltatorilor prin intermediul application
framework-ului.Acest layer(al librariilor) permite device-ului echipat cu Android OS sa lucreze
cu diferite tipuri de date.
Cele mai inportante librarii sunt:
System C library - BSD-derivata din standardul C(libc) ,a fost imbunatatita pentru embedded
Linux-based devices
Media Libraries – bazata pe PacketVideo's OpenCORE; librariile suporta playback si
inregistrarea formatelor audio si videa cunoscute,dar si a formatelor de imagine, incluzand
MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG
Surface Manager - gestionează accesul la subsistemul de afișare și straturile 2D și 3D din mai
multe aplicații
LibWebCore – un engine web browser modern,ce aduce impreuna Android browser si
embeddable web view
SGL – engine pentru support grafic 2D
3D libraries – implementare bazata pe OpenGL ES 1.0 APIs; librariile fie utilizeaza hardware
3D acceleration,fie 3D software rasterizer
FreeType - bitmap si vector de redare font
SQLite- un motor de baze de date relaționale disponibil pentru toate aplicațiile
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
10
2.1.1 Linux Kernel 2.6
In martie 2001, si mai apoi, in iunie 2002, dezvoltatorii core-ului kernel s-a reunit la Summit-ul
Kernel. Scopul principal al Kernel-ului 2.5 era sa faca update-ul layer-ului block (layer
responsabil de dispozitivele bloc, precum hard-drive-urile). Alte teme aduse in discutie au fost:
scalabilitatea, raspunsul sistemului si memoria virtuala. Lista update-urilor este urmatoarea:
- Process scheduler
- Kernel preventiv
- Imbunatatiri ale timpului de raspuns
- Redesign-ul layer-ului bloc
- Imbunatatirea subsistemului `memorie virtuala`
- Imbunatatirea suportului firelor de executie
- Layer de sunet nou.
Process scheduler
Process scheduler-ul este subsistemul kernelului responsabil cu alocarea timpului de procesor.
El este cel care decide ce proces este rulat, si cand. De multe ori, aceasta nu este o sarcina
usoara. Acesta trebuie sa se asigura ca din toata lista proceselor, cel mai important va fi mereu
cel care ruleaza. Imbunatatirile ce se doreau a fi aduse aduse la nivelul organizatorului au fost
urmatoarele:
- Organizare O(1) completa. Fiecare algoritm din cadrul organizatorului ar trebuie sa se
execute intr-o perioada de timp constanta, indiferent de numarul de procese care
ruleaza.
- Scalabilitate SMP perfecta. Ideal ar fi ca fiecare procesor ar trebuie sa aiba propria lista
de procese rulabile din care organizatorul sa aleaga (runque).
- Imbunatatirea afinitatii SMP. Ar trebui sa tinda natural sa grupeze task-urile pe un CPU
anume si sa le ruleze acolo. Migrarea task-urilor de la un CPU la altul ar trebui sa fie
facuta doar in cazul rezolvarii unor distributii neuniforme in ceea ce priveste lungimea
listelor runque.
Noul organizator respecta cerintele descrise mai sus. Prima cerinta, organizarea O(1) completa
se refera timpul de procesare al algoritmului folosit pentru selectia task-ului primordial.
Indiferent de dimensiunea listei de procese eligibile pentru a rulare, timpul in care acest
algoritm este rulat trebuie sa fie mereu acelasi (constant). In vechiul organizator, algoritmul
putea fi sintetizat astfel:
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
11
for (each runnable process on the system) {
find worthiness of this process
if (this is the worthiest process yet) {
remember it
}
}
run the most worthy process
In noua varianta, este verificata eligibilitatea fiecarui proces. Asta presupune ca algoritmul sa
cicleze de n ori pentru n procese. Mai mult, acesta este un algoritm de ordin O(n) – scaleaza
linear cu numarul proceselor. Acesta ar putea fi descris de urmatoarea secventa de pseudocod:
get the highest priority level that has processes
get first process in the list at that priority level
run this process
O alta imbunatatire adusa de noul organiator este accesul rapid la cel mai prioritar proces si la
primult proces din lista. Acesta tine o tabela cu toate aceste procese, putand astfel doar sa
selecteze procesul dorit, fata de a-l cauta, cum facea pana la 2.6.
A doua cerinta se refera la scalabilitatea perfecta SMP. Asta implica ca , in cazul in case se
adauga procesoare la un sistem dat, performantele organizatorului la nivel de procesor raman
neschimbate. Acest lucru nu era valabil in vechea versiune, odata cu cresterea numarului de
procesoare, scazand performantele organizatorului per procesor. Exista un overhead
considerabil dat de acest update, tocmai pentru asta introducandu-se un blocaj pe fiecare
runque, la un moment dat, doar un singur procesor putand avea acces concurent la organizator.
Noul organizator imparte lista ‘runque’ globala in liste individuale per procesor.
Fig 1. Runqueue 2.4 Runqueue 2.5/2.6
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
12
Preemtive kernel
Actualizarea este valabila de la versiunea 2.5.4. Pana la acest moment, procesele se executau
consecutiv. Aceasta modificarea ridica probleme de securitate la nivelul datelor impartasite de
procese. Sistemul SMP (multiprocesare simetrica) se ocupa de acesta problema de securitate.
Mecanismele folosite de acest sistem pentru protectia in conditii de multiprocesare simetrica,
au fost usor de adaptat pentru a oferi securitate in contextul unui kernel preventiv.
Imbunatatiri ale timpului de raspuns
Kernelul preventiv atrage dupa sine imbunatatirea timpului de raspuns, sistemul putand
detecta acu urmatorul `bottleneck`. Dezvoltatorii si-au concentrat atentia asupra algoritmilor in
ideea micsorarii latentei. Pentru asta, au avut in vedere memoria virtuala(VM - `virtual
memory`) si sistemul de fisiere virtual (VFS - `virtual file system`), si, consecutiv, reducand
durata de `lock`.
Redesign al layer-ului bloc
Incepand cu versiunea 2.5.1, cea mai importanta modificare a constat in creearea unei structuri
generice si flexibile pentru a reprezenta request-urile bloc I/O, eliminarea bufferelor de bounce
si suportul I/O direct in memoria inalta, transformand lock-ul io_request_lock per queue, si
realizarea unui nou organizator I/O.
Pana la versiunea 2.5, layerul bloc folosea o structura `buffer-head` pentru reprezentarea
request-urilor I/O. Aceasta metoda era ineficienta din multiple motive, principalul fiind cel ca
layer-ul bloc trebuia sa divida structurile de date in bucati mai mici , doar pentru a le reconstrui
mai apoi in organizatorul I/O. In versiunea 2.5, kernel-ul foloseste o structura de date noua,
struct `bio`, pentru repprezentarea request-urilor I/O. Aceasta este o structura simplificata,
potrivita pentru request-urile I/O raw dau din buffer, lucreaza cu memoria inalta iar datele pot
fi impartite si reconstruite cu usurinta. Rezulta un cod mai curat si mai eficient.
In aceasta versiune a kernel-ului s-a renuntat la hop-ul extra necesar pana acum (low memory)
pentru transferul datelor de pe un dispozitiv de tip bloc in memoria de nivel inalt.
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
13
Fig. 2 Hop-ul intermediar(low memory) pentru accesul datelor
de pe dispozitivele de tip bloc
(buffer-ul bounce)
S-a trecut de la lista globala de procese la liste individuale de procese per procesor, fiecare lista
cu lock-ul ei.
Fig 3. Kernel-ul 2.5 introduce un lock per lista de request-uri (in asteptare)
O imbunatatire majora este structura cozii de request-uri,structura arbore, fata de structura
lineara, folosita pana la versiunea 2.5, imbunatatind astfel timpul de raspuns al sistemului.
Subsistemul VM(virtual memory) imbunatatit
Pana la aceasta versiune, mereu au existat probleme legate de managementul memoriei
virtuale. In versiunea 2.6 apar trei schimbari majore:
- Mapare inversa a VM (rmap)
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
14
- Redesign al algoritmilor – mai simplii si mai inteligenti
- Integrare stransa cu layer-ul VFS
Aceste schimbari au dus la imbunatatirea performantelor in majoritatea cazurilor. In continuare
vom analiza fiecare din cele trei schimbari majore.
Fiecare sistem de memorie virtuala contine atat adrese fizice (adresele paginilor din
cipurile RAM) si adrese virtuale (adresele virtuale disponibile aplicatiilor). Arhitecturile cu
unitate de management al memoriei (MMU) permit un lookup convenabil al adresei fizice
pornind de la adresa virtuala. Acest lucru este de dorit deoarece aplicatiile acceseaza memoria
virtuala in mod constant, sistemul trebuind sa faca conversia din adresa virtuala in cea fizica.
Accesul invers (de la cea fizica la virtuala) nu este la fel de facil. Pentru asta, kernel-ul trebuie sa
scaneze fiecare pagina a memoriei fizice si sa caute adresa dorita, un proces mare consumator
de timp. O mapare inversa a memoriei virtuale ofera o lista de corespondente intre adresa
virtuala si cea fizica. Cu alte cuvinte, in loc de
memoria virtuala cu rmap trebuie doar sa caute in lista corespondenta dorita. Acesta este un
proces mult mai rapid, acest lucru putand fi observat mai ales cand memoria virtuala este
foarte solicitata. In figura 4 se poate observa acest proces de rmap.
Fig.4 Maparea inversa face legatura intre o pagina din memoria fizica si una sau mai
multe pagini din memoria virtuala.
In continuare, algoritmii au fost reproiectati astfel incat sa fie simplificati si mai stabili.
In final, integrarea intre VM si VFS a fost mult imbunatatita. Metodele `write-back` si `read-
ahead` pentru fisiere si pagini, impreuna cu management-ul buffer-ului au fost simplificate.
`bdflush kernel thred` a fost inlocuit de `pdflush`. Noile fire de executie (thred) sunt capabile de
o mai buna saturatie a discului.[5]
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
15
2.2. Procese, fire de executie (threads)
2.2.1. Executia proceselor
Executia unei componente anume a unei aplicatii, este controlata de fisierul
manifest.Elementele componente — <activity>, <service>, <receiver>, and <provider> au cate
un atribut de proces care specifica procesul in cazul in care o componenta a aplicatiei trebuie sa
ruleze. Aceste atribute pot fi setate astfel încât fiecare componentă se fie executată în propriul
proces, sau mai multe componente sa imparta acelasi proces.Pot fi de asemenea setate astfel
incat aceleasi componente sa ruleze in acelasi process, dar pentru aplicatii diferite. Elementul
<application> de exemplu, are un atribut de proces, ce stabileste o valoare implicită aplicabila
tutror componentelor.
Toate componentele sunt instanțiate în firul principal al procesului specificat, și apelurile de
sistemului pentru acea componentă sunt expediate de la aceast thread. Nu sunt create
threaduri separate pentru fiecare instanță. În consecință, metodele care răspund la aceste
apeluri - metode, cum ar fi View.onKeyDown ce raporteaza acțiunile utilizatorului si notificările
despre ciclul de viață se execută întotdeauna în firul principal al procesului.[4]
Sistemul de operare poate sa decida oprirea unui proces la un moment dat, atunci cand
memoria este scazuta si ceruta de alte procese vitale pentru utilizator.Astfel, un proces este
reluat in momentul in care, este nevoie din nou de anumite componete ale aplicatiei.
Inainte de a decide ce proces sa opreasca, Android ia in calcul ce proces este mai important
pentru utilizator, astfel ca , este mai usor sa inchida un proces care nu e vizibil pe ecran , decat
unul existent acolo.
Sistemul Android încearcă să mențină un proces pentru o anumita aplicatie cat mai mult
timp posibil, dar elimina procesele aflate prea mult timp in executie , recuperand astfel
memoria pentru procese noi sau pentru procesele mai importante. Pentru a determina ce
procese sa păstreze in executie, si pe care sa le opreasca, sistemul de operare face o ierarhizare
a lor, in functie de compenentele implicate in process si de starea acestora.
Astfel, procesele cu cea mai mica importanță sunt eliminate primele, apoi cele cu următoarea in
ordinea importantei, și așa mai departe, după cum este necesar , pentru a recupera resursele
sistemului.
Exista o ierarhie a importantei proceselor pe 5 niveluri:
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
16
Foreground process:
Un proces aflat in derulare pentru o aplicatie curenta.Acesta e considerat va fiind in foreground
daca indeplineste una din urmatoarele conditii:
-gazduieste o Activity cu care userul interactioneaza;
-gazduieste un Service legat de Activity-ul cu care interactioneaza userul;
-gazduieste un Service care ruleaza in foreground-acest serviciu este apelat prin metoda
startForeground() ;
-gazduieste un Service care executa una dintre lifecycle callbacks (onCreate(), onStart(), sau
onDestroy()).
-Gazduieste un BroadcastReceiver executat prin metoda onReceive()
Visible Proces
Un proces care nu are nici o componenta in foreground, dar poate afecta ceea ce utilizatorul
vede pe ecran. Un proces este considerat a fi vizibil daca oricare dintre urmatoarele condiții
sunt adevarate:
- găzduiește o Activity care nu se află în foreground, dar este încă vizibila pentru utilizator
(apelata de metoda onPause () ). Acest lucru s-ar putea să apară, de exemplu, în cazul în care
activitatea de foreground a început un dialog, care permite ca activitatea anterioară sa fie
văzuta în spatele ei.
- găzduiește un Service care este legat in foreground de Activity.
Un proces vizibil este considerat extrem de important și nu va fi oprit decat dacă acest lucru
este necesar pentru a menține toate procesele din foreground in executie.
Service process
Este un proces ce execută un serviciu care a fost apelat cu metoda Startservice () și nu se
încadrează în nici una dintre cele două categorii superioare. Deși procesele de servicii nu sunt
direct legate cu orice vede utilizatorul acestea realizeaza în general, lucruri de care utilizatorul
este interesat (cum ar fi redarea de muzică în fundal sau descărcarea de date pe rețea), astfel
încât sistemul le păstrează în funcțiune cu excepția cazului în care nu exista suficientă memorie
pentru a le menține împreună cu toate informațiile generate de procesele vizibile si cele de
foreground .
Background process
Un proces ce deține o activitate care nu este vizibila pentru utilizator (apelata prin metoda
onStop ()). Aceste procese au un impact direct asupra experienței utilizatorului, iar sistemul le
poate opri in orice moment pentru a recupera memorie pentru procesele foreground, cele
vizibile, sau procesul de servicii. De obicei, există mai multe procese de background in executie,
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
17
astfel ca, acestea sunt păstrate într-o lista LRU (cel mai recent utilizate)pentru ca sistemul de
operare sa se asigure că procesul care a fost cel mai recent utilizat de user este ultimul care
urmează să fie oprit. Dacă o activitate isi implementeaza metodele pentru lifecycle corect, și
salvează starea curenta, oprirea procesului ei nu va avea un efect vizibil asupra experienței
utilizatorului, pentru că atunci când utilizatorul navighează înapoi la activitate, aceasta isi
restabilește starea.
Empty process
Este un proces care nu deține componente active ale aplicației.Singurul motiv pentru a menține
acest tip de proces în viață este pentru scopuri de cache, pentru a imbunatati timpul de pornire
data viitoare cand o componentă trebuie să ruleze.Sistemul opreste de multe ori aceste
procese, în scopul de a echilibra resursele generale ale sistemului de cache între proces și
cache-ul subadiacent al kernel-ului.
2.2.2 Realizarea firelor de executie(threads)
Desi exista posibilitatea rularii unui singur proces pentru o anumita aplicatie, la un moment dat,
va exista in background un thread in executie pentru aplicatia respectiva.Tinand cont ca ,
pentru dispozitivele touch actuale este important ca interfata cu userul trebuie sa raspunda
rapid la actiunile acestuia,threadul care gazduieste o anumita activitate, trebuie sa nu raspunda
in acelasi timp si de o aplicatie consumatoare de timp , cum ar fi downloadul.
De aceea, orice activitate de acest gen trebuie transferata catre un alt thread.[4]
Threadurile sunt create in cod folosind standard Java Threads objects. Android oferă o serie de
clase pentru gestionarea firelor de executie - Looper pentru a rula o buclă într-un
thread,Handler –utilizat pentru prelucrarea mesajelor, și HandlerThread pentru înființarea unui
thread, cu o buclă.
Metode pentru Thread-safe
Când un apel la o metodă implementată într-un obiect IBinder provine din același proces ca și
IBinder, metoda este executata în threadul apelantului.
Totusi,atunci cand apelul provine de la un alt proces,metoda este executata intr-un thread ales
dintr-un pool de threaduri pe care sistemul de operare il mentine in acelasi process cu IBinder,
nefiind executat in firul principal al procesului.
De exemplu,in timp ce metoda de servicii onBind() va fi apelata din threadul principal al
procesului servicii,metodele implementate in obiectul pe care onBind() il returneaza vor fi
apelate din threadurile existente in pool.Tinand cont ca un serviciu poate avea mai mult de un
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
18
client, mai multe threaduri pot “angaja” aceeasi metoda IBinder in acelasi timp.Deci , aceste
metode trebuie sa fie implementate astfel incat sa fie thread-safe.
In mod similar,un content provider, poate primi cereri de date ce provin din procese diferite.
Desi clasele ContentResolver si ContentProvider ascund detaliile despre cum interprocesul de
comunicare este realizat, metodele content provider ce raspund la aceste cereri- metodele
query(), insert(), delete(), update(), and getType() sunt apelate dintr-un pool de threaduri in
procesul content providerului, nu in threadul principal.De asemenea, aceste metode trebuie sa
fie implementate astfel incat sa fie thread-safe.
Comunicarea interproces
Android oferă un mecanism pentru inter-comunicare (IPC), folosind Remote Procedure Calls
(RPC), în care o metodă este apelata de către o activitate sau o componentă a unei aplicații, dar
executata la distanță (într-un alt proces), returnand orice rezultat înapoi la apelant.
Aceasta presupune descompunerea unei metode de apelare și a datelor sale la un nivel pe care
sistemul de operare il poate înțelege, transmitand apelul de la procesul și spațiul de adrese
local la procesul și spațiul de adrese de la distanță , apoi reasambland apoi apelul acolo. Valorile
returnate sunt apoi transmise în direcția opusă. Android oferă tot codul pentru a efectua aceste
operațiuni IPC.Pentru a efectua IPC, cererea trebuie să fie legata de un serviciu, folosind
bindService ().
2.3 Modalitatea de stocare a datelor
Comparativ cu alte sisteme de operare , Android OS are o modalitate diferita de stocare a
datelor:fiecare tip de data, inclusiv fisierele, sunt destinate fiecarei aplicatii in parte.
Beneficiaza totusi, si o modalitate prin care datele corespunzatoare unei aplicatii specifice pot si
expuse si celorlalte aplicatii-prin intermediul content providerului.
Un content provider este o componentă opțională a unei aplicatii, care permite accesul pentru
operatiile de citire/scriere pentru datele aplicatie datele aplicației. Content providerii
implementeaza o sintaxa standard pentru solicitarea și modificarea datelor, precum și un
mecanism standard pentru citirea datelor returnate. Android furnizează un număr de content
provideri pentru tipurile de date standard, cum ar fi imagine, audio, și fișiere video și informații
de contact personale.
Indiferent dacă se doreste sau nu exportarea datele aplicației pentru alte aplicatii, este
necesara o modalitate de stocare. Android oferă următoarele patru mecanisme pentru stocarea
și regăsirea datelor: Preferences, Fișiere, Baze de date, Network,Internal storage, external
storage.
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
19
2.3.1 Baza de date
API-ul Android contine suport pentru crearea și utilizarea bazelor de date SQLite. Fiecare
bază de date este asociata aplicației care o creează.Obiectul SQLiteDatabase reprezintă o bază
de date ce contine metode pentru a interacționa cu acesta - de interogări și gestionarea a
datelor. Pentru crearea unei baza de date, se apeleaza rutina SQLiteDatabase.create () și, de
asemenea, subclasa SQLiteOpenHelper.
In ceea ce priveste suportul pentru sistemul de baze de date SQLite, Android dispune de funcții
de gestionare al bazei de date ce permit să stocare de colecții complexe de date arhivate în
obiecte. De exemplu, Android definește un tip de date pentru informațiile de contact; aceasta
este alcătuită din mai multe campuri, inclusiv un nume și prenume (siruri de caractere), o
adresă și numere de telefon (de asemenea, siruri de caractere), o fotografie (imagine bitmap),
precum și alte informații.
Android permite navigarea in baza de baze de date cu ajutorul tool-ului SQLite3 , ce permite să
răsfoiți conținutului, executarea de comenzi SQL, precum și alte funcții utile privind bazele de
date SQLite.
Toate bazele de date, SQLite și altele, sunt stocate pe dispozitiv folosind pathul / date / date /
nume_pachet / baze de date.[4]
2.3.2 Tipuri de fisiere si preferences
Ca modaliate de stocare, datele pot fi retinute direct pe dispozitivul mobil sau pe un
dispozitiv removable. In mod implicit, alte aplicații nu pot accesa aceste fișiere.
Pentru a citi date dintr-un fișier, se apeleaza Context.openFileInput () și se trece numele și
pathul fișierului. Returnează un obiect standard Java FileInputStream.
Pentru a scrie într-un fișier, se apeleaza Context.openFileOutput () cu numele și pathul
fisierului. Returnează un obiect FileOutputStream. Apelarea acestor metode nu funcționeaza
decat pentru fișierele locale.
Preferences reprezinta un mecanism pentru a stoca și a prelua perechi de tipuri de date
primitive de tip key-value. Acesta este de obicei folosit pentru a stoca preferințele in aplicații,
cum ar fi un mesaj de salut implicit sau un font de text care urmează să fie încărcate atunci când
o aplicatie este pornita. Se poate apela Context.getSharedPreferences () pentru a citi și a scrie
valori. Se pot atribui pentru setul de preferințe, sau partaja cu alte componente în aceeași
aplicație, cu Activity.getPreferences .[4]
2.3.3 Network
Stocarea datelor pe web se poate face folosind network serverul propriu.Android ofera o
modalitate de expunere a datelor private, altor aplicatii prin intermediul content
providerului.Astfel, se poate folosi reteaua pentru a stoca si prelua date folosind propriile
servicii web.Pentru a face operatiuni de retea se folosesc urmatoarele clase: java.net.* ,
android.net.*.[4]
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
20
3. Avantajele/Imbunatatirile aduse de noua versiune
3.1. Diminuarea cerintelor hardware
Android 4.4 este proiectat sa ruleze pe o gama mult mai larga de dispozitive mobile, cu
capacitati harware reduse, chiar si pe dispozitive cu memorie de doar 512MB.
Optimizari precum ajustari ale cache-ului codului ale lui Dalvik JIT, KSM (kernel
samepage merging) sau trecerea de la swap la zRAM, toate au condus la un management al
memoriei imbunatatit.
In cadrul noii versiuni intalnim un control foarte strict al consumului de memorie. Astfel in cazul
in care mai multe servicii trebuie sa porneasca in acelasi timp (ex: cazul in care dispozitivul
mobil se conecteaza la o alta retea), Android lanseaza in executie pachete de servicii, in serie si
nu toate odata, in paralel, pentru a evita peak-uri de cerere de memorie.
Tot in acest sens, a fost introdus un nou API, ActivityManager.isLowRamDevice(), ce permite
dezvoltatorilor sa programeze un comportament al aplicatiei in functie de resursele harware ale
dispozitivului. Au fost introduse noi ustensile pentru analiza traficului la nivel de memorie,
procstats tool, meminfo tool.
3.2 Noi capabilitati NFC prin intermediul HCE (host card emulation)
Android 4.4 introduce noua platformă de suport pentru
tranzacții securizate pe bază de NFC prin Emulare Card
Gazdă (HCE – host card emulation), pentru plăți, programe
de loialitate, carduri de acces, permise de trecere, si alte
servicii personalizate. Cu HCE, orice aplicatie de pe un
dispozitiv Android poate emula un smart card NFC,
permițând utilizatorilor ca prin atingere sa inițieze tranzacții
cu o aplicație la alegerea lor – nefiind nevoie de nici un
element de siguranta (SE) în dispozitiv. Aplicatiile pot utiliza, de asemenea, un nou Mod Reader pentru
a acționa ca cititoare de carduri HCE și alte tranzacții bazate pe NFC.
HCE Android emulează carduri inteligente bazate pe protocolul ISO / IEC 7816, care utilizează protocol
de transmisie contactless ISO / IEC 14443-4 (ISO-DEP). Aceste carduri sunt utilizate de mai multe
sisteme de astăzi, inclusiv de infrastructura de plată EMVCO NFC existente. Android folosește
identificatoare de aplicatii (AIDs), asa cum sunt definite în ISO / IEC 7816-4 ca bază pentru rutare a
tranzacțiilor catre aplicațiile Android corecte.
Aplicatiile declara AID-urile în fișierele lor manifest, împreună cu un identificator de categorie care indică
tipul de suport disponibil (de exemplu, "plăți"). În cazurile în care mai multe aplicații acceptă același AID
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
21
în aceeași categorie, Android afișează un fereastra dialog care permite utilizatorului să aleagă care
aplicatia pe care doreste sa o utilizeze.
Atunci când utilizatorul apasa să plătească la un terminal POS, sistemul extrage AID dorit și ruteaza
tranzacția la aplicarea corectă. Aplicația citește datele tranzacției și poate folosi orice servicii locale sau
din rețea pentru a verifica și apoi finaliza tranzacția.
HCE Android necesită un controler NFC în dispozitiv. Suport pentru HCE este deja disponibil pe scară
largă în cele mai multe controlere NFC, care oferă suport dinamic, atât pentru HCE și tranzacțiile SE.
Dispozitivele Android 4.4 care acceptă NFC vor include si `Tap & Pay` pentru plati facile, folosind HCE.
3.3 Framework pentru imprimare Aplicațiile Android au acum posibilitatea de a imprima orice tip de conținut prin Wi-Fi sau de servicii
găzduite-cloud, cum ar fi Google Cloud Print. În aplicații ce au activata optiunea de imprimare,
utilizatorii pot descoperi imprimantele disponibile, schimba dimensiuni de hârtie, alege anumite pagini
pentru a imprima, și imprima aproape orice tip de document, imagine, sau un fișier.
Android 4.4 introduce suport nativ pentru imprimare, împreună cu API-uri pentru gestionarea imprimarii
și adăugarea de noi tipuri de suport de imprimantă. Platforma oferă un manager de imprimare care
mediază între aplicațiile ce solicita imprimare și servicii de tipărire instalate care se ocupa de cererile de
imprimare.Managerul de imprimare oferă servicii partajate și un sistem UI(interfata utilizator) pentru
imprimare, oferind utilizatorilor un control constant în imprimarea de pe orice aplicatie. Managerul de
imprimare asigură, de asemenea, securitatea de conținut, deoarece a trecut peste procese, de la o
aplicație la un serviciu de imprimare.
Producătorii de imprimante pot folosi noi
API-uri pentru dezvoltarea de servicii de
imprimare proprii - componente
conectabile care se adaugă servicii
specifice furnizorului, pentru
comunicarea cu anumite tipuri de
imprimante. Producatorii pot construi
servicii de imprimare și le pot distribui
prin Google Play, oferind un acces facil
pentru utilizatori să găsească și să le
instaleze pe dispozitivele lor.
Aplicațiile destinate clientilor pot utiliza noi API-uri pentru a adăuga capacități de imprimare în aplicațiile
lor, cu modificări minime de cod. În cele mai multe cazuri, trebuie să adăugați o acțiune de imprimare in
Action Bar și o interfață pentru a alegerea elementului destinat imprimarii.
Pentru o mai larga compatibilitate, Android folosește PDF ca format de fișier primar pentru imprimare.
Înainte de imprimare, aplicația trebuie sa genereze o versiune PDF paginata a conținutului de imprimat.
Pentru comoditate, API-ul de imprimare oferă clase helper native și WebView pentru a vă permite să
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
22
creați PDF-uri care folosesc API-uri de desen standard Android. Dacă aplicația utilizatorului știe cum să
deseneze conținutul, se poate crea rapid un PDF pentru tipărire.
Cele mai multe dispozitive care rulează Android 4.4 vor include Google Cloud Print pre-instalat ca un
serviciu de imprimare, precum și mai multe aplicații Google care acceptă imprimarea, inclusiv Chrome,
Drive, Gallery, și QuickOffice.
3.4 Framework pentru accesul la mediile de stocare
Un nou framework pentru accesul la mediile de stocare face ofera utilizatorilor o navigare si deschidere
facila pentru document, imagini și alte fișiere de pe toate lor de mediile lor de stocare preferate. O
interfata UI standard, ușor de utilizat, permite utilizatorilor cautarea si accesarea fișiere recente într-un
mod consecvent în aplicații și furnizori.
Cloud sau de servicii de stocare locale pot participa la
acest ecosistem prin implementarea unui noi clase
`furnizor de documente` care încapsulează serviciile
lor. Clasa furnizor include toate API-urile necesare
pentru înregistrarea furnizorului cu sistemul și de a
gestiona navigarea, citirea, precum și scrierea
documentelor. Furnizorul de document poate oferi
utilizatorilor acces la orice date de la distanță sau
local, care pot fi reprezentate ca fișiere - de la text,
fotografii și imagini de fundal pentru video, audio, și
nu numai.
3.5 Senzori de joasa putere
3.5.1 Gruparea senzorilor
Android 4.4 introduce suport pentru gruparea senzorilor hardware, un nou de optimizare , care poate
reduce semnificativ consumul de energie consumată de senzori in cadrul activităților în curs de
desfășurare .
Prin gruparea senzorilor, Android lucrează cu hardware-ul dispozitivului pentru a colecta și livra
evenimente senzor eficient în loturi , mai degrabă decât individual, pe masura ce acestea sunt detectate
. Acest lucru permite procesorului aplicației să rămână într-o stare de repaus (implica consum redus de
putere) până ce loturile sunt livrate . Se pot solicita evenimente grupate de la orice senzor folosind un
ascultător standard de eveniment, și puteți controla intervalul la care veți primi loturile . Puteți solicita ,
de asemenea, livrare imediata a evenimentelor între ciclurile de lot uri.
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
23
Gruparea senzorilor este ideala pentru un consum redus de energie , utilizare de lungă durată, cum ar fi
sala de fitness , localizare , monitorizare , și altele.
3.5.2 Detectia si contorizarea pasilor
Android 4.4 de asemenea, adaugă suport pentru doi
senzori noi - detector pas și contor pas - care permit
aplicatiei sa inregistreze activitatea utilizatorului - mersul
pe jos, alergatul, sau urcatul scarilor. Acesti noi senzori
sunt implementati pentru un consum redus de energie.
Detectorul pas analizează intrare accelerometru pentru a
recunoaște atunci când utilizatorul a făcut un pas, apoi
declanșează un eveniment cu fiecare pas. Contorul pas
urmărește numărul total de pasi de la ultima repornire a
dispozitivului și declanșează un eveniment cu fiecare
schimbare a numărului de pasi.
3.6 Noi capabilitati media
3.6.1 Inregistrarea continutului afisat pe ecran
Android 4.4 adauga suport pentru înregistrare ecranului și oferă un utilitar de înregistrare ecran care vă
permite pornirea/oprirea înregistrarii pe un dispozitiv care este conectat la mediul dumneavoastră
Android SDK pe USB . Este o modalitate foarte bună de a crea walkthroughs și tutoriale pentru aplicația
dvs. , materialele de testare , clipuri video de marketing , și altele.
Fisierul video va fi salvat in format MP4.
În cazul în care aplicația redă clipuri video sau alt conținut protejat care nu doriți să fie capturat de către
recorder de ecran , puteți folosi SurfaceView.setSecure ( ), pentru a marca conținutul ca sigur .
Puteți accesa ecranul de înregistrare prin intermediul instrumentului ADB inclus în SDK-ul Android ,
folosind comanda ADB shell screenrecord . De asemenea, puteți lansa prin intermediul panoului de
DDMS în Android Studio .
3.6.2 Monitorizare audio
Aplicatiile pot utiliza noi instrumente de monitorizare în
efectul Visualizer pentru a obține actualizări de pe vârf
și nivelul de RMS pentru orice fisier audio în curs de
redare pe dispozitiv.
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
24
3.7 Capacitati de randare imbunatatite
3.7.1 Îmbunătățiri de performanță (live)
Când aplicațiile vor folosi RenderScript, vor beneficia
de reglare performanță live în runtime0ul
RenderScript, fără a fi nevoie de recompilare.
Graficul din dreapta arată câștiguri de performanță
în Android 4.4 pe două chipset-uri populare.
3.7.2 Accelerarea GPU
Orice aplicație ce foloseste RenderScript beneficiaza de accelerare GPU, fără modificări de cod sau
recompilare.
Universitatea “Politehnica” din București Facultatea de Electronică, Telecomunicații și tehnologia informației
25
Bibliografie
1. http://developer.android.com/about/versions/kitkat.html
2. http://www.android-app-market.com/android-architecture.html
3. http://elinux.org/Android_Architecture#Overview_presentations-
4. http://developer.android.com/guide/storage
5. http://www.linuxjournal.com/article/6530