Rozproszony system monitorowania systemów komputerowych ... filenością jest Inżynieria Systemów...
Transcript of Rozproszony system monitorowania systemów komputerowych ... filenością jest Inżynieria Systemów...
Politechnika Warszawska
Wydział Elektroniki i Technik Informacyjnych
Instytut Informatyki
Rok akademicki 2013/2014
PRACA DYPLOMOWA INŻYNIERSKA
Marcin Kubik
Rozproszony system monitorowania
systemów komputerowych - aplikacja
mobilna na platformę Android
Opiekun pracy:
mgr inż. Waldemar Grabski
Ocena . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Podpis Przewodniczącego
Komisji Egzaminu Dyplomowego
Specjalność: Informatyka –
Inżynieria systemów informatycznych
Data urodzenia: 6 kwietnia 1991 r.
Data rozpoczęcia studiów: 1 października 2010 r.
Życiorys
Urodziłem się 6 kwietnia 1991 roku we Wrocławiu. W latach 2006-2009 uczęsz-
czałem do XVIII Liceum Ogólnokształcącego imienia Jana Zamoyskiego w Warsza-
wie do klasy o profilu matematyczno-fizyczno-informatycznym. W 2010 roku rozpo-
cząłem studia na Wydziale Elektroniki i Technik Informacyjnych Politechniki War-
szawskiej, na kierunku Informatyka. Od semestru zimowego 2012/2013 moją specjal-
nością jest Inżynieria Systemów Informatycznych. W lecie 2013 roku (od lipca do
września) odbyłem praktykę w firmie Accenture sp. z.o.o. Poza zainteresowaniami
technicznymi do swoich pasji zaliczam czytanie książek, muzykę oraz sport.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
podpis studenta
Egzamin dyplomowy
Złożył egzamin dyplomowy w dn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Z wynikiem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ogólny wynik studiów . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dodatkowe wnioski i uwagi Komisji . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Streszczenie
Tematem pracy jest monitorowanie urządzeń mobilnych. Powodem stworzenia
tego rodzaju systemu jest brak dostępnych na rynku możliwości gromadzenia danych
dotyczących działania urządzenia mobilnego zintegrowanego z zewnętrznym syste-
mem, który odpowiadałby za przechowywanie takich danych. Przeanalizowano do-
stępne na rynku systemy monitorujące i zwrócono uwagę na brak niezbędnych moż-
liwości. Jako urządzenie mobilne wybrano telefon komórkowy z systemem Android.
Niniejsza praca dyplomowa (tworzona w jej ramach aplikacja mobilna) współpra-
cuje z rozwiązaniem stworzonym w ramach innej pracy inżynierskiej napisanej przez
Krzysztofa Opasiaka. W czasie tworzenia pracy wykonano przykładowe serwisy, które
odpowiadają za pomiary stanu urządzenia mobilnego, przeprowadzono także testy po-
zwalające określić zarówno poprawność rozwiązania jak i komunikację z systemem
monitorującym.
Słowa kluczowe: Android, Monitorowanie, Systemy Rozproszone.
Distributed system of monitoring computer systems - mobileapplication for Android platform
The subject of this work is mobile device monitoring. The idea to create such solution
came from a lack of similar technologies, that allows to gather information about mo-
bile devices and are also integrated with remote, desktop monitoring systems. During
analysis of existing solutions it was decided to create mobile application that collects
information about mobile device and sends it to remote system that is responsible
for storing data and further analyse. Remote part was created by Krzysztof Opasiak
for different thesis. Chosen mobile system is Android. During implementation se-
veral sample services that monitor mobile device were created, multiple tests were
also performed due to checking correctness of solution and integration with remote
monitoring system.
Key words: Android, Monitoring, Distributed Systems.
Spis treści
1 Wstęp 3
2 Systemy Monitorujące 6
2.1 Opis systemów stacjonarnych . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Moduł NSCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Rozwiązania mobilne . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Podsumowanie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Android 18
3.1 Ogólne informacje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2 Architektura systemu . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3 Możliwe pomiary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.4 Dostępne aplikacje monitorujące . . . . . . . . . . . . . . . . . . . . . 22
4 Wymagania 25
4.1 Wymagania ogólne . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2 Wymagania klienta mobilnego . . . . . . . . . . . . . . . . . . . . . . 27
5 Architektura Systemu 29
5.1 Architektura ogólna . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Aplikacja mobilna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.1 Ogólny opis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.2 Serwisy pomiarowe . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2.3 Model danych . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2.4 Schemat bazy danych . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.5 Komunikacja . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2.6 Kryptografia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.2.7 Diagram klas . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.3 Protokół komunikacyjny . . . . . . . . . . . . . . . . . . . . . . . . . 43
6 Implementacja 45
6.1 Moduł pomiarowy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2 Moduł gromadzenia i zapisywania danych . . . . . . . . . . . . . . . 50
1
6.3 Moduł danych tymczasowych . . . . . . . . . . . . . . . . . . . . . . 53
6.4 Moduł synchronizacji czasu . . . . . . . . . . . . . . . . . . . . . . . 55
6.5 Moduł kryptograficzny i autoryzacja . . . . . . . . . . . . . . . . . . 58
6.6 Protokół komunikacyjny . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.7 Warstwa prezentacji . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
7 Testy 67
8 Podsumowanie 71
A Załącznik A - opis aplikacji 73
B Załącznik B - dodawanie nowych serwisów 76
C Załącznik C - zawartość płyty CD 82
2
1 Wstęp
W dzisiejszych czasach telefony komórkowe w znaczący sposób zmieniły sposób
życia. Po etapie, w którym służyły (zgodnie ze swoim pierwotnym przeznaczeniem)
tylko do wykonywania i odbierania połączeń, przeszły one dość intensywną drogę
do stanu, w jakim znajdują się obecnie.
Dzięki szybkiemu rozwojowi sprzętu, technologii i możliwości, jakie oferują nie-
wielkie przecież urządzenia, dość szybko okazało się, że mogą one służyć także do
wielu innych zastosowań. Rozwój sieci Internet, zwłaszcza w wersji mobilnej, bez-
przewodowej, umożliwił wykonywanie niezliczonych ilości operacji za pomocą te-
lefonu z dostępem do Sieci (za pomocą WiFi czy bezprzewodowych standardów
przesyłania danych, jak UMTS czy LTE). Dzięki temu możliwe stało się rezerwowa-
nie biletów lotniczych, sprawdzanie repertuaru najbliższego kina, przeprowadzanie
przelewu bankowego czy wysłanie e-maila. Możliwości, jakie dają takie elementy jak
GPS czy akcelerometr pozwalają na określanie położenia użytkownika, dzięki czemu
możliwe jest działanie aplikacji pozwalających na przykład na pomiar dystansu po-
konanego przez biegacza i zapisanie trasy, jaką się poruszał.
W ostatnich latach głównym systemem operacyjnym na telefonach komórkowych
(oraz dość blisko powiązanych z nimi tabletach) jest Android. Na chwilę obecną
(lipiec 2013) posiada on blisko 70% udziałów na rynku telefonów [15]. Dzięki temu
systemowi (a także jemu podobnym, jak iOS czy Windows Phone) telefony zaczęły
coraz bardziej przypominać centra rozrywki i narzędzia pracy biurowej. Statusem
tym jeszcze do niedawna mogły poszczycić się tylko komputery stacjonarne lub
laptopy.
Rozwój wspomnianych systemów operacyjnych na urządzeniach mobilnych spo-
wodował, że coraz częściej są one używane niemalże na równi z komputerami sta-
cjonarnymi oraz laptopami. Używa się ich do przedstawiania wyników analiz, zmian
w terminarzu spotkań firmowych czy nawet w prostych zadaniach edycyjnych. Do-
stępne są liczbe programy powiązanie z dużymi (stacjonarnymi) odpowiednikami a
także osobne aplikacje umożliwiające synchronizację z danymi stacjonarnymi. Powo-
duje to, że administratorzy i osoby zarządzające infrastrukturą postrzegają telefony
już niemal tak samo jak komputery stacjonarne czy laptopy.
Celem niniejszej pracy dyplomowej jest stworzenie narzędzia umożliwiającego
3
monitorowanie różnego rodzaju urządzeń mobilnych - jako przykładową stworzono
aplikację na system Android, możliwe jest także stworzenie podobnych rozwiązań
dla innych platform. Znaczący wzrost ich popularności spowodował, że zagadnienie
to stało się ważnym elementem działania infrastruktury w firmach czy chociażby
na uczelniach. Chęć zapanowania nad urządzeniami w taki sposób, aby móc bez
przeszkód monitorować i nadzorować ich działania podyktowana jest faktem, że czę-
sto są to urządzenia firmowe, oddawane pracownikom do użytku biznesowego na
czas trwania umowy z danym pracodawcą. Dlatego też różni dostawcy chcą mieć
możliwość bezpośredniego wglądu (oczywiście bez znaczącego naruszania prywat-
ności użytkownika) do historii i wartości opisujących działanie posiadanych przez
nich urządzeń. Ma to szczególnie duże znaczenie właśnie w przypadku urządzeń
mobilnych, które ze względu na swoją specyfikę (wyjątkowo istotny zwłaszcza dla
użytkowników telefonów z dużymi ekranami dotykowymi problem stanu baterii czy
duża mobilność urządzenia) posiadają szereg cech wymagających szczególnej uwagi.
Analizując i przetwarzając wartości opisujące działanie urządzenia mobilnego do-
stawcy urządzeń czy ich administratorzy mogą podjąć decyzje biznesowe dotyczące
zmiany taryfy telekomunikacyjnej czy wymiany modelu aparatu u konkretnego użyt-
kownika. Ważnym elementem pomiarowym jest między innymi moc sygnału WiFi -
w przypadku, gdy na danym urządzeniu jest ona często zbyt niska, może oznaczać
to konieczność rozbudowy infrastruktury wewnątrz siedziby firmy ze szczególnym
uwzględnieniem miejsca pracy danego użytkownika.
Tworzony system powinien mieć możliwość gromadzenia danych na różnych,
często niezależnych od siebie serwerach, monitorowanie urządzeń mobilnych offline
(poprzez tymczasowe zapisywanie informacji na samym urządzeniu i przekazywanie
ich w momencie uzyskania połączenia z siecią), bezpieczny ich przekaz pomiędzy
modułami a także opcję łatwego konfigurowania dostarczonego rozwiązania tak, aby
możliwe było w przyszłości dodanie do stworzonej już aplikacji nowych elementów
w zależności od zaistniałych potrzeb.
System składa się z dwóch głównych modułów - części stacjonarnej, odpowie-
dzialnej za odbieranie i przetwarzanie danych oraz części mobilnej, której głównym
zadaniem jest zbieranie i przekazywanie informacji. Część stacjonarna stworzona
została w ramach pracy inżynierskiej [1], celem niniejszej pracy było stworzenie mo-
4
dułu mobilnego, który można zainstalować na urządzeniach takich jak telefony czy
tablety. W ramach implementacji dostarczono rozwiązanie w postaci aplikacji, która
po zainstalowaniu na urządzeniu mobilnym zbiera informacje na temat działania,
przechowuje je a w momencie nawiązania połączenia z siecią WiFi przesyła do mo-
dułu zewnętrznego.
Wprowadzającym rozdziałem (po niniejszym Wstępie) jest opis dostępnych na
rynku systemów monitorujących wraz z krótką charakterystyką ich zalet i wad. W
rozdziale tym przedstawiono także rozwiązania, jakie udostępniają one dla urządzeń
mobilnych i przeanalizowano, czy rozwiązania te są wystarczające dla potrzeb two-
rzonego systemu monitorowania. W następnym rozdziale zaprezentowano ogólny
opis architektury systemu Android, który jest platformą, na którą tworzona jest
część mobilna. W rozdziale zaprezentowano także dostępne aplikacje umożliwiające
pomiary rozmaitych usług działających na urządzeniu, stwierdzono także ich braki
uniemożliwiające ich prawidłowe wykorzystanie w tworzonym systemie. Na podsta-
wie tych braków stworzono szereg wymagań, które stawiane są przed tworzoną imple-
mentacją. Zostały one zawarte w następnym rozdziale (z podziałem na wymagania
części stacjonarnej i modułu mobilnego). Następnie zaprezentowano ogólną archi-
tekturę tworzonego rozwiązania - także z podziałem na część stacjonarną i mobilną.
Skupiono się przede wszystkim na module mobilnym jako implementowanym przez
autora niniejszej pracy. Po omówieniu schematu rozwiązania opisano implementację
rozwiązania mobilnego z podziałem na moduły odpowiadające za poszczególne ele-
menty aplikacji. Na koniec zaprezentowano testy dostarczonego rozwiązania wraz z
wnioskami, jakie można było na ich podstawie wysnuć. Ostatnim elementem pracy
są załączniki opisujące zarówno ogólny sposób użycia aplikacji jak i możliwości jej
konfiguracji. Zaprezentowano także informacje dotyczące zawartości płyty CD, która
dołączona jest do niniejszej pracy.
5
2 Systemy Monitorujące
2.1 Opis systemów stacjonarnych
Problem monitorowania stanu różnego rodzaju urzadzeń został dostrzeżony już
wiele lat temu. Do zadań wielu administratorów sieci należało dbanie o poprawne
działanie komputerów, routerów czy drukarek. Ręczne sprawdzanie, czy dane urzą-
dzenie działa poprawnie, mogło stanowić wyzwanie w przypadku dużych budynków,
gdzie serwerownie umieszczone są nieraz na różnych piętrach i ich przegląd może zaj-
mować dużo czasu. W przypadku niektórych elementów (jak na przykład serwery
pocztowe) możliwe jest na przykład cykliczne wysyłanie żądanie HTTP i reakcja
w przypadku braku odpowiedzi, jednak oznacza to kolejność pisania dodatkowych
skryptów. Opcja ta nie jest zawsze dostępna, często specyfika usług wyklucza wy-
korzystanie cyklicznego odpytywania.
Zaistniała zatem konieczność stworzenia specjalnego systemu, który zajmowałby
się zarządzaniem monitorowania urządzeń. Program taki powinien przede wszyst-
kim mieć możliwość automatycznego, cyklicznego odpytywania o stan urządzeń i
przetwarzania otrzymywanych wartości. Możliwy powinien być także dostęp przez
przeglądarkę internetową - tak aby administrator mógł monitorować stan urządzeń
także przez sieć.
Systemy takie powstały już w połowie lat 90-tych wychodząc naprzeciw oczeki-
waniom użytkowników. Często różnią się one sposobem działania i możliwościami,
jednak główny cechy są zazwyczaj dość zbliżone.
Pierwszym z systemów jest Nagios [5]. Powstał w roku 1999 z inicjatywy Ethana
Galstada. Jego głównym i podstawowym zadaniem jest monitorowanie zasobów sieci.
Urządzenia i mechanizmy, jakie mogą być sprawdzane to między innymi:
Hosty
Możliwe są pomiary obciążenia procesora, zużycie dysku czy temperatura we-
wnątrz obudowy.
Procesy
Uruchomione na poszczególnych maszynach.
Routery i switche
6
Z wykorzystaniem protokołu SNMP.
Serwery pocztowe
Serwery FTP
Usługi
Na przykład HTTP.
Poprzez system Nagios możliwe jest monitorowanie zarówno komputerów dzia-
łających z wykorzystaniem systemu operacyjnego Unix (i jego pochodnych) oraz
rodziny systemów Windows.W obu przypadkach schemat współpracy polega na od-
pytaniu przez system Nagios modułu zainstalowanego na monitorowanym urządze-
niu. Tam uruchamiana jest wtyczka, który ma za zadanie zbadanie aktualnego stanu
danej usługi. Zebrana w ten sposób informacja jest następnie odsyłana z powrotem
do systemu Nagios. Analogicznie działa monitorowanie urządzeń sieciowych - wtedy
wykorzystywany jest protokoł SNMP. Możliwe jest także stworzenie hierarchii sieci,
co ułatwia sprawdzanie działania urzadzeń pomimo niepoprawnego stanu jednego z
nich. Przykładowo, awaria jednego z routerów w danej sieci nie powoduje przerwania
działania całej sieci a jedynie zmniejszy jej wydajność i dostępność.
Opisane powyżej funkcjonalności są zdefiniowane jako moduły i dołączone do
podstawowej wersji systemu Nagios. Istnieje jednak także możliwość tworzenia wła-
snych wtyczek, które monitorowałyby zdefiniowane przez użytkownika funkcjonalno-
ści. Znacząco zwiększa to funkcjonalność rozwiązania i ułatwia wprowadzanie ulep-
szeń i ułatwień dla specyficznych zastosowań.
Wartości, jakie zwracane są przez wtyczkę oznaczają stan, w jakim znajduje
się monitorowane urządzenie. Akceptowane są 4 wartości, każda informuje o innej
sytuacji danej usługi:
0 - OK
Dana funkcjonalność działa poprawnie.
1 - Warning
Działanie funkcjonalności przekracza normę, lecz mieści się w akceptowalnym
zakresie.
7
2 - Critical
Działanie funkcjonalności przekracza dopuszczalne normy, administrator po-
winien zostać jak najszybciej powiadomiony o zaistniałej sytuacji.
3 - Unknown
Brak informacji o działaniu danej funkcjonalności.
Jedna z tych wartości, wraz z dodatkowymi informacjami (między innymi stem-
plem czasowym, nazwą hosta oraz monitorowanej usługi) składana jest w linię tekstu
zwracaną i przetwarzaną przez system Nagios.
Ważnym podziałem w przypadku wtyczek dla systemu Nagios jest ich sposób ko-
munikacji z serwerem i metody sprawdzania i pomiarów wartości. Decyzja, którą wy-
korzystać, powinna zostać podjęta w zależności od specyfiki urządzenia (lub usługi):
Wtyczki aktywne
Wykonywane i inicjowane przez system Nagios. Wywołuje on daną wtyczkę
okresowo (przez żądanie), w regularnych odstępach czasu i czeka na jej odpo-
wiedź. W przypadku braku odpowiedzi traktuje daną usługę jako wyłączoną.
Wtyczki pasywne
Komunikacja inicjowana jest nie przez serwer a przez wtyczkę. Ona sama dba
o pomiar odpowiednich wartości i przesyła zgromadzone wyniki do serwera
Nagios, gdzie są one przetwarzane i zapisywane.
Wtyczki pasywne wydają się być dobrym rozwiązaniem w przypadku urządzeń,
które są chronione przez zaporę ogniową (ang. firewall) i inicjacja połączenia “z
zewnątrz” może okazać się (bez włączonej opcji przekierowania portów) niemożliwa.
W przypadku, gdy system Nagios ma stały dostęp do monitorowanego urządzenia
(za pośrednictwem sieci Internet) lepszym rozwiązaniem wydają się być (z uwagi na
swoją regularność) wtyczki aktywne.
Opisane powyżej funkcjonalności dotyczą systemu Nagios. Został on opisany
w niniejszej pracy inżynierskiej z uwagi na jego popularność oraz ugruntowanie w
środowisku administratorów. Nie jest to jednak jedyny system zajmujący się mo-
nitorowaniem urządzeń. Powstało wiele różnych rozwiązań usprawniających pracę
administratorów.
8
Jednym z nich jest Icinga [6]. Projekt ten został utworzony w roku 2009 jako
jedna z gałęzi rozwoju systemu Nagios. Po jakimś czasie pomysł wyewoluował, po-
wołany został zatem jako odrębny, konkurencyjny system. Wszystkie informacje
przedstawione na temat systemu Nagios odnoszą się także do systemu Icinga, jest
ona także kompatybilna wstecznie ze swoim poprzednikiem (za wyjątkiem specjal-
nych, dedykowanych wyłącznie dla tego systemu rozwiązań). Opis systemu Nagios
jest zatem jednocześnie opisem systemu Icinga. Warto jednak skupić się na tych
elementach, które odróżniają wspomniane 2 systemy.
Najważniejszą cechą odróżniającą system Icinga od systemu Nagios jest jego
architektura. W przeciwieństwie do poprzednika, który działa jako jeden zwarty mo-
duł, bez szczególnego podziału, system Icinga dzieli się na 3 główne części. Zmiana
ta miała miejsce w drugiej wersji systemu, wersja pierwsza była dość zbliżona pod
względem architektury do systemu Nagios. Części te to:
Icinga Core
Moduł zarządzający, odpowiadający za zbieranie danych i ich przetwarzanie.
Moduł bazy danych
Domyślnie baza MySQL, przechowywanie zgromadzonych danych.
Icinga Web
Wizualizacja danych i umożliwienie dostępu do nich z poziomu przeglądarki
internetowej.
Opisana architektura jest największą różnicą pomiędzy systemami Icinga oraz
Nagios. Istnieje jednak także szereg innych, mniejszych różnic, które powodują, że
system Icinga jest coraz chętniej wybieranym przez administratorów narzędziem do
monitorowania:
• obsługa i wsparcie dla protokołu IPv6
• autentykacja z wykorzystaniem protokołów LDAP oraz Active Directory
• wsparcie dla interfejsu REST
• powiadomienia z ograniczonym czasem (możliwe jest ustawienie czasu, po któ-
rym powiadomienie, na przykład o niepoprawnym działaniu, staje się nieak-
tualne i nie istnieje konieczność informowania administratora
9
• dynamiczna forma prezentacji danych (w module Icinga Web)
• wielokanałowe ostrzeżenia (docierające do różnych instancji systemu Icinga, w
zależności od konfiguracji)
Ważnym czynnikiem, z punktu widzenia programistów chcących budować apli-
kacje w oparciu o system Icinga, jest obecność kolejnych jego edycji w systemie
kontroli wersji Git. Dzięki temu możliwe jest dopasowanie działania systemu do
własnych potrzeb także na poziomie kodu.
Innym systemem monitorującym, różniącym się nieco od poprzednich jest sys-
tem Cacti[7]. W przeciwieństwie do opisanych powyżej systemów Nagios oraz Icinga
przechowywanie danych zdefiniowane jest w postaci cyklicznej bazy danych (ang.
round-robin), co z jednej strony pozwala na zmniejszenie zapotrzebowania na pa-
mięć, z drugiej uniemożliwia przechowywanie wszystkich danych i oznacza ich ka-
sowanie po określonym czasie. Serwis Cacti korzysta z dwóch źródeł dostarczania
danych - skryptu “cmd.php” (dla małych sieci) oraz programu Spine, który umoż-
liwia monitorowanie setek hostów. Nie udostępnia jednak możliwości uruchamiania
wtyczek pasywnych, co znacząco utrudnia wykorzystanie w środowisku mobilnym.
2.2 Moduł NSCA
W niniejszym rozdziale zaprezentowano dodatek NSCA (ang. Nagios Service
Check Adapter), który jest rozwiązaniem pozwalającym w ograniczonym stopniu na
przesyłanie danych z urządzenia mobilnego do systemu monitorującego. Został on
wybrany do analizy z powodu działania zbliżonego do oczekiwanego, tj. możliwości
inicjowania komunikacji przez system monitorowany a nie monitorujący.
Z uwagi na specyfikę systemu Android, który obecny jest przede wszystkim na
urządzeniach mobilnych, nieposiadających ciągłego dostępu do Internetu, ważna jest
funkcjonalność wspomnianych wyżej systemów pozwalająca na inicjowanie zapisu
wartości przez monitorowany serwis a nie przez system monitorujący (jak Icinga czy
Nagios). W przypadku Androida naturalnym ograniczeniem jest brak dostępu do
Internetu. W takich sytuacjach jakakolwiek komunikacja z urządzeniem mobilnym
jest niemożliwa. Powoduje to, że wymiana danych może odbywać się jedynie w mo-
mencie, gdy użytkownik jest podłączony do Internetu. Można tę sytuację porównać
10
do rozpoczynania komunikacji przez urządzenie znajdujące się za systemem NAT, do
którego bezpośredni dostęp z zewnątrz jest niemożliwy (bez włączenia odpowiedniej
opcji przekierowania portów).
Rozwiązaniem, zaproponowanym w systemie Icinga (obecnym także w systemie
Nagios) są tak zwane wtyczki pasywne (Passive Checks), które umożliwiają komuni-
kację asynchroniczną z urządzeniem. Gdy telefon (tablet) staje się widoczny w sieci,
nawiązuje ze swojej strony połączenie z odpowiednią aplikacją, której głównym za-
daniem jest zapis do tak zwanych External Command File. Pliki te są miejscem, do
którego można dopisywać kolejne wyniki pomiarów wraz ze stemplami czasowymi
i opisanymi wyżej poziomami ostrzeżeń. System monitorujący cyklicznie sprawdza
zawartość tego pliku i wczytuje kolejne wartości.
Dla systemów monitorujących opartych na systemie Nagios usługa, która od-
powiada za komunikację z jednej strony z monitorowanymi serwisami a z drugiej
z serwerem, nosi nazwę NSCA - ang. Nagios Service Check Acceptor[8]. Został on
napisany w języku C, co gwarantuje jego szybkość i wysoką wydajność. Do komuni-
kacji z Nagiosem (oraz z jego klonami, takimi jak Icinga), wykorzystuje wspomniane
już External Command File.
NSCA składa się z 2 głównych modułów:
• send_nsca - moduł służący do przesyłania wyników pomiarów do systemu
monitorującego
• nsca - moduł odbierający wyniki pomiarów zarejestrowanych usług przepro-
wadzanych na zewnętrznych urządzeniach i przekazujący je bezpośrednio do
systemu monitorującego (z wykorzystaniem External Command File)
Pierwszy z nich, send_nsca, uruchamiany jest na urządzeniu, które ma być
monitorowane. Jego głównym zadaniem jest zebranie wpisów dotyczących działania
poszczególnych usług i przekazanie ich na serwer zewnętrzny. Odpowiednie parame-
try ustawiane są za pomocą specjalnego pliku konfiguracyjnego zawierającego takie
dane jak adres IP oraz port serwera, usługi, które mają być monitorowane czy opcje
kryptograficzne. Program wczytuje dane ze standardowego wejścia, co ułatwia odpo-
wiednie nimi zarządzanie (na przykład poprzez przetwarzanie potokowe). Składnia
przetwarzanych przez moduł informacji jest następująca:
11
< hostname >< svc_description >< return_code >< plugin_output >
gdzie:
hostname - nazwa urządzenia, na którym uruchomiony jest moduł.
svc_description - opis (nazwa) usługi, której pomiar jest przekazywany.
return_code - stan urządzenia.
plugin_output - dodatkowe informacje w postaci tekstowej.
Dane przekazywane pomiędzy modułem send_nsca a modułem uruchomionym
przy serwerze monitorującym są szyfrowane. Do danych dołączany jest także cy-
kliczny kod nadmiarowy pozwalający na wykrycie błędów transmisji i odrzucenie
danych nimi obarczonych.
Drugim modułem, działającym wraz z serwerem monitorującym, jest moduł
nsca. Odpowiedzialny jest za odbiór danych od modułu send_nsca (po uprzednim
nawiązaniu i zestawieniu połączenia) i przekazanie ich do systemu monitorującego.
Działać może w kilku trybach: jedno- lub wieloprocesowym lub zintegrowanym z
inetd (proces odpowiadający za nasłuch na wszystkich portach danego serwera i
uruchamianie odpowiednich usług w momencie nawiązania połączenia). Komuni-
kacja z systemem monitorującym odbywa się za pomocą opisanego już External
Command File.
Dane przekazywane do systemu szyfrowane są z wykorzystaniem jednego z do-
stępnych algorytmów symetrycznych. Po poprawnej weryfikacji odczytanych danych
są one przekazywane bezpośrednio do External Command File, gdzie są w dalszej
kolejności analizowane przez system monitorujący (tak jak wszystkie inne dostar-
czone do tego miejsca dane).
Wtyczka NSCA (oba jej moduły) znajduje szerokie zastosowanie w przypadku
usług, których monitorowanie jest utrudnione ze względu na występujące przeszkody
takie jak NAT czy czasowy brak dostępu do Sieci. Rozwiązanie to pozwala na wy-
korzystanie w środowiskach Nagios czy Icinga (które z natury są serwisami aktyw-
nymi) korzyści jakie płyną z pasywnej wersji dostarczania danych. Usługa ta posiada
12
jednak szereg wad, które powodują, że nie może być traktowana jako w pełni odpo-
wiedzialne i bezpieczne źródło:
Brak potwierdzeń
W momencie odebrania danych od urządzenia monitorowanego nie są prze-
syłane żadne potwierdzenia mówiące o tym, że dane zostały prawidłowo do-
starczone. Serwis nadający nie może zatem być pewny, że pomiary zostały
przekazane do przetwarzania. Także błędy nie są w jakikolwiek sposób sygna-
lizowane. Powoduje to, że część pomiarów może ginąć w czasie transmisji bez
wiedzy użytkownika chcącego udokumentować działanie danych usług
Szyfrowanie symetryczne
Główną wadą szyfrowania symetrycznego (czyli opartego na jednym, znanym
obu stronom kluczu wykorzystywanym zarówno do szyfrowania jak i deszyfro-
wania) jest całkowita utrata jakiegokolwiek bezpieczeństwa przesyłu danych w
przypadku ujawnienia klucza przez przynajmniej jedną ze stron. Powoduje to,
że komunikacja na nim oparta staje się bardzo niepewna i trudna w prawidło-
wym zarządzaniu (problem z wykryciem faktu ujawnienia klucza, dystrybucja
nowych kluczy).
Kod nadmiarowy
Cykliczny kod nadmiarowy CRC32 wykorzystywany do sprawdzania popraw-
ności przesyłanych danych, z uwagi na swoją niewielką długość, stwarza możli-
wość utworzenia takich samych kodów dla dwóch zupełnie różnych wiadomości.
Może to powodować, że osoba podszywająca się pod użytkownika będzie bez
przeszkód przekazywała fałszywe dane.
Brak uwierzytelniania użytkownika
Jedynymi wartościami, które muszą być znane przez serwis wysyłający dane
są algorytm i dostarczony klucz - nie jest stosowana żadna prawidłowa auto-
ryzacja (na przykład z wykorzystaniem loginu i hasła).
Przesył do jednego odbiorcy
Dane z danego modułu mogą trafiać tylko do jednej instancji serwisu monito-
rującego, co w przypadku dużych korporacji, w których często istnieją osobne
13
instancje do pomiarów różnych usług, może powodować daleko idące utrud-
nienie.
Brak stempla czasowego
Stempel czasowy wyznaczany jest w momencie nawiązania połączenia i służy
jako informacja przekazywana do systemu monitorującego. Nie ma zatem moż-
liwości prawidłowego oznaczenia danych historycznych - zebranych na przy-
kład w czasie braku dostępu do Sieci.
Ostatni z wymienionych defektów prawdopodobnie jest głównym powodem, dla
którego do tej pory nie powstały żadne implementacje modułu send_nsca na urzą-
dzenia mobilne - zarówno dla systemu Android, jak i dla mniej popularnych iOS
czy Windows Phone. Wszystkie dane traktowane byłyby jako zebrane w momencie
nawiązania połączenia, co powodowałoby, że wszystkie starsze niż aktualne wyniki
pomiarów byłyby bezużyteczne. Powoduje to brak jakiejkolwiek informacji na temat
działania urządzenia w momencie braku jego dostępu do Sieci.
Moduł NSCA zatem, pomimo wykorzystywania przez różnego rodzaju organiza-
cje i stanowiący ciekawą alternatywę do normalnego, aktywnego działania systemu
Nagios czy Icinga, nie jest pozbawiony wad. Spowodowały one podjęcie decyzji o
stworzeniu nowej implementacji tego serwisu, uwzględniającej wszystkie wymienione
problemy. Implementacja taka tworzona jest w ramach innej pracy inżynierskiej a jej
możliwości wykorzystane zostały w aplikacji tworzonej na potrzeby niniejszej pracy
inżynierskiej, której głównym celem jest zapełnienie istniejącej luki na rynku i do-
starczenie aplikacji spełniającej rolę modułu send_nsca na urządzeniu mobilnym.
2.3 Rozwiązania mobilne
Z punktu widzenia urządzenia mobilnego istotne są możliwości monitorowania
różnego rodzaju telefonów czy tabletów. Z uwagi na swoją specyfikę (brak ciągłego
dostępu do sieci Internet, szybkie zużycie baterii oraz ograniczona przestrzeń dys-
kowa) konieczna jest stworzenie specjalnych dedykowanych rozwiązań wyłącznie dla
urządzeń mobilnych.
Po analizie dostępnych na rynku rozwiązań zdecydowano się na omówienie przy-
najmniej kilka programów przeznaczonych dla administratorów korzystających z
14
systemów Nagios oraz Icinga. Są to aplikacje instalowane na urządzeniach mobil-
nych, których celem jest umożliwienie osobie zarządzającej pobieranie informacji na
temat stanu monitorowanych urządzeń i oraz ich analizę. Programy te w większości
zostały stworzone jako osobne aplikacje, korzystają także one często z możliwości
oferowanych przez przeglądarkę. Są to:
Icinga Mobile [17]
Wykorzystanie przeglądarki internetowej, podgląd wyników monitorowania,
filtrowanie i sortowanie danych, pełna współpraca z systemem Icinga.
aNag [18]
Analiza wyników monitorowania, planowanie aktualizacji danych o określo-
nych porach, działanie także z wykorzystaniem przeglądarki internetowej.
TiNag [19]
Wyświetlanie wyników w formie graficznej, monitorowanie wielu instancji jed-
nocześnie.
iNag [20]
Niezależność od przeglądarki, wysyłanie poleceń doboru danych, zarządzanie
pobranymi danymi.
W czasie analizy różnego rodzaju opinii zauważono, że największą popularnością
i najchętniej wykorzystywaną aplikacją jest TiNag. W wersji darmowej obejmuje
ona monitorowanie tylko 3 hostów, wersja płatna nie stawia żadnych ograniczeń.
Nieco inaczej jest w przypadku Icinga Mobile, która z racji swojego sprzężenia z
systemem nie zawiera żadnych ograniczeń i możliwe jest monitorowanie dowolnej
ilości serwisów. Podobnie jest z pozostałymi opisanymi aplikacjami.
Jak widać, rozwiązania umożliwiające zebranie danych na temat urządzenia mo-
bilnego są praktycznie niedostępne. Jedyne, częściowe, rozwiązanie zapewniają apli-
kacje TiNag oraz iNag - umożliwiają ręczne (z wykorzystaniem telefonu czy tabletu)
przesłanie danych o stanie danego urządzenia lub serwisu. Jest to przydatne dla ad-
ministratorów, którzy po zauważeniu informacji o błędnym działaniu urządzenia (np.
serwera) mogą udać się na miejsce i stamtąd własnoręcznie wprowadzić nowe infor-
macje dotyczące sytuacji (na przykład stan bezpośrednio po ponownym uruchomie-
niu). Jest to jednak rozwiązanie tylko częściowo spełniające założenia postawione we
15
wstępie - aby możliwe było monitorowanie urządzenia mobilnego, konieczne byłoby
stworzenie w systemie Icinga nowego hosta, który przez cały czas byłby oznaczony
jako nieaktywny i samodzielne wpisywanie na urządzeniu jego stanu (po sprawdze-
niu oczekiwanych wartości). Rozwiązanie takie nie różni się praktycznie od zwykłego
przekazywania danych do bazy danych i nie ma wiele wspólnego z rozważaną w ni-
niejszej pracy koncepcją cyklicznego monitorowania rozproszonego.
Nazwa Platformy Czy wykorzy-
stuje przeglą-
darkę
Monitoruje
urządzenie
mobilne
Przesyłanie
danych do
serwera
Icinga Mobile [17] Android,
iOS
TAK BRAK BRAK
aNag [18] Android TAK BRAK BRAK
TiNag [19] Android NIE BRAK TAK
(Passive
Checks)
iNag [20] iOS NIE BRAK TAK
(Passice
Checks)
Tablica 1: Dostępne aplikacje mobilne
Rysunek 1: Ekrany aplikacji aNag [18] i TiNag[19]
16
2.4 Podsumowanie
Po analizie dostępnych na rynku systemów monitorujących zauważono, że ża-
den z nich nie spełnia wymagań pozwalających w wystarczającym stopniu zadbać o
prawidłowe odbieranie i przetwarzanie danych z urządzeń mobilnych. System Cacti,
z uwagi na brak rozwiązań pasywnych, nie nadaje się do wykorzystania w sytu-
acjach, gdy urządzenie mobilne nie jest podłączone do Internetu (a z taką sytuacją
użytkownik ma najcześciej do czynienia). Stworzony dla systemów Nagios i Icinga
dodatek NSCA posiada kilka ciekawych rozwiązań i umożliwia korzystanie z opcji
monitorowania urządzenia mobilnego, zawiera jednak także szereg wad (brak stem-
pla czasowego dla daty pomiaru, problemy z uwierzytelnianiem), które powodują,
że nie jest to usługa optymalna. Zdecydowano się zatem w tworzonym systemie
na implementację własnej wersji dodatku NSCA, z dodatkowymi usprawnieniami i
wyższym poziomem zabezpieczeń.
17
3 Android
3.1 Ogólne informacje
Niniejsza praca dyplomowa została zrealizowana w formie aplikacji na urządze-
nia mobilne. Zgodnie z tytułem pracy jako platformę, na której zaimplementowano
aplikację mobilną, wykorzystano system Android. Stworzenie aplikacji na ten system
było zobligowane tematem pracy.
W ostatnich latach zaobserwowano ich znaczący i bardzo intensywny rozwój.
Ilość telefonów, smartfonów i tabletów zarówno na krajowym jak i zagranicznym
rynku w ciągu ostatnich kilkunastu lat zwielokrotniła się. Umożliwiają one wykony-
wanie niemal tych samych czynności co komputery stacjonarne czy laptopy.
Na urządzeniach mobilnych, podobnie jak na komputerach stacjonarnych, dzia-
łają rozmaite systemy operacyjne. W chwili obecnej najpopulerniajsze to Android,
iOS oraz Windows Phone. Największy udział w rynku posiada ten pierwszy - do-
stępny jest (według danych z lipca 2013) na niemal 70% urządzeń mobilnych [15].
System iOS, tworzony i zarządzany przez firmę Apple, działa na około 17% urzą-
dzeń. Problemem ograniczającym wzrost zainteresowania tym systemem jest fakt, że
licencje dostępne są tylko dla urządzeń dedykowanych tworzonych przez samą firmę
Apple. Zatem jedyne urządzenia, na których wspomniany system może funkcjonować
to iPady oraz iPhone’y. Trzecim systemem jest Windows Phone, tworzony i zarzą-
dzany przez Microsoft. Posiada obecnie około 5% rynku urządzeń mobilnych, przede
wszystkim związanych z koncernem Nokia. Posiada interfejs graficzny podobny do
systemu stacjonarnego Windows 8, podobnie wygląda także tworzenie aplikacji na
oba środowiska. Inne systemy, jak Symbian czy BlackBerry OS, mają marginalny
udział w rynku i powoli zostają zastępowane przez te opisane powyżej.
Na potrzeby niniejszej pracy dyplomowej zdecydowano się na wykorzystanie sys-
temu Android jako narzędzia pozwalającego na stworzenie aplikacji monitorującej.
Powodów takiej decyzji jest kilka. Pierwszym z nich jest wspomniana popularność
systemu. Współpraca twórców (firmy Google) z firmą Samsung i obecność systemu
Android na urządzeniach tej firmy (takich jak rodziny Galaxy czy Note) powoduje, że
większość użytkowników posiada sprzęt właśnie z tym systemem. Kolejnym ważnym
powodem jest prostota tworzenia aplikacji. System Android działa na zmodyfikowa-
18
nym jądrze systemu Linux. Aplikacje tworzone są najczęściej w języku programowa-
nia Java (dla porównania, aplikacje dla systemu iOS tworzone są z wykorzystaniem
języka Objective-C, domeną systemu Windows Phone jest natomiast C#), które jest
obecnie jednym z najpopularniejszych języków, szeroko wykorzystywanym i posia-
dającym ogromne wsparcie. Korzystanie z możliwości urządzeń mobilnych wymaga
dołączenia dodatkowej biblioteki, która udostępnia API umożliwiające korzystanie
z elementów i mechanizmów charakterystycznych dla telefonów czy tabletów (mo-
duł GPS, akcelerometr itp.). Aplikacje tworzone są za pomocą środowiska programi-
stycznego Eclipse, które poza wsparciem dla języka Java udostępnia (w wersji ADT)
wbudowany emulator urządzenia mobilnego, co pozwala na testowanie aplikacji “na
bieżąco” i przyśpiesza proces implementacji. Wszystkie informacje związane z two-
rzeniem aplikacji na system Android dostępne są także na stronach firmy Google.
Wsparcie ze strony tej firmy jest znaczące i oznacza obecność wielu narzędzi uła-
twiających tworzenie aplikacji. Także proces wdrażania aplikacji do powszechnego
wykorzystania jest znacząco uproszczony, firma wspiera wszelkie projekty, które ko-
rzystają ze stworzonych przez nią narzędzi. Powoduje to, że w Google Play, czyli
sklepie dedykowanym aplikacjom tworzonym na system Android, dostępnych są setki
programów użytkowych, zarówno płatnych jak i darmowych, co powoduje (wraz z
obecnością systemu Linux), że na urządzeniach mobilnych z tym systemem możliwe
jest wykonywanie niemal tych samych operacji co na komputerach stacjonarnych.
3.2 Architektura systemu
Jak przedstawiono wcześniej, Android oparty jest na jądrze systemu operacyj-
nego Linux. Wersją, jaką wykorzystano w procesie tworzenia systemu mobilnego,
jest 2.6. W porównaniu do jądra systemu stacjonarnego jądro systemu Android
jest rozbudowane o dodatkowe usługi, takie jak zarządzanie pamięcią (specyficzną
w środowisku mobilnym), moduły związane z kwestiami bezpieczeństwa i zasilania
czy sterowniki dla narzędzi takich jak akcelerometr, żyroskop czy kamera [14].
Usługi jądra systemu Android obudowane są za pomocą różnego rodzaju biblio-
tek. Służą one przede wszystkim do ułatwienia korzystania z możliwości, jakie daje
urządzenie mobilne. Umożliwiają zarządzanie w sposób niezależny od konkretnej im-
plementacji różnego rodzaju usługami audio-video, związanymi z trójwymiarowym
19
określaniem położenia czy silnikami przeglądarek internetowych.
Na tym samym poziomie co biblioteki systemu Android znajduje się zespół na-
rzędzi do uruchamiania programów i aplikacji w środowisku języka Java. Są to mię-
dzy innymi wewnętrzne biblioteki języka Java a także maszyna wirtualna, niezbędna
do uruchamiania programów. Urządzenia mobilne z systemem operacyjnym Android
udostępniają własną wersję maszyny wirtualnej, znanej pod nazwą Dalvik. Obecność
takich rozwiązań pozwala na stworzenie wirtualnego, niezależnego od wbudowanego
systemu operacyjnego, w którym uruchamiane są aplikacje. Instancja każdej z nich
tworzona jest w formie osobnego procesu. Dzięki temu nie są one od siebie zależne i
błąd czy przerwanie działania jednej z nich nie wpływa w znaczący sposób na dzia-
łanie pozostałych. Dodatkowo ułatwia zarządzanie pamięcią, która wykorzystywana
jest przez poszczególne aplikacje.
Następną warstwą na stosie usług i narzędzi w urządzeniach mobilnych jest war-
stwa aplikacyjna. Środowisko aplikacyjne zawiera zestaw narzędzi pozwalających na
łatwe korzystanie z poziomu kodu z wszystkich podstawowych funkcji bez koniecz-
ności odwoływania się do wewnętrznych opcji systemu. Dostęp do tych narzędzi jest
pełny dla wszystkich developerów tworzących aplikacje. Ułatwienia przez nie wpro-
wadzone umożliwiają dużo szybsze i lepsze zarządzanie dostępnymi w środowisku
usługami.
Ostatnią warstwą są aplikacje. Dla systemu Android stworzono tysiące różnych
programów, które pozwalają na pełne wykorzystanie środowiska i wszystkich dostęp-
nych w nim opcji bez konieczności znajomości narzędzi programistycznych i bardziej
wyspecjalizowanych funkcji.
Chęć pomiaru i wyliczenia wartości określających dane usługi działające na
urządzeniach mobilnych z systemem operacyjnym Android wymaga sięgania do
różnych warstw na stosie narzędzi. Niektóre dostępne są bezpośrednio z poziomu
kodu, można je otrzymać za pomocą wywołania jednej funkcji zwracającej konkretną
liczbę. Inne wymagają sięgnięcia do jądra systemu Linux i pobrania wartości, które
następnie muszą zostać przetworzone i dopiero wtedy mogą zostać przekazane do
zapisu. W tworzonej pracy dyplomowej zaprezentowane zostaną różne sposoby na
zdobywanie informacji na temat działania urządzenia mobilnego.
20
3.3 Możliwe pomiary
WAndroidzie możliwy jest pomiar różnych danych związanych z działaniem sys-
temu oraz urządzenia mobilnego, na którym jest zainstalowany. Dane te dostępne
są w różny sposób. Kilka z wartości, takie jak stan baterii czy jakość (moc) sy-
gnału WiFi dostępne są bez użycia żadnych dodatkowych aplikacji. Widoczne są
one dla wszystkich użytkowników bezpośrednio z poziomu ekranu po wykonaniu
kilku kliknięć. Podobnie jest z ilością odebranych SMSów czy nawiązywanych roz-
mów. Wszystkie dane na ich temat widoczne są bezpośrednio z poziomu urządzenia.
Także informacje na temat ilości uruchomionych aplikacji są dostępne z poziomu
menu, także z podziałem na aplikacje zainstalowane na karcie pamięci oraz w bez-
pośredniej pamięci urządzenia.
Obecność wszystkich tych elementów wynika z faktu, że są to dane potrzebne
w codziennym użytkowaniu urządzenia przez użytkowników. Ilość uruchomionych
aplikacji może spowodować decyzję o usunięciu niektórych z nich lub o dokupieniu
dodatkowej karty pamięci umożliwiającej wydajniejsze ich przechowywanie. Szybkie
wyczerpywanie się stanu baterii może z kolei oznaczać, że konieczna jest jej wymiana
lub rezygnacja z kilku działających w tle procesów.
Niektóre informacje są jednak dużo trudniej dostępne. Dzieje się tak dlatego, że
nie są one potrzebne przeciętnemu użytkownikowi, który nie chce posiadać szczegó-
łowych informacji na temat działania urządzenia i zainstalowanego na nim systemu
operacyjnego, o ile całe środowisko działa poprawnie i z zadowalającym czasem
reakcji. Informacje takie mogą się jednak okazać potrzebne dla administratorów
zarządzających urządzeniami dostępnymi w różnego rodzaju firmach czy na uczel-
niach. Są to wartości opisujące bezpośrednio systemy, problemy, jakie występują w
czasie ich działania oraz inne wskaźniki pomagające ocenić, w jakim stanie znaj-
duje się urządzenie i czy jest konieczna interwencja ze strony osoby zarządzającej
infrastrukturą.
Przykładem danej trudno dostępnej jest zużycie mocy procesora. Informacja
ta może zostać zdobyta poprzez wykorzystanie możliwości, jakie daje system ope-
racyjny Linux. Za jego pomocą możliwe są pomiary aktualnego zużycia poprzez
obliczenie, w jakim trybie działał procesor przez określony, krótki okres. Czas, przez
który procesor działał w tym okresie w trybach innych niż idle uznawany jest za
21
pracujący i jego stosunek do całego czasu traktowany jest jako zużycie CPU.
Informacje dotyczące lokalizacji użytkownika pobierane są za pomocą wywoła-
nia odpowiedniej metody języka Java. API systemu Android udostępnia możliwość
pobrania aktualnej najlepszej lokalizacji, która wyznaczana jest za pomocą różnych
metod - sygnału GPS (jeśli jest dostępny), triangulacji na podstawie sieci teleko-
munikacyjnej czy z wykorzystaniem akcelerometru. Całość pomiarów zebrana jest
w formie dwóch wartości - długości i szerokości geograficznej, które następnie mogą
zostać bez problemów zapisane w bazie danych. Jest to rozwiązanie znacząco uła-
twiające wyznaczanie pozycji użytkownika.
Dostęp do wartości używanych przy pomiarach zostanie zaprezentowany w ni-
niejszej pracy inżynierskiej. Zostaną wykorzystane różne metody zbierania informa-
cji o urządzeniu, zarówno te bezpośrednie korzystające z API systemu Android jak
i z możliwości, jakie daje obecność systemu Linux.
3.4 Dostępne aplikacje monitorujące
Dla systemu Android zostały stworzone rozmaite aplikacje, które umożliwiają
zbieranie danych o urządzeniu mobilnym, na którym zostały zainstalowane. Naj-
częściej są to rozwiązania korzystające z opisanych wcześniej sposobów zdobywania
informacji na temat zmiennych opisujących stan urządzenia. W większości korzy-
stają z rozwiązań dostępnych już na platformie Android, zazwyczaj obudowując je
w przyjazny układ graficzny czy możliwości ustawienia różnych opcji. W tabeli 2
przedstawiono kilka z nich polecanych i wysoko ocenianych przez klientów sklepu
Google Play. Zostały one przeanalizowane zarówno pod kątem funkcjonalności jak
i integracji z rozwiązaniami stacjonarnymi czy istniejącymi już systemami monito-
rującymi.
22
Nazwa Funkcjonalność Integracja
Current Widget
[21]
Pomiar stanu baterii, wizualizacja danych hi-
storycznych, analiza logów
BRAK
OS Monitor [22] Monitorowanie procesów, komunikacji, bate-
rii, interfejsów sieciowych, systemu plików itd.
BRAK (zapis tylko do pa-
mięci telefonu)
System Monitor
[23]
Monitorowanie zużycia zasobów systemowych,
procesora lub jego poszczególnych rdzeni,
możliwość ustawienia częstotliwości odświeża-
nia, przejrzysty układ graficzny
BRAK
Quick System
INFO [24]
Monitorowanie CPU, karty pamięci, sieci czy
zainstalowanych programów
BRAK (zapis tylko do pa-
mięci telefonu)
Smart System Info
[25]
Monitorowanie większości usług na urządze-
niu, także geolokalizacja, prezentacja tylko ak-
tualnych danych (bez danych historycznych)
BRAK
PerfMon [26] Monitorowanie pracy poszczególnych proce-
sów pod kątem zużycia CPU, operacji wejścia-
/wyjścia czy komunikacji sieciowej, reprezen-
tacja w formie ikonek na górnym pasku urzą-
dzenia
BRAK
System Tuner [27] Przedstawianie informacji o procesach, sorto-
wanie pomiarów i ich wyników, czyszczenie
pamięci podręcznej
BRAK (aplikacja uży-
wana raczej do zwiększa-
nia wydajności systemu)
Tablica 2: Aplikacje monitorujące - Android
Żaden z przedstawionych powyżej programów nie posiada funkcjonalności, jaką
jest wykorzystywanie dostępnych na rynku stacjonarnych systemów monitorujących.
Oznacza to, że nie ma możliwości bezpośredniego przekazania wyników przeprowa-
dzonych pomiarów do systemów takich jak Icinga czy Nagios. Niektóre z aplikacji
zapisują zgromadzone dane na dysku urządzenia, przechowując je jako logi, które
są następnie możliwe do bezpośredniego obejrzenia przez użytkownika. Format (nie-
zgodne z tym obecnym w systemach Icinga oraz Nagios) uniemożliwia jednak łatwe
ich przeparsowanie i przekazanie do wewnętrznych struktur systemów monitorują-
cych. Żaden z opisanych systemów nie posiada także możliwości informowania o nie-
pokojących wartościach opisujących działanie urządzanie mobilnego w inny sposób
niż poprzez samo urządzenie - nie ma możliwości wysłania na przykład wiadomości
23
e-mail czy sms.
Czynniki te powodują, że opisane aplikacje nie pozwalają w żadnym stopniu
na wykorzystanie możliwości, jakie dają stacjonarne systemy monitorujące (two-
rzenie mapy sieci, przedstawianie danych historycznych itp.). Pomimo że są one
wykorzystywane przez użytkowników urządzeń mobilnych z systemem Android, ich
możliwości w zakresie zbierania, przetwarzania i przede wszystkim analizy danych
nie wykraczają poza samo urządzenie, na którym są zainstalowane. W przypadku
administrowania większą ilością urządzeń przez administratora sieci firmowej czy wy-
działowej jest to rozwiązanie wysoce niesatysfakcjonujące. Brak centralnego miejsca
gromadzenia danych z różnych urządzeń mobilnych i problematyczne ich przesyłanie
powodują, że na rynku pojawiło się miejsce na aplikację, która z jednej strony będzie
zbierać dane o urządzeniu mobilnym a z drugiej przekazywać je do istniejących sta-
cjonarnych systemów monitorujących, gdzie będą one mogły zostać przetworzone,
przeanalizowane, porównane z innymi i zapisane w bazie danych.
24
4 Wymagania
4.1 Wymagania ogólne
W poprzednich rozdziałach wysunięto i udowodniono tezę, że nie istnieją na
rynku rozwiązania umożliwiające zbieranie danych na urządzeniu mobilnym w try-
bie offline i przekazywanie ich do serwera stacjonarnego w momencie nawiązaniapo-
łączenia z siecią. Istniejące rozwiązania posiadają szereg różnego rodzaju wad, które
znacząco utrudniają lub wręcz uniemożliwiają prawidłowe monitorowanie urządzeń
mobilnych - najpoważniejszym problemem jest brak stempla czasowego dla oznacze-
nia czasu pomiaru a nie czasu wysłania wiadomości.
Zdecydowano się zatem na stworzenie aplikacji-systemu, który umożliwiałby
zbieranie informacji na temat urządzeń mobilnych. Są to zarówno różnego rodzaju
telefony komórkowe, tablety jak i laptopy (których mobilność powoduje konieczność
traktowania ich w podobny jak poprzedników sposób). Pod pojęciem monitorowa-
nia rozumie się cykliczne zbieranie informacji na temat zdefiniowanych wcześniej
usług poprzez wartości opisujące stan i działanie danego sprzętu. Wartości takie,
wraz z odpowiednim opisem, stanowić mogą znaczące źródło informacji na temat
urządzenia.
Praca taka składać się powinna z przynajmniej dwóch modułów komunikują-
cych się ze sobą - modułu mobilnego, obecnego na urządzeniu monitorowanym oraz
modułu stacjonarnego, pełniącego rolę odbiorcy i analizatora danych. Spowoduje to
zarówno łatwość w zarządzaniu odbieraniem danych jak i znacząco uprości tworze-
nie i konfigurowanie modułów obecnych na urządzeniach mobilnych (które różnią
się co do budowy dosyć znacząco w zależności od producenta sprzętu). Oba wspo-
mniane moduły (zarówno mobilny jak i stacjonarny) powinny być od siebie jak
najbardziej niezależne - porozumieć się powinny tylko za pomocą zdefiniowanego
protokołu komunikacyjnego. Powoduje to powstanie zupełnie odrębnych wymagań,
jakie są przed nimi stawiane. Istnieją jednak także wymagania wspólne, związane z
ogółem czynności powodujących poprawne monitorowanie. Są to przede wszystkim:
Spójność danych
Dane nie mogą być w żaden sposób tracone na skutek błędów transmisji -
powinny być zawsze przechowywane przez przynajmniej jedną ze stron.
25
Poufność danych
Dane powinny być chronione zarówno w czasie transmisji jak i w czasie ich
przechowywania.
Integralność danych
Uniemożliwienie ręcznej modyfikacji lub dodania nowych wartości przez osoby
niepowołane.
Oszczędność pasma
Powinny być przekazywane tylko dane niezbędne do prawidłowego funkcjono-
wania, bez dodatkowych, nadmiarowych wartości.
Uwierzytelnianie
Zarówno strona stacjonarna jak i mobilna powinny być traktowane jako bez-
pieczne dopiero po prawidłowym, zdefiniowanym wcześniej uwierzytelnieniu.
Obsługa wielu instancji
Dane powinny zarówno być zbierane z różnych urządzeń mobilnych jak i prze-
kazywane w różne miejsca, w zależności od konfiguracji.
Konfigurowalność
Tworzony moduł powinień być podzielone na podmoduły zgodnie z ich prze-
znaczeniem tak, aby możliwa była wymiana poszczególnych elementów bez
szkody dla działania całego systemu. Dotyczy to między innymi mechanizmów
kryptograficznych czy opcji uwierzytelnienia.
Analiza danych historycznych
System powinien umożliwiać analizę danych historycznych wraz z ich graficzną
reprezentacją.
Odbiór porcji danych
System powinien mieć możliwość odbioru danych w postaci porcji-paczek oraz
wysyłania potwierdzeń aktualnie odebranych wyników pomiarów.
26
4.2 Wymagania klienta mobilnego
Nieco inne są wymagania stawiane przed projektem klienta mobilnego. Z uwagi
na specyfikę tego rodzaju urządzeń główną rolę odgrywają czynniki związanie z za-
pewnieniem bezpieczeństwa danych oraz prawidłowym ich przechowywaniem i prze-
syłaniem do modułu zewnętrznego. Powinna być zagwarantowana pewność zachowa-
nia danych, które są wysyłane przez urządzenie mobilne - ich usunięcie jest możliwe
dopiero po prawidłowym ich odebraniu przez serwis zewnętrzny.
Zbieranie danych offline
Możliwość zbierania danych przez urządzenie nie powinna być determinowana
przez obecność sygnału internetowego - w przypadku jego braku dane powinny
być przechowywane aż do momentu nawiązania połączenia.
Odporność na zgubienie lub utratę danych
Utrata danych przechowywanych na urządzeniu mobilnym lub całkowita jego
niedostępność (zgubienie, kradzież, zalanie) nie powinny dyskwalifikować ca-
łego tworzonego systemu (przede wszystkim pod kątem ujawnienia algorytmów
oraz kluczy kryptograficznych).
Przechowywanie danych
Z uwagi na częstą sytuację braku dostępu do Internetu a co za tym idzie brak
możliwości przesłania danych do serwera zewnętrznego informacje powinny
być przechowywane na urządzeniu tak długo, jak nie powstanie okazja do ich
prawidłowego przesłania.
Oznaczanie daty wykonania pomiarów
Dane powinny być opisywane stosownym (odpornym na błędy) stemplem cza-
sowym w celu ich prawidłowej weryfikacji i identyfikacji.
Odporność na wyłączenie telefonu
Jeśli przed wyłączeniem urządzenia moduł zbierał dane, po jego ponownym
włączeniu sekwencja pomiarowa powinna być kontynuowana w sposób, w jaki
miało to miejsce wcześniej.
Automatyczność
Poza początkową konfiguracją i wyborem monitorowanych usług klient mo-
27
bilny powinien wykonywać wszystkie działania (zarówno zbieranie danych jak
i ich wysyłanie) automatycznie, bez wiedzy użytkownika.
Wydajność
Szybkie zużycie baterii powoduje konieczność zadbania o jak najwydajniejsze
działanie klienta mobilnego - pomiary nie powinny znacząco obciążać mocy
procesora, powinny być także uruchamiane automatycznie przez samo urzą-
dzenie, bez ciągle działającej w tle aplikacji.
Bezpieczeństwo
Klient powinien zarówno uwierzytelniać serwer, do którego przekazuje dane jak
i uniemożliwiać ich niepowołane przeglądanie. Powinien także dopasowywać się
do istniejących na serwerze algorytmów kryptograficznych.
Łatwa rozbudowa
Aplikacja powinna być zaimplementowana w sposób umożliwiający łatwą dal-
szą rozbudowę, bez konieczności reorganizacji całego kodu.
Wizualizacja danych
Program powinien umożliwiać przeglądanie (w jak najprostszej, tabelarycznej
formie) danych zebranych na danym urządzeniu (co może zostać wykorzysty-
wane w przypadku bezpośredniego, szczegółowego przeglądu dokonywanego
przez administratorów).
28
5 Architektura Systemu
5.1 Architektura ogólna
Głównym celem tworzonego systemu jest zbieranie i przetwarzanie danych prze-
kazywanych przez urządzenie mobilne w celu lepszego zarządzania dostępną w da-
nym miejscu infrastrukturą. Jak zostało to opisane w rozdziale dotyczącym wyma-
gań, oznacza to konieczność stworzenia przynajmniej 2 części, z których składać
się będzie tworzone rozwiązanie - modułu stacjonarnego, zbierającego i przetwarza-
jącego dane oraz modułu mobilnego, odpowiadającego za generowanie informacji.
Każda z tych części została zaimplementowana w ramach osobnej pracy dyplomo-
wej, część stacjonarna została wykonana przez [1]. Niniejsza praca odpowiada za
implementację modułu mobilnego i zapewnienie z jego strony poprawnej komunika-
cji pomiędzy oboma elementami.
Część stacjonarna powstała w oparciu o opisany już wcześniej system moni-
torujący Icinga. Wykorzystując dostępne już rozwiązanie uzyskano z jednej strony
pewny i wydajny program zbierający i przetwarzający dane, z drugiej umożliwiono
szerszą dystrybucję tworzonego systemu w oparciu o mechanizmy wykorzystywane
szeroko przez administratorów. Dzięki temu tworzone moduły mogą zostać bezpro-
blemowo włączone do już działających systemów i być wykorzystane do monitoro-
wania urządzeń mobilnych z lepszym skutkiem niż ma to miejsce do tej pory (kiedy
wykorzystywany jest dodatek NSCA).
Moduł stacjonarny podzielony jest na 2 główne części - część przetwarzającą
dane oraz część je odbierającą. Obie części zostały szczegółowo opisane w pracy [1].
Został on zaproponowany z uwagi na braki funkcjonalne w istniejącej już wtyczce
NSCA. Jednym z głównych celów było zatem poprawienie lub wprowadzenie wcze-
śniej działających rozwiązań. Ważne było spełnienie wymagań dotyczących między
innymi stempla czasowego, zapewnienie bezpieczeństwa przesyłanych danych (oraz
ich kontroli), uwierzytelniania użytkowników oraz łatwości rozbudowy. Istotne jest
także, by dane mogły być przekazywane w różne miejsca (konfigurowalne dla po-
szczególnych klientów lub odbieranych wyników pomiarów). Uwierzytelnianie i au-
toryzacja klientów także odbywa się w stworzonym module odbiorczym.
Poniżej przedstawiono uproszczony, poglądowy schemat rozwiązania całego sys-
29
temu - część “moduł odbiorczy” realizowana jest w ramach innej pracy inżynierskiej
[1], niniejsza odpowiada na diagramie za stworzenie modułu mobilnego. Rysunek
stworzony został z wykorzystaniem oprogramowania [37]
Rysunek 2: Ogólny, poglądowy schemat całego systemu
Krótki opis poszczególnych modułów:
Moduł odbiorczy
Realizowany w innej pracy inżynierskiej [1]. Działa w postaci procesu - da-
emona (o nazwie nascav2), który nasłuchuje zgłoszeń z różnego rodzaju urzą-
dzeń mobilnych. W momencie odebrania tego rodzaju żądania zestawia nową
sesję, w której zarządza komunikacją z urządzeniem. Po poprawnej weryfika-
cji i autoryzacji przesyła polecenie rozpoczęcia przesyłu logów, które następ-
nie są analizowane (czy użytkownik ma prawa do ich wstawiania oraz czy
są poprawnie sformatowane). W przypadku ich poprawnego sprawdzenia są
one przekazywane do modułu systemu Icinga. Błędy w komunikacji z urzą-
dzeniem mobilnym (w zdefiniowanym protokole komunikacyjnym) skutkują
zakończeniem bieżącej sesji. Moduł umożliwia obsługę wielu połączeń jedno-
cześnie, każde łączące się z nim urządzenie powinno być poprawnie opisane
w pliku konfiguracyjnym. Moduł stworzony jest w języku C++ z wykorzy-
staniem biblioteki Qt oferującej wiele udogodnień, między innymi w zakresie
tworzenia wielowątkowych aplikacji korzystających z komunikacji sieciowej.
Wykorzystano także bibliotekę CryptoPP, która odpowiedzialna jest za odpo-
wiednią obsługę mechanizmów kryptograficznych. Moduł ten został stworzony
do pracy w systemie operacyjnym Linux.
30
System monitorowania Icinga
System opisany został szczegółowo w rozdziale Systemy Monitorujące - dane
odbierane są z wykorzystaniem Passive Checks, dodawane są odpowiednie
informacje (niezbędne między innymi do prezentacji użytkownikowi danych
w module Icinga Web). Komunikacja pomiędzy modułem odbiorczym a sys-
temem Icinga odbywa się poprzez opisywane wcześniej External Command
File, nie jest ona zatem inicjowana przez sam system monitorujący. Moduł
odpowiedzialny jest także za wizualizację danych, obsługę ostrzeżeń i ewen-
tualne informowanie administratora o zaistniałych sytuacjach. Dba także o
poprawne odpytywanie rozmaitych usług w celu zebrania informacji na ich
temat. System został stworzony na platformę Linux.
Baza danych MySQL
System zarządzania bazą danych, umożliwiający przechowywanie danych w
bezpiecznej, trwałej formie. System Icinga wykorzystuje go do składowania
wszystkich danych dotyczących pomiarów (nazwy urządzenia, monitorowane
serwisy, stany poszczególnych serwisów, stemple czasowe itp.). Dane przecho-
wywane są w postaci tabel relacyjnych - system Icinga umożliwia zarządzanie
nimi w zakresie tworzenia kopii zapasowych, prezentacji danych z poszczegól-
nych okresów. W przypadku przechowywania zbyt wielkiej ilości informacji
dane najstarsze są agregowane a przechowywane w nich wartości są uśred-
nione. Celem takiego działania jest zmniejszenie ilości miejsca potrzebnego do
prawidłowego działania.
Wszystkie moduły mogą być uruchomione na różnych platformach i komuniko-
wać się ze sobą za pomocą sieci. Więcej informacji na temat modułu odbiorczego a
także jego współpracy z systemem monitorowania Icinga zostało zamieszczonych w
pracy inżynierskiej [1].
31
5.2 Aplikacja mobilna
5.2.1 Ogólny opis
Aplikacja stworzona w ramach niniejszej pracy dyplomowej ma za zadanie reali-
zację dwóch głównych funkcjonalności - zbieranie danych i ich wysyłanie do serwera
zewnętrznego. Zbieranie danych odbywa się cyklicznie - co ustalony okres (najczę-
ściej jest to 30 minut). Aby uniknąć znaczącego wzrostu zużycia stanu baterii, po-
miary uruchamiane są niezależnie od działania aplikacji, która po konfiguracji może
zostać wyłączona. Pomiary przeprowadzane są także po wyłączeniu i ponownym
włączeniu urządzenia. Dane po przeprowadzeniu pomiaru przechowywane są w spe-
cjalnie zdefiniowanej w tym celu bazie danych (która związana jest z aplikacją). Po
nawiązaniu komunikacji z modułem odbiorczym (poprzez sieć WiFi) dane są pobie-
rane z bazy danych i przesyłane. Komunikacja odbywa się za pomocą zdefiniowanego
protokołu komunikacyjnego, obsługiwana jest autoryzacja a także szyfrowanie. Po
poprawnym przekazaniu danych są one usuwane z pamięci urządzenia. Użytkownik
ma możliwość wybrania, które serwisy są aktualnie uruchomione, z jakim interwa-
łem czasowym działają. Konfiguruje także odpowiednie dane (jak adres IP serwera
czy nazwę hosta).
Aplikacja podzielona została na moduły, z których każdy odpowiada za część
zdefiniowanych funkcjonalności.
5.2.2 Serwisy pomiarowe
Serwisy pomiarowe są najważniejszym elementem tworzonej aplikacji - bez nich
pozostałe moduły nie miałyby danych, na których mogłyby operować. Serwisy odpo-
wiadają za prawidłowe zebranie danych dotyczących działania poszczególnych usług
urządzenia mobilnego. Dla każdej z usług stworzony jest osobny, dedykowany serwis
- dzięki temu można w łatwy sposób zarządzać pomiarami.
Jak zdefiniowano w wymaganiach, pomiary wykonywane są cyklicznie, co okre-
śloną jednostkę czasu (5 minut, 30 minut, 1 godzina itp.). Automatyczność tego
rodzaju rozwiązania zapewniona jest przez mechanizm biblioteki systemu Android
o nazwie AlarmManager - pozwala on na ustawienie interwałów czasowych, z jakimi
mają być uruchamiane zdefiniowane przez twórcę aplikacji zadania. W tworzonej
32
pracy zadania te odpowiedzialne są za pomiar odpowiednich wartości. Niektóre z
nich (poziom baterii, sygnał WiFi) wymagają wywołania dodatkowych metod od-
powiednich klas, inne sprowadzają się do prostego pobrania wartości. Po odczytaniu
wartości wykorzystują one zdefiniowane przez autora aplikacji narządzia do zapisy-
wania danych w bazie z dowolnego punktu aplikacji. Następnie kończą one swoje
działanie zmniejszając wykorzystanie baterii (co znacząco wpływa na wydajność).
Części pomiarowe zrealizowano w sposób pozwalający na jak największą ela-
styczność - tworzone serwisy muszą spełniać kilka podstawowych warunków, jednak
sam pobór wartości może być wykonywany w sposób dowolny - bez ograniczenia do
jednej klasy czy jednej biblioteki. Wykorzystywane są zarówno metody języka Java
jak i polecenia systemu operacyjnego Linux. Przykładowe implementacje opisane
zostały w rozdziale dotyczącym szczegółów implementacyjnych tworzonej aplikacji.
5.2.3 Model danych
Aby konfigurowalność monitorowanych usług była jak największa, konieczne
stało się maksymalne uproszczenie przechowywanych danych. Wszystkie informacje,
które nie są niezbędne dla poprawnego działania aplikacji i jej integracji z systemami
zewnętrznymi nie są zapisywane w pamięci urządzenia, ponieważ i tak nie zostaną
przesłane na zewnątrz. Ich gromadzenie w pamięci urządzenia powodowałoby zatem
dość szybkie zużywanie się miejsca na dysku (wewnętrznym i zewnętrznym) a wobec
faktu, że dane te nigdy nie byłyby przekazywane dalej, a co za tym idzie także i
usuwane, oznaczałoby to niepotrzebną stratę miejsca.
Tworzona aplikacja, z uwagi na swoją automatyczność i brak komunikacji z użyt-
kownikiem w momencie przeprowadzenia pomiaru, nie zawiera możliwości komen-
towania otrzymywanych wartości. Wydaje się, że nie jest to utrudnienie, bowiem
mierzone wartościa są wartościami prostymi, niewymagającymi opisu (jak ma to
miejsce w przypadku niektórych usług monitorowanych na komputerach stacjonar-
nych). Dużo łatwiejsze i bardziej szablonowe staje się dzięki temu przechowywanie
danych.
Zdecydowano, że przy każdym pomiarze zapisane zostaną 3 wartości. Są to:
• sama wartość mierzona
• data pomiaru
33
• poziom ostrzeżenia (wartość wymagana przez system Icinga)
Dodatkową informacją jest sama nazwa serwisu, który zapisał daną wartość.
Najważniejszym zapisywanym elementem jest oczywiście wartość mierzona przez
serwis. Mogą one przyjmować dowolne wartości liczbowe, zarówno całkowite jak i
ułamkowe. Przykładowo, serwis odpowiadający za pomiar stanu baterii zapisuje
daną wynikową w zdefiniowanej postaci liczbowej w przedziale 0-1.
Drugą daną jest stempel czasowy. Wymagania systemów takich jak Icinga opie-
rają się na chronologicznej kolejności przekazywanych komunikatów. W przypadku
braku ciągłości czasowej system może mieć trudności z prawidłowym odczytaniem
wyników i odrzucić przychodzące informacje. Dlatego ważne jest, aby informacje za-
pisane w przestrzeni aplikacji miały zapisany czas, w którym przeprowadzony został
pomiar. Z jednej strony ograniczy to wspomniane problemy, z drugiej ułatwi admi-
nistratorom czy innym osobom zarządzającym infrastrukturą analizę i weryfikację
spływających danych.
Strefy czasowe oraz indywidualna ingerencja użytkowników w czas systemowy
mogą powodować, że będą występować nieścisłości. Mogą one doprowadzić do sy-
tuacji (na przykład kiedy użytkownik podróżuje pomiędzy miejscami znajdującymi
sie w różnych strefach czasowych), gdy dane wcześniejsze posortowane według zapi-
sanego w aplikacji czasu będą traktowane jako późniejsze. Oznacza to niespójność
danych i konieczność badania ich poprawności w systemie zewnętrznym. Aby temu
zapobiec konieczna jest synchronizacja czasowa z jednym z licznych serwisów NTP.
Pozwalają one na sprawdzenie różnicy między aktualnym czasem zapisanym w pa-
mięci urządzenia a czasem prawdziwym, mierzonym za pomocą skomplikowanych
mechanizmów.
Trzecią, ostatnią, wartością jest poziom ostrzeżeń. Jak wspomniano wcześniej,
w systemie Icinga występują 3 stany, w których może znajdować się dany serwis.
Stan czwarty, oznaczający sytuację nieznaną, z uwagi na specyfikę urządzeń mobil-
nych nie występuje. Dla każdego z serwisów inne są wartości graniczne, rozdzielające
między sobą odpowiednio stany poprawnego działania, dzałania alarmowego (ostrze-
żenia) oraz działania krytycznego, błędnego. Wartości te są domyślnie ustawione na
0, co powoduje, że wyniki wszystkich pomiarów traktowane są jako poprawne, nie-
wymagające ingerencji. Dzięki temu użytkownik, który nie zamierza wprowadzać
34
skomplikowanych ustawień może bez przeszkód korzystać z aplikacji nie przejmując
się bardziej skomplikowanymi ustawieniami.
5.2.4 Schemat bazy danych
Platforma Android umożliwia programiście zapisywanie niezbędnych danych w
przestrzeni aplikacji. Niestety, nie jest możliwy wybór własnej wersji systemu za-
rządzania bazą danych, jest ona narzucona przez system operacyjny. Spośród wielu
dostępnych DBMS twórcy Androida zdecydowali się na system SQLite [28].
Jego główną zaletą, w porównaniu do dużych, stacjonarnych systemów takich
jak Oracle czy MySQL, jest zgodnie z nazwą “lekkość”, czyli stosunkowo małe zapo-
trzebowanie na pamięć i moc obliczeniową. Został stworzony w roku 2000. Powstał
głównie dla systemów wbudowanych oraz takich, gdzie ograniczone zapotrzebowanie
na zasoby jest czynnikiem krytycznym. Wykorzystywany jest w wielu gałęziach in-
formatyki, między innymi w oprogramowaniu antywirusowym (do przechowywania
informacji o wirusach) czy przeglądarkach internetowych (do zapisywania ustawień
użytkownika). Dane zapisywane są jako pliki binarne, co ułatwia ich przenoszenie.
Dla programistów piszących na platformę Android pewną nowością wydaje się
być sposób przechowywania tabel bazy danych na dysku urządzenia. System nie po-
zwala na zdefiniowanie ścieżki do folderu zewnętrznego, w którym składowane będą
pliki. Mogłoby to powodować utrudnienia i opóźnienia przy odczycie danych. Za-
miast tego wszystkie dane umieszczane są w przestrzeni aplikacji, która ich używa.
Umożliwia to zapewnienie spójności, rozwiązuje ewentualne problemy z przypadko-
wym skasowaniem części informacji oraz znacznie przyśpiesza operacje wejścia/wyj-
ścia. Dane takie są trwałe, to znaczy pozostają w pamięci urządzenia do momentu
usunięcia aplikacji.
Możliwe jest dotarcie do danych zgromadzonych w przestrzeni jednej aplikacji z
zewnątrz, tj. z poziomu innej aplikacji czy procesu. Służy do tego ContentProvider,
które umożliwia odpowiednią dla środowisk obiektowych enkapsulację i ograniczony
dostęp do danych w taki sposób, w jaki zdefiniował to programista tworzący apli-
kację, z której ktoś inny chce pobierać lub do której chce wstawiać wartości. Roz-
wiązanie takie powstaje przez stworzenie klasy dziedziczącej po wspomnianym już
ContentProvider i przeciążenie odpowiednich metod. Zostało ono wykonane na po-
35
trzeby niniejszej pracy, zatem inne aplikacje mogą korzystać z danych zapisywanych
w toku działania.
Wymaganiem zdefiniowanym przez system Android jest konieczność tworzenia
liczbowych kluczy głównych. Zazwyczaj tworzone są one jako sekwencja, to zna-
czy każdy nowy wiersz w tabeli powoduje inkrementację licznika, który następnie
wstawiany jest w odpowiednie miejsce. Powoduje to zachowanie zgodności z podsta-
wowym zadaniem klucza głównego, to znaczy niepowtarzalnością wartości. W mo-
mencie usunięcia jakiegoś wiersza z tabeli sekwencja nie wykorzystuje zwolnionego
numeru, co jest pożyteczne w kontekście późniejszego wysyłania danych na serwer
zewnętrzny - możliwe jest wysyłanie danych w koleności kluczy głównych, nie ma
konieczności stosowania dodatkowego warunku tworzonego na podstawie stempla
czasowego.
Dla każdego serwisu w momencie pierwszego uruchomienia aplikacji (można to
porównać do instalacji programu na sprzęcie stacjonarnym) tworzona jest osobna
tabela. Ponieważ informacja o liczbie i rodzaju serwisów znana jest już w momencie
instalacji aplikacji (kompilator przekształca kod języka Java do postaci zrozumiałej
dla systemu Android), nie występuje problem z brakiem tabel dotyczących serwisów,
które zostały dodane w dalszym toku użytkowania.
Tabele tworzone są za pomocą polecenia w języku SQL. Jest ono parametry-
zowane za pomocą nazwy serwisu, co ułatwia ewentualne modyfikacje i powoduje,
że możliwe jest przechowywanie tego polecenia w jednym miejscu. Nazwy kolumn
pozostają bez zmian dla każdego z serwisów. Są to:
COLUMN_ID
Kolumna niewidoczna dla programisty, przechowująca wspomniany już klucz
główny ułatwiający zarządzanie wierszami. Wartość ta nie jest przedstawiana
użytkownikowi.
COLUMN_VALUE
Kolumna zawierająca informacje o stanie urządzenia zmierzonym przez serwis.
Jest to najważniejsza kolumna w tabeli, wartość ta nie może być kluczem
głównym (ponieważ może się powtarzać). Przechowuje wartości liczbowe
COLUMN_STATE
36
Kolumna przechowująca informację o poziomie ostrzeżeń zdefiniowanym dla
systemu Icinga. Jak wspomniano wcześniej, możliwe są 3 wartości: 0 - ozna-
czająca poprawne działanie usługi, 1 - oznaczająca działanie niepoprawne, ale
mieszczące się w akceptowalnych granicach oraz 2 - działanie krytyczne, wy-
magające wprowadzenia zmian i interwencji użytkownika lub administratora.
Inne wartości nie są dopuszczalne.
COLUMN_TIMESTAMP
Kolumna przechowująca stempel czasowy pomiaru. Składnia przechowywanej
wartości opisana została w dalszej części pracy. Informacja ta jest niezbędna
dla systemu Icinga, wykorzystywana jest zatem głównie w momencie komuni-
kacji z systemem zewnętrznym oraz synchronizowana z serwerami NTP przed
wysłaniem. Zapisywany (bez dostępu do sieci) czas pobierany jest z czasu sys-
temowego urządzenia mobilnego.
Na kolumnę COLUMN_STATE nałożone jest ograniczenie (ang. constraint),
które zapewnia, że dane tam zawarte mieszczą się w zbiorze 0,1,2 (co wynika z
nomenklatury systemu Icinga). Użytkownik nie ma możliwości usunięcia danych za-
pisanych przez serwisy monitorujące. Działanie takie byłoby niepożądane z uwagi na
ciągłość przechowywanych wartości oraz ich spójność. Także modyfikacja zapisanych
danych nie jest możliwa. Wynika to z analogicznych powodów.
5.2.5 Komunikacja
Moduł komunikacyjny uruchamiany jest w momencie nawiązania połączenia
z siecią WiFi. Aby jak najbardziej ułatwić korzystanie z aplikacji użytkownikom,
komunikacja z serwerem zewnętrznym rozpoczyna się automatycznie, nie jest po-
trzebna żadna ingerencja użytkownika - wyjątkiem jest wcześniejsze skonfigurowa-
nie parametrów oraz zapis w pamięci urządzenia klucza publicznego dostarczanego
przez serwer (klucz ten jest wykorzystywany do szyfrowania danych). Przed rozpo-
częciem komunikacji następuje sprawdzenie, czy w bazie danych dostępne są dane
niezbędne do wysłania - jeśli nie, nie ma potrzeby nawiązywania połączenia. Jeśli
są obecne dane, następuje ich pobranie do tymczasowego bufora, gdzie dzielone są
na porcje (możliwe do przesłania w jednej paczce). Następnie następuje próba połą-
czenia z serwerem zewnętrznym i w przypadku poprawnego zestawienia komunikacji
37
rozpoczyna się wymiana komunikatów pomiędzy urządzeniem mobilnym a modu-
łem odbiorczym. Pierwszym etapem komunikacji jest uwierzytelnienie - przekazanie
informacji na temat wersji protokołu, metody uwierzytelnienia itp. (szczegółowy
opis dostępny jest w rozdziale Protokół Komunikacyjny). Po poprawnym uwierzy-
telnieniu (w stworzonej aplikacji odbywa się ona z wykorzystaniem loginu i hasła)
rozpoczyna się transfer danych. Dane, uprzednio umieszczone w buforze tymczaso-
wym są pobierane porcjami, szyfrowane i (wraz z dołączonym ich skrótem) prze-
syłane do serwera zewnętrznego. W momencie, gdy serwer potwierdzi prawidłowy
ich odbiór, pojawia się możliwość ich usunięcia z pamięci urządzenia. Do tego celu
wykorzystywane są zapisane uprzednio (tj. przed wysłaniem) klucze główne wierszy.
Za ich pomocą (oraz odpowiedniego warunku w zapytaniu języka SQL) możliwe jest
usunięcie odebranych już przez serwer zewnętrzny wierszy.
Moduł komunikacyjny podzielony jest na kilka pakietów (zgodnie z konwencjami
obecnymi w języku Java). Pierwszy z nich (network) odpowiedzialny jest za prawi-
dłową reakcję na zdarzenie połączenia z siecią WiFi. Po poprawnej obsłudze tego
zdarzenie sterowanie przekazywane jest do modułu socket, który uruchamia osobny
wątek odpowiedzialny za komunikację (tak, aby nie zakłócać pracy zarówno serwi-
sów pomiarowych jak i warstwy graficznej). Wątek ten działa na zasadzie pytanie-
odpowiedź - znajduje się albo w stanie oczekiwania na odpowiedź modułu odbior-
czego albo w sytuacji, w której komunikat otrzymał i zajmuje się stworzeniem i
wysłaniem odpowiedzi. Za każdy stan (oczekiwanie na potwierdzenie danych, ocze-
kiwanie na prośbę o hasło itp.) odpowiada osobna klasa. Każda z nich implementuje
interfejs SocketConnectionState, dzięki czemu możliwe jest wykorzystanie poli-
morfizmu ujednolicenia wywołań metod z odpowiednich obiektów. W czasie komu-
nikacji wykorzystywane są także klasy z pakietu message, który zawiera dwie klasy
odpowiedzialne odpowiednio za dekrypcję i enkrypcję danych. Wykorzystywane są
także (opisane w rozdziale dotyczącym kryptografii) klasy odpowiedzialne za szy-
frowanie, deszyfrowanie danych a także obliczanie skrótów wiadomości.
5.2.6 Kryptografia
Szyfrowanie danych jest bardzo ważnym elementem każdej komunikacji siecio-
wej. Dane przesyłane przez sieci muszą być jak najlepiej zabezpieczane, aby jak naj-
38
bardziej utrudnić ich odczytanie osobom niepowołanym. Dostępne są różne sposoby
zabezpieczania przekazywanych danych, w niniejszej pracy wykorzystano zarówno
szyfrowanie (symetryczne i asymetryczne), jak i skróty wiadomości.
Stworzony moduł kryptograficzny podzielony jest na kilka klas. Za zarządzanie
nimi odpowiada jedna klasa nadrzędna o nazwie CryptoManager, zorganizowana z
wykorzystaniem wzorca projektowego Singleton. Pozostałe klasy to:
AESModule
Moduł odpowiedzialny za obsługę szyfrowania symetrycznego, jest odpowie-
dzialny za wygenerowanie klucza służącego zarówno do szyfrowania jak i de-
szyfrowania oraz poprawną aktualizację wektora inicjalizującego
RSAModule
Odpowiada za obsługę szyfrowania asymetrycznego, wykorzystuje dostarczony
przez serwer klucz publiczny (który może być wykorzystywany także do obli-
czania skrótu wiadomości
SHAModule
Moduł odpowiedzialny zarówno za wyliczanie skrótów wiadomości jak i spraw-
dzanie, czy przysłany wraz z wiadomością skrót jest zgodny ze skrótem wy-
generowanym. Działa z wykorzystaniem odpowiednich mechanizmów zarówno
tworzenia skrótów jak i sprawdzania ich poprawności (mechanizmy te są do-
stępne w bibliotece standardowej języka Java).
KeyLoader
Moduł używany w początkowej fazie działania aplikacji - służy do pobrania z
pamięci urządzenia klucza publicznego i przekazania go do CryptoManagera
w postaci ciągu bajtów.
Każda z części działa niezależnie od siebie (powiązane są tylko poprzez ich zarządza-
nie przez CryptoManager), dzięki czemu uzyskano łatwą wymienność modułów - nie
ma żadnych problemów z zamianą algorytmu szyfrowania symetrycznego czy funk-
cji wyliczającej skrót wiadomości - może się to odbywać bez naruszania pozostałych
elementów.
39
5.2.7 Diagram klas
Aplikacja tworzona na potrzeby niniejszej pracy dyplomowej stworzona została
w języku Java. Jest to język ściśle obiektowy, poszczególne części zapisywane są w
postaci klas. Dla niemal każdej klasy generowany jest osobny plik z kodem źródło-
wym (wyjątkiem są klasy prywatne, które mogą być umieszczone w tym samym
pliku co klasa publiczna). Pliki te grupowane są w pakiety, co umożliwia łatwiejsze
zarządzanie tworzoną implementacją.
W aplikacji zdecydowano się na podział na pakiety w zależności od celu i zastoso-
wania poszczególnych modułów. Wygenerowano 18 pakietów, zawierających łącznie
około 40 klas (liczba ta zmienia się w zależności od ilości serwisów, jakie generowane
są przez programistę). Stworzenie dodatkowej klasy, spełniającej pewne podstawoe
wymagania i działającej w określony sposób (opisany w załączniku) jest jednym
z warunków prawidłowej implementacji dodatkowego serwisu mierzacego wartości
urządzenia mobilnego.
W czasie tworzenia projektu wykorzystano wzorce projektowe. Są one imple-
mentowane, aby uelastycznić stworzoną aplikację a także umożliwić w przyszłości
innym programistom chcącym w przyszłości korzystać i rozwijać stworzony program
łatwiejsze wdrożenie się w schemat implementacji.
Najważniejszym i najpopularniejszym wzorcem, jaki został wykorzystany w
pracy jest Model-View-Controller [3]. Dzieli on projekt na trzy, jak najbardziej nie-
zależne od siebie części, których zadaniem jest współpraca w zakresie wizualizacji
danych (Widok, ang. View), trwałego ich przechowywania (Model) oraz zarządzania
transferem, komunikacją i współpracą pomiędzy poszczególnymi modułami (Kon-
troler, ang. Controller). Z uwagi na specyfikę systemu Android, gdzie wiele klas
uruchamianych jest albo poprzez zarejestrowanie ich jako oczekujących na różnego
rodzaju zdarzenia albo poprzez umieszczenie ich w specjalnych modułach zwanych
Intent, które same zajmują się uruchamianiem ich w odpowiednich momentach, na
diagramie nie jest widoczny ścisły podział na wspomniane trzy części.
Bardzo ważnym i szeroko wykorzystywanym wzorcem jest wzorzec projektowy
Singleton [3]. Służy on do umożliwienia dostępu do jednego, globalnego obiektu da-
nej klasy z poziomu całej aplikacji, bez konieczności tworzenia ich osobnych instancji.
Ma to istotne znaczenie w przypadku klas, które zawierają metody pomocniczne,
40
uruchamiane przez wiele różnych modułów i części aplikacji. W tworzonej pracy
przykładami wykorzystywania tego wzorca są moduły odpowiedzialne za trwały za-
pis danych. Oznacza to między innymi, że dwa różne instancje nie mogą jednocześnie
korzystać z zapisanych danych. Na przedstawionym poniżej diagramie klasy zreali-
zowane z wykorzystaniem wzorca Singleton opatrzone zostały stosowną adnotacją.
Innym wzorcem wykorzystywanym w tworzonej aplikacji jest Maszyna Stanowa
[3]. Wykorzystywany jest on przy zarządzaniu połączeniem z serwerem zewnętrznym.
Każdy stan, w jakim znajduje się urządzenie, reprezentuje inne dane, jakie zostaną
wysłane. Umożliwia także proste określenie, czy otrzymana z serwera odpowiedź
jest zgodna z oczekiwaną oraz co należy zrobić, w momencie otrzymania informacji
o upływie czasu oczekiwania.
Poniższy rysunek stworzony został z wykorzystaniem oprogramowania [37].
41
5.3 Protokół komunikacyjny
Jednym z wymagań stawianych tworzonemu systemowi jest jego uniwersalność.
Tworzona w ramach niniejszej pracy aplikacja mobilna jest tylko jednym z przykła-
dowych rozwiązań, jakie mogą korzystać z części stacjonarnej. Aby możliwe było
tworzenie różnych wersji modułów mobilnych (a także stacjonarnych, lecz zachowu-
jących się w sposób podobny do urządzeń mobilnych) bez konieczności reorganizacji
całego systemu, pojawiła się konieczność stworzenia protokołu komunikacyjnego.
Stanowi on zbiór reguł i zaleceń, ale także reprezentowany jest przez szczegółowy
algorytm opisujący, jak wygląda komunikacja pomiędzy częścią zainstalowaną na
telefonie czy tablecie a serwerem stacjonarnym. Protokół ten jest niezależny od
platformy, możliwa jest jego implementacja na większość platform sprzętowych -
jedynym ograniczeniem jest konieczność korzystania z ustandaryzowanych algoryt-
mów kryptograficznych.
Stworzony przez Krzysztofa Opasiaka [1] protokół zapewnia bezpieczeństwo
w zakresie przesyłania danych, różne opcje autoryzacji i weryfikacji użytkownika.
Wszystkie z tych elementów są wymienne, co powoduje, że mogą być tworzone różne
implementacje, które mogą zostać dodane do już działających wersji. Ogólny algo-
rytm protokołu komunikacyjnego:
• Nawiązanie połączenia i powitanie klienta przez serwer
• Wybór wersji protokołu przez klienta
• Wysłanie i potwierdzenie przez serwera identyfikatora klienta
• Wybór wersji algorytmu szyfrującego symetrycznego
• Przesłanie klucza algorytmu symetrycznego (w sposób szyfrowany)
• Wybór metody autoryzacji
• Autoryzacja klienta (na przykład z wykorzystaniem loginu i hasła)
• Rozpoczęcie transmisji logów
• Kontynuacja transmisji wraz z odsyłaniem potwierdzeń o już otrzymanych
danych
43
• Zakończenie komunikacji, rozłączenie
Ważną cechą algorytmu są wysyłane po niemal każdej wiadomości potwierdze-
nia, które umożliwiają weryfikację, czy dane zostały faktycznie dostarczone. Dzięki
temu możliwe jest ich usuwanie na urządzeniu mobilnym (ale dopiero w momencie
uzyskania informacji o ich prawidłowym odebraniu). Cała komunikacja zorganizo-
wana jest w formie sesji - po poprawnej weryfikacji użytkownika i jego autoryzacji
jest on oznaczony jako zaufany i przesyłane przez niego dane traktowane są jako bez-
pieczne. W dowolnym momencie, jeśli nastąpi przerwa w komunikacji lub nastąpi
zerwanie połączenia, sesja jest kończona i przy następnym połączeniu uruchamiana
jest ponownie.
44
6 Implementacja
6.1 Moduł pomiarowy
Głównym zadaniem aplikacji tworzonej na potrzeby niniejszej pracy inżynier-
skiej jest zbieranie danych o urządzeniu mobilnym. Monitorowane są różne usługi,
każdej z nich dedykowany jest osobny serwis, odpowiedzialny zarówno za przeprowa-
dzenie pomiaru jak i za zapis informacji w bazie danych. Wraz ze zdefiniowanym w
dalszej części modelem dostępu do danych umożliwiają one zarządzanie zmierzonymi
wartościami w łatwy sposób, zarówno pod względem ich zbierania jak i późniejszego
wysyłania na serwer zewnętrzny.
Podstawowym zadaniem serwisu jest przeprowadzenie pomiaru. Może być to
pomiar zarówno bezpośredni - wywołanie odpowiedniej funkcji systemu Android
czy przeprowadzenie pewnych obliczeń na podstawie dostarczonych danych - jak
i pośredni, czyli zbieranie informacji zbieranych w czasie działania urządzenia (na
przykład ilość połączeń wychodzących). Niezależnie od metody dane te powinny
zostać natychmiast zapisane w bazie danych, aby nie zakłócać działania danego
urządzenia (poprzez zbyt intensywne wykorzystywanie mocy procesora).
Serwisy zdefiniowane w powstającej aplikacji dzielą się na 2 kategorie - aktywne
i pasywne.
Serwisy aktywne mają za zadanie przede wszystkim przeprowadzenie pomiaru.
Czynność ta podejmowana jest w momencie, gdy dany serwis zostanie wywołany.
Tego rodzaju wywołania do swojego działania nie wykorzystują żadnych uprzed-
nio zebranych informacji, nie opierają się na danych zebranych przy poprzednich
wywołaniach ani nie zapisują żadnych wartości tymczasowo.
Serwisy pasywne działają na innej zasadzie. Poza obecnym także w serwisach
aktywnych etapem zapisu informacji do bazy danych nie przeprowadzają one po-
miaru w chwili swojego wywołania, lecz korzystają z informacji zbieranych przez
cały czas działania aplikacji. Każde działanie urządzenia mobilnego zarejestrowane
przez użytkownika (na przykład przychodzące wiadomości tekstowe) są rejestrowane
przez aplikację pod postacią licznika wystąpień całego zdarzenia. W momencie wy-
wołania serwisu pasywnego następuje pobranie tej wartości i zapis do bazy danych.
Następnie licznik jest zerowany i może być wykorzystany ponownie do zbierania
45
informacji.
Różnice implementacyjne pomiędzy dwoma rodzajami serwisów polegają na
konieczności stworzenia innych modeli zarówno gromadzenia jak i przetwarzania
danych. Ponieważ serwisy pasywne wymagają zapamiętywania dodatkowych infor-
macji, konieczne jest zdefiniowanie kilku dodatkowych rozwiązań umożliwiających
przechowywanie wartości tymczasowych.
Oba rodzaje serwisów są implementowane jako klasy. Wymaganiem stawianym
przez system jest, aby dziedziczyły one po klasie Service (android.app.Service).
Dzięki temu możliwe jest wywoływanie ich przez AlarmManager, który odpowiada
za cykliczne uruchamianie serwisów pomiarowych.
Całość obliczeń i pomiarów wykonywanych jest w metodzie onStartCommand().
Jest to metoda odziedziczona z klasy nadrzędnej, wywoływana przez AlarmManager.
Dzięki temu możliwe jest wywoływanie konkretnych serwisów niezależnie od siebie
a także nieobciążanie procesora poprzez aktywne oczekiwanie - uruchamianiem po-
miarów zajmuje się natywne narzędzie systemu Android.Przykładowa implementacja metody onStartCommand() dla serwisu odpowie-
dzialnego za zapis ilości działających aplikacji.
public int onStartCommand ( Intent intent , int f l a g s int ID) {
ActivityManager act iv i tyManager = ( ActivityManager )
this . getSystemServ ice (ACTIVITY_SERVICE) ;
L i s t<ActivityManager . RunningAppProcessInfo>
proc In f o s = act iv i tyManager . getRunningAppProcesses ( ) ;
MySQLLiteDataHelper . i n s e r t ( getAppl i cat ionContext ( ) ,
‘ ‘APPLICATION ’ ’ , p r o c In f o s . s i z e ( ) ) ;
s t o pS e l f ( ) ;
return Se rv i c e .START_NOT_STICKY;
}
Metody pobrania danych są różnego rodzaju. Niektóre sprowadzają się do pro-
stego wywołania metody języka Java (konkretnie jednej z jej bibliotek dedykowa-
nych dla systemu Android), inne wymagają skomplikowanych obliczeń (obliczanie
stopnia zajętości procesora). W zaprezentowanym powyżej przykładzie dotyczącym
ilości uruchomionych aplikacji pobranie oczekiwanych danych nie sprawia trudno-
ści - wywołanie odbywa się za pomocą ACTIVITY_SERVICE. Udostępnia on metodę
getRunningAppProcesses(), która zwraca ilość aktualnie uruchomionych aplikacji.
46
Następnie wartość ta zapisywana jest w bazie danych (opis zapisu umieszczony jest
w dalszej części pracy).
Istnieją jednak serwisy bardziej skomplikowane. Przykładem może być serwis
odpowiadający za pomiar obciążenia procesora w urządzeniu mobilnym. W tym
przypadku nie jest dostępna żadna możliwość bezpośredniego pobrania wartości,
konieczne staje się zatem odwołanie do narzędzi dostępnych w systemie Linux, na
którym opiera się Android. W implementacji konieczny stał się odczyt pliku syste-
mowego Linuxa o nazwie proc/stat. Przechowuje on informacje o tym, jak długo
system był w różnych trybach użytkowania (w tym także trybie idle, oznaczającym
bezczynność). Dodanie do siebie tych wartości (bez trybu idle) pozwala na osza-
cowanie całkowitej ilości czasu, w którym procesor wykonywał konkretne zadania.
Jednostką, w jakich urządzenie zwraca wartości. Są tak zwane jiffies - zazwyczaj
są to setne części sekundy. Zwracana informacja wyznacza jednak zużycie od czasu
włączenia procesora (czyli zazwyczaj od włączenia urządzenia mobilnego). Informa-
cja taka nie przedstawia wielkiej wartości, ponieważ wykorzystanie procesora jest
zmienne w czasie i wcześniejsze działania mogłyby wpływać na pomiar, który doty-
czy przede wszystkim aktualnego zużycia. Aby posiadać najświeższe dane, konieczne
jest zatem przeprowadzenie przynajmniej dwóch, następujących po sobie pomiarów
i odjęcie wartości nowszej od wartości starszej (ponieważ informacje są kumulowane
nie istnieje ryzyko otrzymania wartości mniejszej od zera). Ważne jest także, aby
przy pomiarach uwzględniać czas, w którym procesor wykonuje proces idle, czyli
jest w stanie bezczynności. Obliczenie służące do przypisania wartości do zmiennej
value odzwierciedla sposób, w jaki informacje te zostały zebrane w całość. Czas,
po jakim wykonany został pomiar (360 milisekund) jest kompromisem pomiędzy
koniecznością uniknięcia blokowania aplikacji a chęcią otrzymania znacząco różnych
wyników pomiarów tak, aby mogły być one reprezentatywne.Jeszcze inny sposób zdobycia informacji na temat urządzenia mobilnego przed-
stawia zdefiniowany przez autora aplikacji serwis odpowiedzialny za pomiar natę-żenia sygnału WiFi. Aby uzyskać dane, jakie sieci są dostępne oraz która z nichjest w danym miejscu i czasie najmocniejsza, konieczne jest zlecenie urządzeniu, abyprzeprowadził skan otoczenia i na jego podstawie przedstawił wyniki. Oznacza to, żenie jest możliwe zdefiniowanie tylko jednej klasy odpowiedzialnej za całość obliczeńi pomiarów. Konieczne jest zarejestrowanie obiektu odbierającego (ang. Receiver),który po zakończeniu skanowania zostanie poinformowany o wynikach i to z jego
47
poziomu możliwy jest zapis do bazy danych.
WifiManager w i f i = (WifiManager )
getSystemServ ice ( Context .WIFI_SERVICE) ;
ConnectivityManager connect iv i tyManager =
( ConnectivityManager )
getSystemServ ice ( Context .CONNECTIVITY_SERVICE) ;
i f ( connect iv i tyManager . getNetworkInfo (
ConnectivityManager .TYPE_WIFI)
. g e tS ta t e ( ) == NetworkInfo . State .CONNECTED) {
s i gna lRe c e i v e r = new SIGNALREADER( wi f i , t h i s ) ;
r e g i s t e rR e c e i v e r ( s i gna lRece i v e r , new I n t e n tF i l t e r (
WifiManager .SCAN_RESULTS_AVAILABLE_ACTION) ) ;
w i f i . s ta r tScan ( ) ;
} e l s e {
MySQLLiteDataHelper . i n s e r t ( getAppl i cat ionContext ( ) ,
"SIGNAL" , 0 ) ;
}
re turn Se rv i c e .START_NOT_STICKY;
Jak widać, w tej metodzie nie jest przeprowadzany pomiar. Dane są zapisy-
wane tylko w przypadku, gdy urządzenie zwraca informację, że moduł WiFi nie jest
włączony. Zgodnie ze specyfikacją oznacza to wpisanie wartości 0 do bazy danych.
Jeśli moduł WiFi jest włączony, wywoływana jest metoda startScan() serwisy
WIFI_SERVICE. Przeprowadza on skan i pomiar wszystkich widocznych z poziomu
urządzenia mobilnego sieci. Ponieważ działanie to nie jest natychmiastowe i wymaga
pewnego czasu na zakończenie, SIGNALSERVICE kończy swoje działanie, nie wstawia-
jąc żadnej wartości do bazy danych. Ta zostanie wstawiona przez Receiver, który
zostanie wywołany po zakończeniu pomiaru.Metoda onReceive() zdefiniowana w klasie SIGNALREADER (dziedziczącej po
klasie BroadcastReceiver.
pub l i c void onReceive ( Context context , In tent i n t en t ) {
Lis t<ScanResult> r e s u l t s = w i f i . ge tScanResu l t s ( ) ;
ScanResult b e s tS i gna l = nu l l ;
f o r ( ScanResult r e s u l t : r e s u l t s ) {
i f ( b e s tS i gna l == nu l l
| | WifiManager . compareSignalLeve l (
b e s tS i gna l . l e v e l ,
48
r e s u l t . l e v e l ) < 0)
be s tS i gna l = r e s u l t ;
}
MySQLLiteDataHelper . i n s e r t ( context , "SIGNAL" ,
−be s tS i gna l . l e v e l ) ;
parent . s t o pS e l f ( ) ;
}
Jak widać, możliwość pobrania informacji o dostępnych sieciach możliwa jest
dopiero po przeprowadzeniu skanu. Następnie następuje iteracja po wszystkich wi-
docznych sieciach i wybór najmocniejszej w danym momencie. Dopiero ta wartość
jest zapisywana do bazy danych.
Przedstawione przykłady pokazują, że sposób pobrania wartości informującej o
działaniu danego urządzenia może być bardzo różny i wymagać różnych podejść do
problemu. Z drugiej strony możliwa jest niemal nieograniczona rozbudowana algo-
rytmu pomiarowego - nie jest konieczne ograniczanie się tylko do jednej metody.
Jedynym ograniczeniem jest dostępność kontekstu aplikacji, który umożliwia wyko-
rzystanie metod dostępu do bazy danych.
Zupełnie inaczej prezentują się implementacje serwisów pasywnych. Jak już
wspomniano, nie przeprowadzają one pomiaru w momencie wywołania a jedynie
pobierają wartości zapisywane przez cały czas działania urządzenia.
W tym celu konieczne jest stworzenie przynajmniej 2 klas. Pierwsza z nich,
odpowiadająca za odnotowanie wydarzenia (na przykład odebranie wiadomości tek-
stowej) i tymczasowy zapis tej informacji oraz druga, pobierająca łączną liczbę wy-
stąpień i zapisująca ją w bazie danych.
Wszystkie klasy odpowiadające za serwisy pasywne dziedziczą po klasie Broadcast
Receiver, dzięki czemu mogą one reagować na wszelkiego rodzaju zdarzenia. Każde
zdarzenie generuje bowiem sygnał, który jest wysyłany rozgłoszeniowo (ang. broad-
cast). Aby możliwe było jednoznaczne związanie sygnału z serwisem nasłuchującym
(ang. listener), który ma go przechwycić konieczne jest zarejestrowanie odpowied-
niej klasy. Jest to możliwe za pomocą nazwy sygnału. Przykładowo, aby zdefiniować
klasę SMSREADER, której obiekty będą reagować na pojawienie się nowej wiadomości
tekstowej, należy zarejestrować ją jako oczekującą na sygnał:
android.provider.Telephony.SMS_RECEIVED
49
Możliwe jest zdefiniowanie klas nasłuchujących dla niemal wszystkich zdarzeń
występujących na urządzeniu mobilnym. Można do nich zaliczyć m.in. podłączenie
za pomocą kabla USB, włączenie trybu samolotowego lub wyłączenie urządzenia.
W momencie otrzymania informacji wywoływana jest metoda onReceive(), w
której dokonywana jest inkrementacja licznika wystąpień danego zdarzenia. W tym
celu wywoływana jest metoda update klasy SharedPreferencesProxy. Dzięki temu
aplikacja wie, gdzie zapisać daną wartość.
Można zauważyć, że przedstawione implementacje serwisów (zarówno aktyw-
nych jak i pasywnych) znacząco się od siebie różnią i często wymagają różnych po-
dejść do danej usługi. Powoduje to, że niemożliwe stało się stworzenie rozwiązania
szablonowego, konfigurowalnego, które umożliwiałoby szybkie dopisywanie nowych
serwisów przez programistę czy nawet przez użytkownika podczas działania aplika-
cji poprzez wpisanie nazwy usługi, którą chce monitorować. Minimalną ilością kodu,
jaki musi zostać napisany jest klasa spełniająca kilka podstawowych warunków w
zależności od rodzaju serwisu (aktywnego czy pasywnego). Opis konfiguracji przed-
stawiony został w dalszej części pracy.
6.2 Moduł gromadzenia i zapisywania danych
Głównym czynnikiem powodującym powstawanie niniejszej aplikacji są dane. To
one umożliwiają administratorom (a także użytkownikom) na zdobycie informacji
na temat stanu urządzenia mobilnego. Na ich podstawie mogą oni także podjąć
decyzję na przykład o konieczności wymiany telefonu, zmianie planu taryfowego lub
kupnie nowej baterii. Do tego celu potrzebne są cykliczne, powtarzalne informacje
zbierane przez urządzenie mobilne i przekazywane na serwer zewnętrzny. Ważne
jest, aby dane te pogrupowane były według odpowiednich, mierzonych wartości, tj.
aby każdy pomiar był jednoznacznie identyfikowany przez nazwę serwisu, którego
dotyczy.
Informacje gromadzone przez urządzenie zbierane są w bazie SQLite. Jak opi-
sano w rozdziale dotyczącym Modelu Danych, każdy serwis ma do dyspozycji wła-
sną tabelę, do której zapisuje dane. Tabele zapisywane są w przestrzeni aplikacji,
nie jest możliwe tworzenie ich niezależnie od kontekstu, na przykład w formie zapisu
na dysku.
50
Do zapisywania w bazie danych systemu Android bezpośrednio, bez konieczno-
ści ciągłego utrzymywania referencji do obiektu odpowiedzialnego za dostęp służy
klasa ContentProvider. Tworząc klasę dziedziczącą po niej otrzymano narzędzie,
które można wykorzystać do łatwego zarządzania dostępem do bazy danych. Jest
ono swego rodzaju pośrednikiem pomiędzy aplikacją a warstwą zajmującą się bez-
pośrednim dostępem do danych trwałych. Przesłaniając metody odpowiedzialne za
wstawianie, aktualizowanie lub usuwanie danych, a także za wykonywanie zapytań
możliwe jest dopasowanie działania do własnych potrzeb, z uwzględnieniem wyma-
gań zdefiniowanych przez twórcę aplikacji.
Stworzona na potrzeby niniejszej pracy klasa nosi nazwę MyContentProvider. Z
punktu widzenia tworzonej pracy dyplomowej najważniejszymi metodami są te od-
powiedzialne za wstawianie i usuwanie danych - ich aktualizacja w praktyce nie wy-
stępuje. Dla interfejsu użytkownika niezbędne jest także tworzenie zapytań Select,
zwracających dostępne w bazie dane.
Dostępnych do konkretnych wartości odbywa się za pomocą identyfikatorów
zasobów (ang. Uniform Resource Identifier, w skrócie URI). Umożliwiają one
szybkie dotarcie do wszystkich informacji zgromadzonych w bazie danych.
Same dane wstawiane do tabel istnieją w formie par klucz-wartość, gdzie klu-
czem jest nazwa kolumny, do której dana wartość powinna zostać wstawiona. Pary
te są zbierane w obiekcie klasy ContentValues, która następnie przebazywana jest
do odpowiedniej klasy odpowiedzialnej za bezpośrednie wstawianie do bazy danych.
Co ważne, nie ma konieczności ręcznego wstawiania identyfikatorów wierszy, wyko-
nywane jest to automatycznie przez system Android.
Możliwość konfiguracji metod dostępu do danych umożliwiła przeniesienie cię-
żaru dodawania danych takich jak stempel czasowy z użytkownika na aplikację. W
ciele metody insert (odpowiedzialnej za wstawianie danych do tabel)możliwe stało
się automatyczne dodawanie do obiektu klasy ContentValues informacji o czasie
wykonania pomiaru. Nie ma zatem konieczności tworzenia własnych, niekiedy dość
skomplikowanych metod otrzymywania aktualnego czasu. Z czasem związany jest
także problem synchronizacji i stref czasowych. Rozwiązanie przedstawiono w dal-
szej części pracy.
Drugą klasą niezbędną do zarządzania danymi jest SQLiteOpenHelper. Umoż-
51
liwia ona zarządzanie transakcjami a także wersjami bazy danych. Podobnie jest
w przypadku ContentProvider, programista tworzący aplikację powinien potrak-
tować ją jako klasę bazową dla własnej implementacji, która będzie odpowiedzialna
za tworzenie tabel. W tworzonej aplikacji nosi ona nazwę MySQLiteDataHelper.Zapytanie języka SQL, jakie wykorzystywane jest przy tworzeniu tabel umiesz-
czaniu ich w przestrzeni aplikacji parametryzowane jest nazwą serwisu, dla któregotworzona jest tabela:
St r ing TABLE_CREATE = " c r ea t e t ab l e " + "%s" + " ("
+ COLUMN_ID + " i n t e g e r primary key autoincrement , "
+ COLUMN_STATE + " text , " + " value "
+ " in t ege r , timestamp text ) ; " ;
Aktualizacja wersji bazy danych oznacza konieczność usunięcia wszystkich da-
nych (wraz z tabelami) i ponownego wywołania funkcji onCreate(). Jest ono jednak
wykorzystywane bardzo rzadko.
Klasa MySQLiteDataHelper dostarcza także metodę statyczną, będącą pośred-
nikiem pomiędzy serwisami a narzędziem ContentProvider. Stworzenie takiej me-
tody okazało się niezbędne w związku z chęcią maksymalnego uproszczenia operacji
umieszczania danych do bazy i umożliwienia użytkownikowi definiowana jedynie kon-
kretnych wartości, bez konieczności zajmowania się stemplem czasowym lub pozio-
mem ostrzeżeń. Metoda ta odpowiada za stworzenie obiektu klasy ContentValues,
wstawienie do niego informacji o poziomie ostrzeżenia systemu Icinga oraz przekaza-
nie informacji do ContentProvider, które zajmie się dodaniem stempla czasowego
oraz bezpośredni zapis w bazie danych.Ważnym elementem tego procesu, wykorzystującym korzyści płynące ze zdefi-
niowana własnego narzędzia typu ContentProvider jest sposób jego wywoływania:
context . getContentReso lver ( ) . i n s e r t (MyContentProvider .
getUr i ( s e r v i c e ) , va lue s ) ;
Zapis ten uniezależnia twórcę aplikacji od posiadania referencji do obiektu od-
powiedzialnego za zarządzanie bazą danych poprzez rejestrację jednego, globalnego
obiektu, dostępnego za pomocą wywołania content.getContentResolver().
52
6.3 Moduł danych tymczasowych
Baza danych SQLite nie jest jedynym sposobem na zapis informacji w systemach
Android. Nie zawsze dane, jakie programista chce zapisać nadają się do umieszczania
ich w tabelach. Mogą to być na przykład ustawienia, konfiguracje czy inne informa-
cje, które można zapisać za pomocą par klucz-wartość. Pary takie są nieefektywnie
przechowywane w bazie danych, która musiałaby utworzyć osobną tabelę dla każdej
pary (biorąc pod uwagę, że wartość może być różnych typów, nie tylko tekstowych).
Inny przykładem wartości, która na pewno nie powinna być przechowywana w ba-
zie danych są różnego rodzaju hasła. Dostęp do nich powinien być z oczywistych
względów ograniczony do aplikacji, która odpowiada za zarządzanie nimi.
Rozwiązaniem opisanych problemów w systemach Android jest model Shared-
Preferences. Jest to interfejs służący do zapisywania w sposób trwały danych prze-
chowywanych w parach klucz-wartość. Umożliwia zapis różnych typów informacji
opartych na typach prostych w języku Java - int,boolean,String,long,float.
Dane wykorzystywane przez model SharedPreferences przechowywane są w pliku
znajdującym się w przestrzeni danych aplikacji (co chroni przed niepowołanym do-
stępem na przykład do haseł użytkownika). Dostęp do tego pliku domyślnie nie jest
możliwy z przestrzeni innych aplikacji umieszczonych na urządzeniu mobilnym. Aby
dane były chronione, ich tworzenie powinno odbywać się z wykorzystaniem trybu
Activity.MODE_PRIVATE. Dzięki temu dostęp do pliku będzie możliwy tylko z po-
ziomu aplikacji, która posiada dane.
Plików przechowujących dane SharedPreferences może być kilka. Dostęp do
czytania danych jest bezpośredni, wykorzystywane są w tym celu metody o na-
zwie preferences.getXXX(nazwa,wartość_domyślna). Wartość domyślna zwra-
cana jest w momencie, gdy w danym pliku nie ma zapisanych żadnych informacji na
temat zmiennej o danej nazwie lub jest ona innego typu niż oczekiwany. Dla danych
liczbowych jest to zazwyczaj wartość 0, dla znaków ciąg pusty ” ’.
Zapis informacji lub ich modyfikacja wymaga użycia obiektu pośredniczącego
SharedPreferences.Editor, który odpowiada za bezpieczeństwo wstawianych da-
nych. Jest także wykorzystywany przy synchronizacji w przypadku wielowątkowości.
Jego działanie zorganizowane jest na wzór transakcji bazodanowych, co powoduje,
że zapis do pliku nie jest realizowany natychmiast. Ma to miejsce dopiero po wywoła-
53
niu polecenia editor.commit(). Programista tworzący aplikacje może także cofnąć
ostatnio wprowadzone dane (analogicznie do obecnego w systemach bazodanowych
polecenia rollback).
W czasie tworzenia aplikacji mobilnej dostrzeżono, że dostęp do danych zawar-
tych w modelu SharedPreferences ma miejsce z różnych miejsc w aplikacji, zarówno
pośrednio, z poziomu interfejsu użytkownika jak i bezpośrednio, w momencie wy-
woływania serwisów pasywnych. Korzystanie z referencji przenoszonych pomiędzy
obiektami lub metodami mogłoby spowodować problemy związane z synchroniza-
cją oraz utrudnić działanie programistom chcącym rozbudować tworzoną aplikację.
Dodatkowo, nie z każdego miejsca w kodzie aplikacji dostęp taki byłby możliwy,
co tym bardziej utrudnia implementację. Konieczne stało się stworzenie pośrednika
(ang. proxy), który umożliwiałby poprawne zarządzanie znajdującymi się w plikach
danymi. Ważne było, aby metody były bezpieczne pod względem dostępu z wielu
wątków, ponieważ zapisane dane mogły być jednocześnie przetwarzane z różnych
miejsc w aplikacji. Dostęp do pośrednika powinien być oczywiście możliwy z każ-
dego miejsca w aplikacji.
Aby rozwiązać opisane problemy i zaradzić problemom z dostępem zdecydowano
się na stworzenie klasy SharedPreferencesProxy. Została ona stworzona za pomocą
wzorca projektowego Singleton, który gwarantuje istnienie tylko jednej instancji
klasy, synchronizację dostępu a także, za pomocą odpowiedniej metody statycznej,
dostęp z dowolnego miejsca w aplikacji.
Dane, jakie przechowywane są w modelu SharedPreferences (który zarządzany
jest przez SharedPreferencesProxy) to przede wszystkim informacje niezbędne do
prawidłowego działania aplikacji i jej komunikacji z serwisem zewnętrznym. Są to
między innymi:
• Login i hasło użytkownika
• Adres IP oraz port serwera zewnętrznego
• Nazwa urządzenia mobilnego (wykorzystywana przy komunikacji)
W modelu SharedPreferences przechowywane są także informacje na temattego, które z serwisów są aktualnie włączone. Jest to zaimplementowane na zasadzieprzechowywania wartości typu boolean, z kluczem odpowiadającym nazwie każdego
54
z serwisów. Dzięki temu możliwe jest łatwe i szybkie wstawianie i pobieranie warto-ści, co ma istotne znaczenie w przypadku zarówno przeprowadzania pomiarów jak iwizualizacji danych dla użytkownika. Także w SharedPreferences przechowywanesą tymczasowe liczniki wykorzystywane przez serwisy pasywne. Zapis informacji dotakiego licznika (na przykład w wyniku odebrania wiadomości SMS) polega na po-braniu dotychczasowej wartości zapisanej w SharedPreferences, zwiększeniu jej o1 i ponownym zapisie:
pub l i c void update ( f i n a l S t r ing s ) {
ed i t o r . putInt ( s + Ut i l s . number ,
p r e f e r e n c e s . g e t In t ( s +
Ut i l s . number , 0) + 1 ) ;
e d i t o r . commit ( ) ;
}
Wszystkie działania na obiekcie klasy SharedPreferencesProxy wykonywane
są z wykorzystaniem metody getInstance(), która zapewnia synchronizację przy
dostępie do poszczególnych metod, co skutkuje także synchronizacją na poziomie
dostępu do danych zapisanych w SharedPreferences.
Moduł SharedPreferencesProxy powstał jako uzupełnienie do zapisu danych
trwałych z wykorzystaniem systemu bazy danych. Jest on dużo prostszy niż korzy-
stanie z tabel relacyjnych, gwarantuje też szybszy dostęp do informacji. Co najważ-
niejsze, zapewnia wsparcie dla przechowywania danych w formacie klucz-wartość,
dzięki czemu możliwe stało się lepsze zarządzanie dostępem i przechowywaniem kry-
tycznych dla działania aplikacji wartości.
6.4 Moduł synchronizacji czasu
Jednym z elementów danych przesyłanych do serwera systemu Icinga jest stem-
pel czasowy. Jest on wykorzystywany do jednoznacznej identyfikacji pomiaru a także
umożliwia ich chronologiczne przetwarzanie. Każdy pomiar jest jednoznacznie wy-
znaczany przez 3 wartości - urządzenie, na którym jest wykonywany, serwis, któ-
rego dotyczy oraz stempel czasowy. Ważne jest zatem, aby dane dotyczące czasu
były jak najbardziej spójne. Problemem związanym ze spójnością są między innymi
strefy czasowe. Podczas podróżowania wraz z urządzeniem mobilnym użytkownik
może wielokrotnie przekraczać granice takich stref. Powoduje to, że na urządzeniu
(podłączonym do systemu GPS lub Internetu) aktualizowany jest czas dostępny na
55
urządzeniu. Korzystanie z tego czasu powoduje, że zmiany stref czasowych są odnoto-
wywane także w pomiarach przeprowadzanych przez aplikację. Może to powodować
błędy i braki w synchronizacji. Przykładowo, w przypadku użytkownika korzystają-
cego z aplikacji na pokładzie samolotu lecącego ze wschodu na zachód przekraczanie
stref czasowych oznacza, że godziny będą odejmowane, co spowoduje, że czas będzie
wirtualnie “cofany”. Jeśli zostanie on wykorzystany przy zapisach stempli czasowych,
dane zapisane wcześniej (na początku podróży) mogą zostać oznaczoneprzez stempel
jako późniejsze w stosunku do tych zapisanych w momencie lądowania. Powoduje
to brak synchronizacji pomiarów i niemożność korzystania z nich w zagadnieniach
statystycznych, na przykład przy określaniu tendencji pomiaru.
Rozwiązaniem tego problemu jest korzystanie z czasu zapisanego bezpośrednio
w środowiskach systemu Linux (który znajduje się na urządzeniach mobilnych z
systemem Android). Czas ten, nazywany “Unix time” [31], jest dostępny w postaci
sekund jakie upłynęły od północy 1 stycznia 1970 roku. Zapisany jest w postaci
32-bitowej zmiennej typu integer (całkowitoliczbowej). Dostępny jest on w środo-
wisku Android przez bezpośrednie wywołanie odpowiedniej metody. Jego główną
zaletą jest całkowita niezależność od stref czasowych. Czas mierzony w “Unix time”
jest czasem mierzonym według strefy Greenwich i wszelkie przekroczenia stref nie
modyfikują jego wartości. Dzięki temu nie występuje opisany wcześniej problem z
synchronizacją.
Powstaje jednak problem niedokładności pomiarów. Wyłączenie urządzenia, pro-
cesy mocno obciążające procesor lub niedokładność odmierzania czasu (związana ze
specyfiką systemów z podziałem czasu procesora) mogą powodować nieznaczne, kil-
kusekundowe odchylenia w pomiarach. Nie są one krytyczne w przypadku jednego
urządzenia (drobne przesunięcia czasowe nie powodowałyby błędów związanych z
chronologią), mogą mieć jednak znaczenie w przypadku porównywania danych z
różnych urządzeń mobilnych - na przykład przy okazji ustalania nowej taryfy dla
pracowników. Aby temu zapobiec, konieczne jest korzystanie z zewnętrznych serwi-
sów, które umożliwiają pobranie dokładnych danych na temat aktualnego czasu.
W aplikacji zdecydowano się korzystać z serwisów NTP, które są szeroko wy-
korzystywane przez twórców rozmaitych projektów wymagających dokładnej syn-
chronizacji czasowej. NTP oznacza Network Time Protocol (Internetowy Protokół
56
Czasowy). Czas wykorzystywany w tym protokole jest mierzony bardzo dokładnie,
za pomocą najnowocześniejszych narzędzi pomiarowych (między innymi cezowych
zegarów atomowych czy wzorców laserowych). Następnie zmierzony czas, w reakcji
na żądanie przysłane przez użytkownika, jest odsyłany wraz z kilkoma potrzebnymi
informacjami (takimi jak między innymi czas, przez jaki miał miejsce pomiar). Po
przeprowadzeniu stosownych obliczeń na urządzeniu, które wysłało żądanie możliwe
jest bardzo dokładne określenie różnicy pomiędzy czasem “faktycznym” (zmierzonym
przez dedykowane urządzenia) a czasem na urządzeniu mobilnym.
Aby przeprowadzić obliczenia, konieczne jest zapamiętanie aktualnego (w mo-
mencie wysłania żądania) stempla czasowego. Pakiet odesłany przez serwer NTP
zawiera informację na temat czasu odebrania żądania i czasu odpowiedzi na nie. Po
ponownym pomiarze czasu (tym razem w momencie odebrania odpowiedzi) nastę-
puje obliczenie różnicy pomiędzy serwerem NTP a urządzeniem:
(receiveT ime− originateT ime) + (transmitT ime− responseT ime)
2
gdzie [32]:
receiveTime czas odebrania żądania przez serwer NTP
originateTime czas wysłania żądania
transmitTime czas odebrania odpowiedzi z serwera NTP
responseTime czas wysłania odpowiedzi przez serwer NTP
Sam czas wysyłany jest w formie 64-bitowej liczby w formacie BigEndian, gdzie
pierwsze (bardziej znaczące cyfry) oznaczają czas z dokładnością do milisekund,
natomiast druga połowa oznacza czas ułamkowy. Na potrzeby niniejszej pracy wy-
korzystywane są tylko pierwsze 32 cyfry.
Po pobraniu danych z zewnętrznego serwera następuje korekcja czasu zapisa-
nego dla każdego z przeprowadzonych pomiarów. Do każdej z wartości zapisanej w
bazie danych dodawana jest (lub odejmowana) wartość będąca różnicą pomiędzy
czasem dostępnym na urządzeniu mobilnym a czasem zewnętrznym, synchronizu-
jącym. Dzięki temu możliwe jest dokładne porównanie informacji dostępnych na
różnych urządzeniach celem ich lepszej kontroli.
57
W przypadku, gdy w czasie działania aplikacji zostanie wykryty fakt błędnej
chronologii pomiarów, tj. czas pobrany dla kolejnego pomiaru będzie “starszy” (wcze-
śniejszy) niż dla pomiaru poprzedniego, odnotowywany jest błąd i wartość z ta-
kim, błędnie zapisanym stemplem czasowym nie jest zapisywana w bazie danych a
zatem także nie jest wysyłana do serwera zewnętrznego. Rozwiązanie to z jednej
strony może stanowić trudność w przypadku chociażby resetowania licznika czaso-
wego (dzieje się to jednak bardzo rzadko, po poważnych modyfikacjach w urządzeniu
lub w momencie instalowania nowego systemu), z drugiej stanowi wystarczające za-
bezpieczenie dla zachowania spójności przechowywanych i wysyłanych na serwer
zewnętrzny danych.
6.5 Moduł kryptograficzny i autoryzacja
Ważnym elementem protokołu komunikacyjnego jest bezpieczeństwo przesyła-
nych danych. Przesyłane pomiędzy użytkownikami są informacje takie jak wartość
przeprowadzonych pomiarów, dane autoryzacyjne czy nazwy serwisów odpowiedzial-
nych za zbieranie opisów schematu działania urządzenia mobilnego. Dane te powinny
być uznawane za dane czułe, wymagające zabezpieczenia. Dostęp do nich może być
pożądany przez osoby niepowołane, w przypadku danych w dużych korporacjach
mogą to być osoby związane z konkurecją lub osoby chcące osiągać korzyści finan-
sowe ze zdobytych informacji. Ważne jest zatem, aby dane były chronione w jak
najlepszy, dostępny dla twórców i użytkowników systemu sposób.
Podstawowymi metodami ochrony danych przesyłanych za pomocą protokołów
sieciowych jest ich szyfrowanie. Oznacza to ogół czynności mających na celu sprowa-
dzenie danych do takiej postaci, która z jednej strony może być poprawnie odczytana
przez autoryzowane osoby a z drugiej niemożliwe powinno być ich odczytanie przez
osoby pozostałe, niezaufane. Metody szyfrowania danych były używane już od cza-
sów starożytnych i wynaleziono ich wiele rodzajów. W ostatnich latach kilka z nich
zdobyło największą popularność i są szeroko wykorzystywane do wielu różnych za-
stosowań, zarówno komercyjnych jak i prywatnych. Zostały one wykorzystane także
w niniejszej pracy.
Najlepszym sposobem szyfrowania danych jest wykorzystywanie klucza syme-
trycznego. Jest to jeden klucz, o stałej długości, wykorzystywany zarówno do en-
58
krypcji jak i do dekryptażu wiadomości. Dzięki temu możliwa jest łatwa implemen-
tacja i zarządzanie procesem komunikacji. W niniejszej pracy do celów szyfrowania
symetrycznego wykorzystano algorytm AES. Został on opracowany i wdrożony na
początku XXI wieku i póki co nie doczekał się poprawnego i pełnego złamania.
Powoduje to pewność i bezpieczeństwo przesyłanych wiadomości.
Problem z szyfrowaniem symetrycznym pojawia się w momencie, w którym ist-
nieje konieczność przesłania lub rozdystrybuowania klucza symetrycznego. Zazwy-
czaj generowany jest on przez jedną ze stron i następnie rozsyłany jest do wszystkich
komunikujących się z nim węzłów. Jednak przesłanie klucza symetrycznego za wyko-
rzystaniem sieci Internet niesie ze sobą wysokie prawdopodobieństwo przechwycenia
takiej informacji. Ujawnienie klucza dyskwalifikuje cały system i wszystkie pozostałe
klienty także muszą zaprzestać jego używania. Pojawia się zatem konieczność zna-
lezienia sposobu poprawnego przesłania klucza symetrycznego.
Rozwiązaniem tego problemu jest wykorzystanie algorytmów szyfrowania asy-
metrycznego. Opiera się on na istnieniu dwóch kluczy - prywatnego oraz publicznego.
Klucz publiczny dostępny jest dla wszystkich osób, jego znajomość nie daje moż-
liwości rozszyfrowania wiadomości. Wiadomość zapisana z wykorzystaniem klucza
publicznego może być odszyfrowana tylko za pomocą klucza prywatnego, który jest
dostępny tylko dla osoby odczytującej dane (na przykład dla serwera, który udo-
stępnia klucz publiczny). Dzięki temu każdy z klientów, z wykorzystaniem udostęp-
nionego klucza publicznego szyfruje wygenerowany przez siebie klucz symetryczny i
przesyła go do serwera, który ustawia go jako obowiązujący w komunikacji z klien-
tem. W takiej sytuacji wszystkie dane są bezpieczne a klucze mogą zostać rozdy-
strybuowane w sposób bezpieczny dla obu stron, bez ryzyka podszycia się pod jedną
ze stron przez osoby niepowołane.
W tworzonej pracy zaimplementowano oba rodzaje szyfrowań - zarówno syme-
tryczne jak i asymetryczne. Wybraną do implementacji wersją komunikacji z wy-
korzystaniem kluczy publicznego i prywatnego jest RSA. Jest to wykorzystywany
na szeroką skalę algorytm asymetryczny, opierający swoje bezpieczeństwo na trud-
ności faktoryzacji dużych liczb pierwszych. Oba klucze w tworzonej implementacji
mają długość 1024 bitów. Dodatkowym zabezpieczeniem jest wykorzystanie OAEP -
Optical Asymmetric Encryption Padding [33], który dodaje element przypadko-
59
wości do tworzonego szyfru i co za tym idzie jeszcze bardziej utrudnia jakiekolwiek
jego złamanie. Współpraca obu algorytmów zapewnia bardzo wysoką i wysoce wy-
dajną ochronę przesyłanych danych bez ryzyka ich odszyfrowania w skończonym,
przewidywalnym czasie. W momencie pisania pracy (listopad 2013) nie są znane
potwierdzone i udokumentowane poprawne złamania szyfru RSA wraz z OAEP o dłu-
gości większej niż 768 bitów. Dzięki temu złamanie zaimplementowanego szyfru jest
bardzo mało prawdopodobne.
Wykorzystywanym algorytmem symetrycznym jest AES- Advanced Encryption
Standard [34]. Został on stworzony pod koniec XX wieku i jest obecnie najczęściej
i najchętniej wykorzystywanym narzędziem służącym do szyfrowania i deszyfrowa-
nia za pomocą tego samego klucza. Jest to algorytm blokowy, zaimplementowana
długość klucza to 128 bitów, co powoduje szyfrowanie danych podzielonych na 16-
bajtowe bloki. Zdecydowano się także na wykorzystanie trybu CBC, którego główną
cechą jest zależność wszystkich bloków od bloków je poprzedzających. Osiągane jest
to za pomocą dodawania modulo dwa tekstu jawnego każdego bloku z szyfrogra-
mem bloku poprzedniego i szyfrowanie tak powstałej porcji danych. Aby możliwe
było także zaszyfrowanie bloku pierwszego, niezbędne jest dostarczenie tzw. wek-
tora inicjalizującego, który następnie jest dodawany do tekstu jawnego pierwszego
bloku. Aby zachować spójność danych i umożliwić wielokrotne szyfrowanie i od-
czyt danych, niezbędne jest zapisywanie po każdej operacji kryptograficznej nowego
wektora inicjalizującego, którym staje się zawsze ostatni zaszyfrowany blok. Dzięki
temu zapewniona jest niepowtarzalność danych - taka sama porcja informacji za-
szyfrowana takim samym kluczem symetrycznym, ale na innym etapie komunikacji
(tj. z innym wektorem inicjalizującym) generuje zupełnie inny tekst zaszyfrowany.
Dzięki temu algorytm jest jeszcze odporniejszy na próby złamania.
Trzecim i ostatnim elementem komunikacji wykorzystującej szyfrowanie jest
spójność przekazywanych danych. Obie strony powinny mieć możliwość potwier-
dzenia poprawności otrzymanych danych i upewnienia się, że otrzymane informacje
nie zostały w żaden sposób zmodyfikowane lub nie została przesłana tylko ich część.
Aby to zapewnić, do każdej przesyłanej informacji (jeszcze przed jej zaszyfrowaniem)
dołączany jest skrót danych. Wykorzystywanym do tego celu algorytmem jest sze-
roko używany SHA-256 (numer oznacza długość w bitach, skrót ma 32 bajty). Skrót
60
taki z jednej strony gwarantuje pewność potwierdzenia prawidłowości danych (każda
wiadomość generuje zupełnie inny skrót) a z drugiej jednokierunkowość operacji -
nie jest możliwe na podstawie skrótu odzyskanie całej wiadomości. Zaszyfrowaniu
ulega zatem nie tylko przekazywana wiadomość, ale także jej skrót. Po odebraniu jej
przez drugą stronę ponownie generowany jest skrót wiadomości, który następnie jest
porównywany ze skrótem do niej dołączonym. W przypadku ich zgodności można
mówić o poprawnym przesłaniu danych, różnica pomiędzy nimi oznacza konieczność
retransmisji.
6.6 Protokół komunikacyjny
Głównym przeznaczeniem danych zebranych i przechowywanych tymczasowo
na urządzeniu mobilnym jest ich przesłanie do modułu stacjonarnego. Tam są one
przetworzone i przekazane dalej do systemu Icinga, dzięki czemu możliwa jest ich
wizualna reprezentacja oraz analiza. Po poprawnym ich otrzymaniu przez moduł
stacjonarny przekazuje on odpowiednią informację do urządzenia mobilnego, które
może usunąć tę porcję danych oraz rozpocząć procedurę przekazywania następnych.
Dzięki temu zapewniona jest trwałość danych (które zawsze są obecne albo w module
mobilnym albo w części stacjonarnej) oraz wydajność - dane nie są przechowywane
na urządzeniu mobilnym (które z natury ma dość ograniczoną pojemność), tylko
są kasowane w momencie umieszczenia ich w bezpiecznym miejscu na serwerze.
Protokół wymiany informacji pomiędzy częścią mobilną a stacjonarną odpowiada
za prawidłowy przesył.Komunikacja odbywa się z wykorzystaniem socketów. Jest to mechanizm ko-
munikacji pomiędzy różnymi hostami umożliwiający przesyłanie danych w postacistrumienia bajtów. Ponieważ jest on zaimplementowany w obu wykorzystywanychjęzykach programowania (C++ oraz Java) i jest mechanizmem stosunkowo prostym,został wybrany zamiast komunikacji z wykorzystaniem HTTP (która jest nieco mniejwydajna). Do przesyłania informacji za pomocą socketu wykorzystywana jest me-toda:
Socket . getOutputStream . wr i t e ( data , 0 , data . l ength ) ;
Pierwszym parametrem w powyższej metodzie są przesyłane bajty, drugim in-
deks początkowego bajtu oraz ilość bajtów, które mają zostać przesłane. Dzięki
komunikacji na poziomie bajtów nie pojawiają się problemy związane z systemem
61
kodowania czy reprezentacją obiektów typu String w różnych językach programo-
wania.
Algorytm komunikacji rozpoczyna się w momencie nawiązania połączenia inter-
netowego przez urządzenie mobilne. Informacja taka zostaje wysłana za pośrednic-
twem opisywanego wcześniej mechanizmu broadcastu, czyli sygnału przekazanego
do środowiska, że miało miejsce zdarzenie, w tym przypadku nawiązanie połącze-
nia z siecią WiFi. W tworzonej aplikacji za obsługę tego sygnału odpowiada klasa
WiFiReceiver. Pierwszym jej zadaniem jest pobranie informacji o rozbieżnościach
czasowych za pośrednictwem serwerów NTP. Wartość ta jest następnie wykorzy-
stywana do sprawdzania poprawności stempli czasowych i kolejności zapisanych w
bazie danych.
Kolejnym punktem algorytmu wysyłania danych mającym miejsce jeszcze przed
faktycznym nawiązaniem połączenia z modułem stacjonarnym jest cache’owanie
wartości z bazy danych. Celem tej czynności jest przyśpieszenie zdobywania porcji in-
formacji gotowych do wysłania i wydajniejsze nimi zarządzanie. Do DatabaseCache
zapisywane są wszystkie logi z tabeli o aktualnie największym rozmiarze. Następnie
w czasie wymiany informacji z serwerem zewnętrznym są one stopniowo pobierane i
usuwane z bazy w momencie otrzymania informacji o ich prawidłowym odebraniu.
Po wysłaniu wszystkich informacji z tabeli wybierana jest następna tabela z danymi
i to z niej pobierane są nowe wartości do cache’u. W momencie, gdy nie ma już
więcej danych do wysłania wysyłany jest komunikat o zakończeniu transmisji i cała
komunikacji kończy się.
W poniższej tabeli 3 przedstawiono wzorcową wymianę komunikatów pomiędzy
urządzeniem mobilnym a modułem stacjonarnym. Rozpoczyna się od nawiązania
komunikacji przez część mobilną a kończy odebraniem przez część stacjonarną in-
formacji o zakończeniu transmisji.
62
Moduł mobilny Moduł stacjonarny
Nawiązanie połączenia Wysłanie komunikatu HELLO po nawiązaniu po-
łączenia
Wybór wersji protokołu Wysłanie komunikatu ACK w przypadku wybra-
nia aktualnej wersji
Dalsza komunikacja odbywa się z wykorzystaniem szyfrowania asymetrycznego
Wysłanie ID klienta (do
uwierzytelnienia)
Wysłanie skrótu ID klienta oraz prośby o wybór
algorytmu
Wybór wersji algorytmu Komunikat ACK w przypadku akceptowalnej wer-
sji algorytmu
Dalsza komunikacja odbywa się z wykorzystaniem szyfrowania symetrycznego
Wysłanie klucza symetrycz-
nego
Odbiór klucza symetrycznego i wysłanie prośby o
wybór modułu autoryzacji
Wybór metody autoryzacji
(domyślnie login+hasło)
Akceptacja metody autoryzacji, wysłanie prośby o
login
Wysłanie loginu Odbiór i weryfikacja loginu, wysłanie prośby o ha-
sło
Wysłanie hasła Odbiór i weryfikacja hasła, oczekiwanie na logi
Wysłanie pierwszej porcji
logów
Odbiór porcji logów i wysłanie potwierdzenia
... ...
Wysłanie ostatniej porcji lo-
gów
Odbior porcji logów i wysłanie potwierdzenia
Zakończenie transmisji Zamknięcie połączenia
Tablica 3: Protokół komunikacyjny
Każdy z komunikatów ma zdefiniowany czas, po którym należy uznać, że druga
strona nie odpowiada i komunikacja powinna zostać zakończona. Jest to Timeout,
jest on różny w zależności od komunikatu - zazwyczaj wynosi 2 sekundy. W przy-
padku zerwania połączenia utworzona sesja (charakteryzowana przez wykorzysty-
wany klucz symetryczny) kończy się i połączenie nie jest wznawianie aż do momentu
63
otrzymania kolejnego sygnału o połączeniu z siecią WiFi, kiedy to ma miejsce po-
nowna próba nawiązania komunikacji.
Struktura komunikatów różni się w zależności od etapu, w którym dany komu-
nikat występuje. Etapy komunikacji są 3: etap początkowy, gdy komunikacja jest
nieszyfrowana, etap wykorzystujący szyfrowanie asymetryczne i etap ostatni, naj-
dłuższy, wykorzystujący szyfrowanie symetryczne.
W pierwszym etapie komunikat jest podzielony na komórkę oznaczającą jego
długość oraz dane:
< długość komunikatu >< kod komunikatu >< komunikat >
Dodatkowe informacje nie są wymagane, bowiem w początkowym etapie komu-
nikacji nie istnieje ryzyko wysłania danych, których nieprawidłowe odebranie może
skutkować naruszeniem bezpieczeństwa.
W drugim etapie komunikacji dane szyfrowane są z wykorzystaniem klucza pu-
blicznego serwera (ze strony klienta). Wtedy struktura komunikacji jest analogiczna
jak w części pierwszej - z tą różnicą, że zarówno kod komunikatu jak i sam komunikat
są zaszyfrowane kluczem publicznym serwera.
Trzeci etap komunikacji zawiera przekazywanie najważniejszych danych - nazwy
hosta, nazwy użytkownika, hasła oraz samych logów, zatem dbałość o jego bezpie-
czeństwo jest jak największa. Struktura komunikatu jest następująca:
< długość >< długość skrótu >< kod komunikatu >< dane >< skrót danych >
Szyfrowaniem symetrycznym objęty jest cały komunikat z wyłączeniem pierw-
szego bloku, służącego do pobrania długości całej wiadomości. Długość pierwszego
bloku jest stała (dla każdego etapu) i wynosi 4 bajty - na nich zapisana jest (w
konwencji BIG ENDIAN) długość pozostałych, zaszyfrowanych danych.
Do tworzenia i przetwarzania komunikatów stworzono klasy MessageFormer i
MessageDecrypter. Są one wykorzystywane przez klasy realizujące wzorzec projek-
towy Maszyny Stanowej do podtrzymywania i monitorowania komunikacji sieciowej.
Umożliwiło to lepsze i wydajniejsze zarządzanie kodem aplikacji a także stworzenie
osobnego modułu (w rozumieniu hierarchii klas) komunikacyjnego, który może zo-
stać bez przeszkód wymieniony na inny w przypadku zmiany całości protokołu.
64
Komunikacja z modułem stacjonarnym odbywa się z wykorzystaniem dodatko-
wego, częściowo niezależnego od głównego wątku aplikacji. Jest to także wymaganie
narzucone przez API systemu Android - komunikacja sieciowa nie może być wyko-
nywana w głównym wątku. Zabezpieczenie to jest spowodowane chęcią uniknięcia
sytuacji, w której program przestaje być reaktywny dla użytkownika z powodu ocze-
kiwania na wynik komunikacji sieciowej (która ze swojej natury jest zawodna lub o
zmiennym czasie trwania).
6.7 Warstwa prezentacji
Opisywane do tej pory moduły aplikacji są ukryte przed użytkownikiem z niej
korzystającym. Nie jest on w żaden sposób informowany o zapisie do bazy danych,
okresowym uruchomieniu serwisu czy poprawnym wysłaniu danych. Są to czyn-
ności od niego niezależne. Powstała jednakże konieczność stworzenia odpowiedniej
warstwy graficznej, która umożliwiałaby łatwą konfigurację i podgląd wyników po-
miarów. Dodatkowo, przejrzysty układ graficzny jest jednym z głównych czyników
decydujących o sukcesie lub porażce danej aplikacji.
Dla celów niniejszej pracy zdecydowano się na wyodrębnienie kilku funkcjonalno-
ści, z których każda posiada osobny ekran umożliwiający wprowadzanie modyfikacji
konfiguracyjnych czy podgląd wyników pomiarów. Są to:
Wybór serwisów
Umożliwia wybór, które z serwisów i z jakim interwałem czasowym mają zostać
uruchomione. Ustawienia odbywają się za pomocą dostępnych w bibliotece
systemu Android tzw. przełączników (ang. switch).
Podgląd wyników pomiarów
Prezentacja (dla każdego z pomiarów z osobna) wyników pomiarów nieprzesła-
nych jeszcze na serwer. Dostępne są informacje na temat zmierzonej wartości,
stempla czasowego oraz poziomu ostrzeżeń systemu Icinga. Umieszczony został
także guzik umożliwiający (w czasie podłączenia do Internetu) natychmiasto-
wego wysłania danych.
Konfiguracja zgodności z Icingą
Stawianie wartości granicznych dla sytuacji - alarmowej oraz krytycznej w
65
formacie zgodnym z zasadami Passive Checks w systemie Icinga.
Konfiguracja połączenia sieciowego
Ustawienie opcji takich jak IP serwera czy port na których nasłuchuje, ale
także loginu i hasła użytkownika.
Dostęp do każdego z ekranów dostępny jest z poziomu menu głównego. W nim
także dostępne są opcje włączenia wszystkich zainstalowanych serwisów (z domyśl-
nym interwałem czasowym - 30 minut), wyłączenie wszystkich aktualnych urucho-
mionych serwisów a także powrót do podstawowego okna systemowego.
Dostęp do guzików umożliwiających zarówno uruchomienie wszystkich serwi-
sów jak i przejście do ekranu wyboru poszczególnych pomiarów nie jest możliwe
bez uprzedniej konfiguracji przeprowadzonej w części “Konfiguracja połączenia sie-
ciowego”. Dzięki temu w momencie nawiązania połączenia z siecią WiFi nie ma
konieczności pytania użytkownika o dodatkowe dane, całość wymiany informacji
odbywa się niezależnie od jego wiedzy.
Warstwa graficzna (głównie, jeśli chodzi o tabelaryczną prezentację wyników po-
miarów) została dopasowana do różnych rozmiarów urządzeń, na których aplikacja
jest wyświetlana. Zadbano także o poprawną obsługę przekręcenia urządzenia mo-
bilnego z pionu do poziomu (co oznacza w przypadku systemu Android konieczność
zmiany orientacji poszczególnych elementów składowych warstwy prezentacji).
Rysunek 4: Przykładowe ekrany stworzonej aplikacji - ekran głowny, ekran wyboru
serwisów oraz ekran prezentacji rezultatów
66
7 Testy
Testy przeprowadzane w celu sprawdzenia poprawności działania stworzonej
aplikacji obejmują dwa podstawowe działania - poprawność zbierania i zapisywa-
nia pomiarów oraz prawidłowe ich przesyłanie na serwer zewnętrzny. Pierwsza część
jest bezpośrednio związania z działaniem aplikacji, druga jest także związania z
prawidłową komunikacją z serwerem zewnętrznym oraz poprawnością konfiguracji
systemu Icinga.
Jako reprezentatywne do zaprezentowania schematu działania wybrano 2 ser-
wisy najwcześniej zaimplementowane w tworzonej aplikacji: stan baterii oraz moc
sygnału WiFi. Prawdopodobne jest, że to te dwa serwisy będą najczęściej i najchęt-
niej wykorzystywane przez ewentualnych użytkowników.
Testy poprawności działania stworzonej aplikacji wykonywano na urządzeniach
Samsung Galaxy S2 (I-9100 - wersja systemu Android - 4.1.2) oraz Samsung Ga-
laxy Note 3 (wersja systemu Android - 4.4). Poniższe wykresy pochodzą z systemu
monitorowania Icinga, do którego trafiają wszystkie zebrane, przetworzone i prze-
analizowane dane z urządzenia mobilnego [1]. Przeprowadzone testy wykonane zo-
stały na przestrzeni kilku dni, dzięki czemu możliwe było zaobserwowanie trendów w
zachowaniu poszczególnych serwisów. Zauważono (w przypadku serwisu mierzącego
poziom baterii) systematyczny spadek wartości aż do poziomu 8
Rysunek 5: Wyniki pomiarów stanu baterii na urządzeniu Samsung Galaxy S2 w
dniach 24-26 stycznia 2014
W przypadku serwisu mierzącego natężenie sieci WiFi wykres przedstawia się
67
nieco inaczej. Nie występują tu różnego rodzaju tendencje ani systematyczne spadki,
jak w przypadku stanu baterii. Natężenie sygnału WiFi zależy najczęściej od jakości
punktu dostępowego (na przykład routera) oraz odległości od niego. Na wykresie
widoczny są momenty, w których urządzenie znajdowało się w miejscu publicznym,
na świeżym powietrzu, gdzie nie było dostępu do żadnego punktu dostępowego. Co
za tym idzie - wartość sygnału WiFi wynosi 0.
Rysunek 6: Wyniki pomiarów natężenia sieci WiFi w dniach 24-26 stycznia 2014
W celu analizy wydajności urządzenia mobilnego zdecydowano się na przepro-
wadzenie testów o większej częstotliwości, aby móć określić zależności pomiędzy wy-
korzystywaniem urządzenia mobilnego a wynikami pomiarów. Na poniższych wykre-
sach przedstawiono wyniki pomiarów stanu baterii oraz ilości uruchomionych apli-
kacji w czasie pomiarów dokonywanych z interwałem czasowym równym 5 minut. W
godzinach 16:00 - 18:00 urządzenie nie było używane, od godziny 18:00 przez najbliż-
sze 2 godziny intensywnie wykorzystywano możliwości procesora (włączone usługi
takie jak Internet, Bluetooth, przeszukiwanie GPS, największa jasność ekranu). Na-
stępnie, od godziny 20:00 do końca pomiaru (około godziny 22:30) urządzenie było
wykorzystywane jako centrum rozrywki, do słuchania muzyki oraz oglądania filmu
w standardowej jakości.
Jak można zauważyć, w czasie nieużytkowania systemu (pierwszy okres) stan
baterii niemal nie ulegał zmianie. Świadczy to o bardzo małym zużyciu baterii
w momencie wygaszenia ekranu. Z obserwacji wynika bowiem, że zaobserwowany
w ostatnich latach znaczący spadek żywotności baterii w nowoczesnych telefonach
spowodowany jest głównie przez dużo większe niż wcześniej wyświetlacze generujące
68
Rysunek 7: Wykres stanu baterii w dniu 27 stycznia 2014 w godzinach 16:00-22:00
Rysunek 8: Wykres ilości uruchomionych aplikacji w dniu 27 stycznia 2014 w godzi-
nach 16:00-22:00
znacznie większy pobór energii. Uzyskało to odzwierciedlenie w pomiarach.
W drugim okresie użytkowania zaobserwowano znaczący wzrost tempa zuży-
cia baterii. Włączenie dodatkowych usług, jak Internet (w postaci filmu w serwisie
YouTube), Bluetooth (przesyłanie pliku o rozmiarze 380 MB z komputera na urzą-
dzenie mobilne) czy maksymalna jasność ekranu znacząco wpłynęły na baterię, która
zaczęła się w dość szybkim tempie zużywać - zanotowano w ciągu 2 godzin spadek
rzędu 30 punktów procentowych. Prowadzi to do wniosku, że w przypadku dłuższego
tego rodzaju użytkownia urządzenia zainstalowana w nim bateria wystarczyłaby
najwyżej na 5-6 godzin. Informacja ta może mieć istotne znaczenie dla użytkowni-
ków często korzystających z sieci (łączących się za pomocą VPN czy używających
intensywnie poczty).
W etapie trzecim (wyłączone opcje telekomunikacyjne, urządzenie wykorzysty-
wane do słuchania muzyki oraz oglądania materiałów video) można zaobserwować
spadek poziomu baterii o tempie będącym swego rodzaju średnią pomiędzy poprzed-
69
nimi dwoma etapami - poziom spada znacząco szybciej niż w przypadku pozostawie-
nia urządzenia z wygaszonym ekranem (co jest naturalnym zachowaniem), jednak
wolniej niż w przypadku korzystania z transmisji danych. Prowadzi to do wniosku,
że korzystanie z sieci (WiFi, Bluetooth, GSM czy innych) jest czynnością bardziej
obciążającą baterię niż prezentowanie multimediów. Jest to niewątpliwe związane
z faktem, że w czasie korzystania z sieci WiFi urządzenie cały czas przeszukuje
otoczenie w poszukiwaniu najlepszych sieci, GPS natomiast stara się połączyć z
widocznymi satelitami. Oznacza to konieczność wykonania większej ilości operacji
(związanych z komunikacją) niż wyświetlanie obecnego w pamięci urządzenia filmu.
Świadczy to o tym, jak bardzo intensywnie wykorzystywane jest urządzenie mo-
bilne w czasie jakiejkolwiek komunikacji (także rozmowy telefonicznej) i jak duże
znaczenie mają zatem wszelkie metody kompresji danych.
Testowanie pozwoliło na zauważenie istotnych różnic w obu sprawdzanych wer-
sjach systemu operacyjnego Android. O ile w przypadku wersji 4.1.2 pomiary są wy-
konywane dokładnie o określonej godzinie, o tyle w przypadku wersji 4.4 posiadają
one większą nieregularność. Wynika to z wprowadzonej w nowszej wersji systemu
modyfikacji polegającej na łączeniu kilku wywołań AlarmManagera w jedno, aby za-
pewnić jak największą wydajność i jak najmniejsze zużycie baterii. Wprowadzenie
poprawek umożliwiających przeprowadzanie pomiarów dokładnie o czasie także w
najnowszych wersjach jest jednym z elementów, które mogą znaleźć się w przyszłych
wersjach aplikacji mobilnej.
Inną funkcjonalnością, która powinna znaleźć się w przyszłych wersjach tworzo-
nego systemu jest możliwość dodawania własnych notatek do wyników pomiarów aby
móc je następnie w lepszy i wydajniejszy sposób analizować. Notatki takie mogłyby
zawierać na przykład informacje na temat tego, w jaki sposób użytkowane było
urządzenie (rozmowa, oglądanie filmów, korzystanie z Internetu) i być powiązane
z konkretnymi pomiarami. Dzięki temu administrator po przejrzeniu tego rodzaju
informacji może wywnioskować, jakie czynności mają wpływ na różnego rodzaju
pomiary i zareagować w adekwatny sposób. Przykładowo, informacja “Spotkanie
biznesowe” powiązana z pomiarem obrazującym brak sygnału WiFi może prowadzić
do konkluzji, że w pomieszczeniu, w którym tego rodzaju spotkania odbywają się,
zasięg sieci WiFi może być zbyt słaby.
70
8 Podsumowanie
Stworzona w ramach niniejszej pracy inżynierskiej aplikacja mobilna wraz ze
współpracującym z nią modułem stacjonarnym umożliwia dużo lepsze poznanie
działania i aktywności takich urządzeń jak telefony czy tablety. Ponieważ są one
współcześnie bardzo szeroko wykorzystywane i używa ich znacząca część populacji
krajów rozwiniętych, umożliwienie monitorowania i gromadzenia zebranych danych
jest znaczącym ułatwieniem dla osób, które odpowiadają za infrastrukturę w firmach
czy innych instytucjach. Stworzona aplikacja może być wykorzystywana także przez
użytkowników prywatnych, chcących analizować wydatki związane z użytkowaniem
urządzenia mobilnego (na przykład poprzez liczbę wykonanych połączeń).
Tworzenie implementacji ukazało problemy, z jakimi muszą mierzyć się twórcy
różnego rodzaju aplikacji na urządzenia mobilne. Zwyczajowo mała pojemość ba-
terii (w stosunku do poboru mocy przez sprzęt) ogranicza możliwości wykorzysta-
nia skomplikowanych algorytmów i narzuca konieczność szukania jak największych
oszczędności w zakresie użytkowania dostępnych zasobów. Uniemożliwia to wykony-
wanie skomplikowanych obliczeń a także przechowywanie znaczących ilości danych.
Z tych powodów łączność z modułem stacjonarnym (gdzie ograniczenia, zarówno wy-
dajnościowe jak i pamięciowe, są dużo mniejsze) stała się znaczącym ułatwieniem
w tworzeniu modułu mobilnego. Dzięki temu zbierane dane zostają na urządzeniu
tylko do momentu ich poprawnego odebrania przez serwer.
Innym problemem, z jakim zetknięto się w czasie tworzenia pracy, były trudności
związane z dostosowaniem dostępnych w różnych językach programowania modułów
kryptograficznych. Algorytmy operujące na pojedynczych bajtach są często trudne
do poprawnego skonfigurowania, wymagają także od programisty dużej uwagi przy
doborze rozwiązań, które zastosowane są w modułach zarówno po stronie nadaw-
czej jak i odbiorczej. Powoduje to konieczność uzyskania pewnych kompromisów
pomiędzy dostępnością możliwości a chęcią jak najpełniejszego zabezpieczenia prze-
syłanych przez sieć danych.
Tym, co odróżnia stworzoną aplikację od innych dostępnych na rynku rozwiązań,
jest możliwość gromadzenia danych także lokalnie, bez nadpisywania starych war-
tości przez wynik aktualnego pomiaru. Obecność w pamięci danych historycznych
pozwala na dużo lepszą analizę poszczególnych usług. Umożliwia także nieprzesyła-
71
nie (w momencie nawiązania połączenia z siecią) wyników pojedynczych pomiarów
(co byłoby mało wydajne), zamiast tego przekazywać można całe pakiety logów z
informacjami.
Aplikacja w obecnej postaci jest gotowa do wykorzystywania na urządzeniach
mobilnych z systemem Android. Możliwości jej rozbudowy są ogromne, niemal każda
usługa może być monitorowana - warunkiem jest stworzenie odpowiedniego modułu
i modyfikacje w odpowiednich plikach konfiguracyjnych. Łatwość w dodawaniu do-
datkowych opcji (sposób opisany został w załączniku A) wymusiła jak największe
uproszczenie algorytmów zbierania danych i ich przechowywania - efektem jest jed-
nak duża generyczność zastosowanego rozwiązania.
Rozwój urządzeń mobilnych powoduje, że w najbliższych latach pojawią się
różne usługi, których działanie powinno być monitorowane, a których nie sposób
było przewidzieć w czasie tworzenia niniejszej pracy. Konfigurowalność rozwiązania
powoduje jednak, że aplikacja będzie mogła uzwględniać te zmiany i służyć użyt-
kownikowi także w przyszłości. Stanowić zatem powinna ciekawą alternatywę dla
ręcznego sprawdzania stanu rozmaitych parametrów systemowych i ułatwić zarzą-
dzanie możliwościami, jakie dają urządzenia mobilne.
72
A Załącznik A - opis aplikacji
Stworzony moduł mobilny dostępny jest jako aplikacja na system Android. In-
stalacja programu odbywa się poprzez zainstalowanie pliku z rozszerzeniem .apk
- plik ten może zostać zarówno skopiowany bezpośrednio do pamięci telefonu jak
i pobrany z Internetu. Po uruchomieniu pliku pojawi się informacja o wszystkich
uprawnieniach, jakich wymaga aplikacja do prawidłowego działania. Poprawne zain-
stalowanie aplikacji spowoduje stworzenie katalogu DataCollector. Do niego należy
skopiować plik zawierający klucz publiczny dostarczany przez serwer. Plik ten może
mieć dowolną nazwę. Włączenie programu DataCollector spowoduje pokazanie się
na ekranie menu startowego, w którym można dokonać różnego rodzaju operacje.
Rysunek 9: Ekran główny aplikacji
Poszczególne elementy menu służą do:
Start
Uruchomienie wszystkich zdefiniowanych serwisów (z domyślnym interwałem
czasowym - 30 minut).
Stop
Zatrzymanie wszystkich uruchomionych serwisów.
Choose
Przejście do ekranu wyboru serwisów do uruchomienia oraz interwałów czaso-
wych, z jakimi będą uruchamiane.
73
Show results
Przejście do ekranu prezentacji wyników dotychczasowych pomiarów (nieprze-
słanych jeszcze na serwer zewnętrzny). Dane prezentowane są w postaci tabela-
rycznej, z podziałem na poszczególne serwisy. Dostępny jest także (na ekranie
z wynikami) guzik Send all data, który może być wykorzystywany w mo-
mencie, gdy użytkownik jest cały czas podłączony do Internetu i chce w danej
chwili przesłać dane na serwer zewnętrzny.
Icinga Configuration
Wybór poziomów ostrzeżeń - warning i critical, jakimi opatrzone są poszcze-
gólne pomiary. Obecność tego rodzaju wartości jest warunkiem zdefiniowanym
przez system Icinga. Dla każdego serwisu powinny być zdefiniowane oddzielne
wartości.
Network Configuration
Ekran pozwalający na wybór ustawień sieciowych takich jak adres IP i port
modułu odbiorczego, nazwę hosta, login i hasło czy ilość logów, jaka przesy-
łana jest w pojedynczej paczce. Konfiguracja ta jest niezbędna do rozpoczęcia
przeprowadzania pomiarów. (Aktualnie moduł odbiorczy korzysta z adresu
178.235.203.163, nasłuchuje na porcie 8888. Bardziej szczegółowe informacje
można uzyskać w [1]).
Exit
Wyjście z aplikacji - nie powoduje wyłączenia aktywnych serwisów pomiaro-
wych.
Serwisy pomiarowe działają zarówno po wyłączeniu aplikacji jak i po ponownym
uruchomieniu urządzenia mobilnego. Komunikacja z modułem odbiorczym odbywa
się automatycznie, możliwe jest także ręczne wywołanie połączenia za pomocą guzika
Send all data dostępnego na ekranie z wynikami pomiarów.
W katalogu DataCollector tworzony jest także dodatkowy podkatalog /logs,
gdzie dostępne są wszystkie logi z pracy aplikacji - można tam znaleźć informacje o
dacie wykonania pomiaru, stanie połączenia z modułem odbiorczym czy ewentualne
informacje o błędach.
74
B Załącznik B - dodawanie nowych serwisów
Jednym z głównym założeń dotyczących aplikacji mobilnej tworzonej w ramach
niniejszej pracy dyplomowej była jej łatwa konfigurowalność. Obecnie, gdy urządze-
nia mobilne (zarówno telefony jak i tablety) rozwijają się w dużym tempie i niemal
co roku wdrażane są nowe rozwiązania i technologie, wartym uwagi zagadnieniem
stała się elastyczność różnego rodzaju rozwiązań. Wszystkie tworzone w ostatnim
czasie systemy jako jeden ze swoich głównych celów stawiają skalowalność rozwiązań
i możliwość dopasowania ich do dynamicznie zmieniających się trendów na rynku.
Dlatego też ważne jest, aby w aplikacji możliwe było dodawanie nowych serwisów
tak, aby nie wpływać znacząco na jej działanie i nie powodować zbyt daleko idących
modyfikacji w już istniejącym kodzie.
Najlepszym z punktu widzenia użytkowników rozwiązaniem byłaby możliwość
konfiguracji nowych serwisów bezpośrednio, z poziomu samej aplikacji. Wtedy czyn-
ność taką mógłby wykonać niemal każdy użytkownik, także ten nieznający szczegó-
łów implementacji ani zagadnień związanych ze specyfiką tworzenia oprogramowania
na platformę Android. Byłoby to też rozwiązanie najbardziej wolne od błędów i naj-
bardziej skalowalne.
Niestety, z uwagi na charakterystykę zasad, jakie muszą spełniać tworzone dla
systemu Android aplikacje rozwiązanie takie jest niemożliwe do implementacji. Zwią-
zane jest to przede wszystkim z faktem, że wszystkie informacje i wszystkie klasy
języka Java muszą być znane już w momencie przekształcania kodu do postaci zro-
zumiałej przez platformę Android oraz maszyny wirtualnej Dalvik. Ma to miejsce
tuż po zakończeniu działania w środowisku Eclipse i przesłaniu stworzonej aplikacji
na urządzenie mobilne. Wszelkie dalsze modyfikacje są już niemożliwe.
Ważnym czynnikiem ograniczającym możliwości swobodnej implementacji jest
różny sposób pobierania danych - jak zostało to opisane w części dotyczącej serwisów.
Nie jest możliwe stworzenie generycznego szablonu pobierania danych, gdzie jedyną
pracą wykonaną przez programistę jest wstawienie nazwy wartości, która ma być
mierzona. Jak wspomniano, niektóre z serwisów korzystają z prostego wywołania
metody, inne wymagają wielu skomplikowanych obliczeń, inne jeszcze korzystają
z operacji wymagających zarejestrowania dodatkowych modułów. Powoduje to, że
każdy pomiar znacząco się od siebie różni i każdy wymaga indywidualnego podejścia.
75
Ostatnim z powodów, dla których tworzenie nowych modułów aplikacji stanowi
wyzwanie, są informacje potrzebne do zarejestrowania serwisów pasywnych. Jak opi-
sano wcześniej, korzystają one z możliwości, jakie oferuje system Android w zakresie
reagowania na różne, mające miejsce w systemie wydarzenia. W przykładowej im-
plementacji zdecydowano się na wykorzystanie sygnałów wysyłanych w momencie
odebrania wiadomości SMS a także wykonania lub odebrania rozmowy telefonicz-
nej. Każda z tych sytuacji jest odnotowywana przez specjalnie zdefiniowany w tym
celu serwis. Aby zatem stworzyć kolejny serwis korzystający z pasywnych rozwią-
zań, konieczna jest także znajomość sygnałów (a raczej ich nazw kodowych), na jakie
powinny reagować.
Wiele informacji musi zostać umieszczonych w pliku AndroidManifest.xml.
Należą do nich między innymi informacje o uprawnieniach, z jakich korzystają po-
szczególne serwisy (a co za tym idzie także cała aplikacja). Także same serwisy
(obiekty klas dziedziczących po klasie android.app.Service) muszą zostać zare-
jestrowane w pliku AndroidManifest.xml. Nie jest możliwa jego modyfikacja po
zainstalowaniu aplikacji (stałoby to w sprzeczności z podstawowymi zasadami bez-
pieczeństwa, gdyby aplikacja mogła sama sobie przyznawać dodatkowe uprawnienia
i rejestrować różnego rodzaju zachowania w reakcji na określone zdarzenia już po
jej uruchomieniu).
Wszystkie wymienione wyżej czynniki powodują, że w celu stworzenia i dodania
do aplikacji nowego serwisu należy wykonać kilka czynności, które łącznie pozwolą
na skonfigurowanie systemu z nowymi funkcjonalnościami. Poniższy opis zawiera
zbiór instrukcji dotyczących reguł i warunków, jakie muszą zostać spełnione, aby
serwis został poprawnie dodany.
Środowiskiem, w którym należy dokonywać zmian, jest Eclipse (w wersji ADT
- Android Developer Tools). Po pomyślnym zaimportowaniu projektu i próbnym
uruchomieniu w celu sprawdzenia poprawności można przystąpić do konfiguracji.
Składa się ona z kilku czynności:
• Stworzenie klasy odpowiedzialnej za przeprowadzenie pomiaru
• Umieszczenie własnych metod pomiaru
• Wywołanie zdefiniowanej metody wstawienia danych do bazy
76
• (W przypadku serwisów pasywnych) Stworzenie klasy odpowiadającej za re-
agowania na określone zdarzenia
• Dodanie nowego serwisu w pliku konfiguracyjnym AndroidManifest.xml
• Dodanie ewentualnych nowych uprawnień, jakich wymaga przeprowadzenie
pomiaru (AndroidManifest.xml)
• Dodanie nowego serwisu do pliku konfiguracyjnego res/values/config.xml
• Zdefiniowanie (w pliku res/values/config.xml), “kierunku” danego serwisu
(czy wyższa wartość pomiaru jest wartością gorszą czy lepszą)
• (W przypadku serwisów pasywnych) Dodanie (w pliku res/values/config.xml)
informacji na temat nowego serwisu
• (W przypadku serwisów pasywnych) Zarejestrowanie zdarzenia, na które po-
winien reagować serwis pasywny
• (Opcjonalne) Zdefiniowanie napisu, jaki pokazuje się na osi Y wykresu repre-
zentującego usługę
Pierwszą czynnością jest stworzenie odpowiedniej klasy, która będzie odpo-
wiadała za każdy z serwisów. Jej nazwa jest dowolna, konwencja zakłada nazwę
nazwa_wartościSERVICE i umieszczenie jej w pakiecie inz.service. Ważne jest,
aby stworzona klasa dziedziczyła po klasie android.app.Service. Dzięki temu moż-
liwe staje się jej wykorzystanie przez AlarmManager, który odpowiada za cykliczne
uruchamianie pomiarów. W tym momencie warto, w pliku AndroidManifest.xml
dopisać nazwę nowego serwisu, aby był on rozpoznawalny przez środowisko An-
droid. W tym celu należy, w sekcji opisanej jako REGISTERED SERVICES, umieścić
informację na temat stworzonego serwisu w postaci:
<service android:name=”inz.service.NAZWA” />
Należy także (o ile jest to konieczne) umieścić informację na temat ewentualnych
dodatkowych uprawnień, jakie są wykorzystywane przez tworzony serwis. Informacje
na temat uprawnień, jakie są potrzebne przy wykonywaniu poszczególnych pomiarów
można znaleźć w oficjalnej dokumentacji systemu Android. Dodawanie uprawnień
odbywa się za pomocą linijki:
77
<uses-permission android:name=”android.permission.NAZWA_UPR./>
Uprawnienia mogą dotyczyć zarówno dostępu do dysku, pamięci, procesora jak
i do zagadnień związanych z komunikacją internetową czy korzystaniem z dostępu
do wiadomości tekstowych czy przeprowadzonych rozmów. Wszystkie wymagane
uprawnienia są widoczne dla użytkownika w momencie instalacji aplikacji w przej-
rzystej szacie graficznej.
Tworzona klasa, z powodu dziedziczenia po klasie android.app.Service ma
możliwość przesłonięcia metody onStartCommand(). W niej należy umieścić wszyst-
kie obliczenia i działania doprowadzające do uzyskania informacji na temat pomiaru.
Metody zbierania informacji są dowolne. Nie ma żadnych ograniczeń dotyczą-
cych metod dostępu do informacji. Nie jest także konieczne ograniczanie się tylko do
jednej metody. Przykładem jest klasa odpowiedzialna za pomiar mocy sygnału WiFi,
która zleca pomiar wszystkich wartości sygnałów a zebranie wyników i zapis w bazie
danych odbywa się w klasie SIGNALREADER.java. Całość obliczeń i pomiarów po-
winna kończyć sie instrukcją zapisania w bazie danych wyników przeprowadzonych
pomiarów. W tym celu na końcu działania należy umieścić instrukcję:
MySQLLiteDataHelper.insert(String, float)
Pierwszy parametr oznacza nazwę serwisu. Powinna być ona taka sama jak
nazwa zdefiniowana w pliku AndroidManifest.xml. Przykładowo dla serwisu odpo-
wiedzialnego za pomiar ilości uruchomionych aktualnie aplikacji w serwisie o nazwie
APPLICATIONSERVICE, pierwszym parametrem jest słowo “APPLICATION”. Drugim
parametrem jest sama wartość mierzona (w tym przypadku ilość uruchomionych
aplikacji). Może ona przyjmować dowolne wartości liczbowe, w procesie zapisu rzu-
towana jest na typ float. Po poprawnym zapisie możliwe jest zakończenie działania
serwisu.
Nieco inaczej sytuacja przedstawia się w przypadku serwisów pasywnych. Wy-
magają one stworzenia przynajmniej 2 klas - poza opisywaną już klasą o nazwie
z końcówką “...SERVICE.java” należy także stworzyć klasę odpowiedzialną za re-
agowanie na określone zdarzenia. Konwencja nazewnicza zaleca stosowanie nazwy
“...READER.java” i umieszczanie jej w pakiecie inz.reader. Nazwy obu klas po-
winny się zgadzać (dla klasy INCALLSERVICE.java konieczne jest istnienie klasy
INCALLREADER.java. W klasie “...SERVICE.java” w przeciwieństwie do klas odpo-
78
wiedzialnych za serwisy aktywne, nie mają miejsca żadne obliczenia, jedyną instruk-
cją ważną z punktu widzenia aplikacji jest instrukcja:
SharedPreferencesProxy.getInstance().store(String)
Parametrem tej metody jest naza serwisu (na przykład “INCALL”). Uproszcze-
nie takie stało się możliwe z powodu zapisywanie okresowo tylko ilość wydarzeń,
jakie miały miejsce od poprzedniego uruchomienia serwisu, bez konieczności wyko-
nywania żadnych pomiarów.
Klasa “...READER.java” powinna dziedziczyć po klasie BroadcastReceiver
oraz implementować interfejs inz.reader.PASSIVESERVICES (jest to tak zwany
marker-interface, niezawierający żadnych metod, wykorzystywany przy przechowy-
waniu informacji na temat serwisów pasywnych). Wewnątrz klasy należy przeciążyć
metodę onReceive(...), która jest wywoływana w momencie odebrania informacji
o wystąpieniu zdarzenia. Podobnie jak w przypadku serwisów aktywnych, z punktu
widzenia działania aplikacji znaczenie ma tylko jedna instrukcja, odpowiedzialna tym
razem za aktualizację licznika wystąpień danego zdarzenia (odebrania wiadomości
SMS, podłączenie do USB itp.). Zapis odbywa się za pomocą instrukcji:
SharedPreferencesProxy.getInstance().update(String) z parametrem bę-
dącym nazwą serwisu (na przykład “INCALL”).
Innym miejscem, w którym należy dokonać modyfikacji, aby móc wprowadzić do
aplikacji nowy serwis, jest plik konfiguracyjny res/values/config.xml. Pierwszą
czynnością jest zapis do tablicy o nazwie “services” nazwy nowego serwisu tak, aby
mógł on zostać przetworzony w momencie uruchomienia aplikacji. Nowe serwisy
należy dodawać na końcu tabeli.
Następnymmiejscem działania jest tabela “servicesDirections”, gdzie należy umie-
ścić informację na temat tego, czy większa wartość pomiaru jest wartością lepszą
czy gorszą z punktu widzenia użytkownika. Na końcu tabeli należy umieścić:
• 1 - jeśli mniejsza wartość pomiaru jest wartością gorszą (np. stan baterii)
• 0 - jeśli większa wartość pomiaru jest wartością gorszą (np. ilość uruchomio-
nych aplikacji)
Informacje te są wykorzystywane przez moduły odpowiedzialne za poziomy
79
ostrzeżeń systemu Icinga - pozwalają na sprawdzenie, czy zakresy wartości nor-
malnych oraz ostrzegających i krytycznych nie są błędne.
W przypadku serwisów aktywnych nie ma potrzeby wykonywania innych czyn-
ności. Serwisy pasywne wymagają dodatkowego wpisu w tabelach “passiveServices”
a także “passiveServicesFilters”. W pierwszej z nich, na końcu należy umieścić nazwę
serwisu (taką samą jak w tabeli “services”), w drugiej należy umieścić nazwę zda-
rzenia, na jaką dany serwis powinien reagować (w celu aktualizacji licznika). Nazwy
zdarzeń można odnaleźć w oficjalnej dokumentacji systemu Android.
Dodatkową możliwością jest dodanie tekstu jaki dopisywany jest do wyniku
pomiaru w momencie połączenia z serwerem zewnętrznym. Ma to znaczenie przy
okazji rysowania wykresów - przekazana nazwa widnieje na osi Y. Przykładowym
tekstem (dla serwisu mierzącego ilość uruchomionych aplikacji) jest napis “NUM-
BER_OF_APPS”. W tym celu w klasie reprezentującej dany serwis należy umie-
ścić:
public static final String TEXT_FOR_GRAPH = “tekst_do_wywietlenia′′
W przypadku braku takiego zapisu przyjmowany jest domyślny zapis:
nazwa_serwisu+ “_STATE =′′
Opisane powyżej polecenia powinny skutkować poprawnym dodaniem dodat-
kowego serwisu do istniejącej już aplikacji (zarówno aktywnego jak i pasywnego).
Wszelkie błędy mogą wynikać przede wszystkim ze złych nazw serwisów (który są
wykorzystywane w mechanizmach refleksji dostarczanych przez język Java), braku
odpowiednich uprawnień (nieumieszczenie ich w pliku AndroidManifest.xml) oraz
błędy w implementacji. W przypadku pojawienia się błędów należy porównać im-
plementację z tymi dotychczas stworzonymi (zarówno w dziedzinie serwisów aktyw-
nych jak i pasywnych). Jeśli aplikacja wydaje się działać poprawnie, jednak serwisy
nie są wywoływane, należy sprawdzić, czy zostały one poprawnie opisane w pliku
AndroidManifest.xml.
80
C Załącznik C - zawartość płyty CD
Do stworzonej pracy dyplomowej załączono płytę CD. Znajdują się na niej za-
równo kody źródłowe jak i gotowa aplikacja przeznaczona do uruchomienia na urzą-
dzeniiu mobilnym. Zawarto także wyniki testów (w postaci wykresów) oraz doku-
mentację wygenerowaną na podstawie kodu. Organizacja zawartości płyty CD jest
następująca:
Aplikacja
Skompilowana do postaci zrozumiałej dla systemu Android. Możliwa do zain-
stalowania i uruchomienia bezpośrednio po skopiowaniu do pamięci urządze-
nia.
Dokumentacja
Dokumentacja wygenerowana na podstawie komentarzy umieszczonych w ko-
dzie aplikacji. Do tego celu wykorzystano narządzie Javadoc.
Kod źródłowy
Kod aplikacji w języku Java - zawiera także niezbędne biblioteki (związane za-
równo z platformą Android jak i modułami kryptograficznymi i zapisującymi).
Praca dyplomowa
Tekst pracy dyplomowej w postaci pliku .pdf.
Wyniki testów
Wykresy prezentujące wyniki przeprowadzonych testów - do ich wygenerowa-
nia wykorzystano narzędzia dostarczone przez [1]. Omówienie wyników znaj-
duje się w rozdziale Testy.
81
Literatura
[1] Krzysztof Opasiak, Rozproszony Monitoring Systemów Komputerowych, Wydział Elektroniki
i Technik Informacyjnych, Warszawa, 2014
[2] Charlie Collins, Michael Galpin, Matthias Kaepler [tł. Tomasz Walczak], Android w Praktyce,
Helion, 2012
[3] Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides [tł. Tomasz Walczak], Wzorce
projektowe. Elementy oprogramowania obiektowego wielokrotnego użytku, Helion, 2010
[4] inż. Piotr Gala, System nawigacji w obiektach użytku publicznego, Wydział Elektroniki i
Technik Informacyjnych, Warszawa, 2012
[5] www.nagios.org
[6] www.icinga.org
[7] www.cacti.net
[8] assets.nagios.com/downloads/nagiosxi/docs/Using_NSCA_With_XI.pdf
[9] developer.android.com/training/monitoring-device-state/battery-monitoring.html [Dostęp
12 lipca 2013]
[10] code4reference.com/2012/07/tutorial-on-android-alarmmanager/ [Dostęp 29 lipca 2013]
[11] www.sitepoint.com/learning-to-parse-xml-data-in-your-android-app/ [Dostęp 8 sierpnia
2013]
[12] www.anddev.org/viewtopic.php?p=17846 [Dostęp 12 sierpnia 2013]
[13] stackoverflow.com/questions/3394765/how-to-check-available-space-on-android-device-on-
mini-sd-card [Dostęp 16 sierpnia 2013]
[14] electronics.howstuffworks.com/google-phone2.htm [Dostęp 16 listopada 2013]
[15] pl.wikipedia.org/wiki/Android_(system_operacyjny) [Dostęp 19 listopada 2013]
[16] janiths-codes.blogspot.com/2009/11/how-to-convert-publickey-as-string-and.html
[17] https://www.icinga.org/about-icinga-mobile/ [Dostęp 16 września 2013]
[18] play.google.com/store/apps/details?id=info.degois.damien.android.aNag [Dostęp 16 wrze-
śnia 2013]
[19] android.schimpf.es/page/tinag/ [Dostęp 17 września 2013]
82
[20] www.icinga.org/2012/02/17/iphone-apps-for-icinga/ [Dostęp 19 września 2013]
[21] www.play.google.com/store/apps/details?id=com.manor.currentwidget [Dostęp 16 stycznia
2014]
[22] www.play.google.com/store/apps/details?id=com.eolwral.osmonitor [Dostęp 16 stycznia
2014]
[23] androidpolska.pl/view/system_monitor/4726 [Dostęp 16 stycznia 2014]
[24] www.appsapk.com/quick-system-info-pro/ [Dostęp 16 stycznia 2014]
[25] play.google.com/store/apps/details?id=pl.pawelbialecki.smartsysteminfo [Dostęp 17 stycznia
2014]
[26] www.xda-developers.com/android/perfmon-floats-your-devices-performance-on-screen/
[27] www.apps.apk.com/system-tuner/ [Dostęp 18 stycznia 2014]
[28] www.sqlite.org/quickstart.html [Dostęp lipiec-wrzesień 2014]
[29] www.linuxhowtos.org/System/procstat.html [Dostęp 18 sierpnia 2013]
[30] stackoverflow.com/questions/3118234/how-to-get-memory-usage-and-cpu-usage-in-android
[Dostęp 18 sierpnia 2013]
[31] en.wikipedia.org/wiki/Unix_time [Dostęp 3 stycznia 2014]
[32] www.meinbergglobal.com/english/info/ntp-packet.htm [Dostęp 29 grudnia 2013]
[33] ftp://ftp.rsasecurity.com/pub/rsalabs/rsa_algorithm/rsa-oaep_spec.pdf [Dostęp 6 stycznia
2014]
[34] pl.wikipedia.org/wiki/Advanced_Encryption_Standard [Dostęp 21 listopada 2013]
[35] developer.android.com
[36] stackoverflow.com
[37] creately.com
83