Uno Studio Empirico sui Consumi Energetici in Ambiente Android

TESI IN SICUREZZA - LUGLIO 2013 1

Uno Studio Empirico sui Consumi Energetici inAmbiente Android e Possibili Attacchi di

SicurezzaGiuseppe 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 statimisurati i consumi energetici delle varie tecnologie web messe a disposizione da HTML5 e Javascript. I risultati ditali misurazioni sono stati ottenuti attraverso dei test eseguiti con l’ausilio della suite di Energy-Testing BatteryBenchrealizzata a tale scopo. I test hanno evidenziato quali tecnologie risultano essere maggiormente dispendiose in terminidi consumo energetico. Quest’ultime sono state utilizzate per analizzare la possibilita di attuare un attacco di Denial ofService energetico altresı chiamato Battery Drain.

Index Terms—Android, Sicurezza, Consumi, Energia, Batteria, Test, Web, HTML5, Codec.

F

1 INTRODUZIONE

OGNI giorno 1,3 milioni di nuovi dispositiviAndroid, tra tablet e smartphone, vengo-

no attivati. La base di installazioni conta 480milioni di dispositivi nel mondo.

International Data Corporation (IDC) stima cheil solo mercato dei tablet superera quello dei PCnel 2015 [1], mentre se si considera l’intero mer-cato mobile (smartphone + tablet) il sorpasso adiscapito dei PC e gia avvenuto.

L’utenza si sta spostando sempre piu sulmobile, e con esso, di conseguenza, anchequell’insieme di operazioni che finora eranoesclusivamente ad appannaggio dei computer.Oggigiorno i sempre piu evoluti dispositivimobile gestiscono una miriade di informazionipersonali ed attivita, rappresentando per moltepersone strumenti indispensabili nel quotidia-no. Browsing internet, social networking, com-

• Prof. Alfredo De SantisE-mail: [email protected]

• Dr. Aniello CastiglioneE-mail: [email protected]

• Prof. Ugo FioreE-mail: [email protected]

Esame di Sicurezza, Corso di Laurea in Informatica

munication e gaming, tra le principali attivitasvolte con essi.

Lo sviluppo hardware di questi dispositivimostra una crescita esponenziale, supportatadall’ampio bacino d’utenza e da una forteconcorrenza tra le case costruttrici.

Ogni anno processori, memorie, display ealtre componenti diventano sempre piu veloci,migliori ed economiche, perlomeno per chi leproduce. Vengono offerte maggiore capacita,pixel del display e potenza computazionale.La legge di Moore1 a proposito resta ancoravalida e la tecnologia dietro gli smartphonecresce esponenzialmente. Attualmente piu chemai questi ultimi hanno processori piu veloci,memorie di massa piu economiche, maggioreRAM e display di alta qualita. La stessa dif-ferenza tra uno smartphone attuale e uno diqualche anno fa e enorme.

La tecnologia costruttiva delle batterie tut-tavia non ha subito lo stesso miglioramento.Se da un lato si puo affermare che il proces-so evolutivo non sia completamente fermo, lo

1. ”Le prestazioni dei processori, e il numero di transistor ad essorelativo, raddoppiano ogni 18 mesi.”[2]

http://www.idc.com/


stesso procede pero molto lentamente. Il diva-rio e palese se paragonato a quello rapido edesponenziale che accompagna le restanti com-ponenti, che nel tempo tendono a incrementarele loro prestazioni e a miniaturizzarsi. Rispettoa queste ultime la batteria occupa ancora granparte della struttura di un telefono.

Tale fenomeno e dovuto a diversi fattori.Innanzitutto lo sviluppo delle batterie sem-

bra realmente procedere piu lentamente rispet-to alle altre componenti. Basti pensare che latecnologia su cui si basano le batterie per dispo-sitivi mobili e, da diversi anni, ancora quellaagli ioni di litio, con lievi miglioramenti.

In secondo luogo, la tendenza odierna e quel-la di fornire dispositivi sempre piu sottili eleggeri. Piuttosto che sfruttare i vantaggi chesi avrebbero mantenendo le stesse dimensioni,con una maggiore autonomia, i produttori dismartphone forniscono batterie sempre piu sot-tili in modo da poter ridurre le dimensioni deiloro terminali.

Infine, un ruolo influente lo giocano anchei software che necessitano di sempre piu po-tenza, insieme a notifiche push e servizi inbackground sempre attivi.

In questo contesto diviene di fondamenta-le importanza una gestione oculata dell’ener-gia. La batteria diviene quindi il punto debo-le dell’infrastruttura dei dispositivi mobili e,pertanto, forte candidato passibile di attacco.

In questo lavoro si indaga su possibili at-tacchi indotti al fine di ottenere un consumoenergetico anomalo della batteria di dispositivimobili Android.

La scelta di questa piattaforma e dovuta almiglior trend di espansione rispetto agli altriS.O. mobile e alla maggior facilita di misura-zione e analisi grazie alle API native e al codiceaperto del sistema Android.

Il lavoro svolto e stato articolato in diversefasi. Si e partiti da un prima fase di spe-rimentazione nella quale e stato osservato ilconsumo energetico dei codec audio/video te-stati singolarmente in ambiente controllato. Piuprecisamente i test eseguiti hanno riguardatola riproduzione di file video e audio di duratavariabile. Dall’analisi dei risultati e emerso chei codec piu dispendiosi in termini energetici so-no H264 per i file video e Wave per i file audio.

Tali codec sono stati utilizzati nell’ultima fasedella sperimentazione in cui e stata realizzatauna pagina web malevola con l’impiego dellepiu recenti tecnologie web messe a disposizio-ne da HTML5, Ajax e Javascript. Confrontandoil consumo energetico della pagina realizzatacon i normali siti web di comune utilizzo sie riuscito ad ottenere un consumo energeticopari ad 11 volte il consumo delle stesse paginein HTML.

Di seguito vengono illustrati i capitoli attra-verso i quali si articolera questo documento: Ilcapitolo 2 illustra lo stato dell’arte nell’ambitoin cui il nostro lavoro si vuole inserire. Nelcapitolo 3 viene introdotto l’attacco di sicu-rezza realizzato. Il capitolo 4 descrive la spe-rimentazione effettuata in termini di misura-zioni energetiche e realizzazione dell’attacco disicurezza.

