Uno Studio Empirico sui Consumi Energetici in Ambiente Android

TESI IN SICUREZZA - LUGLIO 2013

1

Uno Studio Empirico sui Consumi Energetici in
Ambiente Android e Possibili Attacchi di
Sicurezza
Giuseppe De Rosa, Marco Fazzone, Sabato Napolitano, Michele Tufano
`
Universita degli Studi di Salerno, 84084 Fisciano (SA), Italia
{g.derosa30, m.fazzone, s.napolitano16, m.tufano10}@studenti.unisa.it
Sommario—Viene presentato uno studio di analisi dei consumi energetici su dispositivi mobili Android. Sono stati
misurati i consumi energetici delle varie tecnologie web messe a disposizione da HTML5 e Javascript. I risultati di
tali misurazioni sono stati ottenuti attraverso dei test eseguiti con l’ausilio della suite di Energy-Testing BatteryBench
realizzata a tale scopo. I test hanno evidenziato quali tecnologie risultano essere maggiormente dispendiose in termini
`
di consumo energetico. Quest’ultime sono state utilizzate per analizzare la possibilita di attuare un attacco di Denial of
Service energetico altres` chiamato Battery Drain.
ı
Index Terms—Android, Sicurezza, Consumi, Energia, Batteria, Test, Web, HTML5, Codec.

!

1

I NTRODUZIONE

O

GNI giorno 1,3 milioni di nuovi dispositivi
Android, tra tablet e smartphone, vengono attivati. La base di installazioni conta 480
milioni di dispositivi nel mondo.
International Data Corporation (IDC) stima che
il solo mercato dei tablet superer` quello dei PC
a
nel 2015 [1], mentre se si considera l’intero mercato mobile (smartphone + tablet) il sorpasso a
` a
discapito dei PC e gi` avvenuto.
`
L’utenza si sta spostando sempre piu sul
mobile, e con esso, di conseguenza, anche
quell’insieme di operazioni che ﬁnora erano
esclusivamente ad appannaggio dei computer.
`
Oggigiorno i sempre piu evoluti dispositivi
mobile gestiscono una miriade di informazioni
personali ed attivit` , rappresentando per molte
a
persone strumenti indispensabili nel quotidiano. Browsing internet, social networking, com• Prof. Alfredo De Santis
E-mail: ads@dia.unisa.it
• Dr. Aniello Castiglione
E-mail: castiglione@acm.org
• Prof. Ugo Fiore
E-mail: uﬁore@dia.unisa.it
Esame di Sicurezza, Corso di Laurea in Informatica

munication e gaming, tra le principali attivit`
a
svolte con essi.
Lo sviluppo hardware di questi dispositivi
mostra una crescita esponenziale, supportata
dall’ampio bacino d’utenza e da una forte
concorrenza tra le case costruttrici.
Ogni anno processori, memorie, display e
`
altre componenti diventano sempre piu veloci,
migliori ed economiche, perlomeno per chi le
produce. Vengono offerte maggiore capacit` ,
a
pixel del display e potenza computazionale.
La legge di Moore1 a proposito resta ancora
valida e la tecnologia dietro gli smartphone
`
cresce esponenzialmente. Attualmente piu che
`
mai questi ultimi hanno processori piu veloci,
`
memorie di massa piu economiche, maggiore
RAM e display di alta qualit` . La stessa difa
ferenza tra uno smartphone attuale e uno di
`
qualche anno fa e enorme.
La tecnologia costruttiva delle batterie tuttavia non ha subito lo stesso miglioramento.
`
Se da un lato si puo affermare che il processo evolutivo non sia completamente fermo, lo
1. ”Le prestazioni dei processori, e il numero di transistor ad esso
relativo, raddoppiano ogni 18 mesi.”[2]


