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

Rysunek 3: Diagram klas tworzonego systemu

42

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