2 STATO DELL’ARTE

In letteratura, molti articoli scientifici trattanodei consumi energetici in ambiente Android.La maggior parte di essi si focalizzano sullamisurazione dei consumi dei singoli modu-li hardware che formano l’infrastruttura deglismartphone. Il lavoro ”An Analysis of PowerConsumption in a smartphone”[3] offre un’analisiapprofondita dell’utilizzo energetico delle variecomponenti hardware. In questo studio vengo-no mostrati i risultati di misurazioni fisiche ef-fettuate tramite sensori di resistori posizionatisui circuiti degli smartphone.

Un altro lavoro importante e rappresenta-to da: ”Accurate Online Power Estimation andAutomatic Battery Behavior Based Power ModelGeneration for smartphones” [4]. Quest’ultimo sidifferenzia dal precedente per la metodologiadi misurazione che, in questo caso, avvieneanche via software e non solo in maniera fisica.

In questo lavoro viene descritto PowerTutor:un tool che offre la stima in tempo reale delconsumo energetico dei vari componenti hard-ware del dispositivo Android. Questa stimaviene fatta sulla base di un modello di scaricaottenuto come descritto nel capitolo 7 di [4].

Il modello di scarica e una funzione che, inbase al livello attuale di carica della batteria e i


livelli di utilizzo dei singoli componenti hard-ware del dispositivo (ottenuti attraverso APIAndroid), restituisce una stima del consumoenergetico in tempo reale.

Tale modello viene generato con la tecnicaPowerBooter che prevede i seguenti passi:

1) Ottenere la curva di scarica della batteria(Figura 1). Il voltaggio della batteria vieneregistrato nel tempo fino all’esaurimentodi essa.

2) Determinare il consumo di ogni componentehardware nei vari stati di utilizzo (es. idle,low, high). Variando lo stato di utilizzodi un componente (lasciando gli altri in-variati) viene registrata a distanza di unminuto, per quindici minuti, il voltaggiodella batteria.

3) Si effettua una regressione per derivare il mo-dello 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 attraversoun power meter con quelli stimati utilizzandoil modello precedentemente generato (comedescritto nel capitolo 6 di [4]).

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

PowerTutor offre un servizio di profilingenergetico (Figure 2, 3 e 4), mostrando leinformazioni dei consumi della batteria, siaper i singoli moduli presenti nello smartphone,sia per le singole applicazioni in esecuzionesul dispositivo. E’ possibile diversificareil tipo di profiling settando un intervallodi tempo (last minute, last hour, last day,

total) e un tipo di rilevazione (currentpower, average power, energy usage). Ognivolta che il profiling viene disattivato, tuttidati vengono resettati. In questo modo lesessioni di profiling restano indipendenti. Indettaglio, tramite l’utilizzo delle API standarddi Android (android.media.AudioManager,android.net.wifi.WifiManager, an-droid.hardware.SensorManager, etc.) vienemonitorato lo stato dei singoli modulihardware. Coi dati rilevati viene stimatoil consumo energetico dei componentiattraverso interpolazione sulla base delmodello precedentemente generato.

Figura 2: Schermata del profiling di PowerTutor. Questaschermata mostra i grafici dei consumi per ogni singolocomponente.

E doveroso segnalare, inoltre, il lavoro diBattery Exhaustion Attack Detection with Small


Figura 3: Schermata del profiling di PowerTutor. Questaschermata mostra il consumo energetico totale per ognisingola applicazione ed e stata ottenuta settando l’inter-vallo di tempo a total e il tipo di rilevazione a energyusage.

Handheld Mobile Computers [8] in cui, attraversoalgoritmi e moduli di comunicazione Wi-Fi eBluetooth, si realizzano Battery Drain Attacks,ovvero attacchi di sicurezza che mirino ad otte-nere un denial of service attraverso l’esaurimentodelle risorse energetiche dei dispositivi mobili.

Infine, per l’analisi dei codec audio/video,in Video network traffic and quality comparison ofVP8 and H.264 SVC [7] viene fatto uno studiodi confronto sulla qualita, data rate e la velocitadi encoding.

In questo articolo, viene condotto un lavorodi analisi del consumo energetico dei codecmultimediali che, a differenza di quanto fatto

Figura 4: Schermata del profiling di PowerTutor. Peruna singola applicazione vengono mostrati i consumienergetici dei componenti hardware utilizzati.

nel lavoro di Seeling[7], si concentra sui consu-mi energetici dei codec anziche sui fattori didata rate, qualita etc. Prendendo spunto dallavoro di Buennemeyer[8], anche nel nostrostudio viene interpretato il consumo di batteriacome una possibile vulnerabilita per i sistemimobili, ma, allo stesso tempo ci distinguiamoda esso perche utilizziamo i codec supportatida Android ed HTML5, per eseguire l’attaccodi Battery Drain.

3 ATTACCO DI SICUREZZA

L’attacco di sicurezza progettato, si basa sull’i-dea di sfruttare al massimo il consumo ener-getico 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 conte-nuti multimediali, abbiamo previsto l’utilizzodi funzionalita che mirassero a sfruttare a pienotutte le risorse disponibili, includendo funzionidi: lettura/scrittura di file in memoria, chiama-te AJAX e caricamento di font non presenti neldispositivo.

La tipologia di attacco e stata scelta pensan-do all’utilizzo da parte dell’utente medio di undispositivo mobile escludendo, quindi, l’ideadi poter installare sui dispositivi applicazionidi terze parti e puntando ad eseguire l’attaccoattraverso una pagina web.

La scelta di utilizzare il web per condurrel’attacco di Battery Drain e stata presa in basealla semplicita con cui l’utente puo accedervi,considerando la possibilita di poter navigaresenza l’installazione di alcun software aggiun-tivo. Durante la progettazione dell’attacco, cisiamo posti il vincolo che l’utente non debbaaccorgersi che l’attacco e in corso. Questa sceltaha implicato diverse difficolta nella realizzazio-ne e nelle scelte implementative del sito webmalevolo, attraverso il quale condurre l’attacco.

