M A S A R Y K O V A U N I V E R Z I T A
F A K U L T A I N F O R M A T I K Y
Služby zisťovania polohy v
Android
D I P L O M O V Á P R Á C A
Lýdia Stašková
Brno, jar 2015
Prehlásenie
Prehlasujem, že táto diplomová práca je mojím pôvodným autorským dielom,
ktoré som vypracovala samostatne. Všetky zdroje, pramene a literatúru, ktoré som
pri vypracovaní používala alebo z nich čerpala, v práci riadne citujem s uvedením
úplného odkazu na príslušný zdroj.
Lýdia Stašková
Vedúci práce: Ing. Mgr. et Mgr. Zdeněk Říha, Ph.D.
iii
Poďakovanie
Ďakujem Zdeňkovi Říhovi za navrhnutie zaujímavej témy, vedenie práce a cenné
rady pri konzultovaní tejto práce.
v
Zhrnutie
Cieľom mojej práce bolo preskúmať existujúce spôsoby pre určenie polohy mobilného
zariadenia, ako aj ich funkcionalitu a implementáciu v rámci OS Android, a
následne sa pokúsiť modifikovať OS Android tak, aby vnucoval aplikáciám fiktívne
umiestnenie.
V práci boli vysvetlené tri technológie, na základe ktorých sa zíkava poloha mobilných
zariadení. Ďalej boli popísané jednotlivé vrstvy OS Android so zameraním
sa na ich význam pri implementácii techník získavania polohy. Pre každý z týchto
troch spôsobov boli v OS Android naimplementované metódy, ktoré umožňujú
poskytovať falošnú polohu. Následne bola naprogramovaná mobilná aplikácia,
ktorá tieto metódy využíva.
vii
Kľúčové slová
poloha, Android, GPS, bunka GSM, BTS, smartphone, poloha WiFi, RIL
ix
Obsah
Úvod 3
1 Vývoj mobilných telefónov 5
1.1 Začiatky vývoja 5
1.2 P D A 5
1.3 Smartphony 5
1.4 Služby zisťovania polohy 6
2 Technológie pre získavanie polohy mobilných zariadení 7
2.1 Poloha zariadenia na základe hardvéru (Handset based) 7
2.2 Poloha v sieti (Network based) 9
2.3 Hybrid 13
3 OS Android 15
3.1 Vývoj pre OS Android 15
3.2 Prehľad zdrojového kódu AOSP) 17
3.3 Architektúra systému Android 18
3.4 Android Custom R O M 20
4 Služby zisťovania polohy v OS Android 25
4.1 android,location 25
4.2 android.telephony 28
4.3 android.net.wifi 33
4.4 Google location API 35
5 Implementácia 37
5.1 Existujúce riešenia 37
5.2 Simulovanie polohy v rámci OS Android 37
5.3 Aplikácia Location Manager 40
Záver 47
1
Úvod
Mobilné telefony prešli za posledných pár rokov veľmi rýchlym vývojom. Tento
vývoj nebol sústredený len na kvalitu telefonovania, ale hlavne na pridávanie stále
nových funkcií. Veľa z nich požadovalo vylepšenie alebo pridanie úplne nového
hardvéru. Postupne sa z prístrojov pôvodne určených na telefonovanie, stali vreckové
počítače s pripojením na internet a prakticky neobmedzenou funkcionalitou
(používateľ si môže sťahovať obrovské množstvo aplikácií z internetu, alebo si
sám vlastnú aplikáciu naprogramovať).
Medzi jedny z momentálne najpoužívanejších funkcií patria služby zisťovania
polohy. Zo začiatku tieto služby používali hlavne aplikácie, ktoré s polohou
priamo súvisia, ako napríklad mapy a navigácia. Neskôr vzniklo mnoho aplikácií,
ktorých informácie o polohe slúžia hlavne užívateľovi (aplikácie pre počasie
v danej oblasti, aplikácie pre M H D , služby v okolí...). Momentálne však chce povolenie
zisťovať polohu takmer každá aplikácia, väčšina z nich za účelom cielenej
reklamy.
Toto pomerne veľké využitie služieb polohy posúva vývoj technológií na základe
ktorých sa umiestnenie určuje. Najdôležitejšou technológiou je GPS (Global
Positioning System ). Tento systém zisťuje polohu zariadenia na základe jeho komunikácie
so satelitmi obiehajúcimi okolo planéty Zem. Veľkým mínusom tohoto
systému je, že komunikácia prebieha len ak je dobrá viditeľnosť medzi zariadením
a satelitmi. Vo vnútri budov nefunguje takmer vôbec. Preto boli vymyslené
iné možnosti ako polohu získať, založené na umiestnení zariadenia v nejakej sieti
(internet, C D M A , GSM).
Z používateľského hľadiska nie je vždy žiadané, aby všetky aplikácie poznali
polohu zariadenia. V OS Android je možné si nainštalovať aplikáciu, iba ak dostane
všetky povolenia, o ktoré žiada. Čiže ak žiada povolenie zisťovať polohu,
jediný spôsob ako ju nainštalovať, je dovoliť jej zisťovať polohu zariadenia, čo
môže byť nežiadúce. Toto sa dá obísť tak, že mobilný telefón aplikácií síce podá
polohu, ale nebude skutočná, ale nejaká iná, podvrhnutá.
Cieľom mojej práce je zistiť, z akých všetkých zdrojov je možné dostať informácie
o polohe zariadenia, popísať ako služby zisťovania polohy fungujú, a následne
sa pokúsiť podvrhnut' polohu tak, aby ani relatívne inteligentné aplikácie
nezistili, že sa jedná o fiktívnu polohu. To docielim tak, že sa budem snažiť polohu
simulovať čo najbližšie k ovládaču zariadenia, ktoré polohu poskytuje.
V prvej kapitole stručne popíšem vývoj mobilných telefónov a postupné pridávanie
aplikácií a funkcionality. V druhej kapitole rozoberiem aké sú možnosti, ako
polohu mobilného zariadenia získať. V tretej kapitole sa budem zaoberať architektúrou
operačného systému Android. V štvrtej kapitole popíšem ako presne fungujú
služby zisťovania polohy v OS Android. V poslednej kapitole potom predstavím
existujúce aplikácie, ktoré polohu podvrhujú a princíp, akým polohu simulujú.
Nakoniec popíšem vlastnú implementáciu podávania fiktívnej polohy.
3
1 Vývoj mobilných telefónov
Mobilný telefón je prenosné elektronické zariadenie primárne určené na zabezpečovanie
komunikácie na veľké vzdialenosti. Jednotlivé zariadenia sú pomocou
rádiových vín pripojené k mobilnej sieti, ktorá komunikáciu sprostredkúva. Spojenie
pomocou mobilného telefónu je teda možné len na miestach pokrytých sieťou.
Za posledných pár rokov prešli mobilné telefóny veľmi rýchlym vývojom,
a z pomerne jednoduchých zariadení, určených na telefonovanie, sa stali veľmi
univerzálne prístroje s prakticky neobmedzeným množstvom funkcií.
1.1 Začiatky vývoja
Za prvý mobilný telefón sa považuje Motorola DynTAC 8000X, vynájdená americkým
konštruktérom Martinom Cooperom [5]. Predstavený bol v roku 1973, na
trh sa dostal o 10 rokov neskôr. Jedinou jeho funkciou bolo telefonovanie. Telefón
meral 25 cm a vážil 790 g. Teda aj napriek mobilite nebolo veľmi praktické ho
prenášať kvôli rozmerom.
Ďalší vývoj logicky spočíval v zmenšovaní rozmerov a znižovaní hmotnosti
telefónov. Neskôr boli vyvinuté mobilné zariadenia s monochromatickým displejom.
Prelomovým bol v roku 1989 telefón Motorola MicroTAC, ktorá vážila 348
gramov. K telefónu navyše pribudli funkcie ako hands-free, prevodník mien a zoznam
telefónnych čísel.
Pridanie displejů umožnilo zobrazovanie na ploche telefónu. Zo začiatku slúžil
na informácie o neprijatých hovoroch a pre službu SMS Začali pribúdať ďalšie
funkcie ako budík, hodinky, kalendár, rôzne hry a veľa iných. Vývojom farebného
displeja bolo umožnené pridanie ďalších funkcií ako pozeranie obrázkov, M M S
správy. Do telefónov sa tiež pridávalo stále viac hardvéru ako F M rádio, infraport,
bluetooth, fotoaparát, GPS...
1.2 PDA
Na začiatku 90. rokov sa nezávisle na vývoji telefónov začal vývoj P D A (Personál
Digital Assistent). Pôvodne mali P D A slúžiť ako organizér a adresár. Postupným
pridávaním aplikácií a zlepšovaním hardvéru a softvéru sa z nich stali vreckové
počítače.
1.3 Smartphony
Spojením mobilného telefónu a vreckového počítača vznikli smartphony. Pre smartphone
je najdôležitejší pokročilý operačný systém. Tento systém poskytuje aplikačné
rozhranie pre tvorbu vlastných programov, a tým umožňuje inštalovanie
5
1. V Ý V O J M O B I L N Ý C H T E L E F Ó N O V
aplikácií tretích strán. Možnosti takýchto zariadení sú obmedzené prakticky len
hardvérovo. To zo smartphonu robí zariadenie s neobmedzenou funkcionalitou.
Za prvého predchodcu smartphonov je označovaný Simon Personál Communicator
od firmy IBM, ktorý vyšiel na trh v roku 1994[6]. Mal dotykový displej, ktorý
sa ovládal pomocou stylusu. Disponoval funkciami ako je kalendár, poznámky,
dokázal posielať emaily a samozrejme sa prostredníctvom neho dalo telefonovať.
Za najviac prelomový smartophone sa vo všobecnosti považuje iPhone od firmy
Apple. Bol predstavený 9. januára 2007 a uvedený na trh v júni toho roku. Ako jeden
z prvých telefónov mal multi-dotykový displej, ovládateľný priamo prstami,
čo bolo vyvinuté ako hlavná forma ovládania. Dovtedy sa telefóny ovládali pomocou
klávesnice, alebo ako spomínaný telefón od IBM, pomocou stylusu. V roku
2008 prišiel na trh prvý telefón používajúci operačný systém Android. Bol ním HTC
Dream. Momentálne medzi sebou súperia tri najpoužívanejšie operačné systémy Android,
iOS a Windows.
1.4 Služby zisťovania polohy
Na začiatku vývoja mobilných telefónov a mobilných sietí sa nepočítalo, že sa tieto
technológie budú používať aj na zisťovanie polohy. Prvým impulzom jej zisťovania
boli straty a krádeže mobilných zariadení. Poloha sa určovala na základe
prihlásenia zariadenia k vysielacej stanici. V dnešnej dobe je bežné, že v mobilnom
telefóne sa nachádza zariadenie GPS. To vie určovať polohu veľmi presne,
avšak má problémy s pokrytím v budovách. Preto boli vyvinuté technológie, ktoré
presnejšie určujú polohu na základe pripojenia k sieti a technológie, ktoré určujú
polohu pomocou adresy M A C prístupového bodu k sieti Internet.
Zisťovanie polohy má mnoho použití. Asi najlukratívnejšie je cielená reklama.
Medzi ďalšie patria navigácia, zistenie polohy (užívateľ potrebuje zistiť kde je),
počasie v mieste pobytu, zistenie dostupnosti služieb v okolí (reštaurácie, najbližšia
M H D zastávka, benzínová stanica...), webové aplikácie (lokalizovaný jazyk
stránky, prispôsobenie obsahu podľa polohy), bezpečnosť(server zistí, že sa k nemu
prihlasujete z neobvyklej polohy) a množstvo iných.
6
2 Technológie pre získavanie polohy mobilných zaria­
dení
Existujú rôzne metódy a technológie na získavanie polohy mobilných zariadení.
Líšia sa požiadavkami na hardvér, presnosťou, cenou, časom potrebným pre získanie
polohy, nárokmi na batériu, prostredím, kde je možné ich použiť (pokrytie,
vonku/v budovách). Najdôležitejšími faktormi, ktoré ovplyvňujú trh s technológiami
na získanie polohy sú peniaze, ktoré musí G S M operátor investovať do siete
aby získal polohu a presnosť, akú aplikácie požadujú.
2.1 Poloha zariadenia na základe hardvéru (Handset based)
GNSS - Global Navigation Satellite System je súhrnný názov pre satelitné systémy
určujúce polohu. Americký systém sa nazýva NAVSTAR GPS (Navigation
Signál Timing and Ranging Global Positioning System). Pôvodne bol tento systém
vyvinutý pre americkú armádu. Neskôr v roku 1983 bol prístup umožnený
aj civilistom. Pre tento účel bol vyvinutý systém SA (Selective Avaibility), ktorý
posielal civilistom informácie so zámerne obmedzenou presnosťou ± 100 metrov.
Toto obmedzenie bolo v máji roku 2000 zrušené[7]. GPS prevádzkuje a financuje
ministerstvo obrany Spojených štátov amerických. Momentálne je to najpoužívanejší
systém.
Alternatívou je ruský systém GLONASS, ktorý prvýkrát dosiahol plne funkčný
stav (24 satelitov) v roku 1995, teda o rok neskôr ako GPS. A b y mal systém zabezpečenú
plnú kapacitu, je nutné každý rok vypustiť dva satelity. Kvôli nedostatku
financií, však do roku 1999 nebol vypustený žiaden satelit. To viedlo k situácií,
že v roku 2001 bolo funkčných len 7 satelitov. Opätovne bola obnovená plná prevádzka
až v roku 2011[8]. V rôznych fázach vývoja sú čínsky COMPASS a systém
GM
0m
m
win
4
Ctil
I s
Power
© © ©
Accuracy
© © ©
Coverage
© © ©
Obr. 2.1: Porovnanie jednotlivých technológií podľa vývojárov Google location
API[30]
7
2. T E C H N O L Ó G I E PRE Z Í S K A V A N I E P O L O H Y M O B I L N Ý C H Z A R I A D E N Í
GALILEO, ktorý financuje Európska únia[9].
2.1.1 GPS
GPS je momentálne najpopulárnejšia technológia na zisťovanie polohy. Používa
31 globálnych satelitov, ktoré obiehajú okolo planéty Zem v nadmorskej výške 20
200 kilometrov a posielajú signály príjemcom používajúcim GPS. A b y to celé fungovalo,
musí byť priama viditeľnosť medzi zariadením a satelitom. Sytém GPS
funguje pomocou komunikácie troch segmentov. Prvým segmentom je vesmírny
segment (Space Segment), ktorého súčasťou sú najmä satelity. Druhým je kontrolný
segment (Control Segment). Tvoria ho kontrolné stanice na Zemi, a posledným
je používateľský (User Segment), ktorý je reprezentovaný používateľskými
GPS prijímačmi a aplikáciami, ktoré určujú polohu.
Vesmírny segment
Operácie GPS sú závislé na veľmi presnom čase. Tento čas merajú atómové hodiny
umiestnené na satelitoch. Dáta, ktoré satelity vysielajú, obsahujú informácie
o ich polohe a presnom čase. Všetky satelity majú medzi sebou synchronizovaný
čas a signály vysielajú naraz. Vysielanie sa periodicky opakuje. Signál putuje k prijímačom
rýchlosťou svetla. Vysielaná informácia obsahuje dve časti. Prvou sú dáta
„ephemeris", čo sú informácie o konkrétnom satelite, ktorý vysiela, a druhá časť
sú dáta „almanac", ktoré obsahujú informácie o celej sústave satelitov. Posiené je
teda pomerne veľké množstvo dát.
Aby GPS pokrylo celú planétu Zem, musí byť vždy funkčných aspoň 24 satelitov.
Podľa stránok gps.gov[10] sa americká vláda zaviazala udržiavať 24 fungujúcich
satelitov 95 % času. A b y splnila tento záväzok, má na obežnej dráhe 31
satelitov. Tie obiehajú Zem s periódou 12 hodín rýchlosťou 3,9 km/s. N a určenie
presnej polohy satelitov slúžia stanice na Zemi. Tie sledujú ich pohyb.
Kontrolný segment
Pozostáva z pozemných zariadení, ktoré sledujú satelity GPS, monitorujú ich vysielanie
a analyzujú beh celého systému. Tieto zariadenia posielajú povely satelitom,
manévrujú nimi a sú zodpovedné za údržbu atómových hodín. Prípadné odstávky
satelitov alebo ich opätovné zapojenie do systému oznamuje používateľom
prostredníctvom NANU(Notice Advisory to Navstar Users) správ. Momentálne
pozostáva systém z Master Control Station, Alternativě Control Station, dvanástich
antén a šestnástich monitorovacích staníc.
Master Control Station sa nachádza v štáte Colorado. Jej účelom je riadenie a
kontrolovanie celej sústavy satelitov GPS. Generuje a nahráva navigačné správy
a zabezpečuje presnosť a prevádzku satelitov. O d monitorovacích staníc dostáva
navigačné informácie, tie používa na výpočet presnej polohy satelitov GPS vo vesmíre
a výsledky výpočtov polohy posiela satelitom GPS.
8
2. T E C H N O L Ó G I E PRE Z Í S K A V A N I E P O L O H Y M O B I L N Ý C H Z A R I A D E N Í
Používateľský segment
Zariadenie GPS príjma signál od satelitov GPS, na ktoré má priamu viditeľnosť.
Od jednotlivých satelitov príde signál v trochu inom čase, podľa vzdialenosti od
konkrétneho satelitu. Z času, za ktorý signál k prijímaču dorazil a rýchlosti ktorou
signál šiel (rýchlosť svetla), sa vypočíta vzdialenosť prijímača od satelitu GPS. Pre
určenie polohy v troch dimenziách je nutné, aby v jednom okamihu prijímalo zariadenie
signál aspoň od štyroch satelitov. Vzdialenosť od každého jednotlivého
satelitu predstavuje sféru. Prienikom troch rôznych sfér sú maximálne dva body
v priestore, z ktorých sa iba jeden nachádza na planéte Zem a ten druhý teda nemusíme
brať do úvahy. N a určenie polohy by teoreticky stačili tri satelity. V praxi
ale časy satelitov GPS nie sú synchronizované s prijímačmi signálu GPS a navyše
rýchlosť svetla môže byť v atmosfére rôzna. Signál od štvrtého satelitu je teda
potrebný na určenie časovej odchýlky. A k by sme vyžadovali nutnosť synchronizácie
času medzi prístrojmi, ktoré prijímajú signál GPS a satelitmi GPS, tak by sa
spresnili údaje o polohe alebo by bolo potrebné menej satelitov obiehajúcich okolo
Zeme, avšak prudko by zvýšila cenu prístrojov GPS. N a základe prijatých údajov
si zariadenie vypočíta svoju polohu1
.
2.2 Poloha v sieti (Network based)
Technológie pre získavanie polohy založené na sieťach určujú polohu na základe
toho, kde v sieti je telefón pripojený. Výhodou je, že získanie polohy je nezávislé
na telefóne a na hardvéri, stačí, že je zariadenie pripojené k sieti a teda sú menej
náročné na výdrž batérie ako GPS. Fungujú pomerne dobre vonku aj v budovách.
Pri navrhovaní GSM, C D M A , WiFi ani 3G sa však nepočítalo s využívaním týchto
technológií pre získavanie polohy a preto sú menej presné ako technológie navrhnuté
špeciálne pre lokalizáciu (GPS).
2.2.1 B T S
Presnosť polohy sa líši podľa konkrétnej technológie a metódy výpočtu polohy.
Najmenej presná je „bunková identifikácia" obr.2.2, ktorá určuje najbližšiu BTS
(Base transceiver station). Je to zariadenie, ktoré zabezpečuje bezdrôtovú komunikáciu
medzi používateľským zariadením a sieťou. Používateľským zariadením
je typicky mobilný telefón. Sieť môže byť postavená na ľubovoľnej bezdrôtovej
technológií (GSM, C D M A , W L L , WiFi, W i M A X , prípadne iná W A N technológia),
vo všeobecnosti sa ale väčšinou myslí G S M alebo C D M A sieť. Výpočet zemepisnej
výšky a šírky na základe údajov od BTS stanice má na starosti lokalizačný server
(Location Server), ktorý je súčasťou BTS. „BTS teoreticky pokrýva rozlohu s priemerom
70 km, ale prakticky je pokrytie len viac ako 25 km. Aj keď vieme polohu
1. Alternatívne pošle prijaté dáta na nejaký server, ktorý to počíta za neho, lebo výpočty sú pomerne
náročné
9
2. T E C H N O L Ó G I E PRE Z Í S K A V A N I E P O L O H Y M O B I L N Ý C H Z A R I A D E N Í
(a) bez sektorov (b) so sektormi
Obr. 2.2: Bunková identifikácia
BTS, je veľmi zložité zistiť správnu polohu mobilného zariadenie v tomto 25 km
okruhu. "[11]
BTS majú typicky viacero prijímačov, ktoré dovoľujú obsluhovať viacero rôznych
frekvencií a sektorov. Sektor je priestor kam BTS vysiela signál. Jedna BTS
môže mať viacero sektorov (typicky 3), v tomto prípade „bunková identifikácia"
určí aj konkrétny sektor danej stanice BTS a poloha je o niečo presnejšia. Pre ďalšie
spresnenie údajov sa používa technika „predstihu" (Timing Advance) obr.2.3.
Na základe sily signálu a času odozvy sa približne určí vzdialenosť telefónu od
stanice BTS.
Obvykle je na jednom mieste možné chytiť signál viacerých BTS. Zmeraním
rozdielu v čase, za ktorý signál došiel (TOA - Time of Arrival) sa dá približne
odhadnúť pomerná vzdialenosť zariadenia od jednotlivých staníc. Reálna vzájomná
vzdialenosť staníc je známa. N a základe toho lokalizačný server vypočíta
približnú polohu zariadenia.
Podobne funguje aj metóda „uhol dopadu" (Angle of Arrival) obr.2.4, ale namiesto
času berie do úvahy uhly, pod ktorými signály k jednotlivým staniciam
došli. Keďže vzdialenosť staníc je známa a poznáme dva priľahlé uhly, tak vieme
na základe trojuholníkových pravidiel určiť všetky vzdialenosti v trojuholníku
(stanica, stanica, zariadenie). Táto metóda sa nazýva triangulácia. Čím viac staníc
BTS a sektorov, tým je poloha presnejšia. Najpresnejšie teda fungujú v husto
obývaných oblastiach s dobrým pokrytím.
2.2.2 WiFi
„Nedávny pokrok v bezdrôtovej technológií umožňuje jednoduché a lacné použitie
zariadení WiFi. V dnešnej dobe máme mnoho prístupových bodov WiFi v našich
domácnostiach, kanceláriách, školách, letiskách atď. Používaním týchto prí-
10
2. T E C H N O L Ó G I E PRE Z Í S K A V A N I E P O L O H Y M O B I L N Ý C H Z A R I A D E N Í
((;))
(b) so sektormi
(a) bez sektorov
Obr. 2.3: Predstih (Timing Advance)
Obr. 2.4: Uhol dopadu (Angle of Arrival)
11
2. T E C H N O L Ó G I E PRE Z Í S K A V A N I E P O L O H Y M O B I L N Ý C H Z A R I A D E N Í
stupových bodov WiFi môžeme určiť polohu."[12]
Určovanie polohy na základe pripojenia k uzlu WiFi sa používa ak nie je možné
určiť polohu pomocou GPS, najčastejšie v husto osídlených oblastiach, kde je mnoho
prístupových bodov WiFi.
Parametrom pre zistenie polohy prístupového bodu WiFi býva BSSID2
(Basic
Service Set Identification), ten jednoznačne identifikuje zariadenie. Z databázy polôh
WiFi (WiFi location databases) sa určí poloha prístupového bodu. Pre spresnenie
polohy zariadenia sa používajú rovnaké techniky ako pri BTS staniciach.
Pôvodne bolo pomerne problematické vytvoriť databázu polôh WiFi. Spoločnosť
Google na to využívala vozidlá StreetView, ktoré popri fotografovaní ulíc,
zároveň zisťovali adresy M A C prístupových bodov WiFi a teda vedeli približnú
polohu týchto prístupových bodov. V dnešnej dobe je to oveľa jednoduchšie. Zariadenia
s OS Android používajúce Google Apps 3.4.2 majú v nastaveniach služieb
polohy možnosť používať funkciu Moja Poloha obr.2.5, ktorá periodicky kontroluje
polohu zariadenia získanú cez GPS, Cell-ID alebo WiFi a zároveň kontroluje
adresu BSSID prístupových bodov WiFi, ktorých signál zachytí a tieto informácie
zasiela do databázy spoločnosti Google. Toto sa periodicky opakuje, aj ak zariadenie
nepoužíva žiadnu aplikáciu pre zisťovanie polohy. Podobným spôsobom sa
tvoria aj databázy prístupových bodov mobilných sietí(Edge, 3G, LTE).
Tieto informácie umožňujú spoločnosti Google získať polohu jednotlivých prístupových
bodov. Z množstva získaných polôh sa pomocou nejakej heuristiky odhadne
približná poloha prístupového bodu. Presnosť záleží od počtu predchádzajúcich
prihlásení z tohto bodu. Podobne funguje množstvo iných databáz od rôznych
spoločností. Niekoľko z nich je verejne dostupných. V OS Android Služba
Google Apps podporuje získavanie polohy na základe siete WiFi, alebo mobilných
sietí z databázy spoločnosti Google. 3.4.2
2.2.3 Poloha na základe adresy IP
Najjednoduchší spôsob ako získať polohu na základe adresy IP je verejná databáza
whois. Poskytuje ale iba základné informácie o entite, ku ktorej je daná adresa IP registrovaná,
teda najčastejšie ISP (Internet service provider - poskytovatel' služieb
internetu). Z kontaktných informácií (napríklad PSČ) sa dá určiť mesto, v ktorom
má ISP sídlo, alebo kde sa nachádza nejaký väčší uzol smerovačov ISP Ďalej existujú
rôzne techniky ako pomocou príkazov ping alebo traceroute spresniť zistenú
polohu. O tejto problematike viac tu [13]. Vo všeobecnosti je však poloha na základe
adresy IP veľmi nepresná. V lepšom prípade zistíme mesto, v ktorom sa zariadenie
pripojené pod adresou IP nachádza, v najhoršom nemusíme presne určiť
ani krajinu.
„Naše zistenia indikujú, že databázy pre geolokácie často úspešne určia polohu
adresy IP na úrovni krajiny. Avšak sú zamerané na zopár krajín, väčšinou tých,
2. BSSID je adresa M A C prístupového bodu
12
2. T E C H N O L Ó G I E PRE Z Í S K A V A N I E P O L O H Y M O B I L N Ý C H Z A R I A D E N Í
• ±- 1Ů A O V ' J I 22:03
Služby na zisťovanie polohy
Služba určovania polohy Googh
P o v o l i ť a p l i k á c i á m p o u ž í v a ť ú d a j e z o [ V f
s i e t e W i - F i a m o b i l n ý c h s i e t í n a u r č e n i e
p r i b l i ž n e j p o l o h y
Satelity GPS
P o v o l i ť a p l i k á c i á m p o u ž i ť z a r i a d e n i e
Používať funkciu Moja poloha
Chcete spoločnosti Google povoliť
využívať informácie o polohe na
poskytovanie presnejších
výsledkov vyhľadávania a dalších
služieb?
I
Nesúhlasím Súhlasím
Obr. 2.5: Zapnutie funkcie Moja Poloha v nastaveniach
kde je mnoho používateľov internetu, a to ich robí všeobecne nepoužiteľnými ako
služby lokácie."[14]
2.3 Hybrid
Hybridné systémy používajú na získavanie polohy kombináciu viacerých technológií.
Väčšinou sú postavené na polohe získanej pomocou GPS, skombinovanej
s využitím siete. Výhodou je že poloha je relatívne presná a získaná pomerne
rýchlo. Nevýhodou je, potreba prístupu k internetu a zároveň k signálu GPS, čo
môže byť náročnejšie na batériu, prípadne aj cena je vyššia (pripojenie k internetu
môže byť spoplatnené).
Alternatívne sa dá pozerať ako na hybridné systémy aj na systémy, ktoré zisťujú
polohu nejakého zariadenia pomocou GPS a potom informácie o polohe odosielajú
pomocou siete Internet inému zariadeniu.
2.3.1 A-GPS
A-GPS (Assisted GPS) je postavené na technológií GPS a pomocou internetu komunikuje
s asistenčným centrom. Toto centrum poskytne zariadeniu dáta o dráhach
a palubných časoch satelitov. Tieto dáta nemusí prijímať od satelitov (trvá
to pomerne dlho), a tým sa štart celého procesu urýchli. Okrem toho, môže asistenčné
centrum poskytovať aj výpočtový výkon. Zariadenie z dát prijatých od satelitu,
nič nepočíta, ale tieto dáta odošle asistenčnej stanici, ktorá vypočíta polohu
13
2. T E C H N O L Ó G I E PRE Z Í S K A V A N I E P O L O H Y M O B I L N Ý C H Z A R I A D E N Í
a tú následne odošle zariadeniu. A-GPS sa dá v OS Android vypnúť, ušetrí sa tým
dátový prenos, ale GPS bude štartovať dlhšie.
14
3 OSAndroid
„Android OS je open source technológia, ktorá beží na viac ako 400 miliónoch zariadení
celosvetovo. Táto technológia pozostáva z viacerých komponentov, ktoré
umožňujú vývojárom a výrobcom zariadení pracovať nezávisle." [15]
Operačný systém Android je rozsiahla open source platforma. Tento operačný
systém je primárne vyvýjaný pre smartphony a tablety s dotykovým displejom. Je
prispôsobený obmedzeniam klasických mobilných telefónov ako sú nízka výdrž
batérie, menší výkon zariadenia, dotykové ovládanie....
Spoločnosťou Android vznikla v októbri 2003, v roku 2005 ju kúpila spoločnosť
Google. V roku 2007 bolo založené konzorcium Open Handset Alliance. Toto
konzorcium zoskupuje spoločnosti, ktoré sa zaoberajú vývojom súčiastok, mobilných
telefónov a softvéru pre mobilné telefóny. Medzi najväčšie spoločnosti patria
Google, Samsung, HTC, Qualcom, Intel... Cieľom Open Handset Alliance bolo vyvinúť
otvorený štandard pre mobilné zariadenia. Ich produktom je Android, ktorý
ponúka inovatívne používateľsky prívetivé prostredie, je ľahko rožíriteľný a má
relatívne nízke náklady na vývoj a distrubúciu.
3.1 Vývoj pre OS Android
Platforma Andoridu je založená na pozmenenom Linuxovom jadre. Obsahuje množstvo
systémových a iných C/C++ knižníc. Vyššie vrstvy systému sú postavené na
Dalvik Virtual Machine, ktorý umožňuje beh Javy. V Jave sú napísané frameworky
ktoré poskytujú rozhranie pre programovanie aplikácií v Jave. Pre vývoj v Jave bol
vyvinutý Android SDK (Software Development Kit) ten obsahuje nástroj dx, ktorý
je schopný prevádzať javovské súbory do Dalvikovských.
3.1.1 Aplikácie v Jave
Najčastejšie sa aplikácie pre Andorid vyvíjajú v Jave. Pre vývoj sa používa Android
SDK, ktorý obsahuje Java API knižnice a nástroje pre vývoj, testovanie a debugovanie
aplikácií. Dá sa jednoducho prepojiť s vývojovým prostredím Eclipse. Alternatívou
je vývojové prostredie Android Studio, ktoré bolo špeciálne vyvinuté pre
vývoj aplikácií pre Android. Eclipse sa ale používa dlhšie, a preto je jednoduchšie
nájsť riešenie prípadných problémov s IDE. Všetka dokumentácia je k dispozícií
na stránkach http: //developer. android. com. Programovanie aplikácií v Jave
je založené na štyroch základných komponentoch. To, ktoré komponenty a ako
aplikácia využíva, prípadne aké systémové práva vyžaduje, oznamuje aplikácia
Androidu pomocou X M L súboru Android Manifest.
Najdôležitejším je komponent aktivita - Activity. Základnou vlastnosťou komponentu
Activity je jeho nezávislosť na aplikácií, z ktorej je spúšťaný a takisto na
ostáných aktivitách. Každá aktivita môže spúšťať aktivity iných aplikácií a takisto
môže byť nimi spúšťaná. Jednotlivé aktivity spolu komunikujú pomocou
15
3. OS A N D R O I D
asynchrónnych správ Intent. Spustené aktivity sa ukladajú na zásobník Task. Aktivita
spustená inou aktivitou sa uloží na zásobník nad ňu. A k je daný Intent možné
spracovať viacerými aplikáciami Android vyhodí užívateľský dialog. Aktivita je
implementovaná preťažením základných metód Javovskej triedy Activity ako sú
onCreateO, o n S t a r t O , onResume() , onPauseO, onStopO a onDestroy().
Tieto určujú, čo sa má vykonávať počas životného cyklu danej aktivity. GUI
jednotlivých aktivít a teda aj celkovo aplikácie je deklaratívny. Píše sa v X M L do
súboru layout. xml. K jednotlivým prvkom X M L potom samotná aplikácia pristupuje
pomocou ID.
Ďalšími komponentami sú Service - služby bežiace na pozadí (napríklad odosielanie
e-mailov na pozadí), Broadcast receiver - prijímajú broadcasty a na základe
nich môžu vytvárať Intenty (napríklad receiver zistí, že stav batérie je nízky, vytvorí
Intent a ten môže vyvolať aktivitu, ktorá oznamuje nízky stav batérie) a posledný
komponent Content provider sprístupňuje dáta telefónu aplikáciám (napríklad
užívateľské účty, telefónny zoznam...).
3.1.2 Nativné aplikácie
Pre Android je možné vyvíjať aj natívne aplikácie v C/C++. Podporu zabezpečuje
Android N D K (Native Development Kit). Aj keď vyvíjame aplikáciu v N D K , je
nutné začať štandardnou aplikáciou v Jave a do nej pridávame funkcionalitu písanú
v C/C++. Dôvodom prečo zvoliť vývoj aplikácie v natívnom kóde, je možnosť
obísť javovský framework a komunikovať priamo s jadrom systému alebo
hardvérom písaným v C/C++.
Všetky natívne zdroje sa ukladajú do priečinka j n i . Dôležité je vytvoriť súbor
Android. mk (špeciálny makefile) v priečinku j n i , kde sú uložené informácie o module
a zdrojových súboroch. N D K program musí obsahovať aspoň jeden javovský
súbor. Z neho sú volané funkcie písané v natívnom kóde. V Jave sú nativné funkcie
označené kľúčovým slovom „native". V C/C++ kóde sa k názvu funkcie pridáva
cesta k balíčku, ktorý ich volá.
Nevýhodami N D K sú slabšia podpora a dokumentácia ako má SDK a miešanie
kódu Javy a C. Programátor navyše nemôže využiť framework, ktorý je pracuje
s vyššmi vrstvami OS Android optimalizované. Vývoj v N D K sa odporúča, len
ak sa dá z toho reálne niečo získať. Vo všeobecnosti neplatí, že vývoj v natívnom
kóde je vždy rýchlejší. Je vhodné ho preto použiť iba ak sa jedná o nejaké zložité
výpočty, alebo ak sa chce programátor z nejakého dôvodu vyhnúť frameworku
pre vývoj v Jave.
3.1.3 Jadro
Keďže OS Android je open source, jeho zdrojový kód sa dá stiahnuť. Cesta k zdrojovému
kódu ako aj rôzne návody ako ho zostavovať sa dá nájsť na adrese [16].
OS Android je nutné vyvíjať v systéme Linux alebo Mac OS.
16
3. OS A N D R O I D
I
ALARM • BROWSER • CALCULATOR • CALENDAR • CAMERA
• CLOCK • CONTACTS • DIALER - EMAIL • HOME • IM •
MEDIA PLAYER • PHOTO ALBUM • SMS/MMS • VOICE DIAL
ACTIVITY MANAGER • CONTENT PROVIDERS • LOCATION
MANAGER • NOTIFICATION MANAGER • PACKAGE
MANAGER • RESOURCE MANAGER • TELEPHONY
MANAGER • VIEW SYSTEM • WINDOW MANAGER
AUDIO MANAGER • FREETYPE • LIBC • MEDIA
FRAMEWORK • OPENGL/ES • SQLITE - SSL *
SURFACE MANAGER • WEBKIT
CORE LIBRARIES •
ART-DALVIKVM
AUDIO • BLUETOOTH • CAMERA • DRM •
EXTERNAL STORAGE • GRAPHICS • INPUT •
MEDIA-SENSORS - TV
AUDIO DRIVERS - BINDER (IPC) DRIVERS - BLUETOOTH
DRIVER - CAMERA DRIVER - DISPLAY DRIVER • KEYPAO
DRIVER • POWER MANAGEMENT • SHARED MEMORY
DRIVER • USB DRIVER • WIFI DRIVER
Obr. 3.1: AOSP[17]
3.2 Prehľad zdrojového kódu AOSP)
AOSP (Android Open Source Project) obsahuje tieto adresáre:
bionic Obsahuje základné knižnice jazyka C ako libc, libdl, libstdc++...
build Obsahuje makefiles pre zostavenie OS Android. Dôležitým adresárom je
adresár target, ktorý obsahuje adresáre products a board, pre ktoré sa dá
OS zostaviť. Pri zostavovaní je potom možné špecifikovať, pre aký produkt,
architektúru, cieľ... chceme Android zostaviť. Predajcovia si môžu špecifikovať
vlastné produkty, a napísať k ním vlastné makefiles. Ďalej môžeme špecifikovať,
aké moduly chceme pre daný produkt použiť, aký kemel, jazyky
a krajiny pre ktoré je produkt zostavovaný, aplikácie, ktoré bude obsahovať,
značku, výrobcu...
cts Obsahuje Compatibility Test Suit. Je to nástroj pre automatické testovanie systému,
ktorý určuje či systém spĺňa predpoklady, aby mohol byť považovaný
za Android.
dalvik Dalvik Virtual Machine je nástroj, ktorý prekladá Javovské frameworky do
bytekódu.
device Obsahuje súbory a nastavenia špecifické pre jednotlivé zariadenia.
17
3. OS A N D R O I D
external Všetko, čo nepochádza z projektu Android, ale je pridávané do projektu
Android. Teda externé knižnice, napríklad Apache web server, zip, chromium,
jpeg, openssl, oauth, sqlite...
frameworks Obsahuje frameworky, ktoré poskytujú API pre vývoj aplikácií pre
Android a tým poskytujú prístup k službám ako je WiFi, NFC, VoIP, služby
zisťovania polohy...
hardware Obsahuje zdrovjový kód vrstvy H A L .
ndk Podpora pre natívne aplikácie
out Do tohto adresára sa nakopíruje zostavený operačný systém.
packages Zdrojový kód aplikácií, ktoré sú súčasťou OS Android, ako napríklad
Kalkulačka, Webový prehliadač, Kontakty...
sdk Podpora pre programovanie aplikácií v Jave.
system Jadro systému a systémové adresáre.
3.3 Architektúra systému Android
Architektúra OS Android je rozdelená do 5 vrstiev.
3.3.1 Application framework
Je to najdôležitejšia vrstva pre vývojárov aplikácií pre Android. Sprístupňuje im
služby OS pre použitie v aplikáciách. Obsahuje rôzne API (Application Programming
interface) - rozhrania, ktoré umožňujú pohodlný a jednoduchý vývoj aplikácií.
Obsahuje nástroje pre jednoduchý vývoj užívateľského rozhrania (tlačidlá,
textové polia, obrázky ...), jednoduchý prístup k systémovým nástrojom akým je
napríklad Intent alebo Activity, umožňuje ovládanie telefónu a hardvéru, prístup
k multimédiám, prístup k službám zisťovania polohy a ďalšiu funkcionalitu. Jeho
metódy sú volané priamo aplikáciami a volá v nich služby systému pomocou Binder
IPC.
3.3.2 Binder IPC (Inter Process Communication)
Je to mechanizmus, ktorý poskytuje medzivrstvu pre komunikáciu vrstvy Application
Framework a vrstvy System Services. Dovoľuje aplikačnému frameworku
volať a používať služby systému. Základ je porovnateľný s funkcionalitou iných
klient-server alebo IPC technológií. Líši sa v podpore pre AIDL (Android Interface
Definition Language) a jeho samotnej implementácií. Namiesto zdieľania príkazov
18
3. OS A N D R O I D
APPLICATION FRAMEWORK
BINDER IPC PROXIES
Obr. 3.2: Architektúra systému Android[18]
a požiadaviek, zdieľa klientská a serverová strana spoločné abstraktné rozhranie
pre službu. Jedno takéto rozhranie implementujú dva rôzne objekty. Prvým je lokálny
objekt, ktorý používajú aplikácie a obsahuje prístup k službe, druhým je
vzdialený objekt služby, ktorý obsahuje skutočnú implementáciu služieb. Spustenie
služby na lokálnom objekte sa preloží ako volanie vzdialeného objektu služby.
Framework Binder používa ovládač kernelu pre IPC. Klientom pre ovládač sú
aplikácia, služba (Service) a manažér služby (Service Manager). Ovládač priradzuje
a spravuje ID. Manažér služby sa zaregistruje ako manažér pri štarte zariadenia.
Spravuje zoznam služieb. Jednotlivé služby sa zaregistrujú u manažéra pri
svojom štarte. Najprv aplikácia volaním metódy GetService získa prístup k manažérovi
služby. Potom si vytvorí svoj objekt danej služby (ten sa zaregistruje u
manažéra). Potom aplikácia na objekte volá metódy, ktoré sa prekladajú ako metódy
vzdialeného objektu služby. Poskytovatel' služby musí tieto metódy implementovat'.
[19]
3.3.3 System services
Poskytujú služby vyšším vrstvám. Vytvárajú prístup k funkciám hardvéru pod
nimi. Sú rozdelené na jednotlivé moduly podľa funkcionality, ktorú poskytujú.
1. v tomto prípade rozhranie myslené ako interface v jazyku Java
19
3. OS A N D R O I D
Delia sa na systém a média. Systémové služby sú aplikačný komponent, ktorý
prevádza dlho bežiace operácie v pozadí a neposkytuje používateľské rozhranie.
Služby sú spúšťané iným aplikačným komponentom (najčastejšie komponentom
Activity), bežia však, aj ak užívateľ prepne na inú aplikáciu. Systémové služby
sa nachádzajú v adresári f rameworks. Sú to napríklad ovládanie svetla, batéria,
budík... Služby komunikujú s aplikačným frameworkom pomocou Binder IPC.
Mnohé poskytujú prístup k harvéru volaním metód, ktoré implementuje H A L .
3.3.4 Hardware abstraction layer (HAL)
Je to štandardné rozhranie, ktoré povoľuje systému používať ovládače bez akejkoľvek
vedomosti o tom, aký hardvér je pod nimi. Pre každý konkrétny kus hardvéru
musí byť okrem ovládača naprogramovaný aj jeho H A L . Android implementáciu
konkrétneho H A L nijak nestráži ani neobmedzuje. V zdrojovom kóde sa nachádza
v adresári hardware.
V zdrojovom kóde je to v podstate hlavičkový . h súbor, ktorý obsahuje deklarácie
funkcií, ktoré je potrebné implementovat'. Konkrétne implementácie môžu
byť pridané do AOSP do adresára hardware/<vendor>, kde vendor môže byť spoločnosť,
ktorá H A L implementuje. Väčšinou sú však H A L proprietárne a binárne.
. so súbory je potrebné stiahnuť a pridať spolu s ovládačmi.
3.3.5 Linux Kernel
Verzia kernelu Linuxu pre Android. Kernel pre Android navyše obsahuje niekoľko
pridaných funkcionalit ako wakelocks teda zámky, ktoré zabraňujú systém uspať,
alebo systém spravovania pamäte, ktorý je agresívnejší v uchovávaní pamäti a ďalšie
vlastnosti, ktoré sú dôležité pre fungovanie Androidu ako mobilnej platformy.
3.4 Android Custom ROM
3.4.1 Stiahnutie a zostavenie zdrojového kódu
Ako bolo spomentué vyššie, Android je open-source platforma. Zdrojový kód Androidu
je voľne dostupný z gitového repozitára[20]. Návod pre prácu s repozitárom
je na stránkach androidu[21]. Je možné ho meniť a zostavovať. Keďže je
Android založený na Linuxe, dá sa zostavovať v systéme Mac alebo Linux. Ja som
zostavovala na Linuxe a použila som verziu Android 4.3.1 JellyBean s levelom API
18.
Android používa na zostavenie přednastavené premenné prostredia a systém
súborov make s príponou „mk". Hlavný make súbor v každom adresári má názov
Android.mk. Celý systém obsahuje iba jeden súbor s názvom Makefile.mk, ktorý je
na vrchu zdrojového stromu celého repozitára. Súbory Android.mk určujú, ktoré súbory
sa budú zostavovať pre aké zariadenie. To je možné obmedziť na konkrétny
20
3. OS A N D R O I D
telefon, všeobecne všetky telefony od daného výrobcu, alebo telefony obsahujúce
nejaký hardvér od nejakého konkrétneho výrobcu...
Príkaz pre zostavenie celého systému je make. Okrem toho môžeme zostavovať
aj jednotlivé moduly príkazom make module <názov modulu>. Pomocou príkazu
make a l l zostavíme všetko bez ohľadu na podmienky v súboroch Android.mk.
Zostavený systém zmažeme pomocou make clean. A b y sme mohli použiť špeciálne
makrá spustíme build/envsetup. sh. Pomocou makra croot zmeníme adresár
na koreňový. Makrá cgrep a j grep použijú linuxový program grep len pre
súbory so zdrojovým kódom v jazyku C/C++, respektíve v jazyku Java. Ďalej
môžme použiť ďalšie funkcie a makrá viď [22].
Po stiahnutí z repozitára som zistila, že pre zostavenie Androidu je nutné opraviť
dve chyby. V súbore:
dalvik/vm/native/dalvik_system_Zygote.cpp
chýba odkaz na hlavičkový súbor
# include <sys/resource.h>
a do súboru
development/tools/emulator/opengl/host/renderer/Android.mk
je potrebné prilinkovať knižnicu
+LOCAL_LDLIBS += -1X11.
3.4.2 Zostavenie pre konkrétny telefón
Pre rôzne telefóny sa používajú rôzne výrobcom upravené systémy. V týchto systémoch
sú okrem úpravy softvérových funkcií (napríklad H T C Sense), aj ovládače
pre konkrétny hardvér a iné rôzne funkcionality od výrobcu. Sytém, ktorý je voľne
dostupný sa nazýva Pure Android, čo znamená čistý Android, bez akýchkoľvek
funkcií pre konkrétne telefóny. Takýto Android používajú zariadenia Nexus. Inštalácia
systému Pure Android do ľubovoľného telefónu od ľubovoľného výrobcu
môže dopadnúť tak, že nebudú dostupné nejaké funkcie, alebo sa nepodarí celkovo.
Preto som pracovala so zariadením Samsung Nexus S. Tento telefón používa
staršiu verziu systému Android 4.3.1 JellyBean z júna 2012.
Systém sa implicitne zostavuje pre cieľ generic a je možné ho testovať pomocou
Android emulátoru, ktorý je súčasťou Android SDK. A k chceme zostavovať pre
konkrétne zariadenie, je potrebné stiahnuť binárne súbory s ovládačmi pre dané
zariadenie. Samsung Nexus S, pre ktorý zostavujem, má kódové meno je crespo.
Binárne súbory sa dajú stiahnuť zo stránky Google Developers[23]. Po stiahnutí
je potrebné ich extrahovať a spustiť z koreňového adresára source tree. Potom
pomocou príkazu lunch, ktorý je prístupný až po spustení build/envsetup.sh,
vybrať cieľ zostavovania - crespo. Zostavený operačný systém je v adresári
out/target/product/crespo.
Pre inštaláciu systému do konkrétneho zariadenie je nutné ho najprv rootnuť.
To som spravila podľa návodu na stránke Rootzwiki[24]. Zostavený systém A n droid
sa potom inštaluje do zariadenia prostredníctvom príkazov:
21
3. O S A N D R O I D
LOCAL_PATH := $ ( c a l l n y - d i r )
i n c l u d e $(CLEAR VARS)
tt Build all Java files in the Java subdirectory
L Q C A L S R C F I L E S := $ ( c a l l a l l - j a v a - f i l e s - u n d e r , s r c )
tt None of the APK to build
LQCAL_PACKAGE_NAME := L o c a t i o n M a n a g e r
tt Tell it to build an APK
I n c l u d e $(BUILD_PACKAGE)
i n c l u d e $(CLEAR_VARS)
i n c l u d e $(BUILD MULTI PREBUILT)|
Obr. 3.3: packages/apps/LocationManager/Android.mk
sudo fastboot flash recovery out/target/product/crespo/recovery.img
sudo fastboot flash boot out/target/product/crespo/boot.img
sudo fastboot flash system out/target/product/crespo/system.img
sudo fastboot flash userdata out/target/product/crespo/userdata.img
recovery. img som neflashovala, lebo som chcela aby m i ostal Clockwork recovery,
ktorý som flashla pri roote telefónu.
Google Apps
Systém Android neobsahuje službu Google Apps. Tá obsahuje dôležité aplikácie
od spoločnosti Google ako je napríklad Obchod Play a potom dôležité funckie ako
je pripojenie k účtu Google, alebo pridáva takzvaného NetworkLocationProvider,
ktorý bude spomenutý nižšie. Bez tejto služby je telefón takmer nepoužiteľný, pretože
nové aplikácie sa dajú inštalovať len z príkazového riadku a iba tie, ktoré
majú k dispozícií . apk balík. Služba Google Apps je stiahnuteľná zo stránky Android
Geeks[25]. Služba sa inštaluje v recovery móde. Ten je potrebné si nainštalovať
ako sa píše v návode[24].
sudo fastboot flash recovery recovery-clockwork-6.0.2.5-crespo.img
3.4.3 Zostavovanie aplikácií
Mojím cieľom bolo upraviť OS Android tak, aby poskytoval podvrhnutú polohu.
Aby to bolo pre používateľa pohodlné, je praktické, aby si sám mohol určovať
akú polohu chce, aby Android poskytoval. Pre tento účel som vytvorila aplikáciu.
Keďže aplikácia volá mnou napísané metódy, ktoré sa v klasickom Androide nevyskytujú,
nedá sa zostaviť klasicky pomocou Android SDK v nejakom IDE. Preto
som túto aplikáciu písala ako súčasť operačného systému.
22
3. OS A N D R O I D
Aplikácie patria v Androide do adresára packages/apps. Pre zjednošenie som
aplikáciu vytvárala a zostavovala v Eclipse IDE. Ten vytvorí všetky potrebné adresáre
a súbory. Do adresáru packages/apps som nakopírovala adresár s aplikáciou.
Potom som zmazala adresáre b i n , gen a . setting, ktoré generuje Ecplise a
pre zostavenie nie sú potrebné. Najdôležitejšie je vytvorenie súboru Android.mk.
Podľa neho bude aplikácia zostavená. Ten je potrebné umiestniť do najvyššieho
adresáru aplikácie. Pre moju aplikáciu bol pomerne jednoduchý. Stačilo zadať názov
aplikácie a že chcem aby sa zostavili všetky súbory typu java vo všetkých adresároch
a podadresároch viď obr.3.3. Nakoniec je potrebné dať vedieť Androidu,
pre aký cieľ chceme túto aplikáciu zostavovať. Do súboru build/target/product/core
.mk som pridala k PRODUCT_PACKAGES svoju aplikáciu.
23
4 Služby zisťovania polohy v OS Android
V tejto kapitole popíšem, ako sú implementované jednotlivé frameworky, pomocou
ktorých sa dá zistiť poloha zariadenia. V OS Android je pre služby zisťovania
polohy framework android. location. Ten poskytuje polohu na základe informácií,
ktoré vie telefón získať. V AOSP sú implementované len dva spôsoby, ako získať
polohu zariadenia priamo. Prvým je GPS (GPS Provider) a druhým je takzvaná
pasívna poloha (Pasive Provider).
Poloha sa dá získať ale aj nepriamo. A to pomocou informácií o BTS stanici, ku
ktorej je zariadenie pripojené, respektíve o všetkých BTS staniciach, na ktoré má zariadenie
priamu viditeľnosť. Tieto informácie poskytuje framework android. t e l e phony.
Framework android.net .wif i zase poskytuje adresu M A C prístupového
bodu WiFi ku ktorému je zariadenie pripojené, resp. všetkých prístupových bodov,
na ktoré má dosah.
4.1 android.location
Address Trieda reprezentujúca adresu. Prakticky je to len množina textových reťazcov
opisujúcich polohu.
Criteria Zoznam kritérií pre výber vhodného LocationProvider-a. Napríklad podľa
spotreby energie alebo podľa presnosti. Obsahuje set a get metódy pre každé
kritérium.
Geocoder Umožňuje z danej polohy (Location) na základe zemepisnej šírky a
dĺžky získať adresu(Address) a naopak.
GpsSatellite Momentálny stav GPS Satelitu - azimut, nadmorská výška...
GpsStatus Stav nástroja pre poskytovanie GPS.
Location Trieda reprezentuje geografickú polohu, ktorá je daná hlavne zemepisnou
šírkou a dĺžkou. Naviac obsahuje ďalšie údaje polohe a jej presnosti ako
aj textový reťazec, ktorý obsahuje názov LocationProvidera.
LocationManager Poskytuje aplikáciám prístup k pravidelným aktualizáciám geografickej
polohy zariadenia, alebo vytvorí Intent, keď zariadenie vstúpi do
istej blízkosti danej geografickej polohy.
LocationProvider Abstraktná trieda pre poskytovanie polohy zariadenia. Poskytuje
informácie o danom poskytovateľovi polohy - presnosť, spotreba energie,
aký hardvér potrebuje(GPS satelit, sieť - internetová alebo telefónna),
rýchlosť...1
1. Jej implementáciou nie sú triedy NetworkLocationProvider, GpsLocationProvider ani PassiveProvider,
ktoré budú spomenuté neskôr
25
4. S L U Ž B Y Z I S Ť O V A N I A P O L O H Y V O S A N D R O I D
LocationManager
Služba zisťovania polohy OS Android poskytuje informácie o polohe zariadenia
prostredníctvom triedy LocationManager. Podľa dokumentácie Androidu sú v zásade
dva spôsoby ako zistiť polohu zariadenia pomocou LocationManagera.
Prvým je metóda getLastKnownLocation triedy LocationManager, ktorá berie
ako argument reťazec, reprezentujúci meno poskytovatel'a, vracia poslednú
známu polohu pre daného poskytovateľa a túto informáciu poskytne v zásade
jednorázovo.
Ďalší spôsob je vytvoriť si objekt LocationListener, ktorý pri zmene polohy
volá metódu onLocationChanged(Location location). Tá poskytuje polohu a je
potrebné ju v našom kóde preťažiť. Potom je potrebné požiadať o aktualizácie
pomocou metódy requestLocationUpdates () triedy LocationManager.
LocationManagerService
Je služba, ktorá spravuje poskytovateľov polohy a stará sa o aktualizácie a upozornenia
súvisiace s polohou. Implementuje metódy volané triedou LocationManager.
Väzbu medzi týmito triedami na vrstve IPC Binder zabezpečuje rozhranie
ILocationManager.aidl.
Drží si mapu poskytovateľov a pre nich poslednú známu polohu mProvidersByName.
Implementuje funkciu getLastKnownLocation, a to tak, že pre daného poskytovateľa
vráti z mapy mProvidersByName.
Implementuje triedu LocationWorkerHandler, ktorá dedí od triedy Handier a
preťažuje jej metódu handleMessage(Message msg), ktorá je volaná poskytovatel'mi
polohy. Z premennej msg vyextrahuje polohu a zavolá metódu handleLocationChangedLocked.
V tejto metóde ošetrí pridanie alebo aktualizáciu polohy v mape
mProvidersByName a vysiela polohu všetkým aplikáciám, ktoré o aktualizácie
žiadali pomocou triedy LocationListener.
Metóda handleMessage je volaná systémom po zavolaní metódy reportLocation,
ktorá posiela správu:
mLocationHandler.sendMessageAtFrontOfQueue(m)).
LocationProviderInterface
LocationProviderlnterface je rozhranie, ktoré môže byť implementované nejakým
poskytovateľom polohy. Natívny kód volá metódu reportLocation tohto rozhrania
a tá volá metódu reportLocation triedy LocationManagerService, ktorá rozosiela
aktualizácie.
4.1.1 Poskytovatel' polohy siete
Poloha založená na sieťach (Network Provider) je prístupná až po inštalácií Google
Apps 3.4.2. Dôvodom je, že na zistenie polohy na základe pripojenia k sieti
26
4. S L U Ž B Y Z I S Ť O V A N I A P O L O H Y V O S A N D R O I D
je nutné poznať polohu stanice BTS viď 2.2.1 alebo polohu na základe M A C adresy
prístupového bodu WiFi viď 2.2.2. Tie zariadenie získa z databázy spoločnosti
Google, len po inštalácií Google Apps a prihlásení k účtu Google2
.
Okrem frameworku android.location, je možné zistiť polohu pomocou frameworkov
android.telephony a android.net .wif i . Tie síce neposkytujú informácie
o polohe zariadenia, ale poskytujú údaje o bunke, ku ktorej je zariadenie pripojené,
respektíve o M A C adrese zariadenia. Spoločnosť Google poskytuje služby
The Google Maps Geolocation API, pomocou ktorých sa dá táto poloha získať. A l ternatívne
existuje mnoho ďalších verejných databáz, ktoré poskytujú API pre získanie
polohy zariadenia na základe id bunky / adresy M A C . Medzi najväčšie,
ktoré poskytujú polohu na základe id bunky, patria Combain Mobile[26] a Unwired
Labs[27]. Jediné relevantné API poskytujúce polohu na základe adresy M A C ,
ktoré som našla je od spoločnosti SkyHook[28].
Toto vlastne robí za programátora framework a n d r o i d . l o c a t i o n a výslednú
polohu poskytuje ako Network Provider. Dá sa teda predpokladať, že ak podvrhnem
polohu tak, že zariadenie bude poskytovať údaje o inej bunke / adrese M A C ,
tak aj Network Provider, bude poskytovať polohu podvrhnutú. Je teda dôležité
zistiť zdroj týchto informácií.
4.1.2 Poskytovatel' polohy GPS
Každý výrobca implementuje vlastné ovládače pre svoj hardvér. Tieto ovládače
nie sú súčasťou AOSP a je nutné ich doplniť. Väčšina z nich je k dispozícií iba ako
binárne súbory. Teda nie je možné upraviť ich zdrojový kód. N a úrovni H A L je
v AOSP predpísané rozhranie gps. h. Je to hlavičkový súbor, ktorý obsahuje deklarácie
funkcií, ktoré je potrebné definovať v H A L ovládači. Ako open-source je
k dispozícií implementácia len pre zariadenia GPS spoločnosti Q U A L C O M . Nexus,
s ktorým som pracovala, používa zariadenie GPS od spoločnosti BROADC
O M . N a internete sú k dispozícií len binárne súbory. Teda na úrovni H A L by
bolo možné podvrhnut' polohu iba pre mobilné telefóny so zariadením GPS od
spoločnosti Q U A L C O M .
Vrstva H A L komunikuje s vrstvou systémových služieb pomocou metód implementovaných
v súbore GpsLocationProvider.cpp. Tento súbor tvorí medzivrstvu
na prevádzanie zdrojového kódu medzi jazykom Java a jazykom C++. GpsLocationProvider
implementuje rozhranie LocationProvider viď 4.1 a posiela
informácie o polohe službe LocationManagerService viď 4.1, ktorá posiela informácie
všetkým inštanciám triedy LocationManager, ktoré si jednotlivé aplikácie
vytvorili.
2. spoločnosť Google informácie o polohe zariadenia, resp. človeka prihláseného ku google účtu,
ukladá pre vlastné potreby
27
4. S L U Ž B Y Z I S Ť O V A N I A P O L O H Y V O S A N D R O I D
"j- Application Developers
• Google S AOSP Contributors
• Hardware Manutacturers
SENSORS HUB
Obr. 4.1: Senzory v AOSP[29]
4.1.3 Pasívny poskytovatel'
OS Android ponúka možnosť použiť polohu získanú od takzvaného pasívneho
poskytovateľa polohy, v skutočnosti nejde o reálne zistenie polohy. Pasívny poskytovatel'
poskytuje updaty polohy získané ako posledné od ľubovoľného iného
poskytovateľa, ak si ich vyžiada nejaká iná aplikácia alebo služba. Výhodou môže
byť ušetrenie batérie, nevýhodou neaktuálnosť údajov.
4.2 android.telephony
Tento framework poskytuje informácie o G S M , C D M A , LTE a W C D M A pripojení.
Zo sietí G S M , LTE a W C D M A je možné získať len základné informácie o bunke,
nie ich polohu . Framework pre sieť C D M A poskytuje priamo informácie o polohe.
Framework je vo všetkých prípadoch implementovaný podobne. Keďže Samsung
Nexus S, ktorý používam podporuje iba GSM, tak sa budem sústrediť na túto sieť.
4.2.1 Prehľad tried
CellIdentityGsm Trieda reprezentujúca unikátnu bunku GSM.
Celllnfo Informácie o bunke, získané v nejakom čase, ktoré sa už nemôžu zmeniť.
Slúži na uloženie informácií o bunke, získaných v nejakom konkrétnom čase.
28
4. S L U Ž B Y Z I S Ť O V A N I A P O L O H Y V O S A N D R O I D
Vendor implemented H A L
*gps.cpp
AOSP
gps-h
co m_a ndroid_server_location
G psL oca tionProvid er.cpp
GpsLocat ionProvide r.j ava
LocationManagerService.java _.
ILocationManager.aidl
LocationManager.java
System Service
" J
j Binder IPC |
^ Framework ^|.
Obr. 4.2: Implementácia GPS v OS Android
29
4. S L U Ž B Y Z I S Ť O V A N I A P O L O H Y V O S A N D R O I D
CelllnfoGsm Dedí od Celllnfo. Rozširuje Celllnfo o informácie špecifické pre GSM.
CellLocation Reprezentuje polohu bunky
GsmCellLocation Dedí od CellLocation. Rozširuje CellLocation o informácie špecifické
pre GSM.
CellSignalStrengthGsm Data relevantné k sile signálu. Dôležité pre určenie vzdialenosti
telefonu od stanice BTS.
NeighboringCellInfo Informácie o susedných bunkách (Bunky ktorých signál
zariadenie chytá, ale používa inú bunku).
PhoneStateListener Načúva zmenám súvisiacim so zmenami stavu telefónu.
TelephonyManager Poskytuje prístup k službám telefonie.
4.2.2 G S M
Pre zistenie polohy na základe polohy bunky sú potrebné štyri údaje: M C C (Mobile
Country Code - mobilný kód krajiny), M N C (Mobile Network Code - mobilný
kód siete), L A C (Location Area Code - kód oblasti), CID (Cell Id - id bunky).
Aplikácie dokážu získať M C C , M N C , CID a L A C pomocou G S M API. Podobne
ako polohu v android. location sprístupňuje LocationManager, polohu bunky
CellLocation získame od TelephonyManager. Ten si získame volaním systémovej
služby:
context.getSystemService(Context.TELEPHONY_SERVICE)
TelephonyManager
TelephonyManager poskytuje dve informácie relevatné k polohe. Prvou z nich je
informácia o bunke, ku ktorej je telefón pripojený. Tú získame volaním getCellLocation.
Ďalšou možnosťou je volanie metódy getNeighboringCellInf o, ktoré
vracia zoznam všetkých buniek, na ktoré telefónny signál dosiahne. Informácie
o susedných bunkách neposkytujú všetky zariadenia. Samsung Nexus S túto funkcionalitu
nepodporuje a preto ju nebudem rozoberať do hĺbky.
PhonelnterfaceManager
V oboch prípadoch sú volané metódy rozhrania ITelephony. aidl (toto rozhranie
tvorí vrstvu IPC Binder ako bolo popísané vyššie ). Toto rozhranie je implementované
triedou Phonelnterf aceManager. Táto trieda je rozhraním medzi službami
telefonie a telefónom (aplikáciou určenou na telefonovanie). Táto trieda je v AOSP
v adresári packages/apps/Phone/src/com/android/phone. Metóda getCellLocation
triedy Phonelnterf aceManager volá metódu rozhrania Phone, s rovnakým
menom. N a získanie informácií o susedných bunkách posiela požiadavku pomocou
triedy Handier. Ten potom volá metódu getNeighboringCids rozhrania Phone.
30
4. S L U Ž B Y Z I S Ť O V A N I A P O L O H Y V O S A N D R O I D
AO SP
Ú rildjc
RIL.java
GsrnServiceStateTrackerjava
[Telephony.aidl
Te lephony Ma na ge r.java
BLndEr IPC
Application Framework
Obr. 4.3: Implementácia služieb telefonie v OS Android
31
4. S L U Ž B Y Z I S Ť O V A N I A P O L O H Y V O S A N D R O I D
GSMPhone
Rozhranie Phone je implementované abstraktnou triedou PhoneBase, od ktorej dedí
trieda GSMPhone. V tejto triede je implementovaná metoda getCellLocation tak,
že vracia mSST.cellLoc, čo je poloha bunky zistená službou GSMServiceStateTracker,
ktorá dedí od služby ServiceStateTracker.
GSMServiceStateTracker
Má ako public premennú cellLoc. Tá sa mení ak nastane EVENT_LOCATION_UPDATES_ENABLED.
To znamená, ak sa povolia updaty polohy. To nastáva, ak niekto
zavolá enableSingleLocationUpdate alebo enableLocationUpdates. Môže to
byť aplikácia pomocou TelephonyManager. Ďalej sa mení pri takzvanom PollState.
Ten sa volá pri udalostiach EVENT_SIM_READY, EVENT_RADIO_STATE_CHANGED a EVENT_NETWORK_STATE_CHANGED.
V oboch prípadoch sa volá funkcia getVoiceRegi strationState
rozhrania Commandslnterf ace.
RIL.java
Rozhranie Commandslnterf ace implementuje trieda RIL.java. Okrem nej sú ešte
v súbore triedy RILSender a RILReceiver. Pomocou RILSender odosiela požiadavky
a pomocou RILReceiver príjma a spracúvava odpovede. V metóde getVoiceRegistrationState
je pomocou LocalSocket odoslaná požiadavka RIL_REQUEST_V0ICE_REGISTRATÍ0N_STATE.
Odpoveď na túto požiadavku obsahuje reťazec
s údajmi o CID a L A C . Tie sa odošlú naspäť triede GSMServiceStateTracker,
ktorá si potom aktualizuje informácie.
Informácie o operátorovi - M C C a M N C sa získavajú obdobne. V metóde getOperator
je odoslaná požiadavka RIL_REQUEST_OPERATOR. V odpovedi sú informácie
o M C C a M N C .
Android Rádio Interface Layer
Vo všeobecnosti je RIL vrstva v operačnom systéme, ktorá poskytuje rozhranie pre
rádio. Rádio v tomto kontexte chápané ako hardvér, ktorý má možnosť vysielať a
prijímať signály. V OS Android táto vrstva sprostedkúva rozhranie pre framework
telephony. Má dva základné komponenty. Prvým je RIL Daemon a druhým Vendor
RIL.
RIL Daemon je v AOSP v adresári AOSP/hardware/ril/rild/. Jeho úlohou je zinicializovat'
Vendor RIL a posielať mu všetky požiadavky od frameworku telephony.
Tieto požiadavky posiela formou vyžiadaných (solicited) správ.
Vendor RIL je výrobcom implementovaný a špecifický pre konkrétny hardvér.
V AOSP sa nenachádza, ale musí implementovat' funckie deklarované v hlavičkovom
súbore r i l .h, ktorý je v AOSP v adresári AOSP/hardware/ril/include/tele-
32
4. S L U Ž B Y Z I S Ť O V A N I A P O L O H Y V O S A N D R O I D
Applications S Phone Application ~"\
'. ^2 )
Application UEH
F r a m e w o r k ^ S B í
Libraries
(user s p a c e )
Unix
Libraries
(user s p a c e )
Linux Kernel „ , „
Control
Packet Service
B a s e b a n d ^ J
Obr. 4.4: Android Radio Interface Layer
phony/ Jeho úlohou je spracovať data, ktoré príjme od hardvéru a poslať ich RIL
Daemonovi, vo forme nevyžiadaných 3
{unsolicited) správ.
4.3 android.net.wifi
Framework android.net .wif i poskytuje prístup k informáciám o pripojení WiFi
a momentálne viditeľných prístupových bodoch. N a to, aby sme určili polohu telefónu,
nemusí byť zariadenie pripojené k žiadnej sieti WiFi. Stačí, ak je zapnutý
adaptér a zariadenie je schopné vyhľadať prístupové body. Poloha sa určuje na
základe BSSID. Tento údaj môže byť prístupný aj bez autentizácie voči prístupovému
bodu. NetworkProvider zistí BSSID všetkých prístupových bodov v okolí
telefónu, spáruje ich s polohou (pomocou databázy viď refwifi). N a základe získaných
polôh a intenzity signálu (vie ktorý prístupový bod je bližšie / ďalej) približne
určí polohu zariadenia.
ScanResult Trieda reprezentujúca prístupový bod, ku ktroému zariadenie nie je
pripojené.
Wifilnfo Informácie o stave aktívneho pripojenia WiFi.
3. v zmysle, že o nich nebolo žiadané, nie že sú nechcené
33
4. S L U Ž B Y Z I S Ť O V A N I A P O L O H Y V O S A N D R O I D
WifiManager Poskytuje prístup k službám WiFi.
WifiManager
Prístup k funkciám frameworku w i f i sprostredkúva WifiManager. Zoznam prístupových
bodov vracia metóda getScanResults. Podobne ako to bolo s telefóniou
a službami polohy, WifiManager pomocou rozhrania IWifiManager.aidl metódy
služby Wif iService.
WifiService
Táto služba implementuje rozhranie IWifiManager.aidl a jej úlohou je odpovedať na
požiadavky triedy WifiManager. V metóde getScanResults volá metódu syncGetScanResultsList
triedy WifiStateMachine.
WifiStateMachine
Úlohou tejto triedy je sledovať stav pripojenia WiFi. Má na starosti reagovanie na
všetky udalosti súvisiace s pripojením WiFi. Všetky zmeny týkajúce sa pripojenia
sa odohrávajú v tejto triede. Udržuje si zoznam momentálne viditeľných prístupových
bodov ako mScanResults. Ten sa aktualizuje, ako reakcia na udalosť
SCAN_RESULTS_EVENT. Metóda scanResults triedy Wif iNative vráti akutálny zoznam
výsledkov skenu. V metóde setScanResults sa potom dané výsledky spracujú
a uložia do zoznamu mScanResults.
WifiMonitor
Trieda WifiMonitor čaká na udalosti od wpa_supplicant server a reaguje na ne.
Wpa_supplicant server je server, ktorý sprostedkúva autentizovanú komunikáciu
medzi zariadením a prístupovým bodom WiFi. Je implementovaný výrobcom zariadenia
a v AOSP nie je dostupný. Pre nás zaujímavou udalosťou je konkrétne
udalosť SCAN_RESULTS. Reakcia na túto udalosť je poslanie správy s udalosťou
SCAN_RESULTS_EVENT triede WifiStateMachine.
WifiNative
Táto trieda volá natívne metódy implementované v súbore android_net_wif i_Wif
i . c p p . Metóda scanResults volá natívnu metódu doStringCommand. Táto volá
funkciu doCommand, deklarovanú v súbore wif i . h, ktorú implemetuje v rámci H A L
výrobca wifi. Táto metóda vracia zoznam nájdených prístupových bodov WiFi.
34
4. S L U Ž B Y Z I S Ť O V A N I A P O L O H Y V O S A N D R O I D
Apps
Platform
Sensor Mgr
Sensor HAL
Hardware Sensors
Location Manager
Gps LoeationP rovi der
TY
Neww r kLocatlon Provider
(N LP)
A -
opp/dgso
• i—J 1
TT
_
Obr. 4.5: Získanie polohy bez Google Location API[30]
Fused Location Provider
í ) . Í L
Platform Components
Hardware components
Obr. 4.6: Zjednodušenie získania polohy pomocou Google location API[30]
4.4 Google location API
Momentálne sa odporúča, namiesto frameworku android.location, použiť Google
location API. Toto rozhranie je jednoduchšie a poskytuje presnejšiu polohu.
Google location API je rozhranie od spoločnosti Google pre zisťovanie polohy.
Toto rozhranie si kladie za cieľ poskytovať programátorom aplikácií čo najpresnejšiu
polohu tak, aby programátor nemusel riešiť, od ktorého poskytovateľa poloha
je. Využíva takzvaného „Fused Provider" obr.4.6, ktorý spája všetky možnosti ako
polohu získať a vyberá najlepšiu z nich. Pre výber najlepšej polohy sa zameriava
na tri hlavné kritéria - spotreba energie, presnosť a pokrytie. Ponúka možnosť
vybrať si, akú presnú polohu pre našu aplikáciu potrebujeme. (Menej presná poloha
šetrí batériu). Výhodou je prístup k najpresnejšej možnej polohe vo vnútri aj
vonku.
Pre poskytovanie polohy používa štyri rôzne technológie. Polohu zistenú pomocou
GPS používa vonku a len pri nastavení najvyššej presnosti, kvôli vysokej
spotrebe energie. Ako alternatívu používa polohy získané pomocou prístupového
bodu WiFi a polohu bunky, ku ktorej je telefón pripojený. Zaujímavosťou je vylepšovanie
polohy pomocou senzorov. Pomocou gyroskopu, akcelerometra alebo
35
4. S L U Ž B Y Z I S Ť O V A N I A P O L O H Y V O S A N D R O I D
barometra odhaduje rýchlosť pohybu. N a základe informácií o predchádzajúcej
polohe a odhadnutej rýchlosti vie spresniť polohu (využíva sa najmä pri polohe
získanej zo siete). Ďalšou výhodou je, že ak sa zariadenie nehýbe, nie je nutné
zisťovať novú polohu a šetrí sa tým batéria. Podľa spoločnosti Google fungujú
senzori veľmi spoľahlivo. Ako bonus poskytuje Google Location API informácie o
pohybe, ktorý človek so zariadením vykonáva. N a základe frekvencie zmien v senzoroch
vie rozoznať státie, chôdzu, jazdu na bicykli alebo jazdu autom[30].
36
5 Implementácia
5.1 Existujúce riešenia
Z Google Play je možné si stiahnuť viacero aplikácií, ktoré slúžia na poskytovanie
fiktívnej polohy. Vo všeobecnosti fungujú veľmi podobne, a to tak, že využívajú
metódy triedy LocationManager pre pridávania a odoberanie testovacích poskytovateľov
polohy. Tí sú určení ako nástroj pre vývojárov pre simulovanie polohy za
účelom testovania aplikácií. A b y fungoval, vyžaduje povolenie android.permission.ACCESS_MOCK_LOCATION
a ešte musí byť v nastaveniach v možnostiach pre
vývojárov zakliknuté „Povoliť simulované polohy (Allow Mock Locations)". Bez
rootu telefónu je to jediná možnosť ako simulovať falošnú polohu.
Aplikácia volá metódu addTestProvider triedy LocationManager a polohu nastaví
pomocou metódy setTestProviderLocation, ktorá berie ako argument ľubovoľnú
polohu. Podobne, ako bolo vysvetlené vyššie 4.1, sú volané metódy triedy
LocationManagerService, ktorá si vytvorí inštanciu triedy MockProvider a v nej
si uchováva informácie o simulovanej polohe a poskytuje ich nižším vrstvám. Tu
si treba uvedomiť, že pre získanie polohy podávame na vstupe poskytovateľa ako
reťazec, nie ako inštanciu triedy LocationProviderlnterface
Celé toto riešenie je prispôsobené tomu, že sa bude používať len na testovanie
pre vývojárov. Preto chytrejšia aplikácia veľmi jednoducho zistí, že sa jedná o polohu
podvrhnutú. Najjednoduchším spôsobom je použitie metódy isFromMockPro vider
triedy Location, ktorá vracia hodnotu True, práve vtedy keď je poloha poskytnutá
falošným poskytovateľom. Táto metóda je ale dostupná až od A P I 18
(Android 4.3) Ďalšou možnosťou je volanie :
Settings.Secure.ALL0W_M0CK_L0CATT0N).equals("0")),
ktoré určuje, že v nastaveniach nebolo zakliknuté povolenie simulovania polohy
(vieme, že poloha simulovaná nebola, ak by bolo zakliknuté, tak nevieme určiť
či je poloha pravá alebo nie). Ďalej vieme zistiť, či nejaká aplikácia požaduje povolenie
android.permission. ACCESS_M0CK_L0CATI0N. Vtedy môžme mať taktiež
podozrenie, že poloha nie je pravá. Ďalšou možnosťou je zistenie polohy pomocou
iných frameworkov viď 4.2 a 4.3.
Aplikácia sa potom môže vyhnúť simulovanej polohe tak, že použije metódu
removeTestProvider(String provider) triedy LocationManager. Tým zabráni
konkrétnemu poskytovatel'ovi „provider "(napríklad LocationManager.GPS_PROVIDER)
oznamovať fiktívnu polohu. Potom si vyžiada aktualizácie polohy od rovnakého
poskytovateľa a tie už budú oznamovať reálnu polohu.
5.2 Simulovanie polohy v rámci OS Android
Mojím cieľom je snaha o podvrhnutie polohy v najnižšej možnej vrstve operačného
systému (najbližšie k jadru). A k o uvádzam v kapitole 4 v OS Android je
37
5. I M P L E M E N T Á C I A
najbližšie k ovládaču zariadenia vrstva H A L . Keďže väčšina H A L sú proprietárne,
ideálne je polohu falšovať v triede, ktorá komunikuje s H A L .
5.2.1 GPS
V GPS komunikuje s H A L trieda com_android_server_location_GpsLocationProvider.
cpp. Táto trieda však iba sprostredkúva preklad metód javovskej triedy
GpsLocationProvider do natívneho kódu a posiela ich H A L . Preto polohu podvrhujem
v súbore GpsLocationProvider. j ava.
N a obrázku 4.2 je vidno, ako spolu jednotlivé triedy komunikujú pri zisťovaní
polohy. Pri podvrhovaní som použila rovnaký postup. Trieda LocationManager vo
funkcií setFakeLocation volá, pomocou rozhrania ILocationManager. a i d l , metódu
setFakeLocation triedy LocationManagerService. j ava a tá zavolá metódu
setFakeLocation triedy GpsLocationProvider.j ava.
V tejto triede som vytvorila privátnu premennú f akeLocation typu Location,
ktorá reprezentuje fiktívnu polohu. Implicitne má hodnotu n u l l . Vo volaní funkcie
setFakeLocation sa nastaví na hodnotu, ktorá je predávaná ako argument
tejto funkcie. Ďalej funkcia setFakeLocation volá metódu reportLocation, ktorá
volá metódu triedy LocationManagerService s rovnakým názvom a ten posiela
aktualizácie polohy všetkým, ktorí si ich registrovali. Metóda reportLocation je
normálne volaná z natívneho kódu pri aktualizácií polohy. Túto metódu som upravila
tak, že ak je premenná f akeLocation rôzna od n u l l , tak sa posiela namiesto
zistenej polohy táto podvrhnutá. Podobne ako setFakeLocation funguje metóda
38
5. I M P L E M E N T Á C I A
cancelFakeLocation, akurát premennú f akeLocation nastaví na hodnotu null.
5.2.2 RIL
Ako bolo popísané vyššie, v kapitole 4.2.2, Vendor RIL je proprietámy a RIL Deamon
iba preposiela správy prijaté od triedy RIL. j ava. Teda polohu som podvrhla
v triede RIL. j ava. Poloha, ktorá sa dá získať z toho frameworku, sa získava
z údajov o bunke (CID, L A C , M C C a M N C ) . Pre podvrhnutie polohy som teda
naimplementovala podvrhovanie týchto údajov.
Podobne ako v GPS, v telefonií som tiež volala metódu setFakeLocation od
vrstvy frameworku až po triedu RIL. j ava, postupne cez všetky triedy a rozhrania
na obrázku 4.3. Táto metóda má však tentoraz argumenty CID, L A C , M C C a M N C .
Podvrhovanie polohy je implementované veľmi podobne ako u GPS. Premenné
fakeCid, fakeLac, fakeMcc a fakeMnc sú inicializované na hodnotu -1. Pri zavolaní
setFakeLocation sa nastavia na hodnoty, ktoré boli dané na vstupe tejto
metódy. Naopak pri volaní cancelFakeLocation sa opäť nastavia na hodnotu -1.
V metóde processSolicited triedy RILReceiver sa spracuvávajú odpovede na
vyžiadané správy. Fiktívne údaje sa použijú za predpokladu, že hodnoty fakeLac
a f akeCid sú väčšie alebo rovné nule. Pri odpovedi na správu RIL_REQUEST_VOICE_REGISTRATION_STATE
sa do poľa reťazcov s odpoveďou uložia na správne hodnoty
fiktívne údaje fakeLac a f akeCid. A k je správa RIL_REQUEST_OPERATOR, tak
sa podobne falšujú údaje fakeMcc a fakeMnc.
5.2.3 WiFi
Poloha z frameworku wifi sa dá získať pomocou údajov o SSID prístupových bodov
WiFi, ktoré sú aktuálne dostupné. A k chceme podvrhnut' polohu, musíme
preto podvrhnut' SSID týchto prístupových bodov.
Hlavný rozdiel spočíta v tom, že sa neposiela len jeden fiktívny údaj, ale môže
ich byť viacej. Predpokladá sa, že zariadenie zachytáva signál viacerých prístupových
bodov. Aplikácia teda neposiela len vopred určený malý počet údajov
(ako zemepisná šírka a výška vo frameworku location alebo L A C , CID, M C C a
M N C vo frameworku telephony), ale celý zoznam. Preto je argumentom metódy
setFakeScanResults reťazec, ktorý obsahuje celý výsledok skenovania. Valídny
môže byť aj taký reťazec, ktorý neobsahuje žiadne záznamy. WiFi si potom bude
myslieť, že v dosahu nie sú žiadne prístupové body. Aplikácia sa sama musí postarať,
aby bol odoslaný v správnom formáte.
Trieda, ktorá reaguje na udalosti a na základe nich posiela údaje niekam ďalej,
je Wif iStateMachine. Najrozumnejšie je teda falšovať polohu priamo v nej, ideálne
pri parsovaní výsledkov. Implementácia je principiálne rovnaká ako v prvých
dvoch prípadoch. Metóda setFakeScanResults triedy Wif iManager volá metódu
s rovnakým názvom triedy Wif iService a tá volá metódu triedy Wif iStateMachine
Volanie metódy setFakeScanResults nastaví premennej f akeScanResults obsah
so simulovanými prístupovými bodmi, metóda cancelFakeScanResults na-
39
5. I M P L E M E N T Á C I A
3> H Ů 13 VAŘ 21:30
n G p s L o c a t i o n A c t i v i t y
Paris Q».
Cancel fake location Set this location
B a ©
ifil GsmLocationActivity
Cell ID : 322847
Location Area Code 38023
Mobile Country Code 230
Mobile Network Code 03
5 0 4 1
Cancel fake location Set this location
(a) GpsLocationActivity
(b) GsmLocationAcitivty
Obr. 5.2: Ukážka aplikácie Location Manager
staví hodnotu na n u l l . Metóda setScanResults potom, ak je f akeScanResults
rôzne od n u l l , nastaví premennej mScanResults fiktívne hodnoty1
.
5.3 Aplikácia Location Manager
Je to aplikácia, ktorá umožňuje prístup k naimplementovaným funkciám pre falšovanie
polohy. Obsahuje štyri hlavné aktivity. Prvá aktivita - GpsLocationActivity,
slúži pre falšovanie polohy GPS, druhá aktivita - GsmLocationActivity pre falšovanie
údajov o bunke G S M , tretia aktivita - WifiLocationActitivy pre falšovanie
zoznamu viditeľných prístupových bodov WiFi. Posledná aktivita - TrackAndSpoofActivity
dáva dokopy tieto tri základné funkcie a umožňuje falšovať polohu
naraz pre všetky zdroje.
5.3.1 MainActivity
Je to jednoduchá aktivita, ktorá podáva informácie o aktuálnej polohe a obsahuje
tlačidlá, ktoré umožňujú prístup k ostatným aktivitám. Po kliknutí na tlačidlo Get
1. Tu by mohla nastať pochybnosť, či nenastaviť mScanResults rovno v metóde setFakeScanResults
- to by síce šlo, ale pri najbližšom volaní setScanResults by sa premazali (táto metóda je volaná periodicky,
pomerne často)
40
5. I M P L E M E N T Á C I A
Last known location sa zobrazia posledné známe polohy od všetkých poskytovateľov.
Ďalej si táto aktivita vytvára inštancie triedy LocationListener pre poskytovatel'ov
NETWORK_PROVIDER a GPS_PROVIDER, ktoré čakajú na správu o zmene
polohy. Reakciou na túto správu je potom aktualizácia vypísaných informácií o
polohe.
5.3.2 GpsLocationActivity
Účelom tejto triedy je nastaviť fiktívnu polohu od poskytovateľa GPS_PROVIDER.
Tento polohu určuje na základe zemepisnej šírky a výšky. Podvrhovanie funguje
iba za predpokladu, že je zapnuté zariadenie GPS.
Táto aktivita obsahuje kolónky, kam používateľ zadá zemepisnú šírku a výšku.
Implicitne sa do týchto kolóniek vyplní posledná známa poloha od poskytovateľa
GPS. Alternatívne môže používateľ namiesto polohy zadať adresu do kolónky
Search address or plače a po kliknutí na obrázok lupy sa pomocou triedy Geocoder
dohľadajú údaje o zemepisnej šírke a výške a vyplnia sa do patričných kolóniek.
Kliknutie na tlačidlo Set this location zapne poskytovanie fiktívnej polohy pomocou
metódy setFakeLocation triedy LocationManager. Kliknutie na Cancelfake
location zase simulovanie polohy ruší pomocou metódy cancelFakeLocation triedy
LocationManager.
5.3.3 GsmLocationActivity
Táto aktivita slúži pre falšovanie údajov o bunke GSM. Používateľ zadá do príslušných
kolóniek údaje o bunke ( C I D , L A C , M C C a M N C ) . Po kliknutí na tlačidlo Set
this location sa zavolá metóda setFakeLocation triedy TelephonyManager, ktorá
bude podvrhovať údaje o bunke. Naopak kliknutie na tlačidlo Cancelfake location
ruší podvrhovanie polohy pomocou metódy cancelFakeLocatio triedy Telepho­
nyManager.
Implicitne sa do kolóniek plnia údaje o bunke, ku ktorej je zariadenie práve pripojené.
Tieto údaje sa taktiež pre kontrolu zobrazujú na displeji. Po začatí podvrhovania
polohy sa údaje neaktualizujú hneď, ale až po istom čase, keď sa odošlú požiadavky
na aktualizáciu operátora (RIL_REQUEST_OPERATOR) a aktualizáciu stavu
(RIL_REQUEST_VOICE_REGISTRATION_STATE). Údaje zobrazené na displeji sa samé
nezaktualizujú, je potrebné opustiť aktivitu a znova do nej vojsť o čosi neskôr.
5.3.4 WifiLocationActivity
Hlavnou úlohou tejto aktivity je podvrhovať informácie o viditeľných prístupových
bodoch WiFi, ktoré potom využije Network Provider na určenie polohy zariadenia
v sieti. Sama si interne uchováva zoznam prístupových bodov - accessPoints,
ktorý môže používateľ ľubovoľne upravovať a potom použiť na podvrhovanie.
Prístupový bod je uložený ako inštancia triedy AccessPoint.
41
5. I M P L E M E N T Á C I A
Táto trieda sama o sebe nemá žiadnu inú funckiu. Argumenty konštruktora
sú atribúty prístupového bodu - reťazec BSSID, celé číslo frequency, celé
číslo level, reťazec capabilities, reťazec SSID. Ďalej implementuje getter
a setter pre každý z týchto atribútov. Poslednou implementovanou funkciou
je funckia toString, ktorá vráti textovú reprezentáciu tohto prístupového bodu.
Táto textová reprezentácia má formát (atribúty BSSID, frequency, level, capabilities
a SSID, v tomto poradí oddelené tabulátorom), ktorý je vyžadovaný triedou
Wif iStateMachine, aby šiel prístupový bod parsovať. Takže pri púšťaní funkcie
setFakeResults triedy Wif iManager, stačí medzi jednotlivé prístupové body pridať
odriadkovanie.
Implicitne sú v zozname prístupových bodov WiFi - accessPoints uložené
body, ktoré aktuálne Wif iManager vracia ako výsledky skenu. Aktivita ich zobrazuje
pomocou ListView a sú klikateľné. Po kliknutí na prístupový bod je možné
upraviť mu atribúty - BSSID, SSID, alebo ho úplne odstrániť zo zoznamu accessPoints.
Do zoznamu je takisto možné pridávať nové prístupové body po kliknutí
na tlačidlo Add access point.
Ďalšou funckiou tejto aktivity je, že si môže celý zoznam prístupových bodov
uložiť do pamäte telefónu a neskôr ho načítať a použiť na podvrhovanie polohy.
Po kliknutí na tlačidlo Save access points, sa spustí dialóg, kde sa zadá názov súboru,
do ktorého sa zoznam prístupových bodov uloží. Pred tento názov sa ešte
pridá prefix AP_, na rozlíšenie od iných súborov. Kliknutím na tlačidlo Load access
points sa zobrazí dialóg so všetkými súbormi pre danú aplikáciu, ktoré majú prefix
AP_. Po kliknutí na nejaký konkrétny súbor sa údaje z neho nahrajú do zoznamu
accessPoints.
Falšovanie polohy sa začne ako reakcia na kliknutie na tlačidlo Setfake results.
To spustí metódu setFakeScanResults tejto aktivity. Táto metóda použitím metódy
toString triedy AccessPoint a pridaním odriakovania, vytvorí zo zoznamu
accessPoints reťazec s údajmi o prístupových bodoch. Tento reťazec je poslaný
ako argument metóde setFakeScanResults triedy Wif iManager. Reakciou na kliknutie
na tlačidlo Cancelfake results je volanie metódy cancelFakeScanResults triedy
Wif iManager, aktualizácia zoznamu accessPoints a jeho zobrazenie pomocou
ListView.
5.3.5 TrackAndSpoofActivity
Keďže v ideálnom prípade chceme podvrhovať polohu od všetkých zdrojov naraz
a chceme, aby to robil mobilný telefón „dôveryhodne", naimplementovala som
túto aktivitu, ktorá dovolí nahrať a uložiť si záznam o polohe zariadenia počas
celého dňa do súboru a inokedy, na základe týchto uložených údajov, polohu fal­
šovať.
Na nahrávanie som použila triedu AlarmManager, ktorá umožňuje beh kódu
v špecifický čas, aj ak aplikácia práve vtedy nebeží, alebo je zariadenie v režime
spánku. To sa spúšťa pomocou metódy setRepeating triedy AlarmManager. Prvý
argument je typu int a určuje, či sa bude čas počítať od zapnutia telefónu, alebo
42
5. I M P L E M E N T Á C I A
3> B D t5WJ • 21:37
ijpi WiFiLocationActivity
You can edit the following
Scan Result. Editing BSSID Add access point
can change the Network
location.
Warning, once fake results Save access points
are set you cannot connect
to Wifi network!
Load access points
N a s e B l i k a d l o . f8:8e:85:af:bl :fd
Dalos d o m a f4:ec:38:d2:40:7c
Galaxie J F K d8:B0:e6:d6:0c:e0
S a m o v o f!8:f7:c7:52:el :41
A n n a bc:ee:7b:64:5b:90
Internet f8:8e:85:83:26:25
T P - L I N K _ A 4 7 3 1 E 9 4 : 0 c : 6 d : a 4 : 7 3 : l e
T P - L I N K 00:21:27:de:38:86
(a) WifiLocationActivity
<$>y Ů
iQi SpoofingActivity
Choose file to spoof from
location_03.05.201 5.txt
location_03_05_201 5.txt
location_04_05_201 5.txt
location_05_05_201 5.txt
location_06_05_201 5.txt
(b) SpoofingAcitivty
Obr. 5.3: Ukážka aplikácie Location Manager
sa použije klasický Unixový čas a či sa má zariadenie zobudiť. Ja som zvolila
čas od zapnutia telefónu3
. Ďalšie dva argumenty určujú kedy sa má alarm spustiť
prvýkrát a ako často sa má opakovať. Posledným argumentom je inštancia
triedy Pendinglntent, ktorá reprezentuje broadcast (vysielanie) a špecifikuje aký
Intent sa má pri spustení alarmu vytvoriť. Pre vytvorenie objektu Pendinglntent
potrebujeme triedu, ktorá dedí od abstraktnej triedy BroadcastReceiver a implementuje
metódu onReceive.AlaramManager vždy, keď prejde špecifikovaný čas
na základe inštancie triedy Pendinglntent vytvorí objekt Intent a zavolá metódu
onReceive.
Vytvorila som teda triedu RecordLocationReceiver, ktorá dedí od triedy BroadcastReceiver.
Metódu onReceive implementuje tak, že si uloží informácie o polohe.
Informácie ukladá do súboru, ktorého názov sa skladá z prefixu location_
a za prefixom nasleduje dátum, kedy záznam vznikol. Jednotlivé záznamy vždy
začínajú riadkom s popiskom DATETIME, za ním nasleduje riadok, ktorý obsahuje
časovú známku. Ďalšie riadky potom môžu obsahovať jednotlivé údaje o
polohe, ktoré začínajú aj končia popiskami <GPS>, <GSM> a <WIFI>. Ako poloha
GPS sa ukladá poloha od poskytvoateľa Passive Provider, takže to nemusí byť
nutne poloha získaná do zariadenia GPS, ale to nevadí, lebo cieľom je uložiť čo
najaktuálnejšiu polohu a signál GPS nemusí byť vždy viditeľný. V GPS a G S M
2. počet sekúnd od 1.1.1970
3. v mojom prípade je to vcelku jedno, len potom je potrebné prispôsobiť aj ostatné zadané časy
43
5. I M P L E M E N T Á C I A
sú uložené jednotlivé údaje v presnom poradí oddelené tabulátormi. Vo WIFI je
uložený celý výsledok skenu formátovaný tak, že sa môže rovno predať funkcií
setFakeResults.
Aby bola poloha čo najpresnejšia, tak som okrem tejto triedy vytvorila ešte
triedu UpdateLocationReceiver, ktorá dedí od triedy BroadcastReceiver a tá implementuje
metódu onReceive tak, že si jednorázovo vyžiada aktualizáciu polohy
GPS aj polohy v sieti.
Nahrávanie polohy sa spustí ako reakcia na kliknutie na tlačidlo Štart tracking
location. Vtedy sa v tejto triede vytvoria dva objekty triedy Intent. Prvý bude asociovaný
s triedou UpdateLocationReceiver a druhý s triedou RecordLocationReceiver.
Pomocou statickej metódy getBroadcast získame pre každý z nich objekt
Pendinglntent. Pre jednu triedu môže naraz existovať len jedna inštancia
Pendinglntent. Pri volaní getBroadcast nastavíme posledný argument - f lags
na hodnotu FLAG_UPDATE_CURRENT, ktorá znamená, že pri vytvorení nového objektu
Pendinglntent, starý zaniká. Potom je volaná metóda setRepeating triedy
AlarmManager. Prvýkrát pre updateLocaitonPendinglntent, kde je nastavené, že
sa spustí ihneď a bude sa opakovať každých 15 minút. Druhýkrát pre recordLocationPendinglntent,
kde je nastavené, že sa spustí až o minutu a opäť opakovanť
každých 15 minút. Takto dávame telefónu minútu na to, aby zistil aktuálnu polohu
predtým, ako dáta uložíme.
Reakcia na kliknutie na tlačidlo Stop tracking zastavuje ukladanie polohy,
ale aj aktualizácie polohy minútu predtým. To je naimplementované tak, že volaním
getBroadcast získam inštancie triedy Pendinglntent asociované s triedami
UpdateLocationReceiver a RecordLocationReceiver. To zruší pôvodné broadcasty.
A potom zruším aj tieto novo vytvorené pomocou metódy cancel triedy
AlarmManager . Ďalší moment, kedy sa nahrávanie zruší, je vypnutie telefónu.
Pre falšovanie polohy som si vytvorila novú aktivitu - Spoof ingActivity. Táto
aktivita zobrazuje na hornej polovici displeja ListView, ktorý obsahuje názvy všetkých
súborov, ktoré majú prefix location_. Po kliknutí na nejaký z nich sa tento
súbor prečíta a v dolnej polovici obrazovky v skrolovateľnom TextView, sa zobrazí
jeho obsah. Okrem toho je volaný dialóg pre potvrdenie začatia falšovania
polohy. Po klinutí na No sa nič nedeje, po kliknutí na Yes, sa začne poloha falšovať
na základe dát z tohto súboru.
Falšovanie polohy funguje na podobnom princípe ako nahrávanie. Pomocou
triedy AlarmManager sa každých 15 minút pošle broadcast, ktorý volá metódu
onReceive. Tá je implemetnovaná triedou SetFakeLocationReceiver. Do objektu
Intent sa pridá externý atribút reťazec FILENAME, ktorý obsahuje meno súboru,
z ktorého budeme načrtávať.
SetFakeLocationReceiver funguje tak, že číta súbor, ktorého meno dostal ako
atribút FILENAME. Zo súboru ho na začiatku čítania zaujímajú iba riadky kde je
zapísaný popisok DATETIME, za ním prečíta ďalší riadok, kde parsuje uloženú
4. Mohlo by sa zdať, že stačí pôvodné Pendinglntenty uložiť ako atribút danej aktivity a potom k nim
pristupovať. Problém je v tom že Pendinglntent môže existovať nezávisle na existencií aktivity a po
vypnutí aplikácie by sme naň stratili ukazovateľ
44
5. I M P L E M E N T Á C I A
časovú známku. Ak je čas (porovnáva len hodiny a minúty) menší ako momentálny
systémový čas, tak číta ďalej. Ak je čas väčší alebo rovný, uloží si riadky
súboru až po ďalší riadok s popiskom DATETIME, kde prestáva čítať súbor.
Uložený reťazec potom jednoducho rozparsuje pomocou triedy Pattern a jej
funkcií compile a split. Ak nájde údaje pre GPS volá metódu setFakeLocation
triedy LocatioManager, ak nájde údaje pre G S M volá metódu s rovnakým menom
triedy TelephonyManager a ak nájde data s výsledkami skenu wifi, tak volá metódu
setFakeScanResults triedy WifiManager.
Ukočenie podvrhovania polohy je riešené podobne ako ukončovanie nahrávania
a teda po kliknutí na tlačidlo Stop spoofing sa získajú inštancie triedy PendingIntent
volaním getBroadcast a tie sú následne zrušené. Okrem toho sa ešte zavolajú
metódy cancelFakeLocation triedy LocationManager, cancelFakeLocation
triedy TelephonyManager a cancelFakeResults triedy Wif iManager.
45
Záver
V tejto práci som sa venovala možnostiam ako zistiť polohu mobilného zariadenia
a ich implementácií v operačnom systéme Android. Popísala som ako funguje
zisťovanie polohy mobilných zariadení po technologickej stránke a aké sú rôzne
možnosti ako túto polohu získať, prípadne spresniť. Potom som stručne vysvetlila,
aké základné vrstvy má Android a ako tieto vrstvy medzi sebou komunikujú.
Ďalej sa v práci venujem konkrétnej implementácií služieb, na základe ktorých sa
dá poloha mobilného zariadenia získať. V praktickej časti som upravila Android
tak, že dokáže poskytovať fiktívnu polohu a napísala aplikáciu, ktorá poskytuje
prístup k podvrhovaniu polohy.
Poloha mobilného zariadenia s Androidom sa zisťuje troma spôsobmi. Prvým
spôsobom je poloha od zariadenia GPS. Druhým spôsobom je získanie identifikačných
údajov o bunke G S M , ku ktorej je zariadenie pripojené, respektíve o bunkách,
ktoré sú v jeho dosahu. Posledný spôsob je získanie BSSID prístupových bodov
WiFi, pre ktoré je zariadenie schopné zachytiť ich signál. Spoločnosť Google
má databázy, ktoré mapujú jednotlivé bunky G S M na konkrétnu polohu, respektíve
BSSID prístupových bodov WiFi na konkrétnu polohu. V Androide Google
poskytuje službu Google Apps, ktorá implementuje poskytovateľa polohy Network
provider, ktorý tieto databázy využíva a na ich základe polohu určuje.
Pre každý z týchto troch spôsobov som v OS Android implementovala metódy,
ktoré dokážu túto polohu podvrhnut'. Simulovanie polohy som implementovala
vo vrstve Androidu System Services, ktorá komunikuje s vrstvou HAL - Hardware
Abstraction Layer. Vrstvu HAL výrobcovia implementujú ako proprietámu a preto
sa už nedalo ísť hlbšie k ovládačom zariadení. Žiadna aplikácia, ktorá používa na
získanie polohy javovský framework, nemôže zistiť, že poloha nie je reálna. Na
druhej strane natívne aplikácie môžu komunikovať priamo s HAL, a teda dostať
sa k pravej polohe. Následne som vytvorila jednoduchú aplikáciu, ktorá poskytuje
prístup k týmto metódam.
Poskytovatel' polohy GPS posiela údaje o zemepisnej šírke a výške. Falšovanie
som teda implementovala tak, že aplikácia zavolá metódu, ktorej predá ako
argumenty ľubovoľnú zemepisnú šírku a výšku. Metóda predá poskytovatel'ovi
GPS tieto údaje a odvtedy ich poskytovatel' používa namiesto reálnych dát. Potom
je volaná metóda, ktorá pošle správu s touto falošnou polohou. Problémom je, že
síce poskytuje falošnú polohu, ale ďalšie správy o nej posiela aplikáciám iba ak
reálne chytí signál GPS. V budúcnosti by bolo možné napísať službu, ktorá by pri
nastavení falošnej polohy GPS vynucovala posielanie správ aj bez signálu GPS.
Poskytovatel' polohy siete je implementovaný v službe Google Apps, ktorej zdrojový
kód nie je prístupný. Táto služba berie identifikačné údaje o bunke alebo BSSID
prístupových bodov siete WiFi, a na základe nich určuje polohu - zemepisnú
šírku a výšku. Falšovanie som teda implementovala pomocou metód, ktoré berú
na vstupe údaje o bunke, respektíve BSSID prístupových bodov Wifi a tie potom
Android poskytuje ako pravé. Problémom implementácie je, že na základe adresy
47
5. I M P L E M E N T Á C I A
viem zistiť polohu a tú potom vnútiť ako GPS polohu, ale prakticky sa nedá ku
konkrétej polohe získať najbližšia bunka G S M ani BSSID najbližšieho prístupového
bodu WiFi.
V aplikácií, ktorá poskytuje prístup k podvrhovaniu polohy som preto implementovala
možnosti ako si údaje, z ktorých sa dá zistiť poloha zariadenia ukladať
a neskôr ich použiť ako fiktívnu polohu. K dispozícií je mód, v ktorom si aplikácia
každých 15 minút údaje o polohe od všetkých zdrojov ukladá a potom mód, v
ktorom tieto uložené údaje môže používať na falšovanie polohy.
Podvrhovanie polohy by sa dalo ďalej vylepšiť tak, že by bolo možné ako fiktívnu
polohu podať „nulovú" polohu a zariadenie by hlásilo, že polohu nenašlo.
Aplikácia bola skôr písaná ako prototyp na otestovanie funkčnosti simulovania
polohy a preto neposkytuje veľa funkcií. V budúcnosti by sa mohlo pridať viac
možností pre ukladanie alebo falšovanie polohy, dať používateľovi možnosť určiť
ako často sa poloha nahráva. Pridať možnosť, že si užívateľ sám vytvorí súbor,
v ktorom bude určené, kedy a aká poloha sa má použiť. Prípadne je možné napísať
iné aplikácie, ktoré by falšovanie polohy využívali.
48
Literatúra
[I] UJBÁNYAI, Miroslav. Programujeme pro Android. Vyd. 1. Praha: Grada, 2012,
187 s. Průvodce (Grada). ISBN 978-80-247-3995-3.
[2] MEIER, Reto. Professional Android 2 application development. Indianapolis:
Wiley, c2010, xxxii, 543 s. Wrox programmer to programmer. ISBN 978-0-470-
56552-0.
[3] HOJGR, Radek a Jan STANKOVIČ. GPS: praktická uživatelská příručka. Vyd.
1. Brno: Computer Press, 2007, 221 s. ISBN 978-80-251-1734-7.
[4] MILETTE, Greg a Adam STROUD. Professional Android sensor programming.
Hoboken, N.J.: Wiley, c 2012, xxxiii, 517 p. ISBN 978-1-118-26505-5.
[5] SEWARD, Zachary M . The First Mobile Phone Call Was Made 40 Years Ago
Today. The Atlantic, 2013. [Online], [cit. 3. apríla 2015].
URL http://www.theatlantic.com/technology/archive/2013/04/
the-first-mobile-phone-call-was-made-40-years-ago-today/274611
[6] BBC news: World's first 'smartphone' celebrates 20 years. 2014. [Online], [cit.
15. apríla 2015].
URL http://www.bbc.com/news/technology-28802053
[7] National Coordination Office for Space-Based Positioning: Selective Availability.
[Online], [cit. 15. mája 2015].
URL http://www.gps.gov/systems/gps/modernization/sa/
[8] Russian Space Web: Deployment of the G L O N A S S constellation. [Online], [cit.
15. mája 2015].
URL http://www.russianspaceweb.com/glonass_deployment.html
[9] Linnx Technologies: The Beginner's Guide to Different Satellite Navigation
Systems. [Online], [cit. 16. mája 2015].
URL http://linxtechnologies.com/blog/beginners-guide-satellite-navigation-systems/
[10] National Coordination Office for Space-Based Positioning: What is GPS?.
2014. [Online], [cit. 13. marca 2015].
URL http://www.gps.gov/systems/gps
[II] T A T A R A M , Adapa a A l w y n Roshan PAIS. Location Estimation of Mobile in
GSM and CDMA Networks. In: T H A M P I , Sabu M . , Albert Y. Z O M A Y A , Thorsten
STRUFE, Jose M . A L C A R A Z C A L E R O a Tony T H O M A S . Recent trends
in computer networks and distributed systems security: International Conference,
SNDS 2012, Trivandrum, India, October 11-12, 2012. proceedings. New
York, NY: Springer-Verlag Berlin Heidelberg, 2012, s 456. ISBN 36-423-4134-9.
49
LITERATÚRA
[12] K A W A G U C H I , Nobuo. WiFi Location Information System for Both Indoors
and Outdoors. In: CABESTANY, Joan. Bio-inspired systems: computational
and ambient intelligence: 10th International Work-Conference on Artificial Neural
Networks, IWANN2009, Salamanca, SpainJune 10-12,2009 -.proceedings.
Berlin: Springer-Verlag, 2009, s 639. ISBN 978-3-642-02480-1.
[13] MUIR, James A . a P. C. van OORSCHOT. Internet Geolocation and Evasion.
2006. [Online], [cit. 13. marca 2015].
URL https://www.ccsl.carleton.ca/~jamuir/papers/TR-06-05.pdf
[14] POESE, Ingmar, Mohamed Ali K A A F A R , Benoit DONNET, Bamba GUEYE a
Steve U H L I G . IP geolocation databases: unreliable ? In: SIGCOMM Comput.
Commun. Rev., vol. 41, no. 2, 2011, s 56. [Online], [cit. 14. marca 2015]. ISSN
1436-9915.
URL http://www.net.t-labs.tu-berlin.de/papers/PKDGU-IGDU-11.pdf
[15] KRAJCI, Iggy a Darren C U M M I N G S . AOndroid on x86: an introduction to
optimizing for Intel architecture, s. 2. Expert's voice in microprocessors. ISBN
978-1-4302-6130-8.
[16] Android Open Source Project. [Online], [cit. 13. marca 2015].
URL http://source.android.com
[17] Android Open Source Project: The Android Source Code. [Online], [cit. 13.
marca 2015].
URL http://source.android.com/source/index.html
[18] Android Open Source Project: Android Interfaces. [Online], [cit. 13. marca
2015].
URL https://source.android.com/devices/index.html
[19] P A L A K S H A M U R T H Y , Chethan. Overview of Android binder IPC implementation.
Slideshare, 2014. [Online], [cit. 19. apríla 2015].
URL http://www.slideshare.net/pchethan/android-binder-ipc-implementation
[20] Google Git. [Online], [cit. 17. februára 2015].
URL https://android.googlesource.com/platform/manifest
[21] Android Open Source Project: Downloading and Building. [Online], [cit. 17.
februára 2015].
URL http://source.android.com/source/building.html
[22] Embedded Linux Wiki: Android Build System. [Online], [cit. 19. februára
2015].
URL http://elinux.org/Android_Build_System
50
LITERATÚRA
[23] Google Developers: Binaries for Nexus Devices. [Online], [cit. 23. februára
2015].
URL https://developers.google.com/android/nexus/drivers
[24] RootzWiki: Samsung Nexus S. [Online], [cit. 25. februára 2015].
URL http://wiki.rootzwiki.com/Samsung_Nexus_S
[25] Android Geeks: Download GApps for Android. 2015. [Online], [cit. 25.
februára 2015].
URL http://www.android.gs/download-install-and-flash-google-apps-for-android
[26] Combain Positioning Solutions. [Online], [cit. 14. apríla 2015].
URL h t t p : / / l o c a t i o n - a p i . c o m
[27] Unwired Labs Location API. [Online], [cit. 14. apríla 2015].
URL http://unwiredlabs.com
[28] Skyhook. [Online], [cit. 14. apríla 2015].
URL http://www.skyhookwireless.com
[29] Android Open Source Project: Sensor stack. [Online], [cit. 16. mája 2015].
URL https://source.android.com/devices/sensors/sensor-stack.html
[30] Google Developers: Beyond the Blue Dot: New Features in Android Location.
2013. [Online], [cit. 26. marca 2015].
URL https://developers.google.com/events/io/sessions/325337477
[31] Andev: Fake gps - fake location. [Online], [cit. 16. mája 2015].
URL https://play.google.com/store/apps/details?id=com.fakegps.
mock
[32] IncorporateApps: Fake Location Spoofer Free. [Online], [cit. 16. mája 2015].
URL https://play.google.com/store/apps/details?id=com.
incorporateapps.fakegps.fre
51
A Zoznam príloh
A.1 ZmenyvAOSP
Keďže OS Android je pomerne veľký (48 GB) a ja som v ňom menila len pár súborov,
ako najjednoduchšie mi prišlo dať ako prílohu súbor, ktorý je výstupom príkazu
repo d i f f, ktorý ukazuje zmeny, ktoré som v AOSP spravila oproti AOSP,
z ktorého som vychádzala. Tento súbor je vložený v adresári d i f f.
A.2 Zdrojový kód aplikácie Location Manager
Uložený v adresári location_manager.
A.3 Balík LocationManager.apk
Umožňuje inštaláciu aplikácie Location Manager na akékoľvek zariadenie s OS
Android s API 11a vyšším. Táto aplikácia sa správa úplne rovnako ako pôvodná
aplikácia, ale nevie podvrhovať polohu. Je vložený v adresári location_manager_apk
A.4 Návod k aplikácií Location Manager
Napísala som jednoduchý návod ako ovládať aplikáciu Location Manager. Je uložený
v adresári návod.
53