Hornariu Mihai -Horațiu [613726]

UNIVERSITATEA “LUCIAN BLAGA” DIN SIBIU
FACULTATEA DE INGINERIE
DEPARTAMENTUL DE CALCULATOARE ȘI INGINERIE ELECTRICĂ

PROIECT DE DIPLOMĂ

Absolvent: [anonimizat]

–Sibiu, 2015 –

UNIVERSITATEA “ LUCIAN BLAGA” DIN SIBIU
FACULTATEA DE INGINERIE
DEPARTAMENTUL DE CALCULATOARE ȘI INGINERIE ELECTRICĂ

PROIECT DE DIPLOMĂ

Sistem de monitorizare a activităților
pentru dispozitive mobile Android

Îndrumător: Prof .dr.ing. Zamfirescu Bălă Constantin

Absolvent: [anonimizat]

–Sibiu, 2015 –

1 Cuprins
1. Introducere ………………………….. ………………………….. ………………………….. ………………………….. ……….. 8
1.1 Prezentarea temei ………………………….. ………………………….. ………………………….. ……………………. 8
1.2 Motivația alegerii temei ………………………….. ………………………….. ………………………….. ……………. 9
1.3 Cerințe generale ………………………….. ………………………….. ………………………….. …………………….. 10
1.4 Utilitate ………………………….. ………………………….. ………………………….. ………………………….. ……. 11
2. Considerații teoretice ………………………….. ………………………….. ………………………….. …………………….. 12
2.1 Sisteme Android ………………………….. ………………………….. ………………………….. …………………….. 12
2.2 Versiuni ale sistemului de o perare Android ………………………….. ………………………….. …………… 17
2.3 Android SDK (kit de dezvoltare software) ………………………….. ………………………….. ………………. 23
2.4 Modelul permisiunilor în sistemul de operare Android ………………………….. ………………………… 26
2.5 Securitatea sistemelor Android ………………………….. ………………………….. ………………………….. .. 32
3. Rezolvarea temei de proiect ………………………….. ………………………….. ………………………….. …………… 37
3.1 Cercetări în domeniu ………………………….. ………………………….. ………………………….. ……………… 37
3.1.1 ViewDroid: Towards Obfus cation -Resilient Mobile Application Repackaging Detection 37
3.1.2 Unsafe Exposure Analysis of Mobile In -App Advertisements ………………………….. …………. 40
3.1.3 DroidBarrier: Know What is Executing on Your Android ………………………….. …………….. 42
3.1.4 Can Smartphone Users Turn Off Tracking Service Settings? ………………………….. …………. 44
3.1.5 Cloud -based Real -time location tracking and messaging system: A child -care case study 46
3.2 Proiectarea sistemului ………………………….. ………………………….. ………………………….. ……………. 50
3.2.1 Analiza și specificarea cerințelor ………………………….. ………………………….. ……………………. 50
3.2.2 Proiectarea bazei de date ………………………….. ………………………….. ………………………….. … 53
3.2.3 Arhitectura si stemului ………………………….. ………………………….. ………………………….. ……… 57
3.3 Dezvoltarea aplicației ………………………….. ………………………….. ………………………….. ……………… 60
3.3.1 Mediul de dezvoltare ………………………….. ………………………….. ………………………….. ………. 60
3.3.2 Structura modulelor ………………………….. ………………………….. ………………………….. ………… 62

4 Concluzii ………………………….. ………………………….. ………………………….. ………………………….. ………….. 82
4.1 Gradul d e îndeplinire a obiectivelor ………………………….. ………………………….. ……………………… 82
4.1.1 Obiective îndeplinite ………………………….. ………………………….. ………………………….. ……….. 82
4.1.2 Obiective neîndeplinite ………………………….. ………………………….. ………………………….. ……. 82
4.2 Dificultăți întâmpinate ………………………….. ………………………….. ………………………….. ……………. 83
4.3 Dezvoltări ulterioare ………………………….. ………………………….. ………………………….. ………………. 83
4.4 Cercetare ………………………….. ………………………….. ………………………….. ………………………….. ….. 84
4.5 Participare la concursuri ………………………….. ………………………….. ………………………….. …………. 84
5 Bibliografie ………………………….. ………………………….. ………………………….. ………………………….. ………. 85

8

1. Introducere
1.1 Prezentarea temei
În ultimii ani, dispozitivele mobile au căpătat o importanță majo ră în viețile oamenilor, și mai ales
în domenii de interes sporit, printre care se numără:
 Industria
 Viața cotidiană a fiecărui om, și mai ales cea familială
Odată cu descărcarea și utilizarea la scară largă a aplicațiilor pentru dispozitive mobile, au apă rut
aplicații care folosesc date personale ale utilizatorului. Folosirea datelor personale ale
utilizatorului, precum și cea a datelor referitoare la activitatea acestuia, fie ea personală sau
efectuată la locul de muncă , poate duce la efecte, cum ar fi:
 Punerea în pericol a utilizatorului
 Împiedicarea realizării cu succes a activității acestuia
 Furtul sau pierderea unor informații importante
Pentru a împiedica aceste hazarduri , se consideră că furnizarea unor date către o persoană care
supraveghează utiliz atorul este esențială, existența acestei supravegheri dovedindu -se foarte
importantă în multe cazuri.
Acest proiect de diplomă urmărește implementarea unui Sistem de monitorizare a activităților
pentru dispozitive mobile Android care are ca scop furnizarea unor date referitoare la dispozitiv și
la activitățile efectuate de către utilizator prin intermediul dispozitivului către utilizatorul final al
sistemului, și anume persoana care supraveghează .
Domeniul de aplicabilitate al sistemului e reprezentat de că tre ramura transporturilor a industriei,
precum și de familie. Pe ramura transporturilor, companiile care au ca activitate curieratul rapid
sau transportul de mărfuri pot utiliza sistemul pentru a monitoriza activitatea curierului, precum și
pentru a detec ta poziția acestuia. În cadrul familiei, sistemul poate fi folosit de către părinți pentru

9
control parental, și anume supravegherea activității copiilor pe dispozitivele mobile sau a poziției
acestora.

1.2 Motivația alegerii temei

Pentru realizarea sistemulu i, în timpul celor patru ani de studiu cunoștințe importante au fost
dobândite în cadrul cursurilor: Tehnologii pentru Dezvoltare de Aplicații, Inginerie Software,
Dezvoltarea aplicațiilor WEB, precum și Programare orientată obiect.
Un element motivațional important în demersul realizării proiectului de diplomă îl reprezintă
dorința de a realiza o aplicație sau un sistem prin care activitatea copiilor să poată fi monitorizată
de către părinții acestora. Prezența mesajelor cu conținut nepotrivit primite de c ătre copii, sau
trimiterea de mesaje coroborată cu trimiterea de apeluri putând pune în pericol siguranța și
intimitatea tinerilor. Monitorizarea activității copiilor pe dispozitive, precum și monitorizarea
periodică a locației copiilor pot limita riscuril e la care sunt supuși aceștia, prin simpla informare a
părinților.
Curiozitatea și dorința de cunoaștere au reprezentat alți factori importanți care au dus la începerea
acestui proiect. Dintre acestea, poate fi evidențiată dorința de a afla care sunt mecan ismele prin
care un dispozitiv inteligent al zilelor noastre reacționează la evenimente cum ar fi primirea sau
trimiterea unui apel sau a unui mesaj, precum și mecanismele sau structurile în care aceste date
personale sunt stocate în cadrul sistemului de o perare. De asemenea, o altă curiozitate care a urmat
să primească răspuns a fost aceea de a afla care sunt design pattern -urile folosite în cadrul
sistemului de operare Android, care dintre clasele existente implementează anumite design pattern –
uri, precum și care clase sunt responsabile de notificarea anumitor evenimente, respectiv de
răspunsul la notificările lansate de către aceste evenimente.
Alegând această temă, am descoperit că o provocare ar putea fi reprezentată de către realizarea
celor două aplic ații prin intermediul a două tehnologii și limbaje foarte des întâlnite în zilele
noastre și anume Android(Java) și Web. Realizarea transmisiei datelor personale între aceste două
aplicații astfel încât utilizatorul supravegheat să nu poată observa existen ța aplicațiilor, precum și
transmiterea datelor prin intermediul unui protocol care să nu permită furtul, pierderea sau
deteriorarea acestora , au reprezentat importante provocări și totodată importanți factori
motivaționali.

10

1.3 Cerințe generale

Dispoziti vele pe care este prezent sistemul de operare Android sunt cele mai utilizate în prezent
de către deținătorii de dispozitive mobile. Existența posibilității persoanelor de a supraveghea
activitatea efectuată pe anumite dispozitive sau de a detecta poziția persoanelor care utilizează
aceste dispozitive în timp real este considerată o necesitate în zilele noastre. Utilizarea unui sistem
care realizează această funcționalitate poate micșora, sau chiar îndepărta riscul ca persoana care
utilizează în mod direct dispozitivul mobil să fie predispusă unor atacuri informaționale, sau ca
activitatea personală sau profesională a persoanei respective să fie perturbată.
Un sistem de monitorizare a activităților utilizatorilor pentru platforma Android poate oferi o
modali tate de a micșora aceste riscuri sau de a majora probabilitatea ca întâmplări care pun în
pericol siguranța sau efectuarea activităților să aibă loc foarte rar sau niciodată. Decizia importantă
luată a fost legată de datele care să fie transmise către utilizatorul final al sistemului, și anume cel
care supraveghează. Informațiile cele mai importante luate în considerare și mai apoi transmise
constau din date referitoare la apelurile pe care utilizatorul le efectuează sau recepționează, la
mesajele trimise s au primite, precum și la cele legate de locația, sau poziția dispozitivului și
totodată a utilizatorului. Alte date importante și includerea lor în cadrul acestui sistem reprezintă
obiectul unui studiu ulterior.
Sistemul oferă utilizatorului final facilita tea de a observa în timp real, în orice moment al unei zile,
cu cine comunică persoana care este supravegheată, dacă această comunicare este realizată prin
intermediul apelurilor telefonice sau al mesajelor text. De asemenea, informațiile cele mai
importan te referitoare la celălalt interlocutor sunt preluate și transmise către supraveghetor. Pentru
a realiza o monitorizare în timp real, informații esențiale referitoare la localizarea subiectului,
precum și la data și ora efectuării activităților sunt salvat e și transmise în cadrul sistemului.
Pentru o funcționare cât mai eficientă a sistemului, a fost aleasă implementarea și instalarea unei
aplicații pentru sistemul de operare Android pe dispozitivul subiectului (sau al utilizatorului
supravegheat). Pentru a implementa o aplicație care să poată fi accesată atât pe dispozitivele clasice
(notebook sau computer personal), precum și pe dispozitivele mobile (telefon, tabletă, etc.), s -a
considerat ca fiind cea mai benefică realizarea unei aplicații destinate platf ormei Web. Astfel,
utilizatorul final al sistemului poate accesa aplicația pe fiecare dispozitiv precizat mai sus, fiind
realizată astfel portabilitatea de care are nevoie o aplicație care primește și oferă informații în timp
real.

11

1.4 Utilitate

Acest siste m este util deoarece oferă utilizatorului final posibilitatea de a supraveghea în timp real
activitățile efectuate de către persoana care se dorește a fi supravegheată, dând posibilitatea
vizualizării acestor informații atât în timp real, cât și după o anu mită perioadă de timp, acestea
fiind afișate de către aplicația web în ordine invers cronologică. Astfel, pot fi vizualizate cele mai
recente activități efectuate de către subiectul supravegherii. Posibilitatea unei supravegheri de tipul
celei precizate an terior poate duce la înlăturarea riscurilor la care sunt expuși utilizatorii
dispozitivelor mobile, și anume furtul sau pierderea de date importante, precum și punerea în
pericol sau periclitarea siguranței sau a bunei efectuări a activității personale sau profesionale.
Sistemul poate fi folosit de către părinți, dacă aceștia doresc o monitorizare sporită a activității
copiilor. Copiii sunt supravegheați din punct de vedere al locației în care se află la un anumit
moment, precum și al conținutului mesajelor primite sau trimise, sau al apelurilor efectuate între
aceștia și diferiți interlocutori. De asemenea, firmele a căror activitate constă din livrarea coletelor ,
pot folosi sistemul, respectiv cele două aplicații, pentru a monitoriza locația în care se afl ă cel care
urmează să livreze un anumit pachet, mesajele sau apelurile trimise către destinatari sau primite
de la aceștia, precum și ora la care aceste activități au fost efectuate, iar apoi pot efectua statistici
sau evaluări referitoare la promptitudine a serviciilor unor anumiți angajați precum și la respectarea
orarului livrărilor.
Aplicația destinată dispozitivului mobil va fi instalată de către cel care urmează să supravegheze,
acesta se înregistrează prin intermediul contului de email dorit, va primi ulterior o parolă pentru
accesarea platformei Web, iar această aplicație existentă pe dispozitiv va rula independent,
neputând fi oprită de evenimente precum închiderea ei, sau restartarea dispozitivului, neputând, de
asemenea , fi detectată de către utili zatorul direct al dispozitivului. Persoana care supraveghează
va putea accesa ulterior datele referitoare la activitățile subiectului prin intermediul aplicației Web,
logându -se cu contul de email și parola primită, putând vizualiza aceste informații în ca drul unor
module diferite pentru apeluri, mesaje text sau locație, doar prin accesarea unui serviciu Web , pe
orice dispozitiv dorește.

12
2. Considerații teoretice
2.1 Sisteme Android

În zilele noastre , dispozitivele mobile au căpătat o importanță deosebit de ma re în viața de zi cu zi
a oamenilor. O importantă categorie este reprezentată de către telefoanele mobile. Odată cu
creșterea numărului utilizatorilo r, crește și numărul facilităților care se găsesc pe piață. Începând
de la telefoane simple, utilizate doar pentru a face apeluri, telefoanele mobile ne -au schimbat viața
și au devenit parte din ea. În prezent, ele nu mai sunt folosite doar pentru apeluri, ci au nenumărate
funcționalități, cum ar fi camera foto și video, redarea conținutului audio, TV, browser web etc. Și
odată cu noile tehnologii, programe și sisteme de operare noi sunt necesare.
Sistemele de operare s -au dezvoltat mult în ultimi 15 ani. Începând de la telefoanele alb -negru și
ajungând acum la telefoane smart (smartphones) sau minicomputere, s istemele de operare pentru
dispozitivele mobile au o tot mai mare importanță. În mod special pentru smartphone -uri, sistemele
de operare mobile au avut o evoluție vizibilă de la Palm OS în 1996 la Windows pocket PC în
2000, și apoi la Blackberry OS , iOS și Android [1].
Unul dintre cele două sisteme de operare mobile importante din zilele noastre este Android, celălalt
fiind iOS de la Apple. Lansat în 2007, Android a fost dezvoltat de Google în cola borare cu Open
Handset Alliance , un consorțiu de 86 de comp anii. Fiind un sistem de operare puternic, Android
suportă un număr mare de aplicații și e disponibil pe telefoanele mobile, pe tablete și pe un număr
mare de alte dispozitive portabile. Aceste aplicații fac viața mult mai confortabilă pentru utilizatori.
Principala platformă hardware pentru Android este cea bazată pe arhitectura ARM. Kernel -ul
Android are la bază unul dintre kernel -urile Linux. Din aprilie 2014, dispozitivele Android folosesc
în principiu versiunea 3.4 d e kernel Linux sau una mai nouă , cum ar fi 3.14 folosită pentru Android
5.0. Versiunea de kernel depinde de dispozitivul mobil și de platforma sa hardware. Astfel,
memoria flash pe dispozitivele Android este împărțită în anumite partiții, cum ar fi /sy stem pentru
sistemul de operare , sau /d ata pentru datele utilizatorului și instalări de aplicații [5].