L’attacco e stato realizzato utilizzando stru-menti relativi alle tecnologie di sviluppoHTML5, Javascript, AJAX e php, le quali ven-gono utilizzate al fine di realizzare uno scriptmalevolo, inserito in quella che all’utente appa-re come una normale pagina web, che eseguetutte le funzionalita piu costose in termini ener-getici e di computazione, senza dare all’utentela possibilita di distinguere la nostra pagina daun’altra priva di codice malevolo.

4 SPERIMENTAZIONEL’attacco e stato pianificato sulla base deirisultati ottenuti in fase di sperimentazione,nella quale abbiamo osservato il consumoenergetico dei vari codec audio/video, testatisingolarmente in ambiente controllato.

La sperimentazione, dunque, si e svolta in3 step principali: inizialmente e stato prepa-rato un ambiente di test controllato in mododa automatizzare il testing dei consumi ener-getici, successivamente sono stati eseguiti talitest sui diversi codec multimediali compatibi-li con HTML5, infine, dall’analisi dei risultatiprecedenti e stato creato il sito malevolo.

4.1 Creazione ambiente di test

Il successo del nostro studio si basava sull’ot-tenere misurazioni affidabili dei consumi ener-getici in modo da poter effettuare le miglioriscelte per l’attacco di sicurezza. A tal fine sie reso necessario creare un ambiente di testcontrollato che automatizzasse il testing deiconsumi in modo che i risultati non fossero,quindi, influenzati da errori e rumore umano.

Abbiamo creato BatteryBench, applicazioneAndroid che effettua benchmark energetici eautomatizza le seguenti tipologie di test:

• Video• Audio• Stress

L’applicazione e divisa in 3 omonime sezioni,in cui ognuna predispone la scelta dei possibilitest da effettuare per la categoria scelta. Nellasezione Video (Figura 6) e possibile effettuare itest energetici sulla riproduzione dei contenutivideo e dei relativi codec. Si puo selezionare ilcodec da testare, la durata del test in minuti,e l’opzione che abilita/disabilita l’audio delvideo. In modo analogo per quanto riguardala sezione Audio (Figura 5), dedicata ai testsui consumi della riproduzione di file audio,e possibile scegliere il codec e la durata inminuti del test. Infine la sezione Stress (Fi-gura 7) e dedicata al testing di una serie discript malevoli. Tale sezione viene definita inquesto modo poiche gli script in questionetentano di esaurire le risorse energetiche deldispositivo mobile stressandone il consumo. Diseguito 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 webcon lo scopo di mantenere attivo il moduloWi-Fi.

• Fonts Stress Calls: ricerca di fonts unsafeche mirano al consumo della CPU.

• Hidden Muted Video: esecuzione in back-ground di file video senza che l’utente nesia consapevole.


• Hidden Muted Audio: esecuzione in back-ground di file audio senza che l’utente nesia consapevole.

• Hidden Infrasound Audio: esecuzione difile audio ad infrasuoni, non percepibiliall’orecchio umano.

E possibile selezionare attraverso appositecheckbox le opzioni da attivare e la durata deltest in minuti. In dettaglio, attraverso questasezione e possibile creare uno stress test perso-nalizzato in base all’esigenze dell’utente e deidati da raccogliere abilitando o disabilitandouna determinata opzione.

All’avvio del test di Stress, l’applicazionecomunica tramite una richiesta http al server leopzioni di stress selezionate. Il server includenella pagina web solo gli script php e javascriptrelativi alle opzioni selezionate dall’utente, inquesto modo la pagina web visualizzata dalclient conterra e carichera esclusivamente leopzioni di stress desiderate.

I risultati dei consumi energetici vengonomisurati da PowerTutor, il cui codice con licenzalibera e stato inglobato all’interno della no-stra applicazione. All’interno di quest’ultima, ilcodice di PowerTutor viene richiamato quandonecessario, come se fosse una semplice routine.

Nonostante siano disponibili molteplici ap-plicazioni per Android che offrono servizi dimisurazione dei consumi energetici (quali Bat-teryDoctor o DU Battery Saver), si e scelto diutilizzare PowerTutor poiche e risultato l’unico,tra quelli trovati, che, oltre a fornire valutazio-ni dei consumi energetici dettagliati per ognicomponente hardware del dispositivo e perogni applicazione in esecuzione, sia stata anchecomprovata la sua affidabilita nelle misurazioniattraverso rilevazioni fisiche con strumentazio-ni adeguate (”Accurate Online Power Estima-tion and Automatic Battery Behavior Based PowerModel Generation for smartphones” [4]).

Nello studio sopracitato vengono validatele misurazioni solo per alcuni device mobiliAndroid, tra i quali pero non compare lo smart-phone utilizzato nella nostra sperimentazione.PowerTutor installato sul nostro device (HTCIncredible S) utilizza un modello generico di

scarica della batteria (e quindi non costruito ad-hoc) migliorato attraverso i log anonimi inviatidagli utenti di PowerTutor che utilizzano lo stes-so dispositivo. Questo ovviamente comportadegli errori di stima del consumo energetico.Tuttavia, data la natura comparativa dei testdella nostra sperimentazione, non era impor-tante conoscere precisamente il consumo ener-getico in termini di joule bensı capire qualicodec e tecnologie fossero piu dispendiosi.

Infine, la licenza libera di PowerTutor, a dif-ferenza della maggior parte delle altre appli-cazioni di profiling disponibili closed source,ci ha permesso di automatizzare la fase ditesting abilitando/disabilitando via codice ilprofiling. Tale automazione non sarebbe statapossibile con applicazioni esterne closed sour-ce, in quanto avrebbero necessitato di un inputdell’utente, il quale avrebbe inevitabilmentecompromesso le misurazioni (es. precisione intermini di tempo; pressione di tasti a schermoche comportano consumo).

Con riferimento alla figura 8 illustriamo irelativi passi di esecuzione del programmaBatteryBench:

1) Vengono settati i parametri del test(tipologia di testing, tempo, codec etc.);

2) Viene lanciato il test attraverso l’appositotasto;

