eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Bakalá°ská práce
Záznam provozních dat z mobilního telefonu na platform¥ Android
Martin Jelínek
Vedoucí práce:
Mgr. Michal Ficek
Studijní program: Softwarové technologie a management, Bakalá°ský
Obor: Web a multimedia
27. kv¥tna 2011
iv
v
Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).
Ve Slaném dne 20. 5. 2011
.............................................................
vi
Abstract This work deals with development of application for mobile phone running on Android platform. Application should enable to record information available from device. It includes network information (such as Cell ID, MNC, MCC, LAC, signal strength), information about user (date and time of sent/received SMS and outgoing/incoming calls), information about user's location (GPS coordinates) and information about network (cells information). This data should be send in regular interval to the remote server over GPRS, where it is stored in MySQL database by script. Simple server which would accept this data is also part of this work.
Abstrakt Tato práce se zabývá vývojem aplikace pro mobilní za°ízení b¥ºící na platform¥ Android. Aplikace má umoºnit zaznamenávání informací dostupných ze za°ízení uºivatele. Jedná se o informace o síti (Cell ID, MNC, MCC, LAC, sílu signálu), informace o uºivateli (datum a £as odeslaných/p°ijatých SMS/hovor·, doba hovoru), informace o poloze (GPS sou°adnice) a informace o síti (bu¬ky ve kterých se telefon vyskytuje). Takto zaznamenaná data má aplikace posílat v pravidelném intervalu na vzdálený server p°es GPRS, kde mají být skriptem uloºeny v databázi MySQL. Jednoduchý server, pro zpracování zaslaných dat je také sou£ástí této práce.
vii
viii
Obsah 1 Úvod
1
2 Popis problému, speci kace cíle
3
2.1 2.2 2.3 2.4
Cell Global Identity . . . . . . . . . . . . . . . Síla signálu . . . . . . . . . . . . . . . . . . . . Sousední bu¬ky . . . . . . . . . . . . . . . . . . Lokalizace (Globální Polohovací Systém) . . . . 2.4.1 Asistovaný Globální Polohovací Systém
. . . . .
3 Google Android Platform 3.1 3.2 3.3
3.4 3.5 3.6
Architektura Google Android Platform . . . . . . Aplikace na Google Android Platform . . . . . . Aplika£ní komponenty . . . . . . . . . . . . . . . 3.3.1 Activities (aktivity) . . . . . . . . . . . . 3.3.2 Services (sluºby) . . . . . . . . . . . . . . 3.3.3 Content provider (poskytovatel obsahu) . 3.3.4 Broadcast receiver (p°íjemce broadcast·) . Aktivování komponent . . . . . . . . . . . . . . . Soubor AndroidManifest.xml . . . . . . . . . . . SQLite databáze . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . .
4 4 4 5 5
7
. 7 . 8 . 8 . 8 . 9 . 9 . 9 . 9 . 10 . 10
4 Analýza a návrh °e²ení
11
5 Realizace
13
4.1 5.1
5.2 5.3 5.4 5.5
Výb¥r vývojového prost°edí . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Aktivity a sluºby . . . . . . . . . . . . 5.1.1 Záznam hovor· . . . . . . . . . 5.1.2 Záznam bun¥k . . . . . . . . . 5.1.3 Záznam SMS zpráv . . . . . . . 5.1.4 Záznam síly signálu . . . . . . 5.1.5 Záznam gps . . . . . . . . . . . Ukládání záznam· . . . . . . . . . . . Odesílání záznam· na vzdálený server Php skript na vzdáleném serveru . . . Graphical User Interface . . . . . . . . ix
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
13 14 15 15 16 16 16 17 18 18
x
OBSAH
6 Testování v pr·b¥hu realizace
19
7 Záv¥r
21
A Seznam pouºitých zkratek
25
B Instala£ní a uºivatelská p°íru£ka
B.1 Instala£ní p°íru£ka . . . . . . . . . . B.2 Uºivatelská p°íru£ka . . . . . . . . . B.3 Programátorská p°íru£ka . . . . . . . B.3.1 Struktura projektu na Google B.3.2 Moºná vylep²ení . . . . . . . B.3.3 Roz²í°ení . . . . . . . . . . .
C Obsah p°iloºeného CD
. . . . . . . . . . . . . . . Android . . . . . . . . . .
. . . . . . . . . . . . . . . . . . Platform . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
27
27 27 27 28 28 29
31
Seznam obrázk· 2.1 2.2
Struktura globální identity bu¬ky . . . . . . . . . . . . . . . . . . . . . . . . . Princip Asistovaného Globálního Polohovacího Systému (AGPS), p°evzato z [2]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3.1
GAP architektura (p°evzato z [9]) . . . . . . . . . . . . . . . . . . . . . . . . .
8
4.1
Android emulátor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1 5.2 5.3 5.4
ivotní cyklus aktivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ivotní cyklus sluºby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Úryvek ze speci kace 3GPP TS 27.007 8.5 o RSSI viz [10]. P°evod síly signálu v RSSI na dBm. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GUI aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1
P°ipojení k emulátoru p°es protokol telnet . . . . . . . . . . . . . . . . . . . . 19
5
14 14 16 18
B.1 Adresá°ová struktura Android projektu v Eclipse IDE . . . . . . . . . . . . . 28
xi
xii
SEZNAM OBRÁZK
Kapitola 1
Úvod V dne²ní dob¥ jsou mobilní telefony stále více vybavovány technologiemi, které umoº¬ují snímat prost°edí, ve kterém se uºivatel pohybuje. Sou°adnice z GPS, informace o bu¬kách, ve kterých se telefon vyskytuje, informace o hovorech a dal²í. Tato data se dají vyuºít mnoha zp·soby. Výhoda mobilních telefon· je v tom, ºe je uºivatelé mají prakticky stále u sebe a jen málokdy je odkládají. Díky tomu se dají sbírat velice bohaté informace, které najdou své vyuºití ve velkém mnoºství obor·. Nap°íklad ze záznam· o pozici telefonu se dají ur£it p°átelské vztahy mezi lidmi (viz [3]). Ke sb¥ru takových dat je pot°eba software, který je zaznamená, zpracuje, p°ípadn¥ ode²le na server, kde je skript uloºí do MySQL databáze.
1
2
KAPITOLA 1.
ÚVOD
Kapitola 2
Popis problému, speci kace cíle Cílem mé práce je naprogramovat aplikaci pro mobilní telefon s platformou Android. Aplikace by m¥la být schopna shromaº¤ovat data o uºivateli a jeho okolí, zaznamenávat je do úloºi²t¥ telefonu a pravideln¥ posílat na server, kde je skript uloºí do MySQL databáze. Kaºdý záznam by m¥l obsahovat £asový údaj, kdy byla daná událost provedena, pop°ípad¥ zaznamenána, pokud se jedná o událost kontrolovanou v n¥jakém intervalu. Konkrétn¥ se nám jedná o tato data: Cell Global Identity (CGI), síla signálu, sousední bu¬ky, hovory, textové zprávy, lokalizace (Globální Polohovací Systém). Podobné aplikace jsou namátkou: Netmonitor , Cell ID logger nebo GPS logger a mnoºství dal²ích. Data sbíraná telefonem jsou hodnotná pro studie chování lidí. Nap°íklad studie [3] se zabývá porovnáváním zvyk· lidí ºijících na venkov¥ a ve velkých m¥stech. Z dat, která byla p°i výzkumu shromáºd¥na a zpracována, do²li auto°i k zajímavým výsledk·m. Lidé z venkova mají mén¥ p°átel, ale udrºují s nimi pevn¥j²í vazby, p°i zm¥n¥ prost°edí jedinec p°izb·sobí styl komunikace a lidé z venkova se p°epravují na v¥t²í vzdálenosti neº lidé z velkom¥sta. Dal²í studie [12] popisuje algoritmy pro vypo£ítání rychlosti pohybu telefonu na základ¥ toho, jak se m¥ní síla signálu bu¬ky. To, jak rychle se za°ízení pohybuje, je d·leºitý fakt pro zlep²ení výkonu bezdrátové sít¥. Záznamy hovor·, vyuºití aplikací, statusu telefonu a záznamy o bu¬kách a bluetooth za°ízeních vyuºili auto°i práce [4] data ke studiu lidského chování. Výsledky pak porovnávali s daty, která o sob¥ uºivatelé nahlásili samy. Ve vysokém po£tu p°ípad· (uvádí aº 95%) se jim poda°ilo správn¥ ur£it p°átelské vztahy. V práci [11] autory zajímalo, zda se dají záznamy o identi kátorech bun¥k vyuºít k zlep²ení vyhledávání informací. Nap°íklad vyhledání kina v mém okolí. Do²li k záv¥ru, ºe takovýmto zp·sobem se data vyuºít efektivn¥ nedají, ale je moºné je vyuºít p°i lokalizaci za p°isp¥ní uºivatele. To má fungovat tak, ºe uºivatel °ekne do telefonu svoji adresu, po£íta£ p°evede hlas na text a zjistí jakou polohu mu uºivatel sd¥lil. To je pro po£íta£ náro£ná operace a rychlost výpo£tu závisí na velikosti slovníku (potaºmo po£tu slov, které musí po£íta£ s hlasem porovnat). Díky tomu, ºe má k dispozici identi kátor bu¬ky, kde se uºivatel nachází, zúºí se mu slovník na malou oblast a výpo£et je proto mnohem rychlej²í. 3
4
2.1
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Cell Global Identity
Mobilní sí´ vyuºívá ke komunikaci rádiové vlny. Kaºdý operátor má p°id¥len rozsah frekvencí které m·ºe pouºívat. Rozsah není tak velký aby vysta£il pro ve²kerou komunikaci. Proto je území pokryté signálem rozd¥leno na samostatné celky. T¥mto celk·m se °íka bu¬ky. V bu¬ce je vysílací stanice nebo také základní stanice (BS, Base Station). Zjednodu²en¥ se jedná o anténu schopnou vysílat a p°ijímat radiový signál. Kaºdá bu¬ka sousedí s n¥kolika dal²ími a má sv·j frekven£ní rozsah. Nesousedící bu¬ky mohou mít stejný rozsah frekvencí a tím je zaji²t¥n dostatek kanál· pro uskute£n¥ní ve²keré komunikace. Mobilní za°ízení se p°ipojují k bu¬kám, které jim umoº¬ují komunikaci s dal²ími p°ístroji. Kaºdý mobilní telefon, který je p°ipojen k bu¬ce, o ní má k dispozici informace, které chceme zaznamenat. Cell Global Identity (CGI, viz obrázek (2.1)) je identi kátorem bu¬ky. Je významný p°i ur£ování geogra cké polohy p°ipojených mobilních za°ízení. Pozice telefonu m·ºe být zji²t¥na práv¥ na základ¥ CGI bu¬ky, ve které se za°ízení nachází. CGI se skládá ze 4 £ástí, které popisuji dále. MCC (Mobile Country Code) je 3 ciferné £íslo ur£ující kód státu, ve kterém se bu¬ka nachází. MNC (Mobile Network Code) je 1-3 ciferné £íslo udávající konkrétní sí´ v daném stát¥. Kaºdá bu¬ka v rámci sít¥ má svoje identi ka£ní £íslo (CID, Cell ID). Pro snadn¥j²í identi kaci jsou bu¬ky seskupeny do oblastí v rámci jednoho státu zvaných Location Area, které mají také svoje identi ka£ní £íslo (LAC, Location Area Code). LAC i CID jsou maximáln¥ 16ti bitová £ísla.
Obrázek 2.1: Struktura globální identity bu¬ky
2.2
Síla signálu
Data mezi telefonem a vysílací stanicí se p°ená²ejí pomocí elektromagnetických vln. Vlna musí být dostate£n¥ silná aby ji p°ijíma£ (telefon) dokázal rozpoznat a odli²it od ²umu na pozadí. Síla signálu je obvykle udávána v decibelech na jeden miliwat (dBm). Dal²í pouºívaná hodnota je udávána v odstupu signálu od ²umu (SNR, Signal to Noise Ratio). SNR je pouze relativní hodnota a udává o kolik je siln¥j²í signál oproti ²umu.
2.3.
SOUSEDNÍ BUKY
2.3
5
Sousední bu¬ky
Mobilní sí´ se skládá z bun¥k, které spolu sousedí (viz kapitola 2.1). Mobilní telefon obvykle p°íjímá signál v²ech okolních bun¥k. Signál sousedních bun¥k se p°ekrývá, aby bylo moºné plynule p°ejít z jedné bu¬ky do druhé. Kdyº se uºivatel pohybujena rozhraní bu¬ek, telefon zaznamená v¥t²í sílu signálu nové bu¬ky, v ur£itém moment¥ se odpojí od staré a p°ipojí se k nové. Tomuto jevu se anglicky °íká hando (ruce pry£).
2.4
Lokalizace (Globální Polohovací Systém)
Global Positioning System(GPS) je globální naviga£ní satelitní systém, poskytující informaci o pozici a £ase na celé planet¥ nezávisle na po£así. Podmínkou je aby dané za°ízení vyuºívající GPS m¥lo p°ímý výhled na alespo¬ 4 GPS satelity najednou. Tento systém je vlastn¥n vládou Spojených stát· amerických, ale je dostupný pro ve°ejnost. 2.4.1
Asistovaný Globální Polohovací Systém
Asistovaný Globální Polohovací Stém (AGPS, obrázek 2.2) efektivn¥ zkracuje £as p°i prvotním získávání GPS pozice. Pro stanovení pozice musí telefon nejd°íve najít frekvenci na které satelit vysílá a pak p°ijmout a dekódovat data vysílaná satelitem. P°íjem dat od satelitu bývá ve srovnání s p°íjmem dat z mobilní sít¥ o dost pomalej²í. Kaºdý satelit má navíc jinou frekvenci, takºe ur£ení polohy jen pomocí informací ze satelit· m·ºe být problematické. Zvlá²t¥ pak v oblastech se ²patným výhledem na oblohu. Systém AGPS poskytuje data o frekvencích a pozicích satelit· p°ez mobilní sí´ GPS p°ijíma£·m a díky tomu zna£n¥ urychluje celý proces komunikace telefonu se satelitem.
6
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Obrázek 2.2: Princip Asistovaného Globálního Polohovacího Systému (AGPS), p°evzato z [2].
Kapitola 3
Google Android Platform V této kapitole se v¥nuji platform¥ na které je má aplikace vyvíjena. Google Android Platform (GAP) je softwarový balík pro mobilní za°ízení a skládá se z opera£ního systému, middlewaru a n¥kolika základních aplikací. Pro snadn¥j²í orientaci v tomto dokumentu je nutné znát základy GAP struktury. GAP byla vyvinuta od základu, aby dala moºnost vývojá°·m potaºmo uºivatel·m naplno vyuºívat moºnosti mobilního za°ízení. Vývojá° pí²e aplikace v jazyce Java a má k dispozici prost°edky k tomu, aby napsal velice bohatou a robustní aplikaci. Android je postaven na otev°eném jádru Linuxu a vyuºívá virtuální stroj, který byl vyvinut speciáln¥ pro optimální vyuºití pam¥ti a hardwaru pro mobilní za°ízení. Platforma je open source, takºe kdokoliv m·ºe projekt p°evzít a libovoln¥ roz²í°it. S vývojem za£la splole£nost Google a pozd¥ji se k ní p°idaly dal²í spole£nosti. V dne²ní dob¥ tvo°í 48 spole£ností sdruºení Open Handset Aliance (OHA), která se stará o vývoj této platformy. K dispozici je Android SDK (Software Development Kit), který poskytuje knihovny pro vývojá°e.
3.1
Architektura Google Android Platform
Platforma Android je zaloºena na jádru Linuxu verze 2.6 (obrázek 3.1), který se stará o správu pam¥ti, zabezpe£ení systému, správu proces·, sí´ovou komunikaci, ovlada£e atd. a navíc spojuje softwarovou a hardwarovou vrstvu. Vrstva Android Runtime se skládá z v¥t²iny základních knihoven programovacího jazyka Java a Dalvik Virtual Machine (Dalvik VM). Kaºdá aplikace na platform¥ Android b¥ºí ve svém vlastním procesu, který má kaºdý svou instanci Dalvik VM. Dalvik VM je uzp·sobena k tomu, aby mohla být efektivn¥ spu²t¥na ve více instancích najednou a s minimální spot°ebou pam¥ti. Dal²í vrstva architektury jsou C/C++ knihovny. Namátkou knihovna SQLite umoº¬uje ukládat data na disk nebo vým¥nnou kartu mobilního za°ízení v podob¥ odleh£ené rela£ní databáze. Surface Manager je zodpov¥dný za vykreslování gra ky na display a FreeType je renderer vektorových a bitmapových font·. Vývojá°, stejn¥ tak jako základní aplikace dodávané s telefonem, mají ke knihovnám plný p°ístup p°es Aplication Framework. Tato architektura je navrºena tak, aby se jakákoliv komponenta dala znovu pouºít. Pokud nap°íklad programátor pí²e aplikaci, která mimo 7
8
KAPITOLA 3.
GOOGLE ANDROID PLATFORM
jiné posílá emaily, m·ºe pouºít komponentu, která jiº existuje a pouze jí p°edat parametry emailu. Ten se pak po²le jejím prost°ednictvím a programátor si u²et°í spoustu práce. Díky tomuto mechanizmu mohou být také komponenty nahrazovány. Kdyº nap°íklad n¥komu nebude vyhovovat práv¥ komponenta, která se stará o odeslání mailu, m·ºe si napsat svoji vlastní. V aplika£ní vrstv¥ jsou pak samotné aplikace. N¥které jsou dodávané jiº s telefonem jako je email klient, kalendá°, mapy, internetový prohlíºe£ a jiné jsou ke staºení online nebo si kaºdý m·ºe naprogramovat vlastní.
Obrázek 3.1: GAP architektura (p°evzato z [9])
3.2
Aplikace na Google Android Platform
Kód pro aplikace na GAP je psán v jazyce Java a zkompilováním nástroji SDK z n¥j vznikne soubor, ve kterém jsou zabalené ve²keré zdroje, pot°ebné pro b¥h programu. Tomuto souboru se °íká Android Package a má koncovku .apk. Kaºdý soubor s touto koncovkou je povaºován v rámci Android platformy za jednu aplikaci a je to to jediné co je pot°eba k jejímu nainstalování a b¥hu.
3.3.
APLIKANÍ KOMPONENTY
9
Opera£ní systém (OS) Android je tzv. multi-user, tedy víceuºivatelský. Kaºdá aplikace je povaºována za jiného uºivatele a má p°i°azené své ID. P°i°azení ale probíhá ale na bázi OS a aplikace ho k dispozici nemá. Na základ¥ ID nastavuje OS povolení p°ístupu k soubor·m. Kaºdý proces b¥ºí odd¥len¥ od ostatních a má svoji Dalvik VM. Je spu²t¥n systémem a v moment¥, kdy není nadále pot°eba nebo kdyº je nedostatek pam¥ti, ho OS ukon£í. N¥kdy je t°eba sdílet soubory (datové zdroje) mezi aplikacemi. Toho se dá docílit dv¥ma zp·soby. Dv¥ aplikace mohou mít stejné ID a pro ²et°ení prost°edk· i b¥ºet ve stejném procesu a sdílet Dalivk VM. Nebo m·ºe aplikace zaºádat o povolení k p°ístupu k dat·m jako nap°íklad kontakty, SMS zprávy, le system a pod. Tyto ºádosti jasn¥ povoluje uºivatel p°i instalaci aplikace.
3.3
Aplika£ní komponenty
Stavebními kameny kaºdé aplikace na GAP jsou aplika£ní komponenty. N¥které jsou vstupními body pro komunikaci s uºivatelem, jiné zas pro komunikaci se systémem. V²echny existují jako samostatné entity a mají svou speci ckou roli.
3.3.1
Activities (aktivity)
Aktivity reprezentují uºivatelské rozhraní aplikace. Jedna aktivita odpovídá jednomu oknu aplikace. Nap°íklad email klient m·ºe mít aktivitu, která zobrazí seznam po²ty a druhou pro vytvo°ení nové zprávy. I kdyº tvo°í jeden celek, jsou na sob¥ nezávislé a pokud to aplikace dovoluje, dá se pouºít aktivita z jedné aplikace úpln¥ jinou aplikací. Nap°íklad by aplikace, která zji²´uje pozici, m¥la mít moºnost poslat pozici emailem. Sta£ilo by poslat poºadavek aktivit¥ emailového klienta, p°edat jí polohu a ta by email odeslala.
3.3.2
Services (sluºby)
Sluºba je komponenta, která b¥ºí na pozadí a nemá ºádné uºivatelské rozhraní. Pouºívá se, kdyº je t°eba vykonat dlouho b¥ºící operace nebo jinou £innost, u které není nutná interakce s uºivatelem. Sluºba m·ºe nap°íklad na pozadí p°ehrávat hudbu, zatímco uºivatel pouºívá ·pln¥ jinou aplikaci.
3.3.3
Content provider (poskytovatel obsahu)
Poskytovatel obsahu se stará o p°ístup ke sdíleným dat·m. Jeho pomocí mohu ve svém programu ukládat, £íst a modi kovat data v databázi, na webu nebo na pevném disku (p°ípadn¥ vým¥nné kart¥). Tato komponenta nap°íklad umoº¬uje p°ístup k informacím o kontaktech. Poskytovatel obsahu se nepouºívá jen k p°ístupu ke sdíleným dat·m, ale i k privátním, v rámci jedné aplikace.
10 3.3.4
KAPITOLA 3.
GOOGLE ANDROID PLATFORM
Broadcast receiver (p°íjemce broadcast·)
Broadcast receiver je komponenta, která odpovídá na broadcast(vysílání). Takové vysílání m·ºe pocházet od systému. Typický broadcast je nap°íklad v situaci, kdy je vypnut displej, stav baterie je nízký nebo je vyfocen obrázek. Systém o tom informuje naslouchající receiver, který ho zachytí a m·ºe s ním n¥jak naloºit. V¥t²inou volá sluºbu nebo aktivitu nebo má moºnost vytvo°it oznámení na stavovém panelu telefonu. Samotný receiver nemá uºivatelské rozhraní, stejn¥ jako sluºba. Vysílání nemusí pocházet jen od systému, kaºdá aplikace m·ºe inicializovat svoje broadcasty. Nap°íklad v aplikaci, ve které bude sluºba zaznamenávat signál, m·ºe vytvo°it broadcast v moment¥, kdy se signál v²ech dostupných bun¥k sníºí na konkrétní hodnotu. Broadcast receiver ho p°ijme a vypne funkci automatického p°ipojování do mobilní sít¥, z d·vodu ²et°ení baterie.
3.4
Aktivování komponent
Aktivity, sluºby a broadcast receivery se aktivují asynchroní zprávou nazvanou intent. Intenty fungují jako po²´áci, kte°í doru£ují zprávy mezi jednotlivými komponentami. A to i nad rámec jedné aplikace. M·ºe spolu komunikovat více úpln¥ odli²ných aplikací. Intent je vytvo°en Intent objektem, který de nuje zprávu k aktivaci komponenty. Pro aktivity a sluºby intent de nuje akci, která má být provedena a £asto také URI dat, které komponenta pot°ebuje znát. Nap°íklad lze vytvo°it intent, který bude obsahovat poºadavek pro na£tení webové stránky. Komunikace pomocí intent· nemusí být pouze jednostranná, £asto je pot°eba zjistit výsledek dané akce. K tomu slouºí metoda startActivityForResult(), které se p°edá intent a kód daného poºadavku. Po ukon£ení ºádané akce se automaticky zavolá metoda onActivityResult() v komponent¥, ze které se poºadavek posílal a je jí p°edán kód daného poºadavku a výsledek £innosti v podob¥ intentu. Kód poºadavku tedy slouºí jako identi kace dané komunikace mezi komponentami. Nap°íklad kdyby programátor vytvá°el aplikaci, ve které chce poslat email. Je mu známo, ºe komponenta, vhodná pro odeslání emailu v systému, jiº existuje, takºe vytvo°í intent s akcí odeslat email, do kterého vloºí text zprávy, adresu odesílatele a p°íjemce, p°edm¥t, pop°ípad¥ cestu k p°íloze atd. a také kód poºadavku. Komponenta ode²le email a p·vodní aplikace pak obdrºí jiný intent se stejným kódem poºadavku, jaký m¥l první intent. V tom bude nap°íklad informace o úsp¥²ném odeslání emailu nebo naopak zpráva o nedostupnosti p°ipojení k síti.
3.5
Soubor AndroidManifest.xml
P°ed spu²t¥ním jakékoliv komponenty systém nejd°ív musí v¥d¥t o její existenci. Proto nejd°íve £te soubor AndroidManifest.xml v ko°enovém adresá°i projektu. Tento soubor má více funkcí. Obsahuje v²echny povolení, které aplikace pot°ebuje, jako nap°íklad p°ístup k internetu nebo ke kontakt·m. Pak také de nuje jakou minimální úrove¬ API aplikace vyºaduje pro správnou funk£nost. A deklaruje hardwarové a softwarové zdroje, které jsou aplikací pouºívány jako fotoaparát, bluetooth a dal²í. AndroidManifest.xml má i dal²í funkce. Toto byly pouze ty základní a nej£ast¥ji pouºívané.
3.6.
3.6
SQLITE DATABÁZE
11
SQLite databáze
Na telefonu s GAP se dají ukládat data do rela£ní databáze. Vzhledem k tomu, ºe pam¥´ové úloºi²t¥ telefonu je malé, pouºívá se na GAP odleh£ená verze SQL databáze SQLite. Ta má své omezení (nap°íklad nepodporuje v²echny SQL p°íkazy), ale pro mobilní za°ízení je výhodná hlavn¥ protoºe zabírá málo místa (okolo 300KB viz [10]).
12
KAPITOLA 3.
GOOGLE ANDROID PLATFORM
Kapitola 4
Analýza a návrh °e²ení Jelikoº m¥la být aplikace schopná ukládat záznamy, bylo t°eba zjistit kam se dají na GAP data uloºit. Android nabízí hned n¥kolik moºností. Shared preferences, coº jsou sdílená data ve formátu klí£/hodnota, dále pak Internal Storage, tedy interní úloºi²t¥ telefonu, External Storage (v p°ípad¥, ºe má telefon vým¥nné úloºi²t¥) a SQLite rela£ní databázi. Shared preferences jsou nedosta£ující a £tení a zápis do souboru je zbyte£n¥ komplikované, proti tomu SQLite databáze má bohaté nástroje pro práci s daty. Zaznamenávání dat je dlouhodobá záleºitost, takºe aplikace musí b¥ºet na pozadí aby uºivatel mohl telefon b¥hem této doby pouºívat. Aplikace musí poskytovat zp·sob jak zaznamenávání informací zapnout a vypnout, takºe musí mít Graphical User Interface (GUI, gra cké uºivatelské rozhraní). N¥které operace jako nahrávání záznam· na vzdálený server jsou £asov¥ náro£né a pokud by p°i tom m¥l uºivatel zaplé GUI, zamrzlo by mu a nebyl by schopen nic d¥lat, dokud se v²echna data neode²lou. Takºe je nutné pouºít vlákna. Dal²ím problémem je samotné odeslání záznam· na vzdálený server. Jedna z moºností je ukládání dat do soubor· a odesílání celých soubor· na server. Zápis a £tení ze souboru je ale komplikovan¥j²í neº vyuºití databáze. Proto je jednodu²²í posílat data na server p°ez HTTP poºadavek. Server poºadavek zpracuje a ode²le stejným zp·sobem odpov¥¤.
4.1
Výb¥r vývojového prost°edí
Neº jsem za£al kódovat, musel jsem si vybrat vývojové prost°edí (IDE, Integrated Development Enviroment). V moment¥, kdy jsem s projektem za£al, jsem nem¥l k dispozici ºádný telefon, na kterém bych napsaný program zkou²el. Pot°eboval jsem IDE s prost°edím schopným emulovat telefon. Na internetu jsem na²el informace hlavn¥ o IDE Eclipse a také zmínku o Intellij Idea. Odkaz· na Eclipse bylo markantn¥ více a po prostudování £eho je IDE schopné jsem se pro n¥j rozhodl. Do Eclipse se dá nainstalovat plugin ADT (The Android Developments Tool), který dokáºe telefon emulovat (obrázek 4.1) a má komfortní nástroje pro práci s GAP. Umoº¬uje práci s procesy, se systémem soubor·, zobrazuje výstup v p°ehledné konzoli, dají se s ním d¥lat screenshoty aplikace za b¥hu a hlavn¥ také podporuje debugování programu. P°i spou²t¥ní zabalí ve²keré zdroje do .apk souboru a nainstaluje na emulátor ve kterém pak aplikaci 13
14
KAPITOLA 4.
ANALÝZA A NÁVRH EENÍ
spustí. Dal²í moºností je pak spu²t¥ní aplikace p°ímo v telefonu, pokud je p°ipojen p°es USB konektor k po£íta£i.
Obrázek 4.1: Android emulátor
Kapitola 5
Realizace V této £ásti dokumentu se podrobn¥ zabývám samotnou implementací projektu. Popisuji jeho architekturu a dále se v¥nuji záznamu jednotlivých hodnot. Ke konci kapitoly rozeberu ukládání zaznamenaných dat v telefonu. A na úplný záv¥r popí²i php skript na vzdáleném serveru, který zpracovává data a ukládá je do MySQL databáze.
5.1
Aktivity a sluºby
Základem mé aplikace je hlavní aktivita, která p°edstavuje jedinou moºnost interakce s uºivatelem. Aktivita se vytvo°í zd¥d¥ním t°ídy Activity. Má n¥kolik metod, které souvisí s jejím ºivotním cyklem (obrázek 5.1). Metoda onCreate() je volána v moment¥ vytvo°ení aktivity, takºe v ní jsou inicializovány v²echny komponenty GUI. To znamená tla£ítka a textové inputy. Spu²t¥ní sluºeb, které se starají o záznam jednotlivých hodnot je °e²eno v metod¥ onStart(). Kdyº je aktivita spu²t¥na uºivatelem, vytvo°í instance jednotlivých sluºeb (tedy pokud jiº neb¥ºí), pop°ípad¥ se k nim p°ipojí (bind), pokud je pot°eba s konkrétní sluºbou komunikovat. P°ipojení aktivity ke sluºb¥ je speciální akce inicializovaná Intent objektem, kdy p°ipojená aktivita m·ºe volat metody sluºby dokud se neodpojí. V moment¥ kdy jiº není aktivita viditelná (kdyº uºivatel vypne GUI), se od sluºeb op¥t odpojí (unbind). Úplné zastavení sluºeb, které zaznamenávají data, jsem °e²il tla£ítkem shutdown all services v GUI. Pokud by uºivatel cht¥l vypnout jednotlivé zaznamenávací sluºby, má na GAP implicitn¥ k dispozici srávce aplikací, který to umoº¬uje. Dal²ím krokem bylo vytvo°it sluºby pro záznam jednotlivých hodnot. Podobn¥ jako aktivity mají sluºby sv·j ºivotní cyklus a vytvo°í se zd¥d¥ním t°ídy Service. Ov²em u sluºby jsou dv¥ moºnosti. První je sluºba, která je pouze vytvo°ena a spu²t¥na a není moºné se k ní p°ipojit, a druhá se spou²tí tak, ºe se k ní p°ipojí jiná komponenta, ale jakmile se odpojí, je ukon£ena (obrázek 5.2). Sluºby u kterých bylo t°eba nastavit limity neboj iné hodnoty jsem implementoval jako kombinaci obou typ·. Místo metody onCreate() vyuºívám metod onStartCommand() a onBind(), které jsou volány po metod¥ onCreate() podle toho, zda byla sluºba spu²t¥na nebo do£asn¥ spojena s hlavní aktivitou. V metod¥ onStartCommand() registruji poslucha£e událostí (listenery) nebo vytvá°ím £asova£e (timery), které jsou re15
16
KAPITOLA 5.
REALIZACE
prezentovány vláknem umoº¬ujícím spou²t¥t kód v pravidelných intervalech. A obdobn¥ v metod¥ onDestroy() listenery odregistrovávám a zastavuji £asova£e.
Obrázek 5.1: ivotní cyklus aktivity
5.1.1
Záznam hovor·
K údaj·m o telefonu se v Android API p°istupuje pomocí t°ídy TelefonyManager. Té m·ºeme zaregistrovat listener a naslouchat událostem, jako jsou hovory. Kód vypadá následovn¥:
TelephonyManager tm = (TelephonyManager) getSystemService(TELEPHONY_SERVICE); PhoneStateListener psl = new CallsLogger(this); tm.listen(psl, PhoneStateListener.LISTEN_CALL_STATE);
5.1.
AKTIVITY A SLUBY
17
Obrázek 5.2: ivotní cyklus sluºby
Nejprve tedy získám instanci t°ídy TelephonyManager z kontextu aplikace, pak jí zaregistruji poslucha£e událostí stavu telefonu (LISTEN_CALL_STATE). T°ída CallsLoogger je schopna naslouchat událostem stavu telefonu. V moment¥ kdy se stav zm¥ní, zavolá se její p°íslu²ná metoda s aktuálním stavem a £íslem volajícího (potaºmo volaného):
public void onCallStateChanged(int state, String phoneNumber) { switch(state) { case TelephonyManager.CALL_STATE_RINGING: //p°íchozí hovor - telefon zvoní break; case TelephonyManager.CALL_STATE_IDLE: //ºádná aktivita break; case TelephonyManager.CALL_STATE_OFFHOOK: //existuje alespo¬ jeden aktivní, vytá£ený nebo p°idrºený //hovor a ºádný nevyzvání
18
}
KAPITOLA 5.
}
REALIZACE
break;
Jelikoº se metoda onCallStateChanged() volá i v moment¥ kdy je aplikace spu²t¥na bylo nutné p°idat prom¥nnou pro kontrolu zda jde o první volání £i nikoliv. Ve stavu CALL_STATE_IDDLE tedy p°istoupím k dat·m o hovorech a vytáhnu si z nich poslední hovor, jak nazna£uje kód pod tímto odstavcem. Prom¥nná uri obsahuje informace o tom, k jakým dat·m chci p°istupovat. Pole string·, projection, p°edstavuje názvy sloupc·, které chci z databáze vybrat. K databázi p°istoupím pomocí ContentResolveru, který získám z aktuálního kontextu aplikace. Prom¥nná cur reprezentuje výsledek selektivního dotazu z databáze a obsahuje tedy v²echna poºadovaná data. Jeho iterací bych získal v²echny dostupné hovory provedené s aktuálním telefonem, m¥ ale sta£í poslední hovor a proto jsem v dotazu °adil hovory sesupn¥ podle ID. Díky tomu mám jako poslední prvek v prom¥nné cur uloºen poslední hovor. Pak uº jen zbývá získat konkrétní hodnoty a uloºit je do databáze.
Uri uri = CallLog.Calls.CONTENT_URI; String[] projection = new String[] { CallLog.Calls._ID, CallLog.Calls.NUMBER, CallLog.Calls.DURATION, CallLog.Calls.TYPE, CallLog.Calls.DATE }; Cursor cur = context.getContentResolver().query(uri, projection, null, null, CallLog.Calls._ID + " ASC"); int phoneNumberColumn = cur.getColumnIndex(CallLog.Calls.NUMBER); call.setPhoneNumber(cur.getString(phoneNumberColumn)); Logger.logCall(context, call); 5.1.2
Záznam bun¥k
Záznam bun¥k, ke kterým je telefon p°ipojen, je realizován podobn¥ jako záznam hovor·. Sluºba ale neregistruje listener, ale vytvá°í nové vlákno a nastavuje mu interval. V tomto intervalu se pak vykonává kód vlákna, který kontroluje zda do²lo ke zm¥n¥ bu¬ky £i nikoliv. V p°ípad¥ zm¥ny je bu¬ka zaznamenána. 5.1.3
Záznam SMS zpráv
Na GAP je p°íchozí zpráva oznámena v²em broadcast receiver·m, kte°í této události naslouchají. Záznam p°íchozích zpráv je realizován jedním broadcast receiverem. Ten je v souboru AndroidManifest.xml zaregistrován jako p°íjemce oznámení p°íchozí zprávy.
5.1.
AKTIVITY A SLUBY
19
Kdyº tedy p°íjde uºivateli SMS zpráva, vytvo°í se instance broadcast reveiveru a její metod¥ onReceive() se p°edá Intent objekt s informacemi o této události. Sou£ástí intentu jsou i parametry samotné zprávy. Ty zízkám tak, ºe z intentu p°e£tu data v podob¥ objektu Boundle a z n¥j pak dostanu samotnou zprávu (nebo více zpráv, pokud byla obdrºena zpráva p°esahující 160 znak·) ve formátu PDU (formát pro reprezentaci SMS zpráv obsahující dal²í metadata o p·vodu zprávy a podobn¥). Více informací o formátu PDU viz [1]. Nakonec p°evedeme zprávu na objekt Sms. Odchozí zpráva zatím bohuºel není oznamována ºádným broadcastem (Na fóru [7] je vlákno o poºadavku na vytvo°ení podobné funkcionality i pro odchozí SMS). Proto je záznam odchozí zprávy odli²ný od p°íchozí. Je realizován sluºbou a jedním vláknem. Sluºba p°i spu²t¥ní vytvo°í nové vlákno, které nastaví tak, aby se spou²t¥lo v pravidelném intervalu. Vlákno £te z úloºi²t¥ odeslaných SMS (stejný princip jako v 5.1.1 v £ásti o získávání posledního hovoru) zprávu s nejmlad²ím £asovým údajem, který pak porovnává s £asovým údajem naposledy zaznamenané odeslané SMS. V p°ípad¥, ºe je SMS zpráva nov¥j²í, dojde k jejímu zaznamenání. Ke sluºb¥ je moºné se p°ipojit z hlavní aktivity a nastavit interval spou²t¥ní vlákna. 5.1.4
Záznam síly signálu
Záznam síly signálu je implementován sluºbou a listenerem událostí telefonu. Ve sluºb¥ se vytvo°í instance listeneru a zaregistruje se pro naslouchání událostí zm¥ny signálu. Listeneru se p°i vytvo°ení p°edá hodnota prahu (treshold), který musí hladina signálu p°ekro£it o proti naposledy zaznamenané hodnot¥, aby se uloºila. P°i zm¥n¥ síly signálu a p°ekro£ení prahu se síla signálu p°epo£ítá ze získané hodnoty v jednotkách RSSI na dBm. (Podle speci kace 3GPP TS 27.007 8.5 ([10]) se dBm udává také v RSSI(Received Signal Strength Indication), jejíº p°evod je nazna£en na obrázku 5.3.)
Obrázek 5.3: Úryvek ze speci kace 3GPP TS 27.007 8.5 o RSSI viz [10]. P°evod síly signálu v RSSI na dBm.
5.1.5
Záznam gps
Stejn¥ jako u záznamu síly signálu (5.1.4) probíhá registrace listeneru naslouchajícího zm¥n¥ pozice. Místo t°ídy TelephonyManager se pouºije t°ída LocationManager a listener
20
KAPITOLA 5.
REALIZACE
se zaregistrovává v metod¥ requestLocationUpdates(), která krom¥ listeneru má také dal²í t°i parametry. Prvním je provider. Jsou dv¥ moºnosti, bu¤ GPS provider nebo network provider. D°íve jmenovaný se týká GPS polohy ze satelit· a druhý informací o poloze z bun¥k, ve kterých se telefon vyskytuje. Dal²í parametr udává jak £asto by se m¥l poºadavek na update pozice poslat. Pokud je nastaven na hodnotu r·znou od nuly, m·ºe být poºadavek na zji²t¥ní polohy odloºen o tuto dobu, ale je to jen doporu£ená hodnota, kterou se OS nemusí °ídit. Poslední parametr je minimální vzdálenost. Poºadavek na zji²t¥ní nové pozice se ode²le jen pokud se telefon posune alespo¬ o minimální vzdálenost.
5.2
Ukládání záznam·
T°ída Logger ukládá záznamy. Pouºívá SQLite databázi. Má metodu pro záznam kaºdé ukládané hodnoty a je²t¥ n¥kolik dal²ích metod, které slouºí k získávání nebo ukládání posledních zaznamenaných hodnot pro pozd¥j²í porovnání s aktuálními hodnotami, aby se dalo zjistit, zda se mají data uloºit nebo jsou jiº v databázi. (Jedná se nap°íklad o odeslané SMS zprávy které se musí kontrolovat v n¥jakém intervalu.)
5.3
Odesílání záznam· na vzdálený server
Odeslání záznam· na server je £asov¥ náro£ná operace, která trvá minimáln¥ n¥kolik vte°in, spí²e déle, pokud je záznam· hodn¥. Navíc je pot°eba je zasílat v pravidelném intervalu. Z toho d·vodu je tato funkcionalita spu²t¥na v odd¥lením vlákn¥, které je voláno v uºivatelem nastavitelném intervalu. Nebo se dá zavolat okamºit¥ z GUI. V metod¥ odesílající záznam jsou nejprve pomocí t°ídy TelephonyManager získány IMEI (International Mobile Equipment Identity) a IMSI (International Mobile Subscriber Identity). První je identi kátor mobilního za°ízení p°id¥lený výrobcem, který by m¥l být unikátní pro kaºdý telefon. IMSI je £íslo, p°id¥lené operátorem mobilní sít¥, svázané se SIM kartou uºivatele. Tato dv¥ £ísla jsou pouºita pro identi kaci záznam· v databázi na vzdáleném serveru a posílají se zárove¬ s daty. Samotné odeslání záznamu na server je realizováno metodou sendLog() s jedním parametrem a to polem °et¥zc·. Na první pozici tohoto pole musí být název tabulky, ve které je daný záznam uloºen, dal²í °et¥zce v poli reprezentují jednotlivé sloupce tabulky. V²echny tyto názvy se nesmí vzhledem k implementaci php skriptu (5.4) m¥nit, protoºe jsou v n¥m natvrdo zakódovány a v p°ípad¥ zm¥ny je nutné zm¥nit i php skript, jinak nedojde k uloºení do databáze na serveru. Metoda sendLog() se nejprve p°ipojí k lokální databázi a vybere v²echna data z parametrem zadané tabulky. Pak iteruje p°es jednotlivé prvky a pro kaºdý se vytvo°í odpovídající kolekce objekt· NameValuePair, coº je datový typ reprezentovaný jako klí£/hodnota. Dále je kolekce objekt· NameValuePair odeslána p°ez http request na konkrétní server. Tam poºadavek zpracuje php skript a odpoví na n¥j.
HttpClient httpclient = new DefaultHttpClient();
5.4.
PHP SKRIPT NA VZDÁLENÉM SERVERU
21
HttpPost httppost = new HttpPost(DATAASE_NAME); httppost.setEntity(new UrlEncodedFormEntity(nameValuePairs)); HttpResponse response = httpclient.execute(httppost); HttpEntity entity = response.getEntity(); is = entity.getContent(); Odpov¥¤ se p°evede na °et¥zec ve formátu JSON a zjistí se zda do²lo k úsp¥²nému uloºení záznamu na serveru. Log je pak z lokální databáze smazán.
try { JSONArray jArray = new JSONArray(result); JSONObject json_data = jArray.getJSONObject(0); String foo = json_data.getString(nameValuePairs.get(0).getName())); return foo.equals("true") ? true : false; } catch(JSONException e) { return false; }
5.4
Php skript na vzdáleném serveru
Sou£ástí práce byl i php skript na vzdáleném serveru. Jedná se o jednoduchý skript v jazyku PHP, který £te prom¥nné z HTTP requestu a ukládá do databáze. Nejd°íve se p°ipojí k MySQL databázi pomocí funkce mysql_connect(), kterému p°edá jako parametry hostname, jméno uºivatele a heslo a funkcí mysql_select_db() vybere konkrétní databázi. Pak uº jen kontroluje zda superglobální prom¥nná $_REQUEST obsahuje hodnotu s klí£em názvu tabulky, pokud ano, vytáhne si z ní data. Je ov²em nutné dodrºovat názvy klí£· konzistentn¥ s implementací odesílání záznam· (5.3). Hodnoty jsou pak uloºeny do databáze p°íkazem mysql_query(), který bere jako parametr °et¥zec SQL jazyka a v p°ípad¥ ·sp¥²ného vykonání p°íkazu vrací true (pokud se nejedná o selekci dat). Tuto hodnotu také pak zakódujeme do JSON formátu funkcí json_encode() a po²leme na standardní výstup, který je zachycen jako odpov¥¤ serveru v aplikaci na mobilním telefonu.
5.5
Graphical User Interface
Gra cké uºivatelské rozhraní je velice jednoduché, protoºe aplikace má jen pár nastavitelných hodnot, ale jinak komunikaci s uºivatelem tém¥° nevyºaduje. GUI se vytvá°í jako .xml soubor, do kterého se p°idávají jednotlivé gra cké komponenty, pop°ípad¥ layouty a podobn¥. Tento soubor je uloºen ve sloºce /res/layout a kaºdá komponenta má svoje id, na které se dá v kódu pak odkazovat. Zde je ukázka vloºení edit textu (input box) a tla£ítka a na obrázku 5.4 je výsledné GUI aplikace. Je to pouze jedna obrazovka, která je posunutá scroll barem, protoºe se nevejde na display.
<EditText android:id="@+id/etSentSmsLoggingInterval" android:layout_width="fill_parent"
22
KAPITOLA 5.
android:layout_height="40dip" android:padding="10dip" android:layout_marginTop="8dip" android:text="@string/defaultSmsInterval" android:numeric="integer"/> <Button android:id="@+id/btnSaveSmsSettings" android:layout_height="wrap_content" android:text="@string/saveInterval" android:layout_width= "wrap_content" android:padding="10dip" android:layout_marginTop="8dip">
Obrázek 5.4: GUI aplikace
REALIZACE
Kapitola 6
Testování v pr·b¥hu realizace GUI tvo°í pouze jedna aktivita s n¥kolika málo prvky, proto nebylo t°eba testovat aplikaci s uºivatelem. Ve²keré testy jsem tedy provád¥l sám. Pouºíval jsem k tomu Android emulátor a telefon Google Nexus S s podporou technologie AGPS. Na emulátoru jsem testoval pouze SMS zprávy a hovory. Na telefonu jsem provád¥l v²echny testy a to v£etn¥ SMS zpráv a hovor·. Pomocí protokolu telnet se dá p°ipojit ke konzoli emulátoru a spou²t¥t na n¥m p°íkazy (obrázek 6.1). Dá se simulovat nap°íklad odeslání SMS, p°íchozí hovor atd. S reálným za°ízením se ale pracuje mnohem lépe, protoºe je o hodn¥ rychlej²í a emulátor n¥které v¥ci simulovat ani neumí. Telefon má konkrétní hardware a jednu verzi softwaru. V emulátoru se dá nastavit verze Android platformy a hardware, kterým má virtuální za°ízení disponovat. Na telefonu se nainstaluje a spustí aplikace b¥hem p°ibliºn¥ n¥kolika vte°in proti tomu na emulátoru první spu²t¥ní m·ºe trvat i n¥kolik minut. P°ijaté SMS a p°íchozí hovory jsem zkou²el tak, ºe jsem se p°ipojil ke konzoli emulátoru pomocí protokolu telnet a simuloval je p°íkazy sms send [telefoní £íslo] [text zprávy] a gsm call [telefoní £íslo]. První tedy ode²le do emulátoru SMS a druhý simuluje na emulátoru p°íchozí hovor (viz obrázek 6.1). U p°ijatých SMS zpáv jsem objevil chybu. Kdyº p°i²la zpráva, která byla p·vodn¥ del²í neº 160 znak· a tedy rozd¥lena na více £ástí, zaznamenával jsem jen jednu £ást. Bylo nutné p°idat smy£ku pro pr·chod polem, ve kterém je fragmentovaná zpráva uloºena. Dal²í nedostatek jsem objevil u záznamu hovor·. Po uskute£n¥ní kaºdého hovoru jsou informace o n¥m uloºeny do databáze telefonu ke které program pak p°istupuje. Uloºení trvá n¥jakou dobu a stávalo se mi, ºe se nezaznamenával poslední hovor ale p°edposlední. Musel jsem tedy kód, který do databáze p°istupuje, spustit v novém vlákn¥ a to uspat. V pr·b¥hu testování se 2 vte°iny prokázaly jako dostatek £asu na to, aby se hovor uloºil, a málo £asu, aby se mezitím uskute£nil jiný hovor. Sílu signálu jsem zpo£átku ukládal p°i jakékoliv zm¥n¥. To produkovalo obrovské mnoºství záznam·, jelikoº signál se m·ºe zm¥nit i nap°íklad p¥tkrát b¥hem deseti vte°in. Proto jsem p°idal moºnost nastavitelného tresholdu, tedy hodnoty, o kterou se musí signál zm¥nit aby byl zaznamenán. Testování GPS a bun¥k bylo o n¥co obtíºn¥j²í. GPS pot°ebuje p°ímý výhled na oblohu a zm¥na bu¬ky je nep°edvídatelná, takºe testování muselo probíhat venku. Na ºádný zásadní problém jsem nenarazil. 23
24
KAPITOLA 6.
TESTOVÁNÍ V PRB
HU REALIZACE
Obrázek 6.1: P°ipojení k emulátoru p°es protokol telnet
S £ím byl ov²em problém, byly okolní bu¬ky. P°i testování jsem zjistil, ºe se neukládají v·bec. Metoda getNeighboringCellInfo() t°ídy TelefonyManager má podle manuálu vracet seznam informací o okolních bu¬kách nebo null, pokud jsou bu¬ky nedostupné. Nicmén¥ null mi nevrátila nikdy, vºdy jen seznam s nulovým po£tem prvk·. Hledal jsem tedy na internetu, zda má n¥kdo stejný problém a na²el jsem fórum ([8]), kde uºivatel cyborneo popisuje stejný problém. Uºivatel reto.koenig reaguje na p°ísp¥vek tím, ºe odzkou²el funkci getNeighboringCellInfo() na telefonech od t°í r·zných výrobc· a nefungovala mu jen na telefonu Samsung Galaxy S. Na dal²ím fóru ([5]) popisuje uºivatel kabracity totoºný problém jako jsem m¥l já. Uvádí, ºe vyzkou²el funkci na telefonech Desire HD a Nexus One a na obou mu fungovala, takºe si myslí, ºe je problém u telefon· od spole£nosti Samsung. Dal²ím zdrojem, kde uºivatel desliner pí²e, ºe funkce getNeighboringCellInfo() nefunguje správn¥, je [6].
Kapitola 7
Záv¥r Zadáním práce bylo naprogramovat aplikaci pro GAP, která bude schopná zaznamenávat informace z telefonu a posílat je na vzdálený server. Stanoveného cíle se mi tedy poda°ilo dosáhnout. B¥hem testování jsem odhalil n¥které nedokonalosti aplikace, které jsem vylep²il nebo opravil. Vzhledem k tomu, ºe je GAP opensource platforma a na internetu se dá najít hodn¥ tutoriál· popisujících záznamy v²eho, co telefon zaznamenat m·ºe, je na trhu velké mnoºství aplikací podobné té mojí. Má práce ale seskupuje zaznamenávání r·zných hodnot do jedné aplikace, a tím ho zjednodu²uje. Umoº¬uje odesílání uloºených dat na server a díky tomu je leh£í s nimi pracovat. P°i psaní kódu jsem myslel na moºné zaznamenávání dal²ích hodnot. Proto je jednoduché nadále aplikaci roz²i°ovat.
25
26
KAPITOLA 7.
ZÁV
R
Literatura [1] Informace o formátu PDU. http://www.dreamfabric.com/sms/, stav z 18. 5. 2011. [2] DIGGELEN, F. A-GPS: assisted GPS, GNSS, and SBAS. GNSS technology and applications series. Artech House, 2009. Dostupné z:
. ISBN 9781596933743. [3] EAGLE, N. MONTJOYE, Y. A. BETTENCOURT, L. M. A. Community Computing: Comparisons between Rural and Urban Societies using Mobile Phone Data, . http://reality.media.mit.edu/pdfs/Eagle_community.pdf, stav z 18. 5. 2011. [4] EAGLE, N. PENTLAND, A. LAZER, D. Inferring friendship network structure by using mobile phone, . http://reality.media.mit.edu/pdfs/Eagle_PNAS09.pdf, stav z 18. 5. 2011.
[5] fórum, . http://stackoverflow.com/questions/5536705/android-getneighboringcellinfo-returning-n stav z 19. 5. 2011. [6] fórum, . http://forum.xda-developers.com/showthread.php?p=13927290#post13927290, stav z 19. 5. 2011. [7] fórum, . http://code.google.com/p/android/issues/detail?id=2261, stav z 19. 5. 2011. [8] fórum, . http://www.anddev.org/retrieve_every_neighbor_cid_on_android_platform-t7449.html, stav z 19. 5. 2011. [9] obrázek. http://developer.android.com/guide/basics/what-is-android.html. [10] speci kace. http://www.xs4all.nl/~m10/mac/downloads/3GPP-27007-630.pdf. [11] TREVISANI, E. VITALETTI, A. Cell-ID location technique, limits and bene ts: experimental study. http://wmcsa2004.lancs.ac.uk/Slides/wmcsa2004-06-trevisani-cellidlocation.pdf, stav z 18. 5. 2011. 27
28
LITERATURA
[12] ZHENG, Y. R. XIAO, C. Mobile Speed Estimation for Broadband Wireless Communications over Rician Fading Channels. http://scholarsmine.mst.edu/post_prints/pdf/Zheng_09007dcc806393ff.pdf, stav z 18. 5. 2011.
P°íloha A
Seznam pouºitých zkratek CID
Cell Identi cation
MNC
Mobile Network Code
MCC
Mobile Country Code
LAC
Location Area Code
GPS
Global Positioning System
GPRS CGI BS
General Packet Radio Service
Cell Global Identity
Base Staion
SNR
Signal to Noise Ratio
SMS
Short Message Service
AGPS
Assisted Global Positioning System
GAP
Google Android Platform
OHA
Open Handset Aliance
SDK
Software-Developemnt-Kit
VM
Virtual Machine
OS
Operating System
URI
Uniform Resource Identi er
GUI
Graphical User Interface
API
Application Programming Interface
HTTP
Hypertext Transfer Protocol 29
30
PÍLOHA A.
JSON IDE
JavaScript Object Notation
Integrated Development Enviroment
ADT
The Android Development Tool
PDU
Protocol Data Unit
RSSI
Received Signal Strength Indication
IMEI
International Mobile Equipment Identity
IMSI
International Mobile Subscriber Identity
SIM
Subscriber Identity Module
SEZNAM POUITÝCH ZKRATEK
P°íloha B
Instala£ní a uºivatelská p°íru£ka B.1
Instala£ní p°íru£ka
Aplikaci je moºné nainstalovat na telefon s platformou Android s API verze 8 nebo vy²²í. Soubor SensingApplication.apk v adresá°i apk na p°iloºeném CD je nutno zkopírovat do telefonu a tam ho spustit. Tím se aplikace nainstaluje a je p°ipravená k pouºití. Pokud bude aplikace vyuºívána k záznamu GPS pozice, je nutné mít GPS za°ízení v telefonu zaplé. Pro automatické nebo ru£ní odesílání záznam· na server je nezbytné mít p°ístup k internetu. Tato sluºba m·ºe být placená a je závislá na mobilním operátorovi.
B.2
Uºivatelská p°íru£ka
P°i spu²t¥ní aplikace uvidí uºivatel hlavní aktivitu aplikace. V té je moºné nastavit v²echny zaznamenávací parametry. Interval záznamu odeslaných sms zpráv (v milisekundách). Práh, který musí p°ekro£it signál vzhledem k poslední zaznamenané hodnot¥, aby se uloºil (v dBm). Interval záznamu informací o bu¬ce ke které je telefon p°ipojen. Interval záznamu informací o okolních bu¬kách (v milisekundách). Minimální £as, který by m¥la aplikace po£kat neº se znovu pokusí o zji²t¥ní polohy (orienta£ní hodnota v milisekundách) a minimální vzdálenost o kterou se musí uºivatel s telefonem posunout, aby do²lo ke zji²t¥ní nové polohy (v metrech). Interval odesílání záznam· na server (v hodinách). Ve spodní £ásti GUI je tla£ítko pro okamºité odeslání záznam· na server a tla£ítko pro okamºité vypnutí v²ech logovacích sluºeb. Jednotliv¥ jdou sluºby vypínat jen ze správce aplikací dodávaného implicitn¥ s Android platformou. Sluºbu, která zaznamenává p°ijaté sms, lze vypnout pouze tla£ítkem s popiskem shutdown all services.
B.3
Programátorská p°íru£ka
V první sekci vysv¥tlím, jakou má aplikace na GAP obecnou strukturu. Pak se zmíním o detailech, které by mohli vylep²it mojí aplikaci. A nakonec popí²i, jak je moºné aplikaci roz²í°it pro záznam více hodnot. 31
32 B.3.1
PÍLOHA B.
INSTALANÍ A UIVATELSKÁ PÍRUKA
Struktura projektu na Google Android Platform
Po vytvo°ení nového projektu v Eclipse vznikne adresá°ová struktura jako na obrázku B.1. V té jsou pro nás d·leºité 3 sloºky: src, gen a res a také soubor AndroidManifest.xml v ko°enovém adresá°i projektu. Ve sloºce /src jsou zdrojové soubory jazyku Java, které vytvá°í programátor. Stejn¥ jako u standardního Javovského projektu jsou to t°ídy organizované ve struktu°e balík· (packages). Dal²í d·leºitou sloºkou je /res, která se v¥tví na dal²í podsloºky. Obecn¥ jsou tu uloºeny ve²keré externí zdroje, jako jsou obrázky, ikony, datové soubory a dal²í. V podadresá°i /res/layout jsou .xml soubory popisující layout aplikace. Kaºdá aktivita má své GUI, které odpovídá n¥kterému .xml souboru v této sloºce. Dal²ím podadresá°em je /res/values. V tom jsou uloºeny prom¥nné, na které se pak dá odkazovat p°i tvorb¥ GUI. Obsahuje hlavn¥ texty, jako popisky GUI komponent, ale také nap°íklad stylování okraj· komponenty a dal²í. Toto uspo°ádání nám krásn¥ odd¥luje zdrojový kód programu od vzhledu aplikace, takºe spousta zm¥n je mnohem jednodu²²í a vyºaduje v¥t²inou zásah programátora jen na jednom míst¥. Nap°íklad p°i p°echodu na více jazykových verzí by sta£ilo jen p°idat p°eloºené texty a ty se pak na£tou na základ¥ lokálního nastavení telefonu. Pak jsou v projektu je²t¥ 3 dal²í podsloºky s podobným jménem /res/drawable-hdpi, /res/drawable-ldpi, /res/drawable-mdpi, které obsahují ve²kerou gra ku (obrázky, ikony, ...). Programátor má moºnost p°idat do projektu 3 verze jednoho obrázku v r·zné kvalit¥ a v závislosti na displeji cílového za°ízení se na£te odpovídající soubor. Poslední d·leºitou sloºkou je /gen. Ta v podstat¥ spojuje kód aplikace se zdroji ze sloºky /res. Je v ní generovaný kód v podob¥ Java t°ídy s prom¥nnými reprezentujícími kaºdou poloºku GUI, kaºdý string p°ípadn¥ styl okraj·, obrázky, ikony a dal²í zdroje. V ko°enovém adresá°i je je²t¥ soubor AndroidManifest.xml o kterém jsem se zmi¬oval jiº zde 3.5.
B.3.2
Moºná vylep²ení
Hovor se nezaznamená, pokud dojde do 2 sekund od posledního hovoru k uskute£n¥ní a ukon£ení dal²ího hovoru (pravd¥podobn¥ jediná moºnost je prozvon¥ní), ale ²ance, ºe se tak stane, je velice nízká. Navíc se p°i ukládání hovoru vytahují z databáze ve²keré záznamy, ale jiº na úrovni SQL jazyka by sta£ilo získat jen jeden a o n¥co tak aplikaci zrychlit v p°ípad¥ n¥kolika set, moºná tisíc· záznam·. Okolní bu¬ky se na testovaném telefonu (Google Nexus S) nepoda°ilo zaznamenat. Jak jsem jiº uvedl (6) funkce Android API, která má vracet seznam okolních bun¥k, je bohuºel nevrací. M¥l jsem moºnost nakrátko vyzkou²et aplikaci i na telefonu Samsung Galaxy S, se kterým byl výsledek stejný. Jak jsem zmi¬oval v sekci 5.2, metody pro ukládání záznam· jsou statické. Lep²í by jist¥ bylo ud¥lat ze t°idy Logger singleton (návrhový vzor, kdy má daná t°ída mít v rámci celé aplikace pouze jednu instanci a je neºádoucí, aby jich m¥la víc).
B.3.
PROGRAMÁTORSKÁ PÍRUKA
33
Obrázek B.1: Adresá°ová struktura Android projektu v Eclipse IDE
B.3.3
Roz²í°ení
Aplikace je naprogramována tak, aby bylo jednoduché p°idat nový modul pro záznam dal²ích informací. Zdrojový kód je rozd¥len do p°ehledných balí£k·, z jejichº názvu je patrné, o co se který stará. Roz²í°ení pak spo£ívá v tom, ºe programátor implementuje vlastní sluºbu, která bude zaznamenávat libovolná data, pop°ípad¥ registrovat listenery nebo vytvá°et isntance t°ídy Timer pro £asovaný záznam provád¥ný v pravidelném intervalu. Tu pak musí spustit ve t°íd¥ SetupActivity (v balí£ku cz.cvut.main), pop°ípad¥ se k ní p°ipojit a upravit GUI, pokud chce nastavovat hodnoty d·leºité pro nastavení. Pak je je²t¥ nutné p°idat metodu v t°íd¥ Logger (balí£ek cz.cvut.logger) nap°íklad logMyNewData(), která bude data zapisovat do databáze telefonu. A nakonec ve t°íd¥ LogSender v metod¥ run() p°idat volání metody sendLog() pro odeslání záznamu na server. A to je v²e. Takto lze p°idávat zaznamenávání v podstat¥ jakékoliv nové informace/události dostupné z telefonu. Pokud by nevyhovoval mnou implementovaný php skript na serveru, sta£í ve t°íd¥ LogSender zm¥nit konstantu PHP_SERVER, která obsahje URL serveru a vytvo°it si vlastní. Nicmén¥ je t°eba dát pozor na názvy prom¥nných posílaných na server, jak jsem popisoval zde 5.3.
34
PÍLOHA B.
INSTALANÍ A UIVATELSKÁ PÍRUKA
P°íloha C
Obsah p°iloºeného CD readme.txt /exe
- zkompilovaný program
/html /src
- obsah CD a návod instalace
- abstrakt a javadoc
- zdrojový kód aplikace
/text
- text bakalá°ské práce
35