13
Unele dintre cele mai importante caracteristici și avantaje ale siste mului Android sunt:
Fig. 2-1 Caracteristici și avantaje ale sistemului A ndroid

Cadrul de lucru al aplicațiilor conferă posibilitatea de reutilizare și relocare a componentelor.
Mașina virtuală Dalvik este optimizată pentru dispozitivele mobile, iar grafica este bazată pe o
librărie grafică 2D, grafica 3D având la baza OpenGL ES 1.0.
Sistemul de operare oferă, de asemenea, un magazin online pentru aplicații dezvoltat de Google.
Prin intermediul acestuia, utilizatorii pot selecta și descărca aplicații dezvoltate. cum ar fi jocuri,
simple aplicații sau widget -uri.
Aplicațiile sunt dezvoltate în limbajul de programare Java, librăriile și utilitarele oferite conferind
utilizatorilor avantajul de a dezvolta open -source, de aceea mulți producători de dispozitive preferă
să modifice versiunea de bază a sistemului de operare pentru a -i realiza dispozitivului o interfață
mai ușor de utilizat. Există peste 300000 de aplicații dezvoltate pentru Android și peste 3 miliarde
de descărcări. Pentru dezvoltarea de software, Android oferă SDK -ul Android (kit de dezvoltare
software).

14

Android -ul poate deci fi văzut ca un cadru de lucru constând în librării
C, C++ și Java, bazat pe un kernel Linux. Din acest motiv rezultă
portabilitatea aplicațiilor Android pe un nu măr atât de mare de
dispozitive .

Sistemul de operare constă din 4 layere(nivele) :

1. Nivelul aplicație (aplicațiile fiind dezvoltate în
limbajul java și rulate pe motorul Dalvik)
Android deține un set foarte larg și standardizat de API -uri și librării, dezvoltatorii
putând folosi aceste API -uri pentru a crea jocuri și aplicații, Java făcând astfel
aplicațiile Android portabile pe dispozitivele care suportă sistemul de operare.
Programul Java nu rulează direct pe Android, ci este convertit într -un cod de octeți
Dalvik. Astfel, sistemul poate rula orice aplicație , atât timp cât ea poate fi covertită
în codul Dalvik.

2. Framework -ul
Framework -ul Android este un set de API -uri care dă posibilitatea dezvoltatorilor
de a scrie aplicații repede și ușor. Constă din instrumente pentru crearea elementelor
interfeței grafice cum ar fi : b utoane, câmpuri text, câmpuri pentru imagini, precum
și din instrumente de sistem cum ar fi intent -uri(pentru pornirea altor aplicații sau
activități sau pentru deschiderea fișierelor).

3. Librăriile de sistem
Librăriile de sistem de pe android sunt con struite în principiu pe C și C++, fiind
astfel rapide și eficiente. Din moment ce librăriile rulează deasupra kernelului
Linux, există o mulțime de drivere și librării disponibile care pot fi customizate.

Fig. 2-2 Nivelele sistemului
Android

15
4. Kernel -ul Linux
Kernel -ul linux a fost ales d eoarece s -a dovedit a fi stabil și puternic. Linux are un
bun management al memoriei, un bun management al proceselor și dispune de
funcții cum ar fi comunicația TCP/IP. Pentru un producător de hardware, primul
lucru care trebuie făcut pentru a construi o platforma Android este de a crea un
driver pe kernel -ul Linux.
Bazele aplicațiilor Android:
Aplicațiile Android sunt compuse din una sau mai multe componen te de aplicație din următoarele :
• activități
• servicii
• manager de conținut
• receptori de em isie(broadcast receiver)
• intent

Activitățile sunt părți ale aplicațiilor cu care utilizatorul interacționează, serviciile sunt programe
care rulează în background sau oferă funcționalități altor aplicații, iar receptorul de emisie
reprezintă component a care permite sincronizarea cu evenimente de sistem sau de aplicație. Toate
evenimentele sincronizate cu un eveniment sunt înștiințate de runtime -ul Android odată ce
evenimentul are loc.

Fiecare componentă realizează un rol diferit în comportamentul fin al al aplicației , și fiecare poate
fi activată individual (chiar și de către alte aplicații).
În fișierul manifest toate componentele unei aplicații sunt declarate și ar trebui de asemenea să fie
declarate necesitățile aplicației, cum ar fi : versiunea m inimă de sistem de operare necesară,
configurațiile hardware necesare sau permisiunile pe care utilizatorul trebuie să le acorde.

16

Resursele aplicației care nu țin de cod cum ar fi : imagini, string -uri, fișiere pentru interfață etc. ar
trebui să includă alternative pentru diferitele configurații ale dispozitivelor (cum ar fi string -uri
diferite pentru limba selectată de utilizator), acestea fiind stocate în directorul res al proiectelor
Android.

Principalele funcționalități ale sistemului :
În principi u, dispozitivele trebuie sincronizate cu contul de Google al utilizatorului, prin acest cont
fiind sincronizate elemente precum contactele, calendarul și celelalte aplicații pe care utilizatorul
le-a avut instalate pe dispozitivele anterioare.
Aplicațiile sunt rulate la apăsarea icoanelor, iar calea spre ecranul principal al sistemului de operare
e realizată de butonul “Home” , acesta fiind unul dintre cele 3 butoane standard ale sistemului,
prezente tot timpul pe interfața utilizatorului, cel din mijloc m ai exact. Butonul din dreapta
realizează trecerea înapoi la aplicația sau elementul accesat anterior, iar cel din dreapta deschide
fereastra care permite utilizatorului să vadă care aplicații rulează , respectiv să închidă ce aplicații
dorește.
Notificăril e apar în bara de sus , putând fi detaliate la tragerea în jos a barii. De asemenea în partea
de sus a interfeței se pot găsi informații despre starea dispozitivului , respectiv se pot modifica
setările conturilor și ale dispozitivului [1].

17
Alte functi onalități(aplicații) importante sunt:
 telefon( apeluri, agendă )
 mesaje
 browsere web
 poștă electronică etc.

2.2 Versiuni ale sistemului de operare Android

Sistemul de operare Android a cunoscut diferite forme și versiuni de -a lungul timpului. Numărul
mare de versiuni apărute într -un timp atât de scurt este cauză, după unele păreri, a fragmentării,
sau după alte păreri, cauza e natura sistemelor open -source. Fiecare versiune de Android are un
nume care are la baza un desert, iar toate sunt în ordine al fabetică, iar dispozitivele din aceleași
generații cu configurație hardware asemănătoare suportă doar anumite versiuni de Android. În
continuare sunt prezentate versiunile de Android în ordinea apariției [13]:

Android 1.0 (Apple pie) – nivel API 1 – 23 septembrie 2008
Este prima versiune oficială de Android care a introdus una dintre cele mai importante
caracteristici ale sistemului de operare și anume: descărcarea și updatarea aplicațiilor prin
intermediul magazinului online de aplicații care se numea Android Market pe atunci. De asemenea
Fig. 2-3 Funcționalități Android

18
a fost introdus Web Browser -ul ca utilitate a sistemului, precum și elemente ca folosirea sistemului
de hărți Google sau sincronizarea poștei electronice, a contactelor sau a agendei.

Android 1.1(Banana bread) – nivel API 2 – 9 februarie 2009
A reprezentat o versiune intermediară între cea inițială, 1.0, și prima versiune cu adevărat
importantă, 1.5. Îmbunătățirile semnificative aduse au fost reprezentate de tastatura numerică din
aplicația de apeluri care putea fi as cunsă, precum și de capacitatea de a salva atașamentele
mesajelor.

Android 1.5(Cupcake) – nivel API 3 – 30 aprilie 2009
A fost primul adevărat succes al sistemului de operare Android. SDK -ul 1.5 a adus o mulțime de
schimbări ale interfeței cu utilizatoru l, cele mai importante fiind widget -urile și posibilitatea de a
crea folderele pe ecranul principal. Au fost și schimbări în afara interfeței, cum ar fi introducerea
suportului pentru conexiunea prin Bluetooth, funcții de înregistrare video sau introducere a
tastaturii software cu predicție de text.

Android 1.6(Donut) – nivel API 4 – 15 septembrie 2009
A fost construit având la bază versiunea 1.5, pe care a extins -o. Android 1.6 a adus schimbări
importante în “spatele” interfeței cu utilizatorul, oferind bazele cadrului de lucru (framework -ului)
pentru caracteristicile ce aveau să fie dezvoltate ulterior. Pentru utilizatorul final, cele mai
importante avantaje sunt îmbunătățirile aduse Android Market și funcția de căutare universală
realizată de Google. Ca și hardware, Donut a introdus suport pentru touchscreen -uri de rezoluție
mai mare și suport îmbunătățit pentru cameră și galeriile foto, respectiv video.

19
Android 2.0, 2.01, 2.1 (Éclair) – nivel API 5, 6, 7 – octombrie 2009 – ianuarie 2010
Éclair a repr ezentat un pas mare înainte față de predecesorii săi. 2.0 a adus îmbunătățiri
semnificative în browser și în aplicația de hărți Google Maps, suportând standardul HTML. Pe
lângă interfața nouă, sistemul de navigație Google Maps Navigation a luat naștere în cadrul
versiunii 2.0, fiind adus la un nivel aproximativ egal cu sistemele GPS existente. Versiunea 2.0.1
a luat însă locul versiunii 2.0 relativ repede, introducând practica des folosită ulterior, cea a lansării
versiunilor intermediare care rezolvă erori (așa numitele bug -uri). Versiunea 2.1 a adus un design
îmbunătățit, o interfață cu utilizatorul spectaculoasă care includea efecte 3D, însă rularea
sistemului de operare a fost astfel încetinită și îngreutățită.

Android 2.2(Froyo) – nivel API 8 – 20 mai 2010
Cea mai importantă schimbare adusă a fost introducerea unui compilator Just -In-Time sau JIT care
a îmbunătățit semnificativ puterea de procesare a dispozitivului și totodată viteza. Pe lângă aceasta,
Android 2.2 a introdus suport pentru Adobe Flash 10.1 care oferea posibilitatea utilizatorului de a
reda conținut Flash în browserul web. A fost introdusă și posibilitatea de instalare a aplicațiilor pe
memoria externă, precum și suportul pentru USB tethering.

Android 2.3(Gingerbread) – nivel API 9 – 6 decembrie 2010
Principalele modificări în partea de interfață ale versiunii 2.3 au fost reprezentate de schimbări ale
meniului și ale elementelor de dialog, precum și de introducerea unei noi bare de notificări sau a
noului suport pentru limbă. Pe lângă ac estea, îmbunătățiri ale gestionării consumului de energie
au fost aduse, precum și alte modificări hardware, cum ar fi eficientizarea garbage collector -ului,
distribuția mai rapidă a evenimentelor sau drivere video înnoite. A fost, de asemenea, adăugat
suport pentru noi tehnologii cu m ar fi cel pentru VoIP sau SIP , precum și cel pentru NFC(Near
Field Communication) – comunicația între două dispozitive care se află la distanță foarte mică
unul față de celălalt – suport ce a urmat a fi îmbunătățit în varianta intermediară 2.3.3.

20
Android 3.0(Honeycomb) – nivel API 11 – 22 februarie 2011

Este prima versiune de Android special făcută pentru tablete, care deci aduce o mulțime de noi
elemente de interfață. Este introdus butonul pentru vizualizarea aplicatilor ca re rulează, precum și
protocolul de transport pentru fișiere media. Sunt introduse noțiunile de video chat și private
browsing. A fost introdus suportul multicore, iar elementele noi pentru dezvoltatori au cuprins:
fragmente le, bară de acțiuni contextuală , grafică 2D accelerate hardware, randarea forțată a
layerelor, cache LRU sau posibilitatea de vizualizare a statisticilor de trafic în rețea.
Versiunea intermediară 3.1(Honeycomb) a adus de asemenea îmbunătățiri interfeței, dar și alte
elemente noi, cum a r fi API pentru host USB, suport pentru mouse, joystick sau gamepad sau
widget -uri redimensionabile pentru ecranul principal.
Versiunea 3.2 a introdus un API extins (13) pentru suportul administrării afișajului (screen),
clasificator de resurse pentru afi șaj, atribute de manifest pentru compatibilitatea cu dimensiunea
ecranului și un mod de compatibilitate a ecranului pentru tablete care permite ca aplicațiile de
telefon să pară ca și cum ar fi pe telefon. Versiunea 3.2.1 a adus update -uri mai rapide din A ndroid
Market, precum și îmbunătățiri ale conexiunii Wi -Fi.
Versiunile intermediare au adus rezolvări ale bug -urilor, precum și opțiuni de plată prin telefon,
opțiuni realizabile prin intermediul browser -elor sau a NFC -ului.
Android 4.0 (Ice Cream Sandwi ch- ICS) – nivel API 14 – 18 octombrie 2011
Pe lângă nenumăratele modificări aduse interfeței cu utilizatorul, cum ar fi acțiuni disponibile pe
ecranul blocat (lockscreen), au fost îmbunătățite caracteristici precum introducerea de text și
corectarea cuvi ntelor, sau controlul asupra datelor primite sau trimise în rețea. Pe partea de
dezvoltare au fost introduse API -uri pentru verificarea cuvintelor, c ontrolul camerei de la distanță,
zoom pe imagine, focus continuu, sau flag -uri care ajută controlul element elor de sistem ale
interfeței cu utilizatorul, cum ar fi bara de sistem din aplicații.

21
În versiunea 4.0.1 interfața cu utilizatorul utilizează accelerarea hardware, iar elemente precum
recunoașterea facială pentru deblocarea dispozitivului, un browser web cu până la 16 tab -uri, sau
aplicația Beam care e folosită pentru schimb de date prin NFC, sunt introduse.
Versiunea 4.0.3 a introdus în nivelul API nou, 15, API -uri pentru furnizorul de contacte precum și
pentru aplicații ale ecranului principal, pe când 4.0.4 s -a concentrat pe stabilitatea sistemului și
îmbunătățirea camerei și a rotirii ecranului.