3) Viene avviato il profiling di PowerTutorsettando l’intervallo di tempo a total eil tipo di rilevazione a energy usage inmodo da misurare il consumo energeticodella sola applicazione browser che verralanciata successivamente;

4) Viene avviato il browser predefinito disistema con la pagina web relativa al testselezionato;

5) Allo scadere del tempo definito al passo1, il browser viene chiuso.

6) Viene interrotto il servizio di profiling diPowerTutor

7) Viene mostrata una nuova finestra in cuisi possono osservare i risultati del test.

E da sottolineare che l’avvio del profilingprecedentemente l’apertura del browser noncomporta errori di stima in quanto PowerTu-tor, configurato appositamente per il browser,


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

iniziera a misurare da quando il processo delbrowser sara attivo.

La pagina dei risultati (Figura 4) mostra ilconsumo del browser rispetto ai singoli mo-duli presenti nello smartphone. Tali risultatipossono essere memorizzati in un file di log.

4.2 Analisi e monitoraggio dei consumiIn questa fase, e stato monitorato il consumo ditutti i codec multimediali previsti dallo stan-dard HTML5 che fossero, allo stesso tempo,supportati dal browser stock di Android:

HTML5 Video

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

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

HTML5 Audio

• Ogg Vorbis• WAV PCM• MP3• AAC• WebM Vorbis• Ogg Opus

Di conseguenza, i nostri test non compren-dono il codec Theora.


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

4.2.1 Metodologia di Test

I test sono stati eseguiti su uno smartphoneAndroid a nostra disposizione, in particolareHTC Incredible S con Android 2.3, processoreQualcomm Snapdragon 1024MHz, Display 4’TFT 480*800 pixel.

La durata dei singoli test segue questi stepincrementali:

• 5 min• 15 min• 30 min

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

Figura 8: Schema del funzionamento di Battery Bench.


Siccome il consumo della batteria non e uni-forme, ma dipende dallo stato di scarica in cuiessa si trova [4], tutti i test sono stati eseguitipartendo dallo stato di carica completa dellabatteria del dispositivo.

I test sono stati eseguiti con l’ausilio diBatteryBench.

4.2.2 Test eseguitiI test eseguiti riguardano la riproduzione difiles video (con o senza traccia audio) e di filesaudio di durata variabile (5, 15 e 30 minuti).Precisamente ogni test consiste nella visita diuna pagina web contenente una traccia videoo audio codificata con uno dei codec elencatiprecedentemente.

I test riguardanti i video contenenti trac-cia audio avranno le seguenti combinazioni dicodec 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)• WebM: VP8/Vorbis

HTML5 Video con traccia audio muta• mp4: H.264/MPEG4• WebM: VP8/Vorbis

HTML5 Audio• Ogg Vorbis• WAV PCM• MP3• AAC• WebM VorbisNella Tabella 21 vengono mostrati i test

video eseguiti con le varie combinazioni ditempo, volume e codec.

Analogamente, nella Tabella 2 vengono mo-strati i test audio eseguiti per i diversi codec estep di tempo.

4.2.3 RisultatiDi seguito vengono riportati i grafici deirisultati dei test sui codec audio per gli step da5, 15, 30 minuti (rispettivamente Figure 15, 16 e17) e sui codec video per gli stessi step di tempo

TestID Codec Volume Time1 H264 Max 30 Minutes2 H264 Max 15 Minutes3 H264 Max 5 Minutes4 H264 Min 30 Minutes5 H264 Min 15 Minutes6 H264 Min 5 Minutes7 WebM Max 30 Minutes8 WebM Max 15 Minutes9 WebM Max 5 Minutes10 WebM Min 30 Minutes11 WebM Min 15 Minutes12 WebM Min 5 Minutes

Tabella 1: Test Video

TestID Codec Time1 MP3 30 Minutes2 MP3 15 Minutes3 MP3 5 Minutes4 Wave 30 Minutes5 Wave 15 Minutes6 Wave 5 Minutes7 Opus 30 Minutes8 Opus 15 Minutes9 Opus 5 Minutes10 Vorbis 30 Minutes11 Vorbis 15 Minutes12 Vorbis 5 Minutes13 AAC 30 Minutes14 AAC 15 Minutes15 AAC 5 Minutes16 WebM 30 Minutes17 WebM 15 Minutes18 WebM 5 Minutes

Tabella 2: Test Audio

previsti da 5, 15, 30 minuti (rispettivamenteFigure 19, 20 e 21). Sono stati, inoltre, ricavatii relativi diagrammi di Pareto (Figure 18 e22) in modo da ottenere un’informazionequanto piu dettagliata possibile circala percentuale di consumo energeticoprodotto da ciascun modulo hardware.

Video: Durante la sperimentazione e emersoun consumo costantemente in crescita delcodec H264 nei singoli step da 5, 15, 30minuti. Il gap energetico tra H264 ed il codecdi comparazione WebM rimane costante perogni step, aumentando in maniera funzionalerispetto al tempo di test.

Inoltre, il trend energetico descritto in prece-denza, e stato registrato anche per i test effet-tuati sui medesimi codec e tempi, con tracciaaudio muta, in particolare, si osserva come il


volume dell’audio influisca in minima partenel 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, chesingolarmente costituisce il 53% del consumototale. La somma dei moduli LCD, Audio,CPU risulta essere il 92% dell’intero dispendioenergetico prodotto, lasciando al modulo Wi-Fiil dispendio minore con il solo 8%.Audio: Per quanto riguarda i test eseguiti suicodec audio, non e emersa una situazione deltutto definita, poiche i consumi energetici dialcuni codec sono risultati piuttosto variabilinei singoli step da 5, 15, 30 minuti. Tuttavia si enotato un consumo medio maggiore del codecWave, soprattutto nei tempi brevi, come risultadai relativi grafici riportati in appendice A.

Analizzando il consumo medio dei singolimoduli abbiamo notato che la componente Au-dio insieme al modulo CPU costituiscono l’80%circa del consumo energetico totale, mentreil modulo Wi-Fi assorbe il 20% dell’energiautilizzata per compiere la riproduzione audio.Per i test audio non e stato preso in considera-zione il modulo LCD, non essendo ovviamenterilevante nel confronto.

