1. Prezentare Generală - ERASMUS...

Proiect SOA

– Android Kit Kat –

Profesor coordonator: Student:Stăncescu Ștefan Bajura George Andrei

Master IISC

Universitatea “Politehnica” din BucureștiFacultatea de Electronică, Telecomunicații și tehnologia informației

Contents1. 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........................................................................................................................11

2.2. Procese, fire de executie (threads).................................................................................................16

2.2.1. Executia proceselor..................................................................................................................16

2.2.2 Realizarea firelor de executie(threads).....................................................................................18

2.3 Modalitatea de stocare a datelor....................................................................................................19

2.3.1 Baza de date.............................................................................................................................20

2.3.2 Tipuri de fisiere si preferences..................................................................................................20

2.3.3 Network....................................................................................................................................20

3. Avantajele/Imbunatatirile aduse de noua versiune...............................................................................21

3.1. Diminuarea cerintelor hardware....................................................................................................21

3.2 Noi capabilitati NFC prin intermediul HCE (host card emulation)....................................................21

3.3 Framework pentru imprimare.........................................................................................................22

3.4 Framework pentru accesul la mediile de stocare............................................................................23

3.5 Senzori de joasa putere...................................................................................................................23

3.5.1 Gruparea senzorilor..................................................................................................................23

3.5.2 Detectia si contorizarea pasilor.................................................................................................24

3.6 Noi capabilitati media......................................................................................................................24

3.6.1 Inregistrarea continutului afisat pe ecran.................................................................................24

3.6.2 Monitorizare audio...................................................................................................................24

3.7 Capacitati de randare imbunatatite.................................................................................................25

3.7.1 Îmbunătățiri de performanță (live)...........................................................................................25

3.7.2 Accelerarea GPU.......................................................................................................................25

Bibliografie................................................................................................................................................26

2


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

3


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 AndroidConfiguraț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 aplicații gratuite. Aplicații contra cost sunt disponibile pe Piața Android

4


î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.

5


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 81.6%

6

http://en.wikipedia.org/wiki/Android_Froyo

http://en.wikipedia.org/wiki/Android_Froyo

http://en.wikipedia.org/wiki/Android_2.3

http://en.wikipedia.org/wiki/Android_2.3

http://en.wikipedia.org/wiki/Honeycomb_(operating_system)

http://en.wikipedia.org/wiki/Honeycomb_(operating_system)

http://en.wikipedia.org/wiki/Ice_Cream_Sandwich_(operating_system)

http://en.wikipedia.org/wiki/Ice_Cream_Sandwich_(operating_system)

http://en.wikipedia.org/wiki/Jelly_Bean_(operating_system)




http://en.wikipedia.org/wiki/KitKat_(operating_system)

http://en.wikipedia.org/wiki/KitKat_(operating_system)

http://en.wikipedia.org/wiki/Application_programming_interface


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 + +)

7


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.

8


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

9


2.1.1 Linux Kernel 2.6In 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:

- Organizator O(1)- 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.

Organizatorul O(1)Organizatorul de procese 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:

for (each runnable process on the system) {

10


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 processesget first process in the list at that priority levelrun 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

11


Kernel preventivActualizarea 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 raspunsKernelul 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 blocIncepand 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.

12


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)

13


- 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]

14


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:

15


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,

16


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

17


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 datelorComparativ 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.

18


2.3.1 Baza de dateAPI-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 preferencesCa 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]

19


3. Avantajele/Imbunatatirile aduse de noua versiune

3.1. Diminuarea cerintelor hardwareAndroid 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

20


î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 imprimareAplicaț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ă

21


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 senzorilorAndroid 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.

22


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 pasilorAndroid 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 ecranAndroid 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 audioAplicatiile 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.

23


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 GPUOrice aplicație ce foloseste RenderScript beneficiaza de accelerare GPU, fără modificări de cod sau recompilare.

24


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

25

http://developer.android.com/guide/storage

1. Prezentare Generală - ERASMUS...

Documents

Transcript of 1. Prezentare Generală - ERASMUS...