Android 4.1 – 4.3 (Jelly Bean) – nivel API 16 – 9 iulie 2012 – 24 iulie 2013
Pe lângă punctul principal pe care s -a concentrat, și anume răspunsul cât mai rapid la acțiunile
utilizatorului, Jelly Bean a adus printre altele: conturi pentru mai mulți utilizatori, notificări asupra
cărora se poate acționa, widget -uri pentru ecran atunci când este blocat sau opțiunea de setări
rapide în bara de notificări. Pentr u utilizator, impactul cel mai mare l -a avut concentrarea asupra
căutării prin voce sau răspunsul dispozitivului la gesturi, precum și introducerea serviciilor Google
Now. Pe partea de dezvoltare s -a introdus noțiunea de activitate părinte în manifest în c azul
navigării în adâncime în activități, precum și notificări detaliate, multi -acțiune, sau un manager de
intrări care realizează interogarea dispozitivelor de intrare.
Versiunea 4.2 a scăzut latența răspunsului la atingere, a introdus noțiunea de fragme nte încuibărite,
precum și elemente precum noțiunea de buffering triplu sau optimizări grafice, prin rularea task –
urilor pe pro cesorul grafic , în cazul dispozitivelor care suportau. În cadrul versiunii 4.2.2 s -au
introdus caracteristici precum procentajul și timpul estimat al descărcărilor, încărcare fără fir a
bateriei. De asemenea a fost introdusă noțiunea de USB debugging care permite debug doar pe
computerele autentificate.
Versiunea 4.3 s -a concentrat pe noțiunile: autocompletarea numărului la formare a de către
utilizator, suportul pentru rezolutia 4K, îmbunătățiri importante ale securității și ale performanței,
iar pe partea de dezvoltare a fost introdus suportul pentru librăria OpenGL for Embedded Systems
3.0 , API -ul pentru scanare Wi -Fi, și de asem enea a fost îmbunătățit DRM (managementul
drepturilor digitale).

22
Android 4.4(KitKat) – nivel API 19 – 31 octombrie 2013
KitKat, în variantele lui intermediare de la 4.4 la 4.4.4 , a îmbunătățit accesul la notificări,
performanțele, precum și caracteristi ci ale aplicației pentru cameră sau noțiuni importante de
securitate. Pentru partea de programare au fost introduse API -uri pentru gestionarea mesajelor text
și alte funcții cum ar fi: îmbunătățirea funcției de utilizare a memoriei, chestiuni de securitate
(algoritmi de criptare noi, VPN per utilizator), framework -uri pentru printare sau acces la spații de
stocare, monitorizare audio, sau unelte pentru analizarea utilizării memoriei (statistici ale gradului
de utilizare processor sau statusul memoriei dispo zitivului)

Android 5.0(Lollipop) – nivel API 21 – 17 octombrie 2014
La fel ca și în precedenta versiune de Android, în 5.0, punctele pe care dezvoltatorul s -a concentrat
au fost îmbunătățirea vitezei de lucru, îmbunătățirea consumului de energie, aceast a fiind una
dintre marile probleme ale sistemului de operare și a dispozitivelor din zilele noastre în general, și
o chestiune din ce în ce mai importantă în zilele noastre, și anume securitatea și siguranța
utilizatorului în mediul online, precum și în ce l offline. Interfața cu utilizatorul a fost schimbată în
mică măsură, aproape nesemnificativ. Nenumărate API -uri au fost învechite și înlocuite cu altele
care să confere suport pentru hardware -ul noilor telefoane.

Din cauza înlocuirilor API -urilor și a î nnoirii și îmbunătățirii configurațiilor hardware ale
dispozitivelor o problemă frecventă o reprezintă inccompatibilitatea versiunilor sistemului
Android cu anumite dispozitive sau doar incompatibilitatea parțială datorată anumitor API -uri
învechite, rezul tând astfel perioada limitată în care dispozitivele primesc update -uri oficiale ale
versiunilor sistemului de operare, și anume de aproximativ de 2 ani [4].

23
2.3 Android SDK (kit de dezvoltare software)

SDK -ul Android constă dintr -un set de instrumente de dezvoltare folosite pentru a crea aplicații
pentru platforma Android. SDK -ul Android include următoarele:
 Librăriile necesare
 Debugger
 Un emulator
 Documentație relevantă pentru API -urile (interfețele de program ale aplicației) Android
 Exemple de aplicații conținând și codurile sursă
 Tutoriale pentru sistemul de operare Android
De fiecare dată când Google lansează o nouă versiune de Android, un SDK corespunzător este de
asemenea lansat. Pentru a scrie programe cu ultimele caracteristici, dezvoltatorii trebui e să
descarce și să instaleze SDK -ul pentru versiunea corespunzătoare sistemului aflat pe telefonul sau
dispozitivul respectiv. Componentele SDK -ului pot fi descărcate separat.
Cu toate că SDK -ul poate fi folosit pentru a scrie programe Android în linia de comandă, cea mai
folosită metodă este cea a utilizării unui mediu de dezvoltare integratv(IDE). Majoritatea acestor
IDE-uri conferă o interfață grafică prin care programatorii pot dezvolta mai repede. Având în
vedere că aplicațiile sunt scrise în cod Java , utilizatorii trebuie să aibă un kit de dezvoltare Java
(JDK) instalat.
Pentru a ajuta programatorii să dezvolte efficient, ADT (Android Developer Tools – instrumentele
de dezvoltare Android) oferă un mediu de dezvoltare (Java IDE) pentru dezvoltarea, oper ația de
debug, și împachetarea aplicațiilor Android. Folosing acest IDE, se poate dezvolta pe dispozitive
fizice Android sau se pot, de asemenea, crea dispozitive virtuale care emulează orice configurație
hardware.

24
Limbajul Java a fost ales din mai mult e motive:
 Este un limbaj foarte des folosit și foarte cunoscut
 Poate rula pe o mașină virtuală fara a fi nevoie să fie recompilat pentru telefoane diferite
 Securitate sporită
 Existența instrumentelor de dezvoltare disponibile pentru Jav a
 Este un limbaj cu care multe telefoane sunt compatibile

Android Stud io
Android Studio este un mediu de dezvoltare software popular (cunoscut ca și mediu de dezvoltare
integrat – IDE) care permite programatorilor și dezvoltatorilor accesul la instrumente de codare,
debug, optimizare a performanțelor, verificare a compatibilității versiunilor, verificare a
compatibilității hardware) precum și la alte instrumente care pot ajuta dezvoltatorii să
automatizeze procesul codării. Prin interfața sa modernă și interactivă , Android Studio permite
utilizatorilor să modifice cu ușurință interfața cu utilizatorul a aplicației doar prin mutarea
componentelor și a ferestrelor.
Este disponibilă emularea sistemului Android pe Windows, Linux , precum și pe Mac OS X prin
intermediul Android Studio. De asemenea , acest mediu ofera suport integrat pentru platforma
Google Cloud [18].

Printre cele mai importante caracteristici oferite de Android Studio se numără:
 Suport pentru build bazat pe Gradle(instrument de automatizare a proiectelor – folosește un
graf aciclic pentru a determina ordinea în care task -urile pot fi rulate)
 Capacitatea de refactoring , precum și de remediere rapidă (quick fix) specifice sistemului
Android

25
 Instrumente Lint folosite pentru a detecta probleme de performanță, uzab ilitate,
compatibilitate a versiunilor, etc.
 ProGuard și capabilitate de logare în aplicații
 Dezvoltare a elementelor de design și a componentelor bazată pe template -uri
 Un editor care permite drag -and-drop-ul componentelor, previzualizarea cadrelor(layout s)
pe configurații multiecran, și multe altele
 Suport pentru platforma Google Cloud

Diferențele principale față de plugin -ul pentru Eclipse
Android Studio folosește sistemul de build Gradle, construit pe baza conceptelor Apache
Ant(folosit in Eclipse) și Apache Maven.

Ambele IDE -uri folosesc autocompletarea codului Java, dar în cazul Android Studio codul poate
fi refactorizat în locuri în care acest lucru nu era posibil folosind Eclipse și plugin -ul ADT.
Autocompletarea IntelliJ a Java prezice mai bine , aceasta fiind o îmbunătățire adusă de Android
Studio.

Noul design de interfață este mai rapid în Android Studio, raspunzând mai prompt la schimbări,
acestea putând fi făcute utilizând instrumentul de design, nu manual , în XML, ca în Eclipse.
În Android Studio problema schimbării spațiilor de lucru(workspace) din Eclipse este rezolvată
prin introducerea noțiunii de modul. Așadar, aplicația poate fi deschisă într -un modul, o librărie
poate fi deschisă în alt modul, iar SDK -ul poate fi deshis în altul. Fiec are dintre aceste module
poate avea propriile fișier de build Gradle și poate declara propriile dependințe [20].

26
O altă schimbare importantă e reprezentată de posibilitatea de a previzualiza interfața aplicației pe
diferite dimensiuni sau poziții ale ecran ului:

Fig. 2-4 Previzualizarea interfeței aplicației Android

2.4 Modelul permisiunilor în sistemul de operare Android

Toate aplicațiile pe Android ruleaza într -un Sandbox de aplicații. Fără alte modificări, o aplicație
Android poate accesa doar un număr limitat de resurse. Sistemul gestionează accesul la resurse
care, dacă ar fi folosite incorect sau malițios, ar avea un impact dăunător asupra experienței
utilizatorului, a traficului în rețea , sau asupra date lor de pe dispozitiv.
Aceste restricții sunt implementate într -un număr variat de forme. Anumite API -uri nu conferă
accesul utilizatorului la anumite funcționalități (ex: nu exista API în Android pentru manipularea
directă a cardului SIM). În anumite cazur i, separarea anumitor funcționalități este vazută ca o
măsură de securitate, cum ar fi izolarea datelor stocate în cadrul unei aplicații. În alte cazuri, API –
urile respective sunt destinate spre a fi folosite de către aplicații sigure și protejate printr -un
mecanism de securitate cunoscut ca și Permisiuni(Permissions).

27
Aceste API -uri protejate includ:
 Funcții ale camerei
 Date de localizare(GPS)
 Funcții bluetooth
 Funcții de telefonie
 Funcții de mesagerie
 Conexiuni în rețea/de date
Aceste resurse sunt accesi bile doar prin sistemul de operare. Pentru a se putea folosi de API -urile
protejate pe un dispozitiv, o aplicație trebuie să descrie funcțiile de care are nevoie în propriul
fișier manifest. La pregătirea instalării unei aplicații, sistemul afișează o fere astră utilizatorului
care prezintă permisiunile necesare, iar apoi acesta este întrebat dacă dorește sa continue instalarea
sau nu. Dacă utilizatorul continuă instalarea, sistemul consideră că utilizatorul a acordat toate
permisiunile cerute. Utilizatorul nu poate acorda sau declina anumite permisiuni individuale.
Acesta trebuie să acorde sau să refuze toate permisiunile cerute, acestea fiind considerate ca un
bloc.
Odată acordate, permisiunile sunt aplicate aplicației atât timp cât aceasta ramâne instalată .
Sistemul nu informează utlilizatorul încă o dată despre permisiunile acordate aplicației, iar
aplicațiile care sunt incluse în sistemul de operare nu cer permisiuni utilizatorului.
Permisiunile sunt îndepărtate dacă o aplicație este dezinstalată, deci o reinstalare ulterioară a
aplicației va afișa din nou permisiunile necesare.
De asemenea, utilizatorul poate vedea permisiunile aferente fiecărei aplicații instalate, iar pentru
a restricționa anumite funcționalități cum ar fi: GPS, radio, wi -fi etc., aces tea pot fi oprite global,
la alegerea acestuia. În cazul în care o aplicație încearcă să utilizeze o funcționalitate protejată care
nu a fost declarată în manifest, eșecul va rezulta într -o excepție de securitate care va fi aruncată
înapoi aplicației. Veri ficările permisiunilor sunt realizate la nivelul cel mai jos posibil.
Există multe motive pentru a afișa permisiunile înainte de momentul instalării. Unul ar fi de a
informa utilizatorul dacă aplicația o sa îi îndeplinească așteptările și nevoile, si de as emenea de a
compara aplicația cu alte alternative existente [3].

28

Fig. 2-5 Afișarea permisiunilor pentru aplicații

Cererea de permisiuni:
Este recomandată folosirea unui număr cât mai mic de pe rmisiuni pentru o aplicație. Neavând
acces la permisiuni importante, se reduce riscul folosirii nepotrivite a acelor permisiuni și, de
asemenea aplicația este mai puțin vulnerabilă la atacuri. În general, dacă o permisiune nu e
necesară, atunci nu ar trebu i cerută. Dacă e posibil, e de preferat să se realizeze aplicația pe o cale
care nu necesită permisiuni. De exemplu: în locul cererii accesului la informații despre dispozitiv
pentru a crea un identificator unic, se recomandă crearea unui GUID pentru aplic ația în cauză. De
asemenea este preferată salvarea pe spațiul intern de stocare decât cea pe cel extern.

29

Crearea de permisiuni:
În general, se țintește definirea unui numar cât mai mic de permisiuni atât timp cât securitatea
aplicației e satisfăcută. Cre area unei noi permisiuni nu este comună pentru majoritatea aplicațiilor,
deoarece permisiunile definite de sistem acoperă majoritatea situațiilor. Când este posibil, se
dorește realizarea verificărilor folosind permisiunile existente.
Pentru a face mai ușo r de înțeles la ce anume va avea acces o aplicație, Play Store a îmbunătățit
felul în care permisiunile sunt afișate. Permisiunile sunt organizate în grupuri de permisiuni, ușor
identificabile prin iconițe( ex: pentru locație), pentru a ajuta la clarific area celor mai importante
informații și funcționalități pe care o aplicație le poate accesa pe dispozitivul respectiv. Aceste
informații pot ajuta în luarea unei decizii asupra instalării aplicației.
Lista completă de permisiuni pe care o aplicație le poat e accesa pe dispozitiv poate fi întotdeauna
văzută. De exemplu, se poate vedea daca o aplicație accesează internetul pentru a înțelege dacă are
impact sau nu asupra traficului de date.

Grupuri de permisiuni:
Grupurile de permisiuni sunt concepute pentru a arăta ce va putea accesa o aplicație pe un anumit
dispozitiv. Prin grupurile de permisiuni, se poate observa ce funcționalități sau informații va folosi
o aplicație înaintea descărcării acesteia. Odată descărcată și instalată, o aplicație poate accesa or ice
permisiune individuală dintr -un grup de permisiuni din care face parte.

30
Dintre grupurile de permisiuni, printre cele mai importante și ce permit acestea aplicațiilor:
 Device & app history (istoricul dispozitivului și al aplicațiilor)
o Poate citi date de logare importante
o Obține starea internă a sistemului
o Obține lista de aplicații care ruleaza
 Setări ale transferului de date