4.2.4 Overhead comunicazione con il ServerAl termine di questa prima fase di test, ab-biamo cercato di quantificare l’impatto del-la comunicazione con il server in termini diconsumo energetico. L’obiettivo era quello diconfrontare i diversi codec multimediali senzal’overhead della comunicazione e scambio datitra il client e il server. In altre parole, si volevascoprire se un codec intrinsecamente energy effi-cient in termini di riproduzione e codifica, veni-va penalizzato nei test energetici a causa delladimensione del file e quindi del trasferimentodati. Ovviamente una semplice esclusione delconsumo del modulo Wi-Fi non rappresenta, anostro parere, una strategia affidabile in terminiassoluti.

La strategia che volevamo adottare era quelladi trasferire un file multimediale di piccole di-mensioni e ripeterlo in loop per l’intera duratadel test.

Non e stato tuttavia possibile portare avantitale tecnica, date le politiche di risparmio ener-

getico adottate dal browser stock di Android.Quest’ultimo ignora la funzionalita associata altag loop [9] previsto dallo standard HTML5,che permette la riproduzione in loop di uncontenuto multimediale.

Per aggirare il problema abbiamo provatoad utilizzare le funzionalita di Javascript persimulare un loop. Nello specifico abbiamo pro-vato a richiamare la funzione play sull’elementomultimediale ogni volta che la riproduzioneterminava. Tale tecnica e stata dapprima testatasu un browser per PC, con esito positivo, malo stesso non si e riscontrato sul browser stockdi Android.

In conclusione, non abbiamo potuto annul-lare l’overhead di comunicazione come piani-ficato, ma abbiamo dovuto cercare un modoalternativo per avere un termine di paragonenei consumi dei contenuti audio/video.

Per eseguire i test sui contenuti multimedialiannullando l’overhead della comunicazione inrete abbiamo effettuato le stesse misurazionieseguite precedentemente, ma questa volta uti-lizzando il player multimediale di Android perriprodurre gli audio/video.

4.3 Testing locale

Come descritto in precedenza, volevamoavere dei termini di confronto sui consumienergetici dei codec multimediali annullandoil consumo e l’overhead del modulo Wi-Fi,che influisce pesantemente sui consumi per iltrasferimento di file molto grandi e poco adattiallo streaming (es. Wave). Visto il fallimentodi tutti gli altri tentativi di riprodurre ifile multimediali all’interno del browser, inambiente locale, abbiamo provato ad effettuarele nostre misurazioni utilizzando il playermultimediale stock di Android per riprodurrei suddetti file.


TestID Type Codec Time1 Video H264 5 Minutes2 Video H264 15 Minutes3 Video H264 30 Minutes4 Video WebM 5 Minutes5 Video Wave 15 Minutes6 Video Wave 30 Minutes7 Audio MP3 5 Minutes8 Audio MP3 15 Minutes9 Audio MP3 30 Minutes10 Audio Wave 5 Minutes11 Audio Wave 15 Minutes12 Audio Wave 30 Minutes13 Audio Vorbis 5 Minutes14 Audio Vorbis 15 Minutes15 Audio Vorbis 30 Minutes16 Audio AAC 5 Minutes17 Audio AAC 15 Minutes18 Audio AAC 30 Minutes19 Audio WebM 5 Minutes20 Audio WebM 15 Minutes21 Audio WebM 30 Minutes

Tabella 3: Test eseguiti utilizzando il riproduttore mul-timediale stock di Android. I diversi file sono statiprecedentemente memorizzati in memoria locale perannullare l’overhead di comunicazione su rete.

La metodologia applicata per il testing inlocale e stata del tutto simile a quella utilizzataper il testing su rete precedentemente descritto.In particolare, abbiamo testato i file codificaticon i codec ritenuti meno efficienti in terminienergetici nella precedente fase di testing, ov-vero: Wave per i contenuti audio e H264 perquelli video. I file sono stati memorizzati sulsupporto di memorizzazione di massa dellostesso dispositivo mobile utilizzato per le altrefasi di testing. L’apparecchio e stato riavviatoad ogni iterazione del testing (5min, 15min,30min) quest’ultimo effettuato sempre con bat-teria completamente carica. La pianificazionedei test locali e stata riportata in Tabella 3,in cui sono descritte le diverse iterazioni deltesting. Com’e possibile notare dalla Tabella3, il codec audio Opus non e presente, dalmomento che i riproduttori multimediali diAndroid non supportano il sudetto codec comeriportato nella guida ufficiale per gli svilup-patori [6], quindi non e stato possibile fornirestatistiche per i file codificati in Opus.Le misurazioni energetiche, come per i prece-denti test, sono state registrate grazie a Po-werTutor, il quale veniva avviato appena dopol’accensione, subito prima dell’esecuzione dellariproduzione dei files. I risultati ottenuti ven-

gono riportati di seguito sotto forma di grafici,mentre le relative tabelle numeriche vengonodescritte all’interno dell’apposita appendice B.

In Figura 9, Figura 10 e Figura 11 possiamoosservare il consumo energetico di ognimodulo hardware per i due tipi di codec video.Ogni figura si riferisce ad un determinato stepdi tempo (5 min, 15 min, 30 min). Allostesso modo, in Figura 12, vengono mostrati iconsumi ( in Joule ) nello step da 5 min. per idiversi tipi di codec audio, per ogni modulocoinvolto nella riproduzione ne viene riportatoil dispendio energetico. In Figura 13 e Figura14 e possibile osservare il comportamentodegli stessi codec audio per gli step di testingdi 15 min (Figura 13) e 30 min (Figura 14).

Da quanto si puo osservare nei grafici, i testlocali, non hanno fatto altro che confermare irisultati osservati precedentemente con i testcomparativi su rete. Seppur in maniera piuattenuata, per via del minor sforzo di calcoloda parte del componente CPU, il codec H264vince il confronto con WebM, riconfermandosicome codec video piu energeticamente costoso.Per i codec audio, Wave, continua ad essereil piu dispendioso in termini energetici,soprattutto per la differenza di consumi delmodulo CPU, il quale incide maggiormentenella differenza dei consumi con gli altri codec.


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




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


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




