Záznam provozních dat z mobilního telefonu na platform Android. Martin Jelínek

Transkript

1 ƒ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

2 iv

3 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

4 vi

5 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

6 viii

7 Obsah 1 Úvod 1 2 Popis problému, specikace cíle Cell Global Identity Síla signálu Sousední bu ky Lokalizace (Globální Polohovací Systém) Asistovaný Globální Polohovací Systém Google Android Platform Architektura Google Android Platform Aplikace na Google Android Platform Aplika ní komponenty Activities (aktivity) Services (sluºby) Content provider (poskytovatel obsahu) Broadcast receiver (p íjemce broadcast ) Aktivování komponent Soubor AndroidManifest.xml SQLite databáze Analýza a návrh e²ení Výb r vývojového prost edí Realizace Aktivity a sluºby Záznam hovor Záznam bun k Záznam SMS zpráv Záznam síly signálu 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

8 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 27 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 Android Platform B.3.2 Moºná vylep²ení B.3.3 Roz²í ení C Obsah p iloºeného CD 31

9 Seznam obrázk 2.1 Struktura globální identity bu ky Princip Asistovaného Globálního Polohovacího Systému (AGPS), p evzato z [2] GAP architektura (p evzato z [9]) Android emulátor šivotní cyklus aktivity šivotní cyklus sluºby Úryvek ze specikace 3GPP TS o RSSI viz [10]. P evod síly signálu v RSSI na dbm GUI aplikace P ipojení k emulátoru p es protokol telnet B.1 Adresá ová struktura Android projektu v Eclipse IDE xi

10 xii SEZNAM OBRÁZK

11 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

12 2 KAPITOLA 1. ÚVOD

13 Kapitola 2 Popis problému, specikace 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 identiká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 identiká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

14 4 KAPITOLA 2. POPIS PROBLÉMU, SPECIFIKACE CÍLE 2.1 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 identikátorem bu ky. Je významný p i ur ování geogracké 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 identika ní íslo (CID, Cell ID). Pro snadn j²í identikaci jsou bu ky seskupeny do oblastí v rámci jednoho státu zvaných Location Area, které mají také svoje identika 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.

15 2.3. SOUSEDNÍ BUŒKY 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 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.

16 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].

17 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í graky 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

18 8 KAPITOLA 3. GOOGLE ANDROID PLATFORM jiné posílá y, m ºe pouºít komponentu, která jiº existuje a pouze jí p edat parametry u. 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 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.

19 3.3. APLIKAƒNÍ 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 specickou roli Activities (aktivity) Aktivity reprezentují uºivatelské rozhraní aplikace. Jedna aktivita odpovídá jednomu oknu aplikace. Nap íklad 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 em. Sta ilo by poslat poºadavek aktivit ového klienta, p edat jí polohu a ta by odeslala 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 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 modikovat 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.

20 10 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ý denuje zprávu k aktivaci komponenty. Pro aktivity a sluºby intent denuje 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 identikace dané komunikace mezi komponentami. Nap íklad kdyby programátor vytvá el aplikaci, ve které chce poslat . Je mu známo, ºe komponenta, vhodná pro odeslání u v systému, jiº existuje, takºe vytvo í intent s akcí odeslat , 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 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í u 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é denuje 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é.

21 3.6. SQLITE DATABÁZE 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]).

22 12 KAPITOLA 3. GOOGLE ANDROID PLATFORM

23 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, gracké 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

24 14 KAPITOLA 4. ANALÝZA A NÁVRH E ENÍ 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

25 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 re- 15

26 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 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);

27 5.1. AKTIVITY A SLUšBY 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í

28 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); 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 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. <receiver android:name="cz.cvut.receivedsms.receivedsmslogger" android:enabled="true"> <intent-filter> <action android:name="android.provider.telephony.sms_received" /> </intent-filter> </receiver>

29 5.1. AKTIVITY A SLUšBY 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 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 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 specikace 3GPP TS ([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 specikace 3GPP TS o RSSI viz [10]. P evod síly signálu v RSSI na dbm 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

30 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 identiká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 identikaci 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();

31 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 Gracké 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é gracké 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"

32 22 KAPITOLA 5. REALIZACE android:layout_height="40dip" android:padding="10dip" android:layout_margintop="8dip" android:numeric="integer"/> <Button android:layout_height="wrap_content" android:layout_width= "wrap_content" android:padding="10dip" android:layout_margintop="8dip"></button> Obrázek 5.4: GUI aplikace

33 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

34 24 KAPITOLA 6. TESTOVÁNÍ V PR B 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].

35 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

36 26 KAPITOLA 7. ZÁV R

37 Literatura [1] Informace o formátu PDU. stav z [2] DIGGELEN, F. A-GPS: assisted GPS, GNSS, and SBAS. GNSS technology and applications series. Artech House, Dostupné z: < id=sttshdfhrfuc>. ISBN [3] EAGLE, N. MONTJOYE, Y. A. BETTENCOURT, L. M. A. Community Computing: Comparisons between Rural and Urban Societies using Mobile Phone Data,. stav z [4] EAGLE, N. PENTLAND, A. LAZER, D. Inferring friendship network structure by using mobile phone,. stav z [5] fórum,. z [6] fórum,. stav z [7] fórum,. stav z [8] fórum,. stav z [9] obrázek. [10] specikace. [11] TREVISANI, E. VITALETTI, A. Cell-ID location technique, limits and benets: experimental study. stav z

38 28 LITERATURA [12] ZHENG, Y. R. XIAO, C. Mobile Speed Estimation for Broadband Wireless Communications over Rician Fading Channels. stav z

39 P íloha A Seznam pouºitých zkratek CID Cell Identication MNC Mobile Network Code MCC Mobile Country Code LAC Location Area Code GPS Global Positioning System GPRS General Packet Radio Service CGI Cell Global Identity BS 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 Identier GUI Graphical User Interface API Application Programming Interface HTTP Hypertext Transfer Protocol 29

40 30 P ÍLOHA A. SEZNAM POUšITÝCH ZKRATEK JSON JavaScript Object Notation IDE 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

41 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

42 32 P ÍLOHA B. INSTALAƒNÍ A UšIVATELSKÁ P ÍRUƒKA B.3.1 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 graku (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).

43 B.3. PROGRAMÁTORSKÁ P ÍRUƒKA 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.