Tema 2 - Caracterizarea resurselor intr-un sistem Android

Tema 2 - Caracterizarea resurselor intr-un sistem Android

Scopul temei este sa urmareasca utilizarea resurselor pe un dispozitiv mobil Android (telefon sau tableta) pe parcursul a trei scenarii:

Scenariul de baza (idle)
Scenariul network intensive (mail, calendar etc.)
Scenariul computational + network intensive (un joc multiplayer)

Nota: Pentru scenariile 2 si 3 trebuie sa aveti o conexiune la internet. Recomandam o conexiune WiFi cel putin pentru setup-ul scenariului 3. Mai multe detalii mai jos.

Se vor colecta date precum:

a) Informatii despre device:
- model device (e.g. Samsung GT-55660),
- versiune Android (e.g. 2.3.3),
- total RAM in kB (e.g. 286084),
- free RAM in kB (e.g. 19640),
- total disk space in MB (e.g. 181),
- free disk space in MB (e.g. 42.82),
- CPU (e.g. ARMv6-compatible),
- nivel baterie in % (e.g. 68)
b) Informatii despre aplicatii:
- pachet (e.g. com.polarbit.rthunder2lite),
- uid (e.g. 40565488)
c) Informatii despre resurse per aplicatie:
- total CPU time in ms (e.g. 8320),
- estimate energy for CPU in mJ (e.g. 664),
- GPS time in ms (e.g. 15120),
- estimate energy for GPS in mJ (e.g. 3210),
- number of bytes sent through wireless (e.g. 300),
- number of bytes received through wireless (e.g. 2400),
- estimate energy for wireless in mJ (e.g. 5500)

Cerinte:

(50p) colectarea de date
(25p) afișarea datelor pe ecran
(25p) statistici si comentarii
(Bonus 15p) orice alte date, in afara de cele mentionate la punctele a,b si c de mai sus, colectate sau derivate cu privire la resursele consumate de aplicatii

Nota: Tema trebuie insotita de un fisier readme care sa prezinte comentariile voastre cu privire la fiecare din punctele de mai sus. Punctajul pentru acest fisier readme este astfel inclus in punctajele mentionate, iar absenta sa atrage scaderea de punctaje din toate cerintele temei.

Colectarea datelor

Android permite citirea de informatii cu privire la aplicatii si la resurse prin internal API (pachetul com.android.internal) si hidden API (marcate cu @hide in codul sursa Android). Metodele cuprinse in aceste APIs nu sunt in mod normal accesibile din SDK din diferite motive ale creatorilor Android, precum acela ca nu pot sa garanteze backwards compatibility pentru ele in viitoarele versiuni de API. Metodele de care aveti nevoie pentru aceasta tema au fost insa testate pe Android 2.2, 2.3 si 4.0, pe diferite dispozitive.

Din cauza ca aceste metode nu sunt accesibile din SDK, pentru a rezolva tema va trebui astfel sa apelati la un artificiu de programare, denumit Java Reflection[2]. Studiati modalitatea in care sunt folosite clasa Class si metodele getMethod si invoke intr-o aplicatie open source cu o functionalitate similara cu cea pe care trebuie sa o implementati voi[3]. Nu uitati sa adaugati permisiunile necesare pentru a accesa aceste informatii in AndroidManifest.xml: BATTERY_STATS, GET_TASKS, ACCESS_FINE_LOCATION, WAKE_LOCK, ACCESS_COARSE_LOCATION, CONTROL_LOCATION_UPDATES, ACCESS_LOCATION_EXTRA_COMMANDS.

Exista si alte metode de a folosi internal si hidden APIs[4], insa consideram ca nu sunt avatanjoase pentru cerinta acestei teme, iar Java Reflection este suficient.

O data ce ati inteles mecanismul prin care se apeleaza metodele, studiati aplicatia [3] si API-ul pentru a identifica ce metode puteti folosi pentru a colecta informatii de interes. Recomandam urmatoarele clase:

Informatii cu privire la starea sistemului se pot obtine si din shell prin adb, folosind dumpsys[5] sau, daca aveti telefonul rootat, folosind perf-record[5b]. De asemenea, pe Android se pot consulta o mare parte din fisierele de sistem caracteristice pentru Linux, cum ar fi cele din /proc si cele din /sys. Spre exemplu, pentru a citi cantitatea de date transmisa prin WiFi, puteti folosi exemplul de la [6]. In general, pentru a rula comenzi de shell programatic (din aplicatie) puteti folosi metoda de la [7].

Aceasta parte reprezinta partea de studiu individual a temei. Aveti aici suficiente materiale pentru a intelege despre ce este vorba. Va incurajam sa schimbati pareri cu privire la aceste metode pe forumul dedicat temei.

Metodologie

Observati ca resursele din cerinta sunt in principiu de doua tipuri: resurse statice (raman neschimbate pe timpul scenariilor, e.g. versiunea de Android) si resurse dinamice (se schimba pe parcursul scenariilor, e.g. cantitatea de date transmise prin WiFi). Puteti organiza programul pe care il realizati cum doriti, insa retineti ca resursele statice este suficient sa le cititi o singura data, in timp ce resursele dinamice trebuie citite la intervale regulate de timp. In general cu cat acest sampling se face mai des, cu atat avem o imagine mai buna, insa consumam mai multa energie. Pentru scopul nostru, vom face citiri la 1 min. Consideram ca toate scenariile dureaza 15 minute, adunand astfel cate 15 masuratori pentru fiecare rulare a unui scenariu.

Descrierea scenariilor:

Scenariul de baza (setup: inchideti toate aplicatiile deschise)
- in acest scenariu este suficient sa lasati telefonul idle timp de 15 min, fara nicio actiune (nici nu este nevoie sa inchideti ecranul, lasati-l sa se inchida singur la intervalul setat de voi)
Scenariul network intensive (setup: inchideti toate aplicatiile deschise)
- deschideti aplicatia de mail
- cititi un mesaj primit in urma cu o saptamana
- trimiteti un mesaj nou
- deschideti aplicatia calendar
- adaugati un eveniment nou
- stergeti evenimentul pe care tocmai l-ati adaugat
- deschideti un browser
- accesati cs.curs.pub.ro
- deschideti aplicatia youtube
- urmariti un videoclip
- daca a mai ramas timp din cele 15 minute, lasati telefonul idle, cu aplicatiile de mai sus pornite, pana expira timpul
Scenariul computational + network intensive (setup: instalati si jucati cel putin o data, in mod multiplayer, unul din jocurile de la [8] sau [9], la alegere, apoi inchideti toate aplicatiile deschise)
- jucati-va in mod multiplayer unul din cele doua jocuri (la alegere) timp de 15 minute

Masuratorile pentru fiecare scenariu trebuie repetate de cel putin 4 ori, pentru a observa daca exista alte cauze care influenteaza parametrii masurati. Este important ca la scenariul b sa urmati aceeasi pasi de fiecare data, iar la scenariul c sa va jucati acelasi joc de fiecare data.

Statistici si comentarii

Oferiti statistici sub forma de tabele si grafice (resursa vs timp) cu privire la aplicatia care consuma cel mai mult din resursele sistemului pentru fiecare scenariu in parte. Daca aveti instalata o aplicatie de tune-up, puteti compara rezultatele obtinute de voi cu cele raportate de aceasta (asa ceva poate sa conteze pentru bonus).

Faceti comentarii cu privire la modalitati de a asigura o citire cat mai apropiata de realitate. Identificati posibile cauze care pot sa aduca erori in datele masurate / calculate de voi.