Figura 18: Diagramma di Pareto riferito ai Codec Audio


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




Figura 22: Diagramma di Pareto riferito ai Codec Video


4.4 Costruzione sito malevolo

Grazie ai risultati ottenuti in fase di sperimen-tazione sui codec audio/video, abbiamo po-tuto individuare quei codec che fossero menoefficienti in termini di risparmio energetico.Con queste informazioni abbiamo sviluppatouna pagina web con scripts malevoli, tali daesaurire l’energia del dispositivo nel piu brevetempo possibile.

La base di partenza e stata una pagina inHTML statico di Wikipedia, all’interno dellaquale abbiamo nascosto contenuti multimedialie gli scripts malevoli descritti in seguito.

4.4.1 Descrizione sito malevoloIn questa sezione sono descritte brevementele tecnologie utilizzate per realizzare il sitomalevolo.

• Video e audio nascosti e con volume a zero(Hidden Muted Video e Hidden Muted Audio).I video sono stati inseriti all’interno dellapagina, in modo da non dare all’utentela percezione della loro presenza. Per ivideo sono stati nascosti i controlli ed estato settato il tag di autoplay, impostandol’audio a 0, al fine di renderli invisibili,le dimensioni sono state impostate a 0*0pixel. Per gli audio e stata seguita la stessalogica.

• Utilizzo di codec specifici. I codec uti-lizzati per i contenuti multimediali sonostati scelti in maniera mirata, sulla base deirisultati della sperimentazione e dei con-fronti sui risultati. Abbiamo percio sceltoH264 (video) e Wave (audio).

• Scrittura e cancellazione continua di dati(HTML5 Web Storage). Utilizzando la fun-zionalita di Web Storage fornita da HTML5abbiamo inserito uno script che esegueogni 6 secondi la scrittura e cancellazio-ne all’interno della memoria di un filecontenente una stringa di 25Kb.

• Chiamate continue con Ajax (Ajax StressCalls). Per tenere sempre attivo il moduloWi-Fi con un continuo scambio di daticon il web, abbiamo incluso delle chiamateAJAX ad intervalli regolari di 1 secondo.

• Richiesta di diversi font (Fonts StressCalls). Al fine di stressare ulteriormente

il modulo CPU, abbiamo incluso l’utilizzoall’interno della pagina di fonts consideratiunsafe dai browser; ovvero quei fonts noninclusi di default all’interno dei browser.In questo modo, costringiamo il sistema acercare i fonts da caricare all’interno deldispositivo stesso.

• Utilizzo di infrasuoni (Infrasound Audio).Per aumentare il consumo di tutti i mo-duli, abbiamo introdotto, tra i contenutimultimediali, dei file audio codificati concodec Wave che riproducessero una tracciain infrasuoni (2Hz) al massimo del volumedigitale.

La Tabella 4 mostra i test di stress effettuati.

TestID Stress Option1 None2 HTML5 Web Storage3 Ajax Stress Calls4 Fonts Stress Calls5 Hidden Muted Video6 Hidden Muted Audio7 Hidden Infrasound Audio8 All9 https://www.facebook.com

Tabella 4: Test Stress

4.4.2 HTML5 vs HTML4.01Per la realizzazione del sito malevolo abbiamoutilizzato lo standard HTML5 che ci ha permes-so di inserire all’interno della pagina contenutimultimediali in modo semplice ed efficace pernostri fini. HTML5 definisce due nuovi tag,<video> e <audio>, che definiscono lo standardper incorporare un audio o un video in unapagina web.

Se avessimo dovuto utilizzare l’ultima ver-sione precedente ad HTML5, ovvero la versio-ne 4.01 dello standard HTML, l’efficacia delsito malevolo sarebbe stata ridotta e alcunecomponenti impossibili da utilizzare.

Infatti, in HTML4.01 non e previsto un sup-porto nativo per video e audio. Per permetterela loro esecuzione, essi necessitano di essereincorporati usando tecnologie che si basano suAdobe Flash o su Apple QuickTime. In riferi-mento alla tecnologia Adobe Flash, essa e stataormai abbandonata da molti sistemi operativimobile per motivi di efficienza e di sicurezza.


Inoltre non e possibile nascondere video e/oaudio.

Infine non sarebbe stato possibile utilizzarela tecnologia Web Storage, introdotta appuntocon HTML5, la quale consente una memoriz-zazione di dati sul dispositivo client molto piuefficace dei cookie, e per tale motivo piu adattaai nostri scopi.

4.4.3 Risultati

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

4.4.4 Confronto consumi

Una volta realizzata la pagina web malevolaabbiamo condotto uno studio comparativo conle altre pagine web di utilizzo quotidiano, qua-li: la stessa pagina di Wikipedia dalla qualesiamo partiti per realizzare la pagina male-vola ed una pagina di Facebook. Registran-do ed analizzando i consumi, abbiamo potutoconfrontarli (Figura 24).

4.5 Massive Dynamic Web Attack

In seguito ai normali test, abbiamo voluto di-scostarci dai soli obiettivi prefissati di BatteryDrain Attack, cercando di testare i limiti distress sopportabili da un dispositivo mobile.Abbiamo creato una ulteriore pagina web ma-levola di Dynamic Web Attack, nella qualeabbiamo incluso gli script malevoli descrittiin precedenza e forzato, in maniera dinami-ca, l’inserimento dei contenuti multimediali adintervalli di 1 secondo. Conducendo l’esperi-mento sul dispositivo sotto testing, abbiamonotato che dopo soli 3’ e 10”, si verificavaun overflow in memoria, il browser e tuttele altre applicazioni e servizi in esecuzione inbackground, compreso il servizio di gestionedella UI, venivano chiusi da Android stessocon la conseguente perdita di dati non salvatied un consumo ulteriore dovuto al riavviodell’interfaccia.

Figura 25: Composizione del circuito.

5 VALIDAZIONELe misurazioni effettuate durante la fase disperimentazione sono state validate attraversol’uso di un multimetro (mod. DT830 DigitalMultimeter). Sono stati effettuati due tipi di test:test di amperaggio e test di voltaggio.