o Poate folosi setări care controleaza conexiunile de date
 Contacte
o Poate folosi contactele de pe dispozitiv (citirea și editarea lor)
 Locație
o Locația aproximativă(dată de rețea)
o Locația precisă(dată de GPS și rețea)
o Acces la GPS
o Accesarea de comenzi suplimentare pentru furnizorul locației
 SMS
o Poate include taxarea pentru trimiterea de mesaje text sau multimedia
o Primește mesaje text (SMS)
o Citește mesaje text(SMS sau MMS)
o Primește mesaje text(MMS)
o Editează mesaje text(SMS sau MMS)
o Trimite mesaje SMS, cu sau fără taxare
 Telefonie
o Poate include taxarea apelurilor
o Apelarea anumitor numere de telefon
o Scrierea istoricului de apeluri
o Citirea istoricului de apeluri
o Redirecționarea de apeluri
o Apelarea fără intervenția utilizatorului

31
Alte grupuri de permisiuni sunt reprezentate de către cele care confera accesul la: cameră(capturi
foto și video), microfon(posibilitate de înregistrare audio), in formații despre conexiunile bluetooth
sau Wi -Fi , sau informații despre ID -ul dispozitivului sau statusul telefonului.
Updatarea aplicațiilor:
Când o aplicație se updatează, este posibil sa aibă nevoie să folosească funcționalități sau
informații adițional e controlate de permisiuni. Dacă opțiunea de updatare automată este activată,
atunci nu va fi nevoie ca utilizatorul să accepte sau revizuiască acele permisiuni care sunt deja
incluse într -un grup de permisiuni care a fost deja acceptat pentru acea aplicaț ie.
Dacă o aplicație are nevoie de acces la un grup adițional de permisiuni, utilizatorului îi va fi cerut
să accepte acea updatare, chiar dacă setarea de updatare automată era activată [9].

Fig. 2-6 Adăuga rea de permisiuni în cazul unui update

Existența permisiunilor este deci, un câștig, în teorie. Problema este că acestea au devenit pentru
utilizatori la fel ca și EULA(acceptarea licențelor), o listă prin care se trece prea repede, uneori
insesi zabil, iar necunoașterea de către utilizator a ceea ce permite unei aplicații poate deveni
dăunătoare siguranței și totodată intimității acestuia.

32
2.5 Securitatea sistemelor Android

Android -ul are caracteristici de securitate în interiorul sistemului de opera re care reduc frecvența
și impactul problemelor de securitate ale aplicațiilor. Sistemul este proiectat pentru a permite
dezvoltatorilor sa creeze aplicații cu permisiunile de bază de sistem și de fișiere și să evite deciizile
dificile referitoare la secur itate.
Unele dintre caracteristicile de baza cu referire la securitate care ajuta la crearea aplicațiilor sigure
sunt:
 Android Application Sandbox, care izoleaza datele aplicației si execuția codului de cele
ale altor aplicații
 Un cadru de lucru pentru apl icații cu implementare robusta a funcționalității de baza a
securității cum ar fi criptografia, permisiunile sau IPC securizat
 Un sistem de fișiere criptat care poate proteja datele de pe dispozitivele pierdute sau furate
 Permisiuni acordate de utilizator pentru a restricționa accesul la setarile sistemului, precum
si la datele utilizatorului
 Permisiuni definite pentru aplicații pentru a controla datele folosite de aplicații

Sistemul de operare Android este, astfel, unul foarte sigur. Are mai multe stratur i de protecție
pentru a menține amenințările la distanță, si de asemenea, permisiunile utilizatorului sunt cerute
pentru a realiza aproape orice acțiune care ar putea conduce la compromiterea datelor sau a
sistemului. Totuși, Android -ul este un sistem care acordă utilizatorului și comunității de
dezvoltatori acea încredere cum că aceștia procedează corect tot timpul. Dacă se dorește, multiple
permisiuni pot fi acordate, sau chiar acces la părți mai importante și profunde ale sistemului în
cazul în care disp ozitivul a fost rutat. Sistemul încearcă să protejeze utilizatorul de el însuși, dar
totuși îi permite sa aibă ultimul cuvânt asupra a ceea ce se instalează și asupra cui i se dau
permisiuni.
Pe când se poate spune că aproape nimic nu este complet sigur pe Android, acest sistem este mult
mai sigur decât altele, doar prin faptul ca este bazat pe Linux care face instalarea softurilor
dăunatoare aproape imposibilă. Cel mai bun combatant al pierderii securității unui dispozitiv mobil
este și va fi utilizatorul.
Una dintre cele mai des întâlnite probleme de securitate e reprezentată de stocarea datelor. Fișierele
create pe spațiul intern de stocare sunt accesibile doar aplicației. Protecția este implementată de
către sistem și este suficientă pentru majoritatea a plicațiilor. Problema, în cazul stocării datelor
este reprezentată de spațiul extern de stocare, deoarece fișierele stocate acolo pot fi citite si scrise
de catre orice aplicație [3].

33
Alte mari deficiențe de securitate sunt conexiunile RFI și NFC, acestea fiind lăsate adeseori
deschise, fiind astfel folosite de către deținătorii altor dispozitive pentru a fura date.
Alte probleme de securitate sunt reprezentate de comunicația prin internet sau cea prin telefonie.
Se preferă folosirea protocolului HTTPS or iunde acesta este suportat pe server, deoarece
dispozitivele mobile se conectează frecvent la rețele care nu sunt securizate, cum ar fi hotspot -uri
publice Wi -Fi. De asemenea, nu se recomandă descărcarea datelor din HTTP sau alte protocoale
nesigure. Asta include validarea input -ului in WebView.
Rezolvarea problemei conexiunilor poate fi rezolvată de către utilizator prin deschiderea acestora
doar atât timp cât sunt necesare pentru transmiterea d atelor, și apoi închiderea lor.
Informații personale/Metadata dispozitiv
Android -ul a plasat API -urile care confer accesul la datele utilizatorului într -un set de API -uri
protejate. Aplicațiile care aleg să împărtășeasca aceste informații pot folosi verificările de
permisiuni ale sistemului de operare pentru a protej a date de celelalte aplicații.

Fig. 2-7 Mecanismul protejării datelor prin permisiuni

Furnizorii de conținut de sistem care pot contine date personale cum ar fi contacte sau date de
calendar au fost create cu permisiuni bine identificate. Această granularitate oferă utilizatorului
informații clare despre tipul de informație care va fi oferită aplicației.
Orice aplicație care colectează date personale va avea transferul acelor date restrâns la acea
aplicație . La fel sunt cerute permisiuni și în cazul aplicațiilor care folosesc funcționalități precum
camera, microfonul sau GPS -ul și care pot furniza informații importante referitoare la dialogurile
utilizatorului sau la locația sa.

34
Android -ul de asemenea tinde sa restrângă accesul la date care pot să dezvăluie indirect
caracteristici ale utilizatorului, preferințe, sau modul în care acesta utilizează un dispozitiv. La
bază, aplicațiile nu au acces la log -uri ale sistemului de operare, la istoricul browser -elor, la
numărul de telefon sau informații de iden tificare hardware sau de rețea.
Cu privire la discuția despre securitate, sistemul este predispus la a cădea victimă amenintărilor nu
din cauză că este unul slab din acest punct de vedere al securității, ci deoar ece utilizatorii sunt
veriga slabă. Odată cu puterea pe care Android -ul o conferă utilizatorilor, o mare responsabilitate
a acestora trebuie sa vină.
Android -ul a fost proiectat având securitatea ca unul dintre principiile sale de baza. Fără a fi
comparat cu vreo alta platforma, realizează o bună asigurare a faptului ca procesele nu colectează
prea multa informație (sau prea multe resurse) fără permisiuni. De asemenea, se asigură de faptul
că nicio aplicație sau niciun proces nu primeste acces la nivelul si stem fără privilegiile adecvate,
si de faptul că utilizatorul este întotdeauna conștient de ceea ce se întamplă în spatele interfeței.
Android -ul are deci mai multe nivele de apărare pentru a se proteja împotriva amenințărilor, si de
când Google și -a îndre ptat atenția asupra a ceea ce instalează utilizatorii pe dispozitive, puține
amenințări și -au mai făcut apariția. După o estimare prezentată de responsabilul Android pe
securitate, Adrian Ludwig, 0.0001% dintre instalările de aplicații au reușit să treacă de sistemul cu
multiple nivele de apărare și astfel să producă daune utilizatorilor [10].

Fig. 2-8 Schema nivelelor de securitate

35
Doar pentru a fi instalată, o aplicație trebuie să treaca prin Google Play sau de o avertizare a
instalării din surse necunoscute (în cazul în care opțiunea e activată), iar ulterior, utilizatorul
trebuie sa confirme instalarea. După aceasta, trebuie să treacă de caracteristica de securitate Google
“Verify Apps” care verifică un APK cu baza sa de date a riscurilor înainte de a fi instalat. Apoi,
aplicația este pusă în sandbox și restricționată doar la permisiunile acordate ei, iar securitatea
Android -ului verifică din nou de fiecare dată când aplicația rulează.
Google colectează informații de fiecare dată când un utilizator instaleaza o aplicație atât timp cât
acesta utilizeaza opțiunea “Verify and install” care apare pe dizpozitiv la instalare, sau dacă se
instalează de pe Google Play direct. Aceasta înștiințează utilizatorul dac a o aplicație poate fi
dăunatoare sau nu, în funcție de comparația cu o bază de date Google de dimensiuni mari.
Deci, Android -ul pare un sistem sigur. Dacă dispozitivul este folosit în modul obișnuit, instalările
sunt făcute din surse sigure , iar utilizat orul e conștient de riscuri, șansele de a expune dispozitivul
la riscuri sunt foarte mici, cazul fiind cercetat, bazat pe rezultate [10].

Fig. 2-9 Procenta jul dispozitivelor care respectă standardele secur ității Android

36
Și totuși, imaginea prezentată nu este pe deplin adevărată. Există probleme care nu sunt
menționate, dar pot fi cu ușurință observate:
 Amenințări care nu pot fi luate în calcul dacă nu sunt observate. Toate datele prezentate de
Google sun t bazate pe aplicații care sunt instalate cu opțiunea Verify Apps. Daca aceasta
nu este bifată sau dacă instalările sunt facute din alte surse, cum ar fi Amazon Appstore,
nu este inclusă în baza de date, sau protejată, rezultând astfel concluzia: din ameni nțările
pe care Google le vede putem deduce că multe dintre cele existente nu sunt luate în
considerare
 Android are mecanisme de aparare pentru a se proteja pe sine însuși ca sistem, nu și mare
parte din datele utilizatorului. E o chestiune dacă o aplicați e este daunătoare dacă
compromite sistemul, dar dacă aplicația nu este interesată de controlul dispozitivului,
atunci sistemul de apărare multinivel protejează utilizatorul doar până în punctul instalării
acesteia. Dacă amenințarea are scopul de a fura dat ele, locația, informații despre traficul
de date, lista de contacte, lista de adrese de e -mail, sau orice alte date de pe dispozitiv,
aceasta nu este oprită în niciun fel.
 Lipsa instalărilor nu echivalează cu lipsa amenințărilor. Daca Google nu observă o m ulțime
de instalări malițioase prin sursele sale nu înseamnă că acestea nu au loc sau că amenințarea
nu e reală.
 Multe dintre mecanismele de apărare ale Android -ului sunt depașite de către utilizator prin
câteva atingeri. Mulți utilizatori instalează aplic ații din surse neautorizate cum ar fi site -uri
web sau alte surse. De asemenea instalează variante vechi, care nu mai sunt compatibile pe
variantele noi ale sistemului din punct de vedere al securității , sau pur și simplu rutează
telefonul.

Motivul real pentru care e dificil sa nu luam în calcul amenințările este faptul ca utilizatorul este,
și a fost întotdeauna, veriga slabă în lanțul securității. Sistemul de operare Android nu este singurul
care are această problemă, fiecare platformă , pentru desktop sau dispozitive mobile, are aceeași
problemă. Deci, nu contează daca există un grad de protecție sau nu, daca utilizatorul acceptă să
instaleze o aplicație. De aceea e important să se cunoască dacă o aplicație e malițioasă sau nu
dinainte de instalarea ei.
O rezolvare a problemei poate fi și doar simpla citire a notelor și a comentariilor oferite de
utilizatorii aplicațiilor, cea mai rea rezolvare, dar cea mai rapidă, utilizatorul dându -și seama ce ar
trebui sa facă o aplicație sau dacă aceasta va avea un c omportament ciudat sau cere permisiuni
care nu au legatură cu funcționalitatea.

Dezbaterea legată de securitatea dispozitivelor mobile este una de actualitate, la fel ca cea legată
de cea a desktop -urilor. O certitudine este că marea majoritate a utilizat orilor care instalează
aplicații din surse cunoscute și sigure nu vor avea probleme și nu vor întâlni amenințări. La fel ca

37
în cazul desktop -urilor , utilizatorii cu obiceiuri de descărcare și instalare bune și cu o cunoaștere
a termenilor vor fi o importa ntă linie de apărare. Utilizatorii care nu au aceste cunoștințe sunt cei
mai predispuși la a fi victime ale atacurilor și ale acestor amenințări constante ale siguranței pe
dispozitivele mobile. Persoanele fără acest discernamânt, în principal copiii, sunt victimele acestor
atacuri. Instalarea unor aplicații care sa combată furtul de date cum ar fi locația, apelurile, mesajele
sau care sa detecteze accesul la conținut nepotrivit pentru aceștia reprezintă una din soluțiile
rezolvării acestei probleme.

3. Rezol varea temei de proiect
3.1 Cercetări în domeniu
3.1.1 ViewDroid: Towards Obfuscation -Resilient Mobile Application Repackaging
Detection

Autori
Fangfang Zhang, Heqing Huang, Sencun Zhu, Dinghao Wu, and Peng Liu
The Pennsylvania State University
University Park , PA, USA
Ideea principală
Odată cu creșterea numarului vânzărilor de aplicații pentru dispozitivele mobile, a crescut și
numărul de aplicații care sunt reîmpachetate sub un alt nume și folosite cu scopuri malițioase. O
aplicație populară poate fi modifica tă inserând conținut dăunător în aplicația originală și folosindu –
se apoi de popularitatea acesteia pentru a accelera propagarea manifestării dăunătoare. Aplicația
dezvoltată în cadrul studiului reprezintă o abordare într -o interfață cu utilizatorul a dete cției
repackaging -ului aplicațiilor și are la bază un graf al interacțiunii(navigării) între view -urile
aplicației, realizat prin analiza statică a acestora. Aplicația a fost realizată pentru a detecta perechile
de aplicații(originală -copie) și nu pentru a detecta care e cea originală și care e copia.