`
stesso procede pero molto lentamente. Il diva`
rio e palese se paragonato a quello rapido ed
esponenziale che accompagna le restanti componenti, che nel tempo tendono a incrementare
le loro prestazioni e a miniaturizzarsi. Rispetto
a queste ultime la batteria occupa ancora gran
parte della struttura di un telefono.
`
Tale fenomeno e dovuto a diversi fattori.
Innanzitutto lo sviluppo delle batterie sem`
bra realmente procedere piu lentamente rispetto alle altre componenti. Basti pensare che la
tecnologia su cui si basano le batterie per dispo`
sitivi mobili e, da diversi anni, ancora quella
agli ioni di litio, con lievi miglioramenti.
`
In secondo luogo, la tendenza odierna e quel`
la di fornire dispositivi sempre piu sottili e
leggeri. Piuttosto che sfruttare i vantaggi che
si avrebbero mantenendo le stesse dimensioni,
con una maggiore autonomia, i produttori di
`
smartphone forniscono batterie sempre piu sottili in modo da poter ridurre le dimensioni dei
loro terminali.
Infine, un ruolo influente lo giocano anche
`
i software che necessitano di sempre piu potenza, insieme a notifiche push e servizi in
background sempre attivi.
In questo contesto diviene di fondamentale importanza una gestione oculata dell’energia. La batteria diviene quindi il punto debole dell’infrastruttura dei dispositivi mobili e,
pertanto, forte candidato passibile di attacco.
In questo lavoro si indaga su possibili attacchi indotti al fine di ottenere un consumo
energetico anomalo della batteria di dispositivi
mobili Android.
`
La scelta di questa piattaforma e dovuta al
miglior trend di espansione rispetto agli altri
S.O. mobile e alla maggior facilit` di misuraa
zione e analisi grazie alle API native e al codice
aperto del sistema Android.
`
Il lavoro svolto e stato articolato in diverse
`
fasi. Si e partiti da un prima fase di spe`
rimentazione nella quale e stato osservato il
consumo energetico dei codec audio/video te`
stati singolarmente in ambiente controllato. Piu
precisamente i test eseguiti hanno riguardato
la riproduzione di file video e audio di durata
`
variabile. Dall’analisi dei risultati e emerso che
`
i codec piu dispendiosi in termini energetici sono H264 per i file video e Wave per i file audio.

2

Tali codec sono stati utilizzati nell’ultima fase
`
della sperimentazione in cui e stata realizzata
una pagina web malevola con l’impiego delle
`
piu recenti tecnologie web messe a disposizione da HTML5, Ajax e Javascript. Confrontando
il consumo energetico della pagina realizzata
con i normali siti web di comune utilizzo si
`
e riuscito ad ottenere un consumo energetico
pari ad 11 volte il consumo delle stesse pagine
in HTML.
Di seguito vengono illustrati i capitoli attraverso i quali si articoler` questo documento: Il
a
capitolo 2 illustra lo stato dell’arte nell’ambito
in cui il nostro lavoro si vuole inserire. Nel
capitolo 3 viene introdotto l’attacco di sicurezza realizzato. Il capitolo 4 descrive la sperimentazione effettuata in termini di misurazioni energetiche e realizzazione dell’attacco di
sicurezza.

2

S TATO DELL’A RTE

In letteratura, molti articoli scientifici trattano
dei consumi energetici in ambiente Android.
La maggior parte di essi si focalizzano sulla
misurazione dei consumi dei singoli moduli hardware che formano l’infrastruttura degli
smartphone. Il lavoro ”An Analysis of Power
Consumption in a smartphone”[3] offre un’analisi
approfondita dell’utilizzo energetico delle varie
componenti hardware. In questo studio vengono mostrati i risultati di misurazioni fisiche effettuate tramite sensori di resistori posizionati
sui circuiti degli smartphone.
`
Un altro lavoro importante e rappresentato da: ”Accurate Online Power Estimation and
Automatic Battery Behavior Based Power Model
Generation for smartphones” [4]. Quest’ultimo si
differenzia dal precedente per la metodologia
di misurazione che, in questo caso, avviene
anche via software e non solo in maniera fisica.
In questo lavoro viene descritto PowerTutor:
un tool che offre la stima in tempo reale del
consumo energetico dei vari componenti hardware del dispositivo Android. Questa stima
viene fatta sulla base di un modello di scarica
ottenuto come descritto nel capitolo 7 di [4].
`
Il modello di scarica e una funzione che, in
base al livello attuale di carica della batteria e i


livelli di utilizzo dei singoli componenti hardware del dispositivo (ottenuti attraverso API
Android), restituisce una stima del consumo
energetico in tempo reale.
Tale modello viene generato con la tecnica
PowerBooter che prevede i seguenti passi:
1) Ottenere la curva di scarica della batteria
(Figura 1). Il voltaggio della batteria viene
registrato nel tempo fino all’esaurimento
di essa.
2) Determinare il consumo di ogni componente
hardware nei vari stati di utilizzo (es. idle,
low, high). Variando lo stato di utilizzo
di un componente (lasciando gli altri invariati) viene registrata a distanza di un
minuto, per quindici minuti, il voltaggio
della batteria.
3) Si effettua una regressione per derivare il modello di scarica. Tramite il dataset ottenuto,
utilizzando la tecnica di bootstrap [10],
viene generato il modello di scarica.
`
Il modello cos` ottenuto e stato validato conı
frontando i dati misurati fisicamente attraverso
un power meter con quelli stimati utilizzando
il modello precedentemente generato (come
descritto nel capitolo 6 di [4]).

3

total) e un tipo di rilevazione (current
power, average power, energy usage). Ogni
volta che il profiling viene disattivato, tutti
dati vengono resettati. In questo modo le
sessioni di profiling restano indipendenti. In
dettaglio, tramite l’utilizzo delle API standard
di
Android
(android.media.AudioManager,
android.net.wifi.WifiManager,
android.hardware.SensorManager,
etc.)
viene
monitorato lo stato dei singoli moduli
hardware. Coi dati rilevati viene stimato
il consumo energetico dei componenti
attraverso interpolazione sulla base del
modello precedentemente generato.

Figura 1: Curva di scarica della batteria rappresentata in
un grafico Voltaggio/stato di scarica.

PowerTutor offre un servizio di profiling
energetico (Figure 2, 3 e 4), mostrando le
informazioni dei consumi della batteria, sia
per i singoli moduli presenti nello smartphone,
sia per le singole applicazioni in esecuzione
sul dispositivo. E’ possibile diversificare
il tipo di profiling settando un intervallo
di tempo (last minute, last hour, last day,

Figura 2: Schermata del profiling di PowerTutor. Questa
schermata mostra i grafici dei consumi per ogni singolo
componente.

`
E doveroso segnalare, inoltre, il lavoro di
Battery Exhaustion Attack Detection with Small


Figura 3: Schermata del profiling di PowerTutor. Questa
schermata mostra il consumo energetico totale per ogni
`
singola applicazione ed e stata ottenuta settando l’intervallo di tempo a total e il tipo di rilevazione a energy
usage.

Handheld Mobile Computers [8] in cui, attraverso
algoritmi e moduli di comunicazione Wi-Fi e
Bluetooth, si realizzano Battery Drain Attacks,
ovvero attacchi di sicurezza che mirino ad ottenere un denial of service attraverso l’esaurimento
delle risorse energetiche dei dispositivi mobili.
Infine, per l’analisi dei codec audio/video,
in Video network traffic and quality comparison of
VP8 and H.264 SVC [7] viene fatto uno studio
di confronto sulla qualit` , data rate e la velocit`
a
a
di encoding.
In questo articolo, viene condotto un lavoro
di analisi del consumo energetico dei codec
multimediali che, a differenza di quanto fatto

4

Figura 4: Schermata del profiling di PowerTutor. Per
una singola applicazione vengono mostrati i consumi
energetici dei componenti hardware utilizzati.

nel lavoro di Seeling[7], si concentra sui consumi energetici dei codec anzich´ sui fattori di
e
data rate, qualit` etc. Prendendo spunto dal
a
lavoro di Buennemeyer[8], anche nel nostro
studio viene interpretato il consumo di batteria
come una possibile vulnerabilit` per i sistemi
a
mobili, ma, allo stesso tempo ci distinguiamo
da esso perch´ utilizziamo i codec supportati
e
da Android ed HTML5, per eseguire l’attacco
di Battery Drain.

3

ATTACCO DI SICUREZZA

L’attacco di sicurezza progettato, si basa sull’idea di sfruttare al massimo il consumo energetico dei codec audio/video analizzati, uti`
lizzando quelli che sono risultati piu energy


inefficient, al fine di ottenere un Battery Drain.
Inoltre, in combinazione all’utilizzo dei contenuti multimediali, abbiamo previsto l’utilizzo
di funzionalit` che mirassero a sfruttare a pieno
a
tutte le risorse disponibili, includendo funzioni
di: lettura/scrittura di file in memoria, chiamate AJAX e caricamento di font non presenti nel
dispositivo.
`
La tipologia di attacco e stata scelta pensando all’utilizzo da parte dell’utente medio di un
dispositivo mobile escludendo, quindi, l’idea
di poter installare sui dispositivi applicazioni
di terze parti e puntando ad eseguire l’attacco
attraverso una pagina web.
La scelta di utilizzare il web per condurre
`
l’attacco di Battery Drain e stata presa in base
`
alla semplicit` con cui l’utente puo accedervi,
a
considerando la possibilit` di poter navigare
a
senza l’installazione di alcun software aggiuntivo. Durante la progettazione dell’attacco, ci
siamo posti il vincolo che l’utente non debba
`
accorgersi che l’attacco e in corso. Questa scelta
ha implicato diverse difficolt` nella realizzazioa
ne e nelle scelte implementative del sito web
malevolo, attraverso il quale condurre l’attacco.
`
L’attacco e stato realizzato utilizzando strumenti relativi alle tecnologie di sviluppo
HTML5, Javascript, AJAX e php, le quali vengono utilizzate al fine di realizzare uno script
malevolo, inserito in quella che all’utente appare come una normale pagina web, che esegue
tutte le funzionalit` piu costose in termini enera `
getici e di computazione, senza dare all’utente
la possibilit` di distinguere la nostra pagina da
a
un’altra priva di codice malevolo.