5.1 Test di amperaggioIl circuito (Figura 25) e stato realizzato colle-gando in serie il multimetro, la batteria e il di-spositivo mobile. L’obiettivo della validazionee di verificare, attraverso strumentazione fisica,i risultati presentati da PowerTutor.

Attraverso il multimetro e stato misuratol’amperaggio all’interno del circuito, con il di-spositivo in funzione e col profiling di Power-Tutor attivo. Sono stati registrati i valori rilevatida PowerTutor (in mW e V) e dal multimetro(in A). Per confrontare i valori ottenuti da Po-werTutor con quelli del multimetro, sono staticonvertiti mW e V in A applicando la formula:

A =

(mW1000

)V

I risultati sono riassunti in tabella 5.PowerTutor Multimetro Errore Percentuale0,171 A 0,180 A 0,009 A 5%

Tabella 5: Risultati test amperaggio

Dai risultati si evince che l’errore commessoda PowerTutor in termini assoluti e dell’ordinedi mA (con uno scarto percentuale del 5%).


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

5.2 Test di voltaggio

Utilizzando gli stessi strumenti utilizzati du-rante il test di amperaggio, e stata modificatala struttura del circuito ponendo in parallelo ilmultimetro, per misurare il voltaggio. I risultatiottenuti sono riassunti in tabella 6.

PowerTutor Multimetro Errore Percentuale3,77 V 3,97 V 0,20 V 5,3%

Tabella 6: Risultati test voltaggio

Confrontando i risultati si e evinto che ilvalore di errore, anche in questo caso risultaessere del 5%.

6 CONCLUSIONI

Valutando i risultati ottenuti in fase di testinge emerso che i codec piu dispendiosi in ter-mini energetici sono risultati essere H264 peri contenuti video e Wave per gli audio. Questiformati sono stati inseriti poi in una normale

pagina HTML statica di Wikipedia, in manie-ra invisibile, insieme ad altri script esposti inprecedenza, per creare la pagina web malevola.

Confrontando il consumo energetico dellapagina da noi realizzata con i normali siti webdi comune utilizzo siamo riusciti ad ottenere unconsumo energetico pari ad 11 volte il consumodella stessa pagina in HTML e consumi parial 4.5 volte maggiori rispetto ad una pagina diFacebook. Siamo giunti alla conclusione che at-traverso l’impiego malevolo delle piu semplicie note tecnologie web, si ottengono consumienergetici tali da portare la batteria del dispo-sitivo in uso alla scarica in tempi molto piubrevi.

Una possibile soluzione che un utente puoutilizzare al fine di evitare attacchi di questogenere, puo essere quella di disabilitare l’e-secuzione di codice JavaScript. Cio comportaovviamente il vantaggio di essere meno vulne-rabile ad attacchi che sfruttino le potenzialitadi questo linguaggio, ma lo svantaggio di nonpoter usufruire di contenuti dinamici offerti


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

ormai da numerose pagine web. Se l’utenteriesce ad individuare la pagina web che pro-voca il consumo anomalo della batteria delproprio dispositivo, si consiglia di contattarel’amministratore del sito.

7 SVILUPPI FUTURI

Il naturale proseguimento di tale studio e rap-presentato dal continuo aggiornamento dei casidi test, sia per quanto riguarda i nuovi co-dec multimediali che verranno introdotti, siaper le future tecnologie web che si avranno adisposizione.

Si necessita, inoltre, di incrementare il nu-mero di dispositivi su cui effettuare bench-mark. Una possibile soluzione potrebbe esse-re il rilascio dell’applicazione ”Battery Bench”sullo store Android in modo da ricevere ano-nimamente log di esecuzioni di test da utentivolontari.

Un ulteriore sviluppo potrebbe essere quellodi creare un’applicazione che sia in grado di

rilevare e difendere l’utente da eventuali attac-chi di Denial of Service energetico. Le possibilistrategie di difesa potrebbero essere due:

• Analisi statica del codice sorgente dellepagine web prima di essere caricate inmodo da individuare il codice malevolo.

• Analisi dinamica delle prestazioni e deiconsumi della batteria in modo da av-vertire prontamente l’utente e bloccarel’esecuzione del codice.

APPENDICE ARISULTATI TEST CODEC

A.1 Codec Audio

CPU Audio Wi-FiWave 93.40 134.10 94.90Opus 58.40 128.20 72.60

Vorbis 49.80 122.80 65.20WebM 87.20 117.20 61.70

MP3 98.80 116.90 69.40AAC 47.10 118.80 60.40

Tabella 7: Valori di consumo energetico (espressi inJoule) ottenuti dal testing dei codec audio per 5 minuti.



Vorbis 318.90 364.80 185.10WebM 307.80 357.50 197.10

MP3 289.30 313.80 161.90AAC 297.70 343.80 178.80



Vorbis 667.70 695.10 329.10WebM 665.90 689.80 318.50

MP3 689.90 693.10 247.60AAC 669.40 675.10 269.30


A.2 Codec Video

CPU LCD Audio Wi-FiH264 93.20 289.80 109.80 50.80

WebM 97.50 278.50 90.30 66.80H264 vol. 0 87.70 284.50 106.40 63.10

WebM vol. 0 91.50 273.20 76.80 52.80

Tabella 10: Valori di consumo energetico (espressi inJoule) ottenuti dal testing dei codec video per 5 minuti.


WebM 297.60 825.30 323.30 129.70H264 vol. 0 268.20 826.50 332.90 126.40

WebM vol. 0 270.50 815.70 331.40 128.20



WebM 637.70 1589.00 665.10 191.80H264 vol. 0 558.40 1689.10 581.00 230.50

WebM vol. 0 548.70 1654.00 565.50 196.40


APPENDICE BRISULTATI TEST LOCALI

CPU LCD AudioH264 52.40 311.40 118.30

WebM 48.90 310.90 107.20

Tabella 13: Valori di consumo energetico (espressi inJoule) ottenuti dai test di riproduzione in ambiente localedei file video per 5 minuti.

CPU LCD AudioH264 167.50 840.70 342.50