38
Rezultate
Aplicația a fost testată pe 100 de aplicații dintre cele de top existente pe Google Play, alese aleator
din fiecare categorie, acestea fiind comparate cu cele aparținând aceleiași categorii. Detecț ia a fost
realizată în doi pași:
 Execuția aplicațiilor pe un smartphone pentru a verifica similaritatea
funcționalităților
 Verificarea codului, inclusiv a fișierelor de layout și a permisiunilor
Doar dacă din ambele criterii rezultă similarități, se consid eră ca și caz real de
copiere(reîmpachetare). Au fost găsite 129 de cazuri de perechi false dintr -un total de 573,872 de
perechi, acestea fiind categorisite ca rezultate pozitive false. Aceast rezultat e datorat utilizărilor
acelorași librării de către amb ele aplicații, iar dimensiunea graf -ului uneia dintre aplicații este
relativ mică.
Numărul de perechi care nu au fost detectate de aplicație este de 33, dintre care 11 nu au cod
comun, sau au foarte puțin, deci neincluderea lor în rezultatul unei detecții este o decizie corectă.
Alte 10 perechi sunt folosite, nu pentru funcționalitățile lor, ci pentru a crea conținut malițios cum
ar fi shortcut -uri sau mesaje trimise fără știrea utilizatorului. Celelalte aplicații nu au fost detectate
deoarece codul de baz ă e comun, însă add -on-urile , cum ar fi cele pentru social media, sunt mari
și complexe în comparație cu codul de bază.
Coloana procentajului reprezintă proporția aplicațiilor care, fie copiază, fie sunt copiate. În medie,
4,7% din aplicațiile testate rep rezintă cazuri reale de reîmpachetare.
Timpul mediu de execuție este de aproximativ 11s per pereche. Doar pentru 0,6% din aplicații,
construcția grafului de view -uri durează mai mult de un minut, iar pentru 0,2% compararea
grafurilor durează la fel de mul t.

39

Tabel 3-1 Numărul aplicațiilor reîmpachetate detectate de ViewDroid

Limitări
Aplicația poate detecta urmatoarele trei tipuri de atacuri:
 Lazy attacks – nu schimbă funcționalitatea aplicației, ci doar numele autorului sau anumite
reclame
 Amateur attacks – schimbă/adaugă/șterg anumite funcționalități, cum ar fi trimiterea de
mesaje sau apeluri malițioase sau contra cost
 Malware – se folosesc de popularitatea aplicației copiate pentru a mări popularitatea
aplicației pereche
Și totuși, unele atacuri pot modifica grafurile de view -uri fără a ține cont de capacitatea atacului
sau de performanța aplicațiilor care copiază. Iar pentru a înlătura posibi litatea omiterii unor
perechi ar trebui aplicată o analiză dinamică, iar o abordare hibridă între analiza statică și cea
dinamică reprezintă o temă a unui studiu viitor.

40
Concluzii
Rezultatele evaluării aplicației, al cărei scop este de a detecta aplicațiil e reîmpachetate, arată că
sistemul poate descoperi reîmpachetarea aplicațiilor în ciuda prezenței unor metode de ascundere
a acestei tehnici, acest sistem putând fi, de asemenea, folosit pentru experimente la scară largă
[23].

3.1.2 Unsafe Exposure Analys is of Mobile In -App Advertisements

Autori

Michael Grace, Wu Zhou, Xuxian Jiang, Ahmad -Reza Sadeghi

Ideea principală

Odată cu apariția smartphone -urilor, au apărut și funcții suplimentare pe lângă funcțiile standard
de telefonie și mesagerie ale unui t elefon normal. Aproape două treimi dintre aplicațiile pentru
aceste dispozitive sunt gratuite. Pentru a compensa, mulți dezvoltatori incorporeaza o librărie de
publicitate în aplicațiile lor. Scopul studiului este de a observa aceste librării și la ce risc uri expun
acestea intimitatea și securitatea utilizatorului. Aceste librării colecteaza informații private (de
exemplu: locația utilizatorului pentru promovare ulterioară), sau unele colecteaza invaziv
informații care țin de jurnalul de apeluri sau cel de mesaje al utilizatorului, numărul de telefon sau
informații legate de conturile acestuia.

Fig. 3-1 Posib ilele riscuri ale promovării în aplicațiile pentru s martphone

41

Rezultate

Sistemul scanează f iecare librărie de promovare pentru a detecta dacă aceasta utilizează vreunul
din 76 de API -uri periculoase. Rezultatele arată că unele API -uri care sunt marcate ca periculoase
sunt folosite în mod constant de aceste librării. Acestea includ API -urile pent ru locatie și cele
pentru citirea informațiilor despre dispozitiv. Aceste librării folosesc API -urile pentru a detecta
care sunt grupurile țintă.

Locația reprezintă un conținut relevant pentru zona geografică a utilizatorului, iar informația
despre dispo zitiv returnează IMEI -ul telefonului, un identificator unic care e folosit pentru a
identifica ce fel de conținut a servit unui anumit utilizator. Alte API -uri periculoase sunt folosite
de aceste librării care permit efectuarea de apeluri telefonice sau tr imiterea de mesaje text, fără
știrea utilizatorului, dar sunt declanșate de către acesta, prin accesarea reclamei.

Cererile de informații reprezintă o categorie mai dăunătoare care nu are ca scop direcționarea
ultierioară a promovării. Aceste API -uri au c el mai grav efect. Această informație este o
amenințare pentru siguranța utilizatorului deoarece este folosită în corelație cu alte date despre
acesta. De exemplu, unele aplicații caută ultimul număr apelat și îl trimit printr -un URL către un
server.
Alte librării citesc baza de date a mesajelor pentru a afla care este furnizorul de servicii responsabil
pentru rutarea mesajelor către, respective dinspre utilizator.
Un alt tip important de risc este cel al transmiterii involuntare de date importante către o aplicație,
transmitere realizată doar prin ulterior accesării unei reclame.

Fig. 3-2 Numărul de librării conținute de aplicații

42
Majoritatea aplicațiilor incorporează una sau maxim două librării care pot colecta informații despre
utilizator, fiind astfel suficientă prezența unei librării pentru ca utilizatorul să fie supus riscurilor.

Limitări și dezvolt are ulterioară

Studiul este limitat la acele librării care sunt purtate de către aplicațiile gazdă. În particular,
librăriile de promovare curente sunt existente standalone (de sine stătătoare), putând fi astfel
incluse de către dezvoltatorii de aplicații.
Este posibilă existența mai multor mecanisme care ar putea realiza ascunderea folosirii API -urilor
Android periculoase (accesarea informațiilor personale). Există proiecte de cercetare care țintesc
detectarea sau înlăturarea acestor atacuri. Extinderea aplicației pentru a putea integra aceste
sisteme poate face obiectul unui studiu viitor.

Așadar, libr ăriile examinate, printre care se numără librării dintre cele mai folosite pe piață, expun
utilizatorul la riscuri precum executarea unui cod nedorit în cadrul aplicațiilor. Având în vedere
gradul scăzut de detectare a diferențelor dintre acțiunile executa te de librării și cele executate de
aplicația gazdă, necesitatea schimbării modului de implementare a librăriilor este din ce în ce mai
critică [8].

3.1.3 DroidBarrier: Know What is Executing on Your Android

Autori

Hussain M. J. Almohri, Danfeng ( Daphne) Yao, Denis Kafura

Ideea principală

Cauza care st ă la baza vulnerabilităților sistemului Android constă din aplicații care sunt executate
fără știința utilizatorului. Tehnica prezentată, și anume, autentificarea proceselor pentru aplicațiile
Android, completează mecanismul sandbox -urilor cu scopul de a furniza protecția resurselor de
sistem împotriva aplicațiilor neautorizate și dăunătoare. Modelul de autentificare a proceselor
rezolvă problema obligând procesele aplicațiilor să fie autentificate înainte ca acestea să utilizeze
resurse ale sistemului.

43

Rezultate

Principala funcție a modelului de autentificare a proceselor este de a detecta procesele neautorizate
în timpul rulării(la runtime). Pentru a realiza această funcție a fost dezvolt at un sistem care
implementează autentificarea obligatorie a tuturor proceselor ale fiecărei aplicații care rulează în
Android. Folosindu -se de autentificarea obligatorie, sistemul garantează detecția proceselor care
nu sunt autentificate și previne astfel atacuri ulterioare.

Fig. 3-3 Secvență de atac care trece de mecanismul sandbox și instalează aplicații
fără permisiunea utilizatorului

Aplicațiile înregistrate de sistem sunt cele pe care utilizatorul dorește să le ruleze. Această
înregistrare permite utilizatorului să controleze care aplicații sunt legitime pentru a rula. Sistemul
include capabilitatea de detecție, aceasta având scopul de a monitoriza crearea de procese și
activități, și de a autentifi ca procese în timpul rulării.
Conform cu modelul aplicațiilor Android, fiecare pachet de aplicații trebuie să ruleze cel puțin un
proces care nu aparține altor aplicații. Pentru a detecta aplicațiile Android dăunătoare, sistemul
este proiectat să găsească aceste aplicații prin detecția creării de procese. Potrivit analizelor,
aproximativ 36,7% din aplicații nu respectă privilegii și execută shell script -uri ascunse care
necesită propriile lor procese.
Categoriile malițioase incluse în teste cuprind: ingine rie socială sofisticată, exploatarea
vulnerabilității root -ului, precum și atacuri financiare. Sistemul a detectat cu succes toate probele
care au fost testate din aceste trei categorii, care nu s -au autentificat cu success. Aplicațiile care au

44
încercat să ruleze executabile necunoscute, au fost detectate cu success în momentul creării
proceselor.

Concluzii și dezvoltare ulterioară

Modelul realizat este unul general care furnizează autentificarea sigură a proceselor care aparțin
aplicațiilor care rulează pe un dispozitiv Android. Abordarea garantează protejarea sistemului
împotriva execuției aplicațiilor malițioase, care pot exploata atât vulnerabilitățile sistemului, cât și
cele ale aplicațiilor, pentru a fi instalate pe dispozitiv.
Această funcționalitat e este realizată prin autentificarea obligatorie care conduce la detecția cu
succes a proceselor care pot duce la apariția viitoare a atacurilor.
Dezvoltările ulterioare se vor concentra pe autentificarea comunicațiilor dintre procese, precum și
pe autenti ficarea accesului la resursele aplicațiilor [2].

3.1.4 Can Smartphone Users Turn Off Tracking Service Settings?

Autori

Veelasha Moonsamy, Lynn Batten, Malcolm Shore

Ideea principală

Serviciile de urmărire(tracking) joacă un rol important în eco sistemul smartphone -ului. Aceste
servicii pot fi folosite în moduri greșite de către promovatori doar pentru interesul personal.
Telefoanele mobile oferă aceste servicii de tracking pentru diverse scopuri, cum ar fi: asistența la
condus sau în orientare tu ristică, dar și pentru serviciile de promovare. Contribuția studiului constă
în:

 Dezvoltarea unui sistem care poate fi folosit pentru a monitoriza traficul în timp
real

 Determinarea gradului de funcționabilitate a setărilor de locație sau de promovare

 Identificarea motivelor apariției tracking -ului neașteptat

45

Rezultate

Google aplică un model bazat pe permisiuni ca măsură de restricționare a accesului la resurse de
sistem privilegiate. Astfel, utilizatorul trebuie să acorde acces tuturor permisiu nilor cerute de către
aplicații pentru ca acestea să fie instalate.

Orice librărie de promovare inclusă în aplicații primește aceleași privilegii ca și aplicația care a
cerut acele permisiuni. Pentru serviciile de locație, utilizatorul are opțiunea de a garanta sau bloca
complet accesul la informațiile referitoare la locația dispozitivului.
Ca rezultat, utilizatorii se așteaptă ca aplicațiile instalate să folosească doar informații despre
locație atunci când serviciile sunt pornite. Urmărirea prin promo vare pe dispozitivele Android nu
poate fi blocată în totalitate.

Pentru ca informația privată trimisă prin intermediul serviciilor de urmărire să fie monitorizată, la
baza studiului a stat comunicația C2S (client spre server). Experimentul a constat din două părți,
și anume: rularea aplicațiilor cu ambele servicii pornite (locație și promovare), în prima parte,
respectiv oprirea serviciilor pentru locație și limitarea celor pentru promovare în a doua parte.

În tabelul următor e prezentat numărul de apli cații care au generat scurgeri de informații legate de
cuvintele cheie alese (IP și GPS pentru informația dinamică, respectiv adresa MAC, IMEI,
DeviceID și AndroidID pentru cea statică), în funcție de modul de operare al serviciilor.

Testele au fost real izate pe un set de date provenit de la 102 de aplicații Android cu scopul de a
testa dacă serviciile rulează conform cu așteptările.

Tabel 3-2 Numărul de aplicații/Mod de operare al serviciilor

46

Limitări și dezvoltare ulterioară

Informația dinamică este folosită de către serviciile de urmărire și este modificată de către locația
fizică a dispozitivului. S -a observat că unele aplicații, atunci când serviciile pentru locație sunt
oprite, transmit informații care conțin adresa IP a dispozitivului. O astfel de informație care se
schimbă atât de des, poate fi considerată puțin semnificativă, dar o colecție de astfel de informații,
care duc la descoperirea locației utilizatorului, poate fi folosită în scopuri greșite.

Referitor la in formația statică, peste 80% din aplicațiile Android trimit informația despre IMEI
spre server fără știrea utilizatorului.
Un factor important este acela că scurgerile de informații nu sunt realizate doar prin intermediul
acestor servicii. Utilizatorii car e instalează certificate SSL pot pierde cu ușurință date. De exemplu
în 95% din aplicațiile testate (102), adrese de email și parole au fost transmise.
Ca studiu ulterior, cercetătorii, și industria din domeniu, ar putea dezvolta aplicații open -source
care să compenseze cu vulnerabilitățile din securitate existente în aplicațiile oferite pe piețele
oficiale.

În concluzie, chiar și în eventualitatea în care utilizatorii blochează sau limitează accesul serviciilor
de tracking, datele pot fi preluate de către aplicații și transmise apoi mai departe, efectuându -se
astfel scurgerea de informații. De asemenea, datele care sunt transmise prin intermediul acestor
servicii nu conțin doar informații despre locație, ci și o cantitate de alte informații care se poate
dovedi a fi folosită malițios [14].

3.1.5 Cloud -based Real -time location tracking and messaging system: A child -care
case study

Autori
Cong -Thinh Huynh, Huu -Quoc Nguyen, Xuan -Qui Pham, Tien -Dung Nguyen, Eui -Nam Huh

Ideea pri ncipală

Cloud Computing reprezintă una dintre modalitățile de realizare a monitorizării în timp real, a
trimiterii de mesaje sau a procesării de baze de date. Prin intermediul Mobile Cloud Computing
parin ții își pot supraveghea copiii și, de asemenea, pot ști dacă aceștia sunt în siguranță în orice
moment și în orice loc. Pentru realizarea acestei idei a fost dezvoltat un sistem bazat pe cloud