4

S PERIMENTAZIONE

`
L’attacco e stato pianificato sulla base dei
risultati ottenuti in fase di sperimentazione,
nella quale abbiamo osservato il consumo
energetico dei vari codec audio/video, testati
singolarmente in ambiente controllato.
`
La sperimentazione, dunque, si e svolta in
`
3 step principali: inizialmente e stato preparato un ambiente di test controllato in modo
da automatizzare il testing dei consumi energetici, successivamente sono stati eseguiti tali
test sui diversi codec multimediali compatibili con HTML5, infine, dall’analisi dei risultati
`
precedenti e stato creato il sito malevolo.

5

4.1

Creazione ambiente di test

Il successo del nostro studio si basava sull’ottenere misurazioni affidabili dei consumi energetici in modo da poter effettuare le migliori
scelte per l’attacco di sicurezza. A tal fine si
`
e reso necessario creare un ambiente di test
controllato che automatizzasse il testing dei
consumi in modo che i risultati non fossero,
quindi, influenzati da errori e rumore umano.
Abbiamo creato BatteryBench, applicazione
Android che effettua benchmark energetici e
automatizza le seguenti tipologie di test:
•
•
•

Video
Audio
Stress

`
L’applicazione e divisa in 3 omonime sezioni,
in cui ognuna predispone la scelta dei possibili
test da effettuare per la categoria scelta. Nella
`
sezione Video (Figura 6) e possibile effettuare i
test energetici sulla riproduzione dei contenuti
`
video e dei relativi codec. Si puo selezionare il
codec da testare, la durata del test in minuti,
e l’opzione che abilita/disabilita l’audio del
video. In modo analogo per quanto riguarda
la sezione Audio (Figura 5), dedicata ai test
sui consumi della riproduzione di file audio,
`
e possibile scegliere il codec e la durata in
minuti del test. Infine la sezione Stress (Fi`
gura 7) e dedicata al testing di una serie di
script malevoli. Tale sezione viene definita in
questo modo poich´ gli script in questione
e
tentano di esaurire le risorse energetiche del
dispositivo mobile stressandone il consumo. Di
seguito vengono riportati gli script di stress
(che verranno dettagliati nella sezione 4.4):
•

•

•

•

HTML5 Web Storage: ripetute scritture/cancellazioni di file in local storage.
Ajax Stress Calls: continue richieste al web
con lo scopo di mantenere attivo il modulo
Wi-Fi.
Fonts Stress Calls: ricerca di fonts unsafe
che mirano al consumo della CPU.
Hidden Muted Video: esecuzione in background di file video senza che l’utente ne
sia consapevole.


6

scarica della batteria (e quindi non costruito adhoc) migliorato attraverso i log anonimi inviati
dagli utenti di PowerTutor che utilizzano lo stes•
so dispositivo. Questo ovviamente comporta
degli errori di stima del consumo energetico.
Tuttavia, data la natura comparativa dei test
della nostra sperimentazione, non era impor`
E possibile selezionare attraverso apposite tante conoscere precisamente il consumo enerı
checkbox le opzioni da attivare e la durata del getico in termini di joule bens` capire quali
`
codec e tecnologie fossero piu dispendiosi.
test in minuti. In dettaglio, attraverso questa
`
sezione e possibile creare uno stress test persoInfine, la licenza libera di PowerTutor, a difnalizzato in base all’esigenze dell’utente e dei ferenza della maggior parte delle altre applidati da raccogliere abilitando o disabilitando cazioni di profiling disponibili closed source,
una determinata opzione.
ci ha permesso di automatizzare la fase di
All’avvio del test di Stress, l’applicazione testing abilitando/disabilitando via codice il
comunica tramite una richiesta http al server le profiling. Tale automazione non sarebbe stata
opzioni di stress selezionate. Il server include possibile con applicazioni esterne closed sournella pagina web solo gli script php e javascript ce, in quanto avrebbero necessitato di un input
relativi alle opzioni selezionate dall’utente, in dell’utente, il quale avrebbe inevitabilmente
questo modo la pagina web visualizzata dal compromesso le misurazioni (es. precisione in
client conterr` e caricher` esclusivamente le termini di tempo; pressione di tasti a schermo
a
a
opzioni di stress desiderate.
che comportano consumo).
I risultati dei consumi energetici vengono
misurati da PowerTutor, il cui codice con licenza
Con riferimento alla figura 8 illustriamo i
`
libera e stato inglobato all’interno della no- relativi passi di esecuzione del programma
stra applicazione. All’interno di quest’ultima, il BatteryBench:
codice di PowerTutor viene richiamato quando
1) Vengono settati i parametri del test
necessario, come se fosse una semplice routine.
(tipologia di testing, tempo, codec etc.);
2) Viene lanciato il test attraverso l’apposito
Nonostante siano disponibili molteplici aptasto;
plicazioni per Android che offrono servizi di
3) Viene avviato il profiling di PowerTutor
misurazione dei consumi energetici (quali Batsettando l’intervallo di tempo a total e
`
teryDoctor o DU Battery Saver), si e scelto di
il tipo di rilevazione a energy usage in
utilizzare PowerTutor poich´ e risultato l’unico,
e `
modo da misurare il consumo energetico
tra quelli trovati, che, oltre a fornire valutaziodella sola applicazione browser che verr`
a
ni dei consumi energetici dettagliati per ogni
lanciata successivamente;
componente hardware del dispositivo e per
4) Viene avviato il browser predefinito di
ogni applicazione in esecuzione, sia stata anche
sistema con la pagina web relativa al test
comprovata la sua affidabilit` nelle misurazioni
a
selezionato;
attraverso rilevazioni fisiche con strumentazio5) Allo scadere del tempo definito al passo
ni adeguate (”Accurate Online Power Estima1, il browser viene chiuso.
tion and Automatic Battery Behavior Based Power
6) Viene interrotto il servizio di profiling di
Model Generation for smartphones” [4]).
PowerTutor
7) Viene mostrata una nuova finestra in cui
Nello studio sopracitato vengono validate
si possono osservare i risultati del test.
le misurazioni solo per alcuni device mobili
`
`
Android, tra i quali pero non compare lo smartE da sottolineare che l’avvio del profiling
phone utilizzato nella nostra sperimentazione. precedentemente l’apertura del browser non
PowerTutor installato sul nostro device (HTC comporta errori di stima in quanto PowerTuIncredible S) utilizza un modello generico di tor, configurato appositamente per il browser,
•

Hidden Muted Audio: esecuzione in background di file audio senza che l’utente ne
sia consapevole.
Hidden Infrasound Audio: esecuzione di
file audio ad infrasuoni, non percepibili
all’orecchio umano.


Figura 5: Schermata di Battery Bench per il testing dei
codec audio.

inizier` a misurare da quando il processo del
a
browser sar` attivo.
a

7

Figura 6: Schermata di Battery Bench per il testing dei
codec video.

•
•

H.264
WebM
Theora (non supportato [5])

•
La pagina dei risultati (Figura 4) mostra il
consumo del browser rispetto ai singoli moduli presenti nello smartphone. Tali risultati HTML5 Audio
possono essere memorizzati in un ﬁle di log.
• Ogg Vorbis
• WAV PCM
4.2 Analisi e monitoraggio dei consumi
• MP3
`
In questa fase, e stato monitorato il consumo di
• AAC
tutti i codec multimediali previsti dallo stan• WebM Vorbis
dard HTML5 che fossero, allo stesso tempo,
• Ogg Opus
supportati dal browser stock di Android:
Di conseguenza, i nostri test non comprenHTML5 Video
dono il codec Theora.