WebM 154.80 835.50 317.90


CPU LCD AudioH264 328.80 1674.00 692.40

WebM 318.40 1643.00 691.80


CPU AudioMP3 37.10 109.90

Wave 39.80 112.60Vorbis 32.40 111.80

AAC 29.40 110.50WebM 34.90 111.80

Tabella 16: Valori di consumo energetico (espressi inJoule) ottenuti dai test di riproduzione in ambiente localedei file audio per 5 minuti.

CPU AudioMP3 99.50 345.60

Wave 118.40 364.80Vorbis 112.90 353.90

AAC 118.10 365.10WebM 115.80 328.90



CPU AudioMP3 214.80 695.40

Wave 235.90 701.90Vorbis 221.90 675.10

AAC 117.80 698.20WebM 221.30 687.50


APPENDICE CRISULTATI TEST SITO MALEVOLO

CPU Wi-Fi AudioInfrasounds 54.90 197.70 117.80

Audio 61.20 186.80 110.60Video 84.20 161.80 60.30

Web Storage 113.90 13.80 0.00Ajax 32.50 34.60 0.00

Fonts 28.50 39.40 0.00

Tabella 19: Valori di consumo energetico (espressiin Joule) ottenuti dallo stress test per ogni opzioneapplicabile.

CPU Wi-Fi AudioStatic HTML 25.70 33.60 0.00

Battery Drain Attack 283.80 228.36 153.90facebook.com 75.40 72.70 0.00

Tabella 20: Valori di consumo energetico (espressi inJoule) ottenuti dal confronto delle diverse pagine webprese in esame.

APPENDICE DINVENTARIO FILE UTILIZZATI

Type Codec SizeAudio AAC 28.8 MBAudio MP3 28.9 MBAudio Ogg Opus 34.1 MBAudio Ogg Vorbis 28.1 MBAudio Wave 318.3 MBAudio WebM 28.9 MBVideo H264 43.4 MBVideo WebM 15.4 MBAudio Infrasuono Wave 53.1 MB

Tabella 21: File utilizzati

APPENDICE ECODICE SORGENTE

Di seguito vengono elencati i file sorgenti uti-lizzati durante la sperimentazione, disponibilial seguente link: https://www.dropbox.com/sh/cxgyl09fzdjoagj/5ShETNttio

audioB a t t e r y T e s t . phps t r e s svideo

./ audio :

s r cTestAudioAac . htmlTestAudioMP3 . htmlTestAudioOpus . htmlTestAudioVorbis . htmlTestAudioWav . htmlTestAudioWebM . html

./ audio/ s r c :

audio . aacaudio . m4aaudio . mp3audio . ogg opus . opusaudio . ogg vorbis . oggaudio . wavaudio .webm

./ s t r e s s :

addAudio . phpaddFonts . phpaddInfra . phpaddObj . phpa j a x . phpaudioaudio . phpBatteryDrainAttack . phpdoRequest . phpf i l l &erase . j sf o n t s . phpf o n t s . t x ti n f r a

https://www.dropbox.com/sh/cxgyl09fzdjoagj/5ShETNttio

https://www.dropbox.com/sh/cxgyl09fzdjoagj/5ShETNttio


infrasounds . phplinkAudio . t x tl i n k I n f r a . t x tl i n k . t x tS i c u r e z z a f i l e sS icurezza . htmlvideovideo . 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 :

s r cTestVideoH264 . htmlTestVideoH264NoAudio . htmlTestVideoWebM . htmlTestVideoWebMNoAudio . html

./ video/ s r c :

NoAudio . mp4NoAudio .webmvideo . mp4video .webm

RINGRAZIAMENTI

Si ringraziano gli autori di PowerTutor per lalicenza libera (GNU General Public License) sottola quale e stata rilasciata la sopracitata ap-plicazione, utilizzata nel nostro studio per ilrilevamento dei consumi energetici.

RIFERIMENTI BIBLIOGRAFICI

[1] Ryan Reith, Tom Mainelli e Michael Shirer ”IDC ForecastsWorldwide Tablet Shipments to Surpass Portable PC Shipmentsin 2013, Total PC Shipments in 2015”http://www.idc.com/getdoc.jsp?containerId=prUS24129713, 28 Maggio 2013.

[2] Legge di Moorehttp://it.wikipedia.org/wiki/Legge di Moore, 1965.

[3] A. Carroll e G. Heiser ”An Analysis of Power Consumptionin a smartphone”, In Proceedings of the 2010 USENIXconference 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 andAutomatic Battery Behavior Based Power Model Generation forSmartphones”, In Proceedings of the 8th IEEE/ACM/IFIPInternational Conference on Hardware/Software Codesignand System Synthesis 2010, pp. 1-10.

[5] Compatibility table for support of the Ogg/Theora videoformathttp://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 Traffic And Quality Comparison Of VP8 AndH264 SVC”, In Proceedings of the 3rd Workshop on MobileVideo Delivery, 2010, pp. 1-5.

[8] T.K.Buennemeyer, M. Gora, R. Marchany e J. Tront:”Battery Exhaustion Attack Detection With Small HandHeldMobile Computers”, In Proceedings of IEEE InternationalConference on Portable Information Devices, 2007, pp. 1-5.

[9] HTML5 Autoplay, Loop and Muted: table list of whichbrowser support the autoplay, loop and muted attributeshttp://www.longtailvideo.com/html5/autoloop/.

[10] WikipediaBootstrapping (statistics)http://en.wikipedia.org/wiki/Bootstrapping (statistics).

http://www.idc.com/getdoc.jsp?containerId=prUS24129713

http://www.idc.com/getdoc.jsp?containerId=prUS24129713

http://it.wikipedia.org/wiki/Legge_di_Moore

http://caniuse.com/ogv

http://developer.android.com/guide/appendix/media-formats.html

http://developer.android.com/guide/appendix/media-formats.html

http://www.longtailvideo.com/html5/autoloop/

http://en.wikipedia.org/wiki/Bootstrapping_(statistics)

Uno Studio Empirico sui Consumi Energetici in Ambiente Android

Technology

Transcript of Uno Studio Empirico sui Consumi Energetici in Ambiente Android