47
pentru găsirea locației în timp real și pentru trimiterea de mesaje. Scopul acestui sistem este de a
asigura sigur anța copiilor.

Rezultate

Sistemul (CRLTMS) este compus din: o combinație între telefonul copilului (conectat prin interne t
la un server de monitorizare) , un serviciu Google Cloud prin intermediul căruia părinții pot
supraveghea locația copilului și pot c omunica cu acesta prin intermediul unui telefon, al unei
tablete sau al unui laptop printr -un web browser sau o aplicație mobilă în timp real.

Obiectivele urmărite au fost:
comunicarea prin mesaje între părinți
și copii în timp real, precum și
urmărir ea locației copilului și
notificarea părintelui în funcție de
locație

Sistemul afișează fiecare mișcare a copilului pe o hartă Google Maps. Cercul albastru reprezintă
zona de siguranță, punctul roz – punctul de pl ecare, iar cel albastru – punctul în care se află copilul
în momentul de față. Când copilul iese din zona de siguranță, un mesaj automat va fi trimis către
părinte.
Fig. 3-4 Sistemul bazat pe cloud de detectare a
locației în timp real și de trimitere
a mesajelor

48

Sistemul are caracteristici de securitate puternice fiind folosit împreună cu dispozitiv ele clienților,
serverul web și mediul cloud. Conturile părinților sunt criptate cu algoritmi de hashing MD5 în
baza de date, iar id -ul copilului este un șir unic generat si securizat pe platforma Google Cloud.

Fig. 3-5 Exemplu de funcționare a sistemului

49

În tabelul următor se regăsesc statistici cu privire la numărul de mesaje trimise pe oră, numărul de
mesaje primite si procentul din baterie consumat per oră, respective per mesaj, atât în modul 3G,
cât și în modul Wifi.

Tabel 3-2 Statistici realizate

Limitări
Una dintre puținele limitări e reprezentată de posibilitatea netrimiterii anumitor mesaje în
intervalul de timp scurs între închiderea conexiunii la internet și deschiderea ei ulterioară. Rata
netrimiterii este mult mai mică în cazul Wifi decât în cel al 3G deoarece conexiunea poate fi
restabilită într -un timp mult mai scurt.

Evoluția așteptată
Evaluările arată că sistemul poate ajuta părinții să a ibă evidența locației copiilor și să comunice cu
aceștia în timp real. Studiul poate fi extins pentru a adapta sistemul mai multor scenarii, cum ar fi:
urmărirea transporturilor, precum și serviciul medical de urgență bazat pe locație sau sisteme de
averti zare în caz de dezastru sau eveniment critic [12].

50

3.2 Proiectarea sistemului

3.2.1 Analiza și specificarea cerințelor

Înțelegerea contextului conform domeniului de aplicare

Acest sistem de monitorizare a activităților pentru sisteme mobile Android oferă utili zatorilor, mai
exact persoanelor care supraveghează, posibilitatea de a monitoriza activitatea unor anumite
persoane pe dispozitivele mobile deținute de către acestea, această monitorizare fiind realizată în
timp real. Un astfel de sistem de monitorizare t rebuie să ofere utilizatorului informații suficiente
pentru posibilitatea împiedicării ulterioare a unor hazarduri precum furtul de informații, punerea
în pericol a persoanei care folosește dispozitivul sau periclitarea activității personale sau
profesiona le a respectivei persoane.
Un astfel de sistem trebuie să furnizeze informații referitoare la interacțiunea dintre utilizatorul
dispozitivului și alte persoane, precum și cele referitoare la timpul interacțiunii și locația efectuării
acesteia. Vizualizarea acestor informații trebuie să fie posibilă oricând, prin intermediul unui
dispozitiv care să aibă acces la serviciul de internet.

Un sistem de monitorizare trebuie să aibă în structura sa trei componente esențiale, și anume:
 Un server care realizează leg ătura între celelalte două componente ale sistemului
 Componenta care preia informații legate de activitatea pe dispozitiv și le transmite spre
server
 Componenta care preia informațiile de pe server și le oferă utilizatorului prin intermediul
unei intefețe grafice

Sistemul trebuie să confere utilizatorului posibilitatea de a accesa informațiile preluate de pe
dispozitiv în orice moment de timp, furnizarea acestor informații de către componenta care le preia
de pe dispozitiv trebuind să fie imposibil de înt rerupt de către interacțiunea om -dispozitiv.

51
Pentru ca utilizatorul să poată accesa aceste informații pe un alt dispozitiv, indiferent de sistemul
de operare care rulează pe acest dispozitiv, componenta care oferă informațiile în formă finală
utilizatorul ui este reprezentată de către o aplicație care să ruleze pe majoritatea browserelor web,
indiferent dacă dispozitivul este reprezentat de către un sistem desktop sau de unul mobil.

Serviciile oferite de un sistem de monitorizare trebuie să asigure anumite criterii esențiale:
 Imposibilitatea de a fi detectat
 Imposibilitatea de a fi oprit din funcționare (atât timp cât dispozitivul funcționează)
 Securitatea transferului de informații
 Securizarea accesului la informații
 Acces doar persoanelor autorizate de că tre beneficiar
 Furnizarea de informați i în momentul apariției acestora
 Independența de tipul dispozitivului pe care se dorește accesarea datelor
Informațiile cele mai importante pe care le poate accesa beneficiarul acestui sistem sunt
reprezentate de către :
 Date despre apelurile efectuate/primite pe dispozitivul supravegheat
 Date despre mesajele existente pe dispozitiv
 Data și ora la care activitățile mai sus precizate au fost realizate
 Locația dispozitivului și totodată a utilizatorului la un moment dat
 Afișarea locației dispozitivului

Cerințe specifice bazei de date

Este necesar ca baza de date a sistemului să cuprindă următoarele informații:

 Date despre dispozitiv
 Date pentru logarea utilizatorului în sistem
 Date referitoare la apeluri
 Date referito are la mesaje
 Date referitoare la locație
 Timpul preluării datelor de la dispozitiv

52

Cerințe specifice sistemului

Pentru ca sistemul să respecte cerințele și să îndeplinească funcționalităț ile unui sistem de
monitorizare a dispozitivelor mobile, apl icațiile din care acest sistem constă trebuie să ofere
următoarele funcționalități:

Aplicația pentru dispozitivul Android:
 Rulează atât timp cât dispozitivul este în stare de funcționare
 Nu poate fi oprită de către utilizatorul dispozitivului
 Pornește od ată cu pornirea sistemului de operare al dispozitivului
 Preia informații referitoare la apeluri și mesaje și le transmite către server
 Preia locația dispozitivului periodic și o transmite către server
 Criptează informațiile înainte de momentul trimiterii l or către server
 Nu oferă notificări sau funcționalități prin care poate fi ușor detectată

Fișierele de la nivelul server -ului:
 Primesc informațiile de la aplicația Android
 Despachetează informațiile
 Se conectează la baza de date
 Stochează informațiile în tabelele corespunzătoare din baza de date

Aplicația (fișierele) Web:
 Permite atât logarea, cât și delogarea vizitatorului
 Se conectează la baza de date
 Afișează informațiile referitoare la apeluri, mesaje, locație
 Afișarea mesajelor se face într -un forma t paginat
 Afișează ultima locație detectată prin intermediul serviciilor Google Maps

53

3.2.2 Proiectarea bazei de date

În cadrul bazei de date a sistemului sunt necesare următoarele informații:
 Date despre beneficiarul sistemului
 Date despre dispozitivele sup ravegheate
 Date referitoare la apelurile de pe dispozitive
 Date referitoare la mesajele de pe dispozitive
 Date referitoare la locația dispozitivelor

Aceste date sunt stocate într -o bază de date de tip MySQL , acesta fiind unul dintre cele mai des
folosite sisteme de baze de date, integrarea sa în alte sisteme de aplicații (web sau desktop) fiind
una mult mai facilă decât cea a altor sisteme. În figurile următoare vor fi prezentate tabelele care
aparțin bazei de date precum și structura finală a acesteia:

Tabela Dispozitive :

În tabela Dispozitive sunt stocate informații referitoare la toate dispozitivele care sunt monitorizate
de către sistem, precum și cele referitoare la persoana care va supraveghea activitatea respectivului
dispozitiv .
Fig. 3-6 Tabela Dispozitive

54

 ID_TELEFON – reprezintă cheia primară a tabelei Dispozitive și ID-ul dispozitivului
monitorizat
 EMAIL – reprezintă adresa de email folosită de către beneficiar pentru înregistrare și
ulterior pentru logare
 PAROLA – reprezintă parola generată aleator la nivelul serverulu i în momentul
înregistrării. Va fi folosită de către utilizator pentru logare în aplicația Web
 CHEIE – reprezintă cheia cu care vor fi criptate informațiile, unică pentru fiecare utilizator
în parte

Tabela Apeluri:
În cadrul tabelei Apeluri sunt stocate informații referitoare la apelurile efectuate sau primite de
către utilizatorii dispozitivelor.

 ID – reprezintă cheia primară a tabelei Apeluri și ID -ul apelului
 ID_TELEFON – reprezintă cheia străină a tabelei Apeluri și ID -ul dispozitivului de care
aparține apelul
 TIP_APEL – reprezintă tipul apelului și anume: INCOMING, OUTGOING sau MISSED
(primit, efectuat sau ratat)
 NUMAR – reprezintă numărul de telefon apelat sau numărul de la care s -a efectuat apelul
primit sau ratat
 NUME – reprezintă numele persoan ei (contactului) aferente numărului în agenda
dispozitivului ( câmpul este completat cu “necunoscut” în cazul în care numărul nu aparține
niciunui contact din agendă)
 DATA – reprezintă data și ora efectuării apelului (preluate de pe dispozitiv)
 DUR ATA – reprezintă durata apelulu i
Fig. 3-7 Tabela Apeluri

55

Tabela Mesaje:
În cadrul tabelei Mesaje sunt stocate informații referitoare la mesajele primite de către utilizatorul
dispozitivului mobile, sau trimise de către acesta.

 ID – reprezintă cheia primară a tabelei Mesaje și ID -ul mesajului
 ID_TELEFON – reprezintă cheia străină a tabelei Mesaje și ID -ul dispozitivului de care
aparține mesajul
 TIP_APEL – reprezintă tipul mesajului și anume: PRIMIT sau TRIMIS
 NUMAR – reprezintă numărul de telefon la care s -a trimist mesajul sau de la care s -a primit
acesta
 NUME – reprezintă numele persoanei (contactului) aferente numărului în agenda
dispozitivului ( câmpul este completat cu “necunoscut” în cazul în care numărul nu aparține
niciunui contact din agendă)
 DATA – reprezintă data și ora efec tuării mesajului (preluate de pe dispozitiv)
 TEXT – reprezintă textul mesajului

Fig. 3-8 Tabela Mesaje

56
Tabela Locatie:
Tabela Locatie conține informații referitoare la locațiile în care a fost detectat dispoziti vul la
anumite momente de timp.
 ID – reprezintă cheia prima ră a tabelei Locatie și ID -ul locatiei
 ID_TELEFON – reprezintă cheia străină a tabelei Locatie și ID -ul dispozitivului a cărui
locație a fost preluată
 LOCATIE – reprezintă totalitatea informațiilor despre locație oferită de serviciul de
localizare din cadr ul dispozitivului
 ADRESA – reprezintă adresa la care a f ost detectat dispozitivul ( stradă, număr , localitate )
 LATITUDINE și LONGITUDINE – reprezintă coordonatele geografice care descriu
punctul în care a fost detectat dispozitivul
 DATA – reprezintă data și ora detectării locației(preluate de pe dispozitiv)
Diagrama finală a bazei de date:

Fig. 3-10 Diagrama finală a bazei de date
Fig. 3-9 Tabela Locatie

57

În final, după proiectarea structurii tabelelor aferente bazei de date, relații le dintre aceste tabele au
fost realizate. Între tabela dispozitive și celelalte trei tabele ale bazei de date există o relație one –
to-many care are cheia ID_TELEFON. Această alegere e motivată deoarece un singur dispozitiv
supravegheat de un singur benefi ciar poate efectua sau primi mai multe apeluri. De asemenea, un
singur dispozitiv mobil poate primi sau trimite mai multe mesaje, precum și poate fi detectat la
mai multe locații de către sistem.

3.2.3 Arhitectura sistemului

În figura următoare este prezent ată arhitectura conceptuală a sistemului de monitorizare. Aceasta
reprezintă imaginea de ansamblu a structurii, comunicației, funcționalităților sistemului precum și
a informațiilor furnizate de acesta și de modulele în cadrul cărora acestea sunt furnizate .
Fig. 3-11 Arhitectura conceptuală a sistemului

58
Sistemul constă din:

 O aplicație client, nativă Android, care este instalată și apoi rulată pe un dispozitiv mobil
Android
 Un server, la nivelul căruia sunt prezente fișiere al căror scop este de a administra datele
provenite de la aplicația Android și de a le stoca în baza de date
 Baza de date, localizată la nivelul server -ului
 O aplicație Web care constă din fișiere având rolul de a prelua informații din baza de date
și a le afișa apoi în cadrul unei interfețe cu utilizatorul

Prima aplica ție este conc epută pentru a rula pe dispozitivul gazdă și pentru a transmite date ori de
câte ori este nevoie către baza de date. Aplicația Android este vizibilă doar în momentul primei
utilizări dupa instalare. În acel moment beneficiarul sistemului trebuie să se înre gistreze în sistemul
de utilizatori prin intermediul unui cont de email. Detaliile referitoare la parolă și înștiințările
ulterioare le va primi la această adresă de email. Această aplicație nu trebuie să poată fi detectată
ușor de către utilizatorul dispo zitivului. Totodată, funcționarea aplicației nu poate fi oprită de către
acest utilizator, aceasta repornind în cazul restartării sistemului, precum și în cazul încercării opririi
aplicației.
În momentul primirii sau trimiterii unui mesaj sau a unui apel, precum și în cazul preluării locației
dispozitivului la un anumit moment, informațiile necesare monitorizării acestor evenimente sunt
preluate și transmise către fișierele de la nivelul server -ului, într -un anumit format. Aceste fișiere
despachetează infor mația provenită de la aplicația Android, ținând cont de acest format, se
conectează la baza de date și stochează aceste informații apoi în tabelele corespunzătoare din
cadrul bazei de date.

În momentul logării cu succes a beneficiarului și a accesării apl icației Web în cadrul platformei
Web, acesta poate accesa în cadrul unor tab -uri diferite informațiile referitoare la apeluri, precum
și cele referitoare la mesaje sau locație. De asemenea, ultima locație a dispozitivului preluată de
către sistem poate fi vizualizată de către beneficiar în cadrul tab -ului corespunzător prin
intermediul serviciilor Google Maps. Datele sunt preluate din baza de date prin intermediul
fișierelor din cadrul aplicației Web, iar acestea sunt decriptate folosind același standard ut ilizat în
momentul criptării efectuate la nivelul aplicației Android.