8

Figura 7: Schermata di Battery Bench con le varie
opzioni per il lancio dello stress-test.

4.2.1

Metodologia di Test

I test sono stati eseguiti su uno smartphone
Android a nostra disposizione, in particolare
HTC Incredible S con Android 2.3, processore
Qualcomm Snapdragon 1024MHz, Display 4’
TFT 480*800 pixel.
La durata dei singoli test segue questi step
incrementali:
•
•
•

5 min
15 min
30 min

Il dispositivo viene riavviato ad ogni step e
la cache del sistema svuotata per avere, ad ogni
test, lo stesso ambiente di partenza.

Figura 8: Schema del funzionamento di Battery Bench.


`
Siccome il consumo della batteria non e uniforme, ma dipende dallo stato di scarica in cui
essa si trova [4], tutti i test sono stati eseguiti
partendo dallo stato di carica completa della
batteria del dispositivo.
I test sono stati eseguiti con l’ausilio di
BatteryBench.
4.2.2 Test eseguiti
I test eseguiti riguardano la riproduzione di
files video (con o senza traccia audio) e di files
audio di durata variabile (5, 15 e 30 minuti).
Precisamente ogni test consiste nella visita di
una pagina web contenente una traccia video
o audio codificata con uno dei codec elencati
precedentemente.
I test riguardanti i video contenenti traccia audio avranno le seguenti combinazioni di
codec audio/video e formato:
• mp4: H.264/MPEG4 (AAC LC)
• WebM: VP8/Vorbis
Di seguito vengono elencati i test eseguiti:
HTML5 Video con traccia audio
• mp4: H.264/MPEG4 (AAC LC)
HTML5 Video con traccia audio muta
• mp4: H.264/MPEG4
HTML5 Audio
• Ogg Vorbis
• WAV PCM
• MP3
• AAC
• WebM Vorbis
Nella Tabella 21 vengono mostrati i test
video eseguiti con le varie combinazioni di
tempo, volume e codec.
Analogamente, nella Tabella 2 vengono mostrati i test audio eseguiti per i diversi codec e
step di tempo.
4.2.3 Risultati
Di seguito vengono riportati i grafici dei
risultati dei test sui codec audio per gli step da
5, 15, 30 minuti (rispettivamente Figure 15, 16 e
17) e sui codec video per gli stessi step di tempo

9

TestID
1
2
3
4
5
6
7
8
9
10
11
12

Codec
H264
H264
H264
H264
H264
H264
WebM
WebM
WebM
WebM
WebM
WebM

Volume
Max
Max
Max
Min
Min
Min
Max
Max
Max
Min
Min
Min

Time
30 Minutes
15 Minutes
5 Minutes
30 Minutes
15 Minutes
5 Minutes
30 Minutes
15 Minutes
5 Minutes
30 Minutes
15 Minutes
5 Minutes

Tabella 1: Test Video
TestID
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Codec
MP3
MP3
MP3
Wave
Wave
Wave
Opus
Opus
Opus
Vorbis
Vorbis
Vorbis
AAC
AAC
AAC
WebM
WebM
WebM

Time
30 Minutes
15 Minutes
5 Minutes
30 Minutes
15 Minutes
5 Minutes
30 Minutes
15 Minutes
5 Minutes
30 Minutes
15 Minutes
5 Minutes
30 Minutes
15 Minutes
5 Minutes
30 Minutes
15 Minutes
5 Minutes

Tabella 2: Test Audio

previsti da 5, 15, 30 minuti (rispettivamente
Figure 19, 20 e 21). Sono stati, inoltre, ricavati
i relativi diagrammi di Pareto (Figure 18 e
22) in modo da ottenere un’informazione
`
quanto piu dettagliata possibile circa
la percentuale di consumo energetico
prodotto da ciascun modulo hardware.
`
Video: Durante la sperimentazione e emerso
un consumo costantemente in crescita del
codec H264 nei singoli step da 5, 15, 30
minuti. Il gap energetico tra H264 ed il codec
di comparazione WebM rimane costante per
ogni step, aumentando in maniera funzionale
rispetto al tempo di test.
Inoltre, il trend energetico descritto in prece`
denza, e stato registrato anche per i test effettuati sui medesimi codec e tempi, con traccia
audio muta, in particolare, si osserva come il