59
Astfel, transmisia datelor este securizată în cadrul sistemului, decriptarea informațiilor realizându –
se doar în momentul care precede afișarea lor în cadrul interfeței cu utilizatorul . Aceste detalii de
proiectare a sistemului îi conferă acestuia modularitatea, integritatea și securitatea necesare
realizării unui sistem de supraveghere conform cerințelor prezentate în capitolul anterior.
Interacțiunea dintre utilizatorul sistemului, d ispozitivul monitorizat, interfața Web cu utilizatorul,
precum și cea cu și dintre modulele din care constau aceste părți componente ale sistemulu i poate
fi observată în figura următoare :

Fig. 3-12 Diagrama Use case a sistemului

60
3.3 Dezvoltarea aplicației
3.3.1 Mediul de dezvoltare

Android Studio

Aplicația pentru dispozitivul mobil a fost dezvoltată folosind Android Studio, un mediu de
dezvoltare software (mediu de dezvoltare integrat – IDE), iar sistemul pe car e s-a rulat emularea
sistemului Android este reprezentat de un sistem Windows pe 64 de biti.
Alegerea mediului Android Studio este motivată de către următorii factori:
 Suportul pentru build bazat pe Gradle al Android Studio
 Posibilitatea de refactoring și de quick fix specifice Android sporită față de cea din
Eclipse
 Autocompletarea IntelliJ a Java
 Dezvoltarea componentelor bazată pe template -uri
 Design -ul de interfață mai rapid al Android Studio
 Posibilitatea de modificare a interfeșei prin instrumentul d e design
 Folosirea modulelor în locul spațiilor de lucru din Eclipse
 Posibilitatea de previzualizare a interfeței

Android SDK

A fost folosit framework -ul Android 5.0 pentru implementarea aplicației pentru dispozitivul mobil
pentru avantajele oferite sau incluse, dintre care se pot enumera:
 Librăriile necesare dezvoltării unei aplicații pentru dispozitive mobile
 Prezența debugger -ului putând fi realizat debug la nivelul liniei de cod
 Prezența unui emulator, aplicațiile putând fi rulate virtual pe acesta
 Sample -uri de aplicații care includ codul sursă
 Tutoriale pentru sistemul de operare Android

61
Java

Limbajul de programare Java a fost ales din mai multe motive:
 Folosirea sa la scară largă, precum și cunoașterea sa
 Posibilitatea de a fi rulat pe o mașină virtuală fără a fi nevoie de recompilare pentru
dispozitive mobile diferite
 Securitatea sa sporită, o caracteristică esențială a unei aplicații dintr -un sistem de
monitorizare
 Instrumentele de dezvoltare disponibile
 Compatibilitatea cu multe dispozitive mo bile

PHP

Limbajul PHP a fost ales datorită avantajelor pe care le conferă pentru construirea paginilor Web,
putând fi rulat pe mai multe platforme, fie ele desktop sau mobile și putându -se conecta la mai
multe tipuri de baze de date. Unul dintre cele mai importante aspect este reprezentat de către
posibilitatea îmbricării cu cod HTML.

Javascript

Printre avantajele folosirii limbajului de programare se numără:
 Executarea codului pe procesorul client, și nu pe al server -ului web
 Simplitatea limnajului
 Rezultatele sunt returnate aproape instant, codul fiind executat pe computerul
utilizatorului

Google Maps API

Folosirea API -ului Google Maps a fost aleasă deoarece Google Maps este cel mai folosit serviciu
de hărți din lume cu peste 250 de milioane de utili zatori activi, doar pe dispozitivele mobile. Un
alt motiv este reprezentate de faptul că prin intermediul API -ului portabilitatea aplicației web este
completată, aplicații bazate pe locație putând fi folosite prin intermediul unui browser web sau al
dispoz itivelor mobile.

62

MySQL

Motivele alegerii limbajului de interogare a bazelor de date MySQL sunt:
 Securitatea limbajului
 Accesibilitatea limbajului, parolele fiind criptate și multiple straturi de securitate
fiind incluse
 Scalabilitate, MySQL putând utiliz a până la 50 de milioane de rânduri sau mai mult
 Bună administrare a memoriei, prevenind pierderile de informații
 Portabilitate, rulează pe multe sisteme de operare

3.3.2 Structura modulelor

Aplica ția Android

Scopul aplicației Android, prezentă pe dispozitiv ul mobil monitorizat, este de a prelua informațiile
în momentul în care unul dintre următoarele evenimente are loc: apel primit/trimis, mesaj
primit/trimis, locație a dispozitivului preluată, și de a le transmite mai departe într -o structură de
date presta bilită prin intermediul unui request HTTP POST către fișierele de la nivelul server -ului
care se ocupă cu administrarea datelor primite de la aplicația Android și salvarea lor în baza de
date. Funcționalitatea acestor fișiere de la nivelul server -ului, pre cum și a celor de la nivelul
aplicației web va fi descrisă într -un capitol ulterior. În cadrul acestui capitol se dorește explicarea
funcționării aplicației de pe dispozitivul mobil Android.

Fișierul AndroidManifest

Fiecare aplica ție Android trebuie să c onțină un fișier AndroidManifest.xml (cu exact această
denumire) în directorul său rădăcină. Fișierul manifest conține informații esențiale care trebuie
oferite de către aplicație sistemului Android, informații pe care sistemul trebuie să le aibă înaintea
rulării codului oricărei aplicații.

63
Printre roluril e fișierului manifest se numără:
 Denumirea pachetului Java pentru aplicație. Numele pachetului deservește ca
identificator unic pentru aplicație
 Descrie componentele aplicației – activitățile, serviciil e, broadcast receiver -ele,
content provider -ele din care este compusă aplicația.
 Numește clasele care implementează fiecare componentă și prec izează
capabilitățile acesteia
 Declară de ce permisiuni are nevoie aplicația pentru a accesa părți protejate ale
API-urilor și pentru a interacționa cu alte aplicații
 Declară nivelul minim al API -ului Android cerut de către aplicație

Pentru aplicația Android din cadrul sistemului:

 Precizează numele pachetului – identificator unic al aplicației

 Permisiunile de care aplica ția are nevoie pentru a rula , dintre care enumerăm permisiuni
pentru: a accesa serviciul de internet, a accesa serviciul de locație, a citi jurnalele de apeluri
și SMS -uri etc.

64

 În interiorul blocului application, prezintă care sunt component ele aplicației, care sunt
clasele corespunzătoare componentelor, care este ordinea apariției lor, respectiv relațiile
dintre acestea [17]

Diagrama claselor

În următoarea figură va fi prezentată diagram claselor din cadrul aplicației pentru dispozitivul
mobil Android, funcționalitatea acestor clase urmând a fi apoi descrisă.

65

Fig. 3-13 Diagrama de clase a aplicației Android

66
Activitatea – MainActivity

Fiind nevoie ca aplicația să nu fie detectată, int erfața cu utilizatorul reprezintă o componentă care
trebuie ascunsă. Singura activitate disponibilă poate fi vizibilă doar la prima accesare a aplicației,
imediat după momentul instalării. Aceasta constă dintr -un camp care trebuie completat de către
persoa na care urmează să supravegheze cu adresa de email, și de un buton de register. După
apăsarea butonului, adresa de email, și ID -ul telefonului sunt transmise către server, o parolă
urmând a fi trimisă către beneficiar pe adresa acestuia de email. De asemen ea, aici este setată ca
aplicația să nu apară în meniul pentru aplicații al dispozitivului prin metoda
setComponentEnabledSetting.

Integritatea aplicației

Pentru ca aplica ția să ruleze atât timp cât dispozitivul este în stare de funcționare, informațiil e fiind
astfel transmise în orice moment de timp, este necesar un număr de funcționalități ale aplicației
Android, și anume:
 Restartarea aplicației (serviciilor) ori de câte ori utilizatorul încearcă închiderea
ei
 Pornirea aplicației ori de câte ori sistem ul de operare este repornit

67
1. În cazul în care utilizatorul dorește să oprească aplicația din funcționare :
În cadrul metodei on Destroy din clasa Myservice ( în momentul în care serviciul este distrus) este
trimis un Broadcast care con ține mesajul de Intent – „YouWillNeverKillMe”

În fișierul manifest existând un receiver care este notificat atunci când mesajul de Intent
„YouWillNeverKillMe ” este trimis c ătre broadcast în sistem,

receiver -ul cu apar ținând clasei RestartServiceReceiver va primi notificare, iar metoda onReceive
din cadrul clasei va fi apelat ă [11].

Această metodă realizează pornirea unei noi instanțe a serviciului care a fost distrus (închis) –
MyService. Astfel, se asigură funcționarea continuă și imposibil de întrerupt de către utiliza tor
prin închiderea unui serviciu sau a aplicației.

68

2. În cazul în care utilizatorul restartează dispozitivul:
În cadrul fișierului manifest este definit un alt receiver, care este notificat în momentul în care
acțiunea de boot a sistemului de operare a fost efectuată cu succes .

În acel moment, BroadcastReceiver -ul cu numele StartMyServiceAtBootReceiver primește o
notificare din partea sistemului, apelându -se ulterior metoda onReceive din cadrul clasei
respective.

Metoda onReceive realizează pornirea unui serviciu – MyService.

Preluarea apelurilor

Pentru preluarea apelurilor și transmiterea lor către server, în cadrul fișierului manifest este definit
un receiver, care este notificat ori de câte ori o schimbare asupra stării telefonului, sau a
PHONE_STATE , are loc [7].

69

În cadrul clasei IncomingCallInterceptor (BroadcastReceiver), metoda onReceive este apelată ori
de câte ori receiverul este notificat de către o schimbare asupra PHONE_STATE.
În cadrul metodei, starea curentă (PHONE_STATE) este preluată . Stările posibile în cazul
apelurilor telefonice sunt: RINGING – telefonul sună, OFFHOOK -receptor ridicat sau IDLE – în
afara apelurilor. Tranzițiile posibile sunt:
 IDLE -RINGING -IDLE dacă utilizatorul nu răspunde
 IDLE -RINGING -OFFHOOK -IDLE dacă utilizatorul ră spunde

Dacă starea este RINGING, atunci aceasta este marcată în cadrul unui membru static. La fel se
procedează și în cazul stării OFFHOOK.
Revenirea în starea IDLE a dispozitivului poate marca finalul unui apel. În cazul în care tranziția
către starea IDLE se face din starea RINGING sau OFFHOOK, înseamnă că un apel a fost primit
sau trimis de pe acel dispozitiv. Pe această ramură de program se preiau informațiile referitoare la
apelul respectiv. Se așteaptă o perioadă de o secundă pentru ca informațiil e să fie preluate în urma
modificărilor efectuate de apel.

70

Este interogat un URI referitor la conținutul jurnalului de apeluri, fiind obținute astfel informațiile
necesare, care vor fi convertite ulterior în String -uri. Sunt preluate prin intermediul u nui Cursor
informații referitoare la tipul apelului, numărul de telefon, data și ora, precum și durata. De
asemenea este preluat și ID -ul dispozitivului.

Numele contact -ului corespunzător apelului este obținut prin interogarea URI -ului contactelor,
folosindu -se de numărul de telefon. Dacă numele rămâne null, înseamnă că numărul respectiv nu
este salvat în agenda dispozitivului în cadrul vreunui contact. Variabila name va primi astfel
valoarea “necunoscut” .

71
Cursoarele deschise și folosite vor fi închis e după finalizarea utilizării lor.
Datele vor fi convertite în string -uri înaintea trimiterii lor către baza de date.

În funcție de tipul apelului, în membrul care urmează sa fie transmis către baza de date este salvat
acest tip: OUTGOING – apel trimis, INCOMING -apel primit, MISSED -apel ratat.

Aceste informații urmează a fi trimise către fișierele PHP din cadrul server -ului printr -un request
de tipul HTTP POST, transmiterea datelor către server fiind prezentată în cadrul unui capitol
ulterior.
Preluare a mesajelor

Pentru preluarea mesajelor, în cadrul metodei onStart a clasei MyService, a serviciului principal
al aplicației este instanțiat un ContentResolver. În cadrul acestui ContentResolver este înregistrat
un obiect de tipul clasei YourObserver (Cont entObserver), acest ContentObserver fiind notificat
de fiecare dată când URI-ul care referă mesajele din cadrul dispozitivului suferă modificări [16].

72

În cadrul metodei onChange din clasa YourObserver (atunci când conținutul dispozitivului care se
refer ă la mesaje se schimbă) este interogat URI -ul care parsează “content: //sms ” prin intermediul
unui cursor, la fel ca și în cazul apelurilor. Se utilizează informațiile referitoare la ultimul mesaj
de pe dispozitiv, și anume: textul mesajului, numărul de tel efon, data și ora.

Numele contactului corespunzător numărului de telefon al mesajului este obținut similar cazului
apelurilor.

73
Dacă tipul mesajului este “1”, atunci sistemul se refer ă la un mesaj primit. Dacă tipul este “2”,
atunci sistemul se referă l a un mesaj trimis.

Din cauză că uneori informațiile legate de un mesaj erau prelucrate și trimise către server de două
ori, se verifică daca mesajul curent este același cu precedentul, iar dacă aceasta se confirmă,
mesajul nu va mai fi prelucrat a dou a oară. Aceasta este verificată prin intermediul metodei
smsChecker.

74
Preluarea locației

Preluarea locației este inițializată în cadrul clasei MyService, în metoda onCreate. O alarmă este
setată să se restarteze o dată la 30 de minute (un interval care s ă limiteze consumul de baterie al
serviciilor de locație). O dată la 30 de minute sunt efectuate operațiile necesare pentru preluarea
informațiilor referitoare la locația dispozitivului.

Receiver -ul LocationPoller este notificat la activarea alarmei. Ar e simpla funcționalitate de a
delega un eveniment către serviciul LocationPollerService.
În cadrul clasei LocationPollerParameter sunt setați parametri necesari pentru preluarea ulterioară
a locației. În cadrul parametrilor este setată perioada de două min ute care se va aștepta de la
activarea serviciilor până la preluarea propriu -zisă a locației. De asemenea se alege care este
furnizorul de locație, GPS sau rețea.
Serviciul LocationPollerService reprezintă nucleul motorului de preluare a locației. Se folos ește
de un WakeLock pentru a se asigura că procesorul rămâne activ pe durata preluării locației.
Tratează atât condiția de success, cât și cea de timeout.
Funcția getLock realizează inițializarea WakeLock -ului la prima utilizare. Se folosește un
WakeLock partial deoarece este necesar procesorul pornit, nu și ecranul.

75
Metoda requestLocation este apelată de către LocationPoller pentru a porni preluarea locației.
Preia WakeLock -ul, apoi pornește serviciul folosindu -se de Intent -ul furnizat.

În cazul ini țializării cu success a serviciilor, un Broadcast al unui mesaj de Intent către
LocationReceiver este lansat. Prioritate are serviciul de GPS, doar în cazul în care acesta nu este
accesat, se trece la network. În cazul în care BroadcastReceiver -ul Location Receiver este notificat,
rezultatul achiziției locației este preluat printr -o instanță a clase LocationPollerResult. Se preia
locația, iar în cazul în care aceasta este nulă, se preia vechea locație.

76

Prin intermediul unui obiect de tipul Geocoder se obț in informații referitoare la locație, cum ar fi
adresa, furnizând ca parametric metodei getFromLocation latitudinea și longitudinea obținute
anterior.

Informațiile sunt apoi transmise către server.

77
Transmiterea informațiilor către fișierele PHP (serve r)

Transmiterea informațiilor către server este realizată în cadrul fiecărei clase care necesită această
funcționalitate prin intermediul metodei postText, executată pe un fir de execuție diferit.

În cadrul metodei, variabila postReceiverUrl memorează Url-ul care identifică fișierul PHP către
care se fa face request -ul HTTP POST. De asemenea, se instanțiază un client HTTP, iar într -o listă
de obiecte de tipul NameValuePair (cheie -valoare) se stochează datele care urmează a fi transmise.
Prin metoda setEn tity se setează entitatea care urmează a fi transmisă, precum și modul de
encodare. Se execută apoi HTTP POST request -ul și se tratează răspunsul primit.
Ca și exemplu, observăm metoda postText din cadrul clasei LocationReceiver (transmiterea
locației căt re fișierul corespunzător de pe server):

78

Criptarea informațiilor

Înainte de a fi transmise către fișierele de gestionare, datele sunt criptate prin standardul AES cu o
cheie diferită pentru fiecare dispozitiv în parte (Cipher Block Chaining, No paddi ng)

Acest standard are nevoie de un vector de inițializare, între acesta și primul bloc, efectuându -se
operații de XOR și shiftare. De asemenea, un cifru este inițializat cu caracteristicile standardului
prezentate anterior. Acest cifru este iniți alizat, ca cifru de criptare, cu cheie și vector de inițializare.
În variabila encrypted va fi stocată valoarea criptată a textului dorit.

Fișierele de gestionare a informațiilor de la nivelul server -ului

Legătura dintre module, clasele Android, fișiere de gestionare și fișiere aplicație web

MODUL Clasă Android Fișier gestionare
(http://2.cateisibiu.ro/) Fișier aplicație
(http:// 2.cateisibiu.ro/site/)
Înregistrare MainActivity register.php login.php
Apeluri IncomingCallInterceptor test.php apeluri.php
Mesaje YourObserver test.php mesaje.php
Locatie LocationReceiver locatie.php locatie.php
Tabel 3-3 Legătura dintre module, clase Android, fișiere de gestionare și fișiere
aplicație web

79
Pentru fiecare modu l, în cadrul metodei postText din clasa Android respectivă, se trimit date către
URL -ul corespunzător fișierului de gestionare de pe server, urmând a fi stocate în baza de date
prin intermediul acestor fișiere, și mai apoi preluate prin intermediul fișiere lor aplicație și afișate
în cadrul interfeței cu utilizatorul.

Operațiile din cadrul fișierelor

În cadrul fiecărui fișier de gestionare a informațiilor se realizează conexiunea la baza de date
MySQL prin intermediul numelui de server, utilizatorului, pa rolei și al numelui bazei de date [21].

În cadrul fișierului register.php operații suplimentare, de generare a unei parole aleatoare pentru
fiecare utilizator și de trimitere a datelor de înregistrare către adresa de email a acestuia, sunt
efectuate.
Fiecare fișier de gestionare preia datele transmise prin metoda HTTP POST ș i le inserează în baza
de date. Fișierul test.php testează dacă pentru cheia “functie” a perechii cheie -valoare respective
este “apel” sau “mesaj”. În cazul apelului, informațiile sunt inserate în tabela apeluri printr -o
interogare SQL, respectiv în cazul mesajului, informațiile vor fi stocate în tabela mesaje .

80
Aplicația (fișierele) web

Aplicația web permite, în urma logării cu succes a utilizatorului, navigarea între diferite fișier e de
tip PHP, în care beneficiarul sistemului poate viziona informații referitoare la apelurile de pe
dispozitivul monitorizat, mesajele, locația acestuia (o dată la 30 de minute), precum și ultima
locație la care a fost detectat dispozitivul prin intermed iul unui script Javascript și a API -ului
Google Maps.
Ca și acțiune a butonului de logare din cadrul login.php este o redirecționare către fișierul
verifica.php. Datele (utilizator și parolă) sunt trimise prin POST spre acest fișier. În cadrul
fișierului v erifica.php, se verifică dacă aceste informații corespund cu cele existente în baza de
date. Dacă aceasta se confirmă ele vor fi salvate în variabile de sesiune, împreună cu ID -ul
dispozitivului, și vor fi valabile până la expirare sau închiderea sesiunii.
În cadrul fișierelor apeluri.php, mesaje.php, locatie.php (accesate post fixând
http://2.cateisibiu.ro/site/ ), vor fi preluate din baza de date, conexiunea la baza de date făcându -se
prin intermediul fișierului conectare.php, informațiile referitoare la a peluri, mesaje și locație, fiind
decriptate și ulterior afișate într -un format tabelar, câte 10 intrări p e pagină, în cadrul paginii web,
după cum putem observa și în figura următoare (figura conține doar primele 4 intrări din cadrul
paginii și conține inf ormații despre apeluri). Informațiile sunt afișate în ordine invers cronologică
(cea mai recentă intrare este prima în tabel).

Fig. 3-14 Modulul Apeluri al aplicației web

81

Pentru a obține ultima locație pr eluată a dispozitivului, s -a ales utilizarea API -ului Google Maps,
prin intermediul unui script Javascript. În cadrul scriptului, pe o instanță a unei hărți Google Maps,
este poziționat un marker, cu coordonatele (latitudine și longitudine) corespunzătoare ultimei
locații salvate în baza de date.
Pentru adresă :

Fig. 3-15 Ultima locație preluată

Marker -ul poziționat pe harta Google Maps este:

Fig. 3-16 Afișa rea marker -ului ultimei locații pe hartă

82
4 Concluzii
4.1 Gradul de îndeplinire a obiectivelor

4.1.1 Obiective îndeplinite

Sistemul realizat îndeplinește cu succes funcționalitățile de care are nevoie un sistem de
monitorizare a dispozitivelor mobile, și anume:
 Impos ibilitatea de a fi detectat
 Imposibilitatea de a fi oprit din funcționare (atât timp cât dispozitivul funcționează)
 Securitatea transferului de informații
 Securizarea accesului la informații
 Acces doar persoanelor autorizate de către beneficiar
 Furnizarea de informați i în momentul apariției acestora
 Independența de tipul dispozitivului pe care se dorește accesarea datelor
Aceste funcționalități au fost îndeplinite atât prin alegerile referitoare la proiectarea sa, precum și
prin cele referitoare la tehnolog iile prin care a fost implementat. Alegerea sistemului de operare
Android a făcut ca obiectivele referitoare la integritatea sistemului să fie îndeplinite, prin
intermediul claselor bazate pe design pattern -ul Observer. Acest design pattern a fost de mare folos
și pentru preluarea informațiilor necesare unui astfel de sistem. De asemenea, criteriul de
portabilitate și accesibilitate al sistemului a fost realizat prin intermediul alegerii realizării unei
aplicații pe platforma web, aplicație care să poată fi accesată atât pe sistemele de tip desktop, cât
și pe cele mobile.

4.1.2 Obiective neîndeplinite

Principalul obiectiv care nu a fost pe deplin îndeplinit este reprezentat de către preluarea continuă
a locației. Preluarea locației dispozitivului este preluată l a două minute de la activarea serviciilor,
aceasta fiind o limitare, preluarea după un interval mai scurt de două minute ducând la inexactitatea
informațiilor, și totodată ineficiența modulului. De asemenea, deoarece consumul de baterie cauzat
de serviciil e de locație este unul mare, s -a decis, în urma testelor, preluarea locației, și totodată
pornirea serviciilor, la un interval de 30 de minute. Astfel, consumul de energie este limitat, nefiind
sesizabil de către utilizatorul dispozitivului.
Blocarea posib ilității utilizatorului de a dezinstala aplicația de pe dispozitivul mobil respectiv ar
duce la imposibilitatea instalării de versiuni ulterioare (a update -urilor). Un update presupune

83
dezinstalarea versiunii vechi și instalarea celei noi. Aplicația poate fi dezinstalată, dar punerea în
pericol a integrității aplicației este limitată de criterii cum ar fi: denumirea aplicației care să ducă
la anonimitate, precum și rularea serviciilor și a funcționalităților deținute într -un mod aproape
imposibil de detecta t de către utilizator.

4.2 Dificultăți întâmpinate

Pe parcursul dezvoltării și implementării sistemului au fost întâmpinate dificultăți. Dintre acestea
pot fi enumerate:
 Înțelegerea mecanismului de funcționare al claselor care tratează evenimente în sistemul
Android (clase care respectă design pattern -ul Observer)
 Folosirea URI -urilor și modalitatea de observare a modificării conținutului
 Realizarea mecanismului de preluare a locației, acesta preluând un WakeLock pentru a
utiliza procesorul, precum și găsirea intervalelor minime necesare pentru preluarea cu
exactitate a locației sau pentru optimizarea consumului de energie cauzat de către serviciile
de locație
 Inserarea latitudinii și longitudinii (preluate din baza de date) în cadrul script -ului care
realizea ză afișarea marker -ului pe harta Google Maps

4.3 Dezvoltări ulterioare

Dezvoltarea ulterioară a acestui sistem va fi realizată în conformitate cu studiul efectuat asupra
articolului de cercetare “ Cloud -based Real -time location tracking and messaging system: A child –
care case study ” prezentat în cadrul capitolului 3.1.5.
Se dorește realizarea unui subsistem de notificare, prin care persoana care monitorizează să fie
înștiințată în cazul în care utilizatorul, respectiv dispozitivul, părăsește o zonă prestabilit ă (de
exemplu un cerc pe hartă). De asemenea, se dorește adăugarea unei funcționalități care să realizeze
notificarea supraveghetorului în cazul apariției unor mesaje al căror text poate duce la punere în
pericol a utilizatorului dispozitivului.
Aceste ave rtizări ar putea fi transmise către o altă aplicație Android prezentă pe dispozitivul
persoanei care monitorizează, sau ca și mesaje de tip text către telefonul acestei persoane.
Astfel, utilizatorul ar avea posibilitatea de a primi înștiințări în momentu l în care persoana
monitorizată ar putea fi în pericol, sau nu și -ar îndeplini activitatea conform cerințelor.

84
4.4 Cercetare

Pe lângă partea practică (proiectare, implementare) prezentată anterior în cadrul acestei lucrări de
diplomă, menționez mai jos contr ibuțiile științifice aduse în urma elaborării următoarelor articole:
Hornar iu M., Butean A., Moldoveanu F., ObDroid: An Android permanent monitoring tool based
on the observer pattern , The 12th edition of Romanian Human -Computer Interaction Conference
2015, 24-25 September 2015, Bucharest (waiting for review)

4.5 Participare la concursuri

Ulterior finalizării proiectului de diplomă , am participat la concursul Hardware and Software
Engineering, în cadrul Facultății de Inginerie, U niversitatea “Lucian Blaga” din Sibiu.
Proiectul a c âștigat Mențiunea a 3 -a în cadrul concursului mai sus precizat.

85
5 Bibliografie

[1] A guide to the Android operating system,
http:// connect.dpreview.com/post/8437301608/guide -to-android -os
[2] Almohri M.J.H, Yao D., Kafura D., DroidBarrier: Know What is Executing on Your
Android, published in Proceedings of the 4th ACM conference on Data and application
security and privacy, ISBN: 978 -1-4503-2278 -2, March 2014
[3] Android Application Security,
https://source.android.com/devices/tech/security/overview/app -security.html
[4] Android versions comparison, http://socialcompare.com/en/comparison/android -versions –
comparison
[5] Android, http://www.enginee rsgarage.com/articles/what -is-android -introduction
[6] Prof. Shedge K.N, Mr. Pathak S., Prof. Rokade S.M. , Android -Broadcast Receiver ,
published in International Journal of Emerging Technology and Advanced Engineering,
ISSN 2250 -2459, March 2013,
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.413.9805&rep=rep1&type=pdf
[7] Detect incoming call and call hangup event in Android,
http://karanbalkar.com/2014/ 02/detect -incoming -call-and-call-hangup -event -in-android/
[8] Grace M., Zhou W., Jiang X, Sadeghi A -R., Unsafe Exposure Analysis of Mobile In –
App Advertisements , published in Proceedings of the fifth ACM conference on Security
and Privacy in Wireless and Mo bile Networks, April 2012
[9] How App Permissions Work & Why You Should Care [Android],
http://www.makeuseof.com/tag/app -permissions -work -care-android/
[10] How Secure Is Android, Real ly?, http://lifehacker.com/how -secure -is-android -really –
1446328680
[11] How to make Android service unstoppable and run it countinuously
http://androidtrainningcenter.blogspot.ro/2013/05/how -to-make -android -service –
unstoppable.html
[12] Huynh C -T., Nguyen H -Q, Pham X -Q, Nguyen T -D, Huh E -N, Cloud -based Real -time
location tracking a nd messaging system: A child -care case study , published in ACM
International Conference on Ubiquitous Information Management and Communication,
ACM IMCOM, ISBN: 978 -1-4503 -3377 -1, January 2015
[13] Inside the different Android Versions, http://www.androidcentral.com/android -versions

86
[14] Moonsamy V., Batten L., Shore M., Can Smartphone Users Turn Off Tracking
Service Settings? , published in Proceedings of International Conference on Advances in
Mobile Com puting & Multimedia, ISBN: 978 -1-4503 -2106 -8, December 2013
[15] Observer Design Pattern in Java, http://www.journaldev.com/1739/observer -design –
pattern -in-java-examp le-tutorial
[16] Use Android’s ContentObserver in Your Code to Listen to Data Changes – Wolfram
Rittmeyer, http://www.grokkingandroid.com/use -contentobserver -to-listen -to-changes/
[17] www.developer.android.com
[18] www.opensourceforu.com
[19] www.stackoverflow.com
[20] www.techopedia.com
[21] www.w3schools.com
[22] www.wikipedia.com
[23] Zhang F., Huang H., Zhu S., Wu D., Liu P. , ViewDroid: Towards Obfuscation –
Resilient Mobile Application Repackaging Detection , published in Proceedings of the
2014 ACM conference on Security and priva cy in wireless & mobile networks, July 2014