volume dell’audio influisca in minima parte
nel consumo energetico del modulo audio, cos`
ı
come riportato anche nello studio [4].
`
`
Dai test e risultato che il modulo piu dispen`
dioso in termini energetici e quello LCD, che
singolarmente costituisce il 53% del consumo
totale. La somma dei moduli LCD, Audio,
CPU risulta essere il 92% dell’intero dispendio
energetico prodotto, lasciando al modulo Wi-Fi
il dispendio minore con il solo 8%.
Audio: Per quanto riguarda i test eseguiti sui
`
codec audio, non e emersa una situazione del
tutto definita, poich´ i consumi energetici di
e
alcuni codec sono risultati piuttosto variabili
`
nei singoli step da 5, 15, 30 minuti. Tuttavia si e
notato un consumo medio maggiore del codec
Wave, soprattutto nei tempi brevi, come risulta
dai relativi grafici riportati in appendice A.
Analizzando il consumo medio dei singoli
moduli abbiamo notato che la componente Audio insieme al modulo CPU costituiscono l’80%
circa del consumo energetico totale, mentre
il modulo Wi-Fi assorbe il 20% dell’energia
utilizzata per compiere la riproduzione audio.
`
Per i test audio non e stato preso in considerazione il modulo LCD, non essendo ovviamente
rilevante nel confronto.
4.2.4 Overhead comunicazione con il Server
Al termine di questa prima fase di test, abbiamo cercato di quantificare l’impatto della comunicazione con il server in termini di
consumo energetico. L’obiettivo era quello di
confrontare i diversi codec multimediali senza
l’overhead della comunicazione e scambio dati
tra il client e il server. In altre parole, si voleva
scoprire se un codec intrinsecamente energy efficient in termini di riproduzione e codifica, veniva penalizzato nei test energetici a causa della
dimensione del file e quindi del trasferimento
dati. Ovviamente una semplice esclusione del
consumo del modulo Wi-Fi non rappresenta, a
nostro parere, una strategia affidabile in termini
assoluti.
La strategia che volevamo adottare era quella
di trasferire un file multimediale di piccole dimensioni e ripeterlo in loop per l’intera durata
del test.
`
Non e stato tuttavia possibile portare avanti
tale tecnica, date le politiche di risparmio ener-

10

getico adottate dal browser stock di Android.
Quest’ultimo ignora la funzionalit` associata al
a
tag loop [9] previsto dallo standard HTML5,
che permette la riproduzione in loop di un
contenuto multimediale.
Per aggirare il problema abbiamo provato
ad utilizzare le funzionalit` di Javascript per
a
simulare un loop. Nello specifico abbiamo provato a richiamare la funzione play sull’elemento
multimediale ogni volta che la riproduzione
`
terminava. Tale tecnica e stata dapprima testata
su un browser per PC, con esito positivo, ma
`
lo stesso non si e riscontrato sul browser stock
di Android.
In conclusione, non abbiamo potuto annullare l’overhead di comunicazione come pianificato, ma abbiamo dovuto cercare un modo
alternativo per avere un termine di paragone
nei consumi dei contenuti audio/video.
Per eseguire i test sui contenuti multimediali
annullando l’overhead della comunicazione in
rete abbiamo effettuato le stesse misurazioni
eseguite precedentemente, ma questa volta utilizzando il player multimediale di Android per
riprodurre gli audio/video.

4.3

Testing locale

Come descritto in precedenza, volevamo
avere dei termini di confronto sui consumi
energetici dei codec multimediali annullando
il consumo e l’overhead del modulo Wi-Fi,
che influisce pesantemente sui consumi per il
trasferimento di file molto grandi e poco adatti
allo streaming (es. Wave). Visto il fallimento
di tutti gli altri tentativi di riprodurre i
file multimediali all’interno del browser, in
ambiente locale, abbiamo provato ad effettuare
le nostre misurazioni utilizzando il player
multimediale stock di Android per riprodurre
i suddetti file.


TestID
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Type
Video
Video
Video
Video
Video
Video
Audio
Audio
Audio
Audio
Audio
Audio
Audio
Audio
Audio
Audio
Audio
Audio
Audio
Audio
Audio

Codec
H264
H264
H264
WebM
Wave
Wave
MP3
MP3
MP3
Wave
Wave
Wave
Vorbis
Vorbis
Vorbis
AAC
AAC
AAC
WebM
WebM
WebM

11

Time
5 Minutes
15 Minutes
30 Minutes
5 Minutes
15 Minutes
30 Minutes
5 Minutes
15 Minutes
30 Minutes
5 Minutes
15 Minutes
30 Minutes
5 Minutes
15 Minutes
30 Minutes
5 Minutes
15 Minutes
30 Minutes
5 Minutes
15 Minutes
30 Minutes

Tabella 3: Test eseguiti utilizzando il riproduttore multimediale stock di Android. I diversi file sono stati
precedentemente memorizzati in memoria locale per
annullare l’overhead di comunicazione su rete.

La metodologia applicata per il testing in
`
locale e stata del tutto simile a quella utilizzata
per il testing su rete precedentemente descritto.
In particolare, abbiamo testato i file codificati
con i codec ritenuti meno efficienti in termini
energetici nella precedente fase di testing, ovvero: Wave per i contenuti audio e H264 per
quelli video. I file sono stati memorizzati sul
supporto di memorizzazione di massa dello
stesso dispositivo mobile utilizzato per le altre
`
fasi di testing. L’apparecchio e stato riavviato
ad ogni iterazione del testing (5min, 15min,
30min) quest’ultimo effettuato sempre con batteria completamente carica. La pianificazione
`
dei test locali e stata riportata in Tabella 3,
in cui sono descritte le diverse iterazioni del
testing. Com’` possibile notare dalla Tabella
e
`
3, il codec audio Opus non e presente, dal
momento che i riproduttori multimediali di
Android non supportano il sudetto codec come
riportato nella guida ufficiale per gli svilup`
patori [6], quindi non e stato possibile fornire
statistiche per i file codificati in Opus.
Le misurazioni energetiche, come per i precedenti test, sono state registrate grazie a PowerTutor, il quale veniva avviato appena dopo
l’accensione, subito prima dell’esecuzione della
riproduzione dei files. I risultati ottenuti ven-

gono riportati di seguito sotto forma di grafici,
mentre le relative tabelle numeriche vengono
descritte all’interno dell’apposita appendice B.
In Figura 9, Figura 10 e Figura 11 possiamo
osservare il consumo energetico di ogni
modulo hardware per i due tipi di codec video.
Ogni figura si riferisce ad un determinato step
di tempo (5 min, 15 min, 30 min). Allo
stesso modo, in Figura 12, vengono mostrati i
consumi ( in Joule ) nello step da 5 min. per i
diversi tipi di codec audio, per ogni modulo
coinvolto nella riproduzione ne viene riportato
il dispendio energetico. In Figura 13 e Figura
`
14 e possibile osservare il comportamento
degli stessi codec audio per gli step di testing
di 15 min (Figura 13) e 30 min (Figura 14).
`
Da quanto si puo osservare nei grafici, i test
locali, non hanno fatto altro che confermare i
risultati osservati precedentemente con i test
`
comparativi su rete. Seppur in maniera piu
attenuata, per via del minor sforzo di calcolo
da parte del componente CPU, il codec H264
vince il confronto con WebM, riconfermandosi
`
come codec video piu energeticamente costoso.
Per i codec audio, Wave, continua ad essere
`
il piu dispendioso in termini energetici,
soprattutto per la differenza di consumi del
modulo CPU, il quale incide maggiormente
nella differenza dei consumi con gli altri codec.


Figura 9: Risultati dei test locali relativi ai codec video - 5 min. con riferimento alla Tabella 13


12



Figura 12: Risultati dei test locali relativi ai codec audio - 5 min. con riferimento alla Tabella 16

13




14


Figura 15: Risultati Codec Audio - 5 min. con riferimento alla Tabella 7


15



Figura 18: Diagramma di Pareto riferito ai Codec Audio

16


Figura 19: Risultati Codec Video - 5 min. con riferimento alla Tabella 10


17



Figura 22: Diagramma di Pareto riferito ai Codec Video

18


4.4

19

Costruzione sito malevolo

Grazie ai risultati ottenuti in fase di sperimentazione sui codec audio/video, abbiamo potuto individuare quei codec che fossero meno
efficienti in termini di risparmio energetico.
Con queste informazioni abbiamo sviluppato
una pagina web con scripts malevoli, tali da
`
esaurire l’energia del dispositivo nel piu breve
tempo possibile.
`
La base di partenza e stata una pagina in
HTML statico di Wikipedia, all’interno della
quale abbiamo nascosto contenuti multimediali
e gli scripts malevoli descritti in seguito.
4.4.1 Descrizione sito malevolo
In questa sezione sono descritte brevemente
le tecnologie utilizzate per realizzare il sito
malevolo.
• Video e audio nascosti e con volume a zero
(Hidden Muted Video e Hidden Muted Audio).
I video sono stati inseriti all’interno della
pagina, in modo da non dare all’utente
la percezione della loro presenza. Per i
`
video sono stati nascosti i controlli ed e
stato settato il tag di autoplay, impostando
l’audio a 0, al fine di renderli invisibili,
le dimensioni sono state impostate a 0*0
`
pixel. Per gli audio e stata seguita la stessa
logica.
• Utilizzo di codec specifici. I codec utilizzati per i contenuti multimediali sono
stati scelti in maniera mirata, sulla base dei
risultati della sperimentazione e dei con`
fronti sui risultati. Abbiamo percio scelto
H264 (video) e Wave (audio).
• Scrittura e cancellazione continua di dati
(HTML5 Web Storage). Utilizzando la funzionalit` di Web Storage fornita da HTML5
a
abbiamo inserito uno script che esegue
ogni 6 secondi la scrittura e cancellazione all’interno della memoria di un file
contenente una stringa di 25Kb.
• Chiamate continue con Ajax (Ajax Stress
Calls). Per tenere sempre attivo il modulo
Wi-Fi con un continuo scambio di dati
con il web, abbiamo incluso delle chiamate
AJAX ad intervalli regolari di 1 secondo.
• Richiesta di diversi font (Fonts Stress
Calls). Al fine di stressare ulteriormente

•

il modulo CPU, abbiamo incluso l’utilizzo
all’interno della pagina di fonts considerati
unsafe dai browser; ovvero quei fonts non
inclusi di default all’interno dei browser.
In questo modo, costringiamo il sistema a
cercare i fonts da caricare all’interno del
dispositivo stesso.
Utilizzo di infrasuoni (Infrasound Audio).
Per aumentare il consumo di tutti i moduli, abbiamo introdotto, tra i contenuti
multimediali, dei file audio codificati con
codec Wave che riproducessero una traccia
in infrasuoni (2Hz) al massimo del volume
digitale.

La Tabella 4 mostra i test di stress effettuati.
TestID
1
2
3
4
5
6
7
8
9

Stress Option
None
HTML5 Web Storage
Ajax Stress Calls
Fonts Stress Calls
Hidden Muted Video
Hidden Muted Audio
Hidden Infrasound Audio
All
https://www.facebook.com

Tabella 4: Test Stress

4.4.2 HTML5 vs HTML4.01
Per la realizzazione del sito malevolo abbiamo
utilizzato lo standard HTML5 che ci ha permesso di inserire all’interno della pagina contenuti
multimediali in modo semplice ed efficace per
nostri fini. HTML5 definisce due nuovi tag,
<video> e <audio>, che definiscono lo standard
per incorporare un audio o un video in una
pagina web.
Se avessimo dovuto utilizzare l’ultima versione precedente ad HTML5, ovvero la versione 4.01 dello standard HTML, l’efficacia del
sito malevolo sarebbe stata ridotta e alcune
componenti impossibili da utilizzare.
`
Infatti, in HTML4.01 non e previsto un supporto nativo per video e audio. Per permettere
la loro esecuzione, essi necessitano di essere
incorporati usando tecnologie che si basano su
Adobe Flash o su Apple QuickTime. In riferi`
mento alla tecnologia Adobe Flash, essa e stata
ormai abbandonata da molti sistemi operativi
mobile per motivi di efficienza e di sicurezza.


20

`
Inoltre non e possibile nascondere video e/o
audio.
Infine non sarebbe stato possibile utilizzare
la tecnologia Web Storage, introdotta appunto
con HTML5, la quale consente una memoriz`
zazione di dati sul dispositivo client molto piu
`
efficace dei cookie, e per tale motivo piu adatta
ai nostri scopi.
4.4.3

Risultati

I consumi energetici del sito prodotto sono
stati testati in maniera molto fine, abilitando un
solo tipo di script per volta. I risultati raccolti
sono stati organizzati all’interno di un grafico
(Figura 23) in cui possiamo notare quale script
`
risulta essere il piu energy inefficient.

Figura 25: Composizione del circuito.

5

VALIDAZIONE

Le misurazioni effettuate durante la fase di
sperimentazione sono state validate attraverso
Una volta realizzata la pagina web malevola l’uso di un multimetro (mod. DT830 Digital
abbiamo condotto uno studio comparativo con Multimeter). Sono stati effettuati due tipi di test:
le altre pagine web di utilizzo quotidiano, qua- test di amperaggio e test di voltaggio.
li: la stessa pagina di Wikipedia dalla quale
siamo partiti per realizzare la pagina male- 5.1 Test di amperaggio
vola ed una pagina di Facebook. Registran- Il circuito (Figura 25) e stato realizzato colle`
do ed analizzando i consumi, abbiamo potuto gando in serie il multimetro, la batteria e il diconfrontarli (Figura 24).
spositivo mobile. L’obiettivo della validazione
`
e di verificare, attraverso strumentazione fisica,
i risultati presentati da PowerTutor.
4.5 Massive Dynamic Web Attack
`
Attraverso il multimetro e stato misurato
In seguito ai normali test, abbiamo voluto di- l’amperaggio all’interno del circuito, con il discostarci dai soli obiettivi prefissati di Battery spositivo in funzione e col profiling di PowerDrain Attack, cercando di testare i limiti di Tutor attivo. Sono stati registrati i valori rilevati
stress sopportabili da un dispositivo mobile. da PowerTutor (in mW e V) e dal multimetro
Abbiamo creato una ulteriore pagina web ma- (in A). Per confrontare i valori ottenuti da Polevola di Dynamic Web Attack, nella quale werTutor con quelli del multimetro, sono stati
abbiamo incluso gli script malevoli descritti convertiti mW e V in A applicando la formula:
in precedenza e forzato, in maniera dinamimW
1000
ca, l’inserimento dei contenuti multimediali ad
A=
V
intervalli di 1 secondo. Conducendo l’esperimento sul dispositivo sotto testing, abbiamo I risultati sono riassunti in tabella 5.
notato che dopo soli 3’ e 10”, si verificava PowerTutor Multimetro Errore
Percentuale
un overflow in memoria, il browser e tutte 0,171 A
0,180 A
0,009 A
5%
le altre applicazioni e servizi in esecuzione in
Tabella 5: Risultati test amperaggio
background, compreso il servizio di gestione
della UI, venivano chiusi da Android stesso
Dai risultati si evince che l’errore commesso
con la conseguente perdita di dati non salvati
`
ed un consumo ulteriore dovuto al riavvio da PowerTutor in termini assoluti e dell’ordine
di mA (con uno scarto percentuale del 5%).
dell’interfaccia.
4.4.4

Confronto consumi


21

Figura 23: Confronto tra i consumi (in Joule) dei diversi script malevoli presenti nella pagina di stress test con
riferimento alla Tabella 19

5.2

Test di voltaggio

Utilizzando gli stessi strumenti utilizzati du`
rante il test di amperaggio, e stata modiﬁcata
la struttura del circuito ponendo in parallelo il
multimetro, per misurare il voltaggio. I risultati
ottenuti sono riassunti in tabella 6.
PowerTutor
3,77 V

Multimetro
3,97 V

Errore
0,20 V

Percentuale
5,3%

Tabella 6: Risultati test voltaggio

`
Confrontando i risultati si e evinto che il
valore di errore, anche in questo caso risulta
essere del 5%.

6

C ONCLUSIONI

Valutando i risultati ottenuti in fase di testing
`
`
e emerso che i codec piu dispendiosi in termini energetici sono risultati essere H264 per
i contenuti video e Wave per gli audio. Questi
formati sono stati inseriti poi in una normale

pagina HTML statica di Wikipedia, in maniera invisibile, insieme ad altri script esposti in
precedenza, per creare la pagina web malevola.
Confrontando il consumo energetico della
pagina da noi realizzata con i normali siti web
di comune utilizzo siamo riusciti ad ottenere un
consumo energetico pari ad 11 volte il consumo
della stessa pagina in HTML e consumi pari
al 4.5 volte maggiori rispetto ad una pagina di
Facebook. Siamo giunti alla conclusione che at`
traverso l’impiego malevolo delle piu semplici
e note tecnologie web, si ottengono consumi
energetici tali da portare la batteria del dispo`
sitivo in uso alla scarica in tempi molto piu
brevi.
`
Una possibile soluzione che un utente puo
utilizzare al ﬁne di evitare attacchi di questo
`
genere, puo essere quella di disabilitare l’e`
secuzione di codice JavaScript. Cio comporta
ovviamente il vantaggio di essere meno vulnerabile ad attacchi che sfruttino le potenzialit`
a
di questo linguaggio, ma lo svantaggio di non
poter usufruire di contenuti dinamici offerti


22

Figura 24: Confronto dei consumi (in Joule) tra le diverse pagine web con riferimento alla Tabella 20

ormai da numerose pagine web. Se l’utente rilevare e difendere l’utente da eventuali attacriesce ad individuare la pagina web che pro- chi di Denial of Service energetico. Le possibili
voca il consumo anomalo della batteria del strategie di difesa potrebbero essere due:
proprio dispositivo, si consiglia di contattare
• Analisi statica del codice sorgente delle
l’amministratore del sito.
pagine web prima di essere caricate in
modo da individuare il codice malevolo.
• Analisi dinamica delle prestazioni e dei
consumi della batteria in modo da av7 S VILUPPI F UTURI
vertire prontamente l’utente e bloccare
`
Il naturale proseguimento di tale studio e rapl’esecuzione del codice.
presentato dal continuo aggiornamento dei casi
di test, sia per quanto riguarda i nuovi coA PPENDICE A
dec multimediali che verranno introdotti, sia
per le future tecnologie web che si avranno a R ISULTATI T EST C ODEC
A.1 Codec Audio
disposizione.
Si necessita, inoltre, di incrementare il nuCPU Audio Wi-Fi
mero di dispositivi su cui effettuare benchWave 93.40 134.10 94.90
mark. Una possibile soluzione potrebbe esseOpus 58.40 128.20 72.60
Vorbis 49.80 122.80 65.20
re il rilascio dell’applicazione ”Battery Bench”
WebM 87.20 117.20 61.70
sullo store Android in modo da ricevere anoMP3 98.80 116.90 69.40
nimamente log di esecuzioni di test da utenti
AAC 47.10 118.80 60.40
volontari.
Un ulteriore sviluppo potrebbe essere quello Tabella 7: Valori di consumo energetico (espressi in
di creare un’applicazione che sia in grado di Joule) ottenuti dal testing dei codec audio per 5 minuti.


Wave
Opus
Vorbis
WebM
MP3
AAC

CPU
313.40
264.20
318.90
307.80
289.30
297.70

23

Audio
354.20
338.40
364.80
357.50
313.80
343.80

Wi-Fi
178.80
175.70
185.10
197.10
161.90
178.80

A PPENDICE B
R ISULTATI T EST L OCALI

Tabella 8: Valori di consumo energetico (espressi in
Joule) ottenuti dal testing dei codec audio per 15 minuti.

Wave
Opus
Vorbis
WebM
MP3
AAC

CPU
673.90
675.80
667.70
665.90
689.90
669.40

Audio
693.50
694.60
695.10
689.80
693.10
675.10

CPU
52.40
48.90

LCD
311.40
310.90

Audio
118.30
107.20

Joule) ottenuti dai test di riproduzione in ambiente locale
dei ﬁle video per 5 minuti.

Wi-Fi
332.80
324.50
329.10
318.50
247.60
269.30

H264
WebM

Joule) ottenuti dal testing dei codec audio per 30 minuti.

A.2

H264
WebM

CPU
167.50
154.80

LCD
840.70
835.50

Audio
342.50
317.90


Codec Video

H264
WebM
H264 vol. 0
WebM vol. 0

CPU
93.20
97.50
87.70
91.50

LCD
289.80
278.50
284.50
273.20

Audio
109.80
90.30
106.40
76.80

Wi-Fi
50.80
66.80
63.10
52.80

H264
WebM

CPU
328.80
318.40

LCD
1674.00
1643.00

Audio
692.40
691.80


Joule) ottenuti dal testing dei codec video per 5 minuti.

H264
WebM
H264 vol. 0
WebM vol. 0

CPU
305.40
297.60
268.20
270.50

LCD
901.80
825.30
826.50
815.70

Audio
337.10
323.30
332.90
331.40

Wi-Fi
158.60
129.70
126.40
128.20


H264
WebM
H264 vol. 0
WebM vol. 0

CPU
653.40
637.70
558.40
548.70

LCD
1785.00
1589.00
1689.10
1654.00

Audio
685.80
665.10
581.00
565.50

Wi-Fi
241.30
191.80
230.50
196.40


MP3
Wave
Vorbis
AAC
WebM

CPU
37.10
39.80
32.40
29.40
34.90

Audio
109.90
112.60
111.80
110.50
111.80

dei ﬁle audio per 5 minuti.

MP3
Wave
Vorbis
AAC
WebM

CPU
99.50
118.40
112.90
118.10
115.80

Audio
345.60
364.80
353.90
365.10
328.90



24

CPU
214.80
235.90
221.90
117.80
221.30

MP3
Wave
Vorbis
AAC
WebM

Audio
695.40
701.90
675.10
698.20
687.50

A PPENDICE E
C ODICE S ORGENTE

Di seguito vengono elencati i ﬁle sorgenti utilizzati durante la sperimentazione, disponibili
al seguente link: https://www.dropbox.com/
Tabella 18: Valori di consumo energetico (espressi in sh/cxgyl09fzdjoagj/5ShETNttio


A PPENDICE C
R ISULTATI T EST S ITO M ALEVOLO

Infrasounds
Audio
Video
Web Storage
Ajax
Fonts

CPU
54.90
61.20
84.20
113.90
32.50
28.50

Wi-Fi
197.70
186.80
161.80
13.80
34.60
39.40

Audio
117.80
110.60
60.30
0.00
0.00
0.00

Tabella 19: Valori di consumo energetico (espressi
in Joule) ottenuti dallo stress test per ogni opzione
applicabile.

Static HTML
Battery Drain Attack
facebook.com

CPU
25.70
283.80
75.40

Wi-Fi
33.60
228.36
72.70

Audio
0.00
153.90
0.00

Joule) ottenuti dal confronto delle diverse pagine web
prese in esame.

A PPENDICE D
I NVENTARIO F ILE U TILIZZATI
Type
Audio
Audio
Audio
Audio
Audio
Audio
Video
Video
Audio Infrasuono

Codec
AAC
MP3
Ogg Opus
Ogg Vorbis
Wave
WebM
H264
WebM
Wave

Size
28.8 MB
28.9 MB
34.1 MB
28.1 MB
318.3 MB
28.9 MB
43.4 MB
15.4 MB
53.1 MB

Tabella 21: File utilizzati

audio
B a t t e r y T e s t . php
stress
video
. / audio :
src
TestAudioAac . html
TestAudioMP3 . html
TestAudioOpus . html
TestAudioVorbis . html
TestAudioWav . html
TestAudioWebM . html
. / audio/ s r c :
audio . aac
audio . m4a
audio . mp3
audio . ogg opus . opus
audio . ogg vorbis . ogg
audio . wav
audio . webm
./ s t r e s s :
addAudio . php
addFonts . php
a d d I n f r a . php
addObj . php
a j a x . php
audio
audio . php
B a t t e r y D r a i n A t t a c k . php
doRequest . php
f i l l &e r a s e . j s
f o n t s . php
fonts . txt
infra


i n f r a s o u n d s . php
linkAudio . t x t
linkInfra . txt
link . txt
Sicurezza files
S i c u r e z z a . html
video
video . php
. / s t r e s s /audio :
audio . wav
./ s t r e s s /i n f r a :
1hz . wav
. / s t r e s s /video :
NoAudio . mp4
. / video :
src
TestVideoH264 . html
TestVideoH264NoAudio . html
TestVideoWebM . html
TestVideoWebMNoAudio . html
. / video/ s r c :
NoAudio . mp4
NoAudio . webm
video . mp4
video . webm

R INGRAZIAMENTI
Si ringraziano gli autori di PowerTutor per la
licenza libera (GNU General Public License) sotto
`
la quale e stata rilasciata la sopracitata applicazione, utilizzata nel nostro studio per il
rilevamento dei consumi energetici.

25

R IFERIMENTI BIBLIOGRAFICI
[1] Ryan Reith, Tom Mainelli e Michael Shirer ”IDC Forecasts
Worldwide Tablet Shipments to Surpass Portable PC Shipments
in 2013, Total PC Shipments in 2015”
http://www.idc.com/getdoc.jsp?containerId=
prUS24129713, 28 Maggio 2013.
[2] Legge di Moore
http://it.wikipedia.org/wiki/Legge di Moore, 1965.
[3] A. Carroll e G. Heiser ”An Analysis of Power Consumption
in a smartphone”, In Proceedings of the 2010 USENIX
conference on USENIX annual technical conference, pp.
2-12.
[4] L. Zhang, B. Tiwana, R. P. Dick, Z. Qian, Z. M. Mao, Z.
Wang e L. Yang: ”Accurate Online Power Estimation and
Automatic Battery Behavior Based Power Model Generation for
Smartphones”, In Proceedings of the 8th IEEE/ACM/IFIP
International Conference on Hardware/Software Codesign
and System Synthesis 2010, pp. 1-10.
[5] Compatibility table for support of the Ogg/Theora video
format
http://caniuse.com/ogv, 2013.
[6] Supported Media Formats http://developer.android.com/
guide/appendix/media-formats.html
[7] P. Seeling F. Fitzek, G. Ertli, A. Pulipaka e M. Raisslein:
”Video Network Trafﬁc And Quality Comparison Of VP8 And
H264 SVC”, In Proceedings of the 3rd Workshop on Mobile
Video Delivery, 2010, pp. 1-5.
[8] T.K.Buennemeyer, M. Gora, R. Marchany e J. Tront:
”Battery Exhaustion Attack Detection With Small HandHeld
Mobile Computers”, In Proceedings of IEEE International
Conference on Portable Information Devices, 2007, pp. 1-5.
[9] HTML5 Autoplay, Loop and Muted: table list of which
browser support the autoplay, loop and muted attributes
http://www.longtailvideo.com/html5/autoloop/.
[10] Wikipedia
Bootstrapping (statistics)
http://en.wikipedia.org/wiki/Bootstrapping (statistics).

Uno Studio Empirico sui Consumi Energetici in Ambiente Android

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (12)

Similar to Uno Studio Empirico sui Consumi Energetici in Ambiente Android

Similar to Uno Studio Empirico sui Consumi Energetici in Ambiente Android (20)

Recently uploaded

Recently uploaded (9)

Uno Studio Empirico sui Consumi Energetici in Ambiente Android