Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Méréstechnikai és Információs Rendszerek Tanszék
Székely István
MONITOROZÓ ALKALMAZÁS FEJLESZTÉSE ANDROID PLATFORMRA Szakdolgozat
1 KONZULENS
Dr. Micskei Zoltán Imre BUDAPEST, 2013
Tartalomjegyzék Összefoglaló ..................................................................................................................... 5 Abstract............................................................................................................................ 6 1 Bevezetés ....................................................................................................................... 7 1.1 Célok ....................................................................................................................... 7 1.2 Dolgozat felépítése ................................................................................................. 8 2 Irodalomkutatás ........................................................................................................... 9 2.1 Elérhető monitorozó alkalmazások ......................................................................... 9 2.1.1 Teljesítményfigyelő alkalmazások .................................................................. 9 2.1.2 „Kémalkalmazások” ...................................................................................... 10 2.1.3 TaintDroid ...................................................................................................... 11 2.2 Az Android bemutatása......................................................................................... 11 2.2.1 Az operációs rendszer felépítése.................................................................... 11 2.2.2 Android alkalmazások felépítése ................................................................... 12 2.3 Biztonság .............................................................................................................. 12 2.3.1 Fájlelérés ........................................................................................................ 13 2.3.2 Engedélyek..................................................................................................... 13 2.4 A rendszer és az azon futó alkalmazások monitorozható jellemzői ..................... 15 2.4.1 Monitorozás rendszerfájlokon keresztül ........................................................ 15 2.4.2 Információk az API-n keresztül ..................................................................... 16 2.4.3 Szenzorok megfigyelése ................................................................................ 16 2.4.4 Monitorozható jellemzők összegezve ............................................................ 16 2.5 Lehetséges beavatkozások .................................................................................... 17 3 Tervezés ...................................................................................................................... 18 3.1 Alkalmazás funkcionalitásai ................................................................................. 18 3.1.1 Felhasználó felület ......................................................................................... 18 3.1.2 Szabályok elemei ........................................................................................... 19 3.2 Szabályok definiálása............................................................................................ 20 3.3 Alkalmazás alapvető felépítése ............................................................................. 20 4 Megvalósítás ............................................................................................................... 22 4.1 Alkalmazás felépítése ........................................................................................... 22 4.2 Alkalmazás komponenseinek megvalósítása ........................................................ 24
4.2.1 Service-ek ...................................................................................................... 24 4.2.2 Activity-k ....................................................................................................... 26 4.2.3 BroadcastReceiver-ek .................................................................................... 28 4.3 Monitorozás megvalósítása................................................................................... 28 4.3.1 Fájlból történő adatbeolvasás......................................................................... 29 4.3.2 Listener-ek használata.................................................................................... 29 4.3.3 Egyéb monitorozható jellemzők .................................................................... 30 4.4 Végrehajtás megvalósítása .................................................................................... 31 4.5 Szabályok betöltése ............................................................................................... 32 4.6 Összefoglalás ........................................................................................................ 32 5 Tesztelés ...................................................................................................................... 33 5.1 T1: egyszerű szabály ............................................................................................. 33 5.2 T2: időzített feltétel ............................................................................................... 34 5.3 T3: VPN szolgáltatás ............................................................................................ 35 5.4 T4: összetett szabály ............................................................................................. 35 5.5 Összefoglalás ........................................................................................................ 36 6 Összegzés..................................................................................................................... 37 Irodalomjegyzék............................................................................................................ 39 Függelék ......................................................................................................................... 40
HALLGATÓI NYILATKOZAT Alulírott Székely István, szigorló hallgató kijelentem, hogy ezt a szakdolgozatot meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat (szakirodalom, eszközök stb.) használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Hozzájárulok, hogy a jelen munkám alapadatait (szerző(k), cím, angol és magyar nyelvű tartalmi kivonat, készítés éve, konzulens(ek) neve) a BME VIK nyilvánosan hozzáférhető elektronikus formában, a munka teljes szövegét pedig az egyetem belső hálózatán keresztül (vagy hitelesített felhasználók számára) közzétegye. Kijelentem, hogy a benyújtott munka és annak elektronikus verziója megegyezik. Dékáni engedéllyel titkosított diplomatervek esetén a dolgozat szövege csak 3 év eltelte után válik hozzáférhetővé. Kelt: Budapest, 2013. 12. 16.
...……………………………………………. Székely István
Összefoglaló Az okostelefonok folyamatos fejlődésének és az azokra elérhető alkalmazások növekvő számának köszönhetően egyre több feladat elvégzésére tudjuk készülékeinket felhasználni. Azonban fontos, hogy a telefonunk mindig elérhető legyen számunkra, megbízhatóan működjön. Több mobil operációs rendszer is elérhető, ezek közül az Android az egyik legelterjedtebb. Az Android egy nyílt forráskódú, Linux alapú operációs rendszer. Eredetileg érintőképernyős mobiltelefonokra szánták, azonban ma már egyéb eszközön is elérhető, mint például tableteken, gépjárművek fedélzeti számítógépein. A beépített eszközökkel az alkalmazások működését csak korlátozottan tudjuk megfigyelni. Az alkalmazások telepítésekor a szükséges engedélyeken keresztül láthatjuk, hogy milyen műveleteket hajthat majd végre, azonban ezek felhasználásáról futás közben nincs visszajelzés. A platformhoz elérhető külső alkalmazások közül a legelterjedtebbek a teljesítményfigyelő alkalmazások, amik a hardveres jelmezőket figyelik meg. Ezenkívül még elterjedtek a kémalkalmazások is, amik segítségével a készülék tulajdonosáról lehet információkat szerezni. A szakdolgozat keretében egy olyan monitorozó alkalmazást készítettem, aminek a segítségével a telefon tulajdonosa tudja a telefonján futó alkalmazások működését megfigyelni és esetlegesen automatikusan beavatkozni. Az alkalmazásban feltételeket és cselekvéseket lehet megadni. Amennyiben valamely feltétel teljesül, az ahhoz tartozó cselekvések végrehajtása kerülnek. Az alkalmazás a készülék és az alkalmazások teljesítmény jellemzőit monitorozza. Segítségével megfigyelhető például a CPU terhelés, hálózati forgalom mérete, akkumulátor állapota. A cselekvések segítségével kiadható egy értesítés, leállításra kerülhetnek az alkalmazások vagy akár letiltható a hálózati hozzáférés. A dolgozatban bemutatom az Android platformot. Megvizsgálom, hogy milyen jellemzőit lehet a készüléknek és a futó alkalmazásoknak megfigyelni. Ezután megtervezem és elkészítem az alkalmazást, amit végül tesztelek.
5
Abstract Smartphones are getting more and more advanced and there is a huge variety of applications available. Therefore we can use our devices for more and more tasks. However, it is important that our phone is always available and reliable. There are several mobile operating systems available, out of which Android is the most widely used one. It is an open source, Linux-based operating system. Originally it was designed for touch-screen phones, but nowadays there are several other devices that can run Android, such as tablets, board-computers. With the help of the built-in tools the observation of running applications is considerably limited. Although the operations to be executed can be seen at the installation, based on the required permissions, the system does not provide any feedback about the running applications’ activity. There are several monitoring applications available which can provide information about the device and the applications. The most widespread ones are the performance monitoring applications, which can give information about the system’s and the application’s hardware usage. Besides, spy applications are also widespread, with the help of which information can be gained about the phone’s owner. In the thesis I created a monitoring application, with the help of which the owner of the phone can observe the activity of the running applications, and, if necessary, can intervene. The user can define conditions and actions for the application. When a condition is fulfilled, the given actions are executed. The application monitors the features of the applications and the system’s performance, such as CPU usage, network usage, and battery level. The action can be a notification, an application kill, or a network usage restriction. In this thesis I introduce the Android platform. I examine that what kind of information can be gained from the device and the applications. Afterwards I design and implement the monitoring application, and finally I test the application.
6
1 Bevezetés Napjainkban az okos telefonok széles körben elterjedtek, ezen belül Androidos készülékeket használnak a legtöbben. Sikerét többek között nyíltságának köszönheti. Nyílt forráskódú, így a kisebb gyártóknak is lehetőségük lett Androidos telefon készítésére. Továbbá alkalmazásokat független fejlesztők is készíthetnek és a Google Play-en közzétehetik. Ennek köszönhetően alkalmazások széles választéka érhető el és egyre több feladat elvégzésére használjuk telefonjaikat. Azonban ezek az alkalmazások van, hogy hibásan működnek vagy nagy erőforrás igényük miatt az akkumulátort túl korán lemerítik. Ezen kívül egyre gyakoribb, hogy az alkalmazások tudtunk nélkül érzékeny adatokat továbbítanak az interneten keresztül. A célom egy olyan Android alkalmazás készítése, ami alkalmas a rendszer és az azon futó alkalmazások monitorozására. Az alkalmazásban szabályokat lehet definiálni, amik előre meghatározott feltételekből és cselekvésekből épülhetnek fel. A feltételek vonatkozhatnak a teljes rendszerre vagy egy kijelölt alkalmazásra, ahogy a cselekvések hatása is lehet rendszerszintű vagy alkalmazásszintű. Így létrehozható például egy olyan szabály, ami bezárja az adott alkalmazást, ha annak huzamosabb ideig magas a CPU használata és ezáltal lassítja a rendszert, meríti az akkumulátort.
1.1 Célok A feladatkiírás alapján az alábbi célokat tűztem ki célul, a szakdolgozatban ezeknek a pontoknak a kidolgozását fogom bemutatni.
Az Android platform bemutatása.
Androidos készülék és a futó alkalmazások megfigyelhető jellemzőinek összegyűjtése.
Alkalmazás tervezése majd tesztelése, ami képes a telefon és az azon futó alkalmazások megfigyelésére.
Az elkészült alkalmazás működésének szemléltetése.
7
1.2 Dolgozat felépítése A második fejezetben bemutatom, hogy milyen a témámhoz hasonló alkalmazások érhetők el Android-ra. Ezután ismertetem az operációs rendszer és az alkalmazások felépítését. Végül bemutatom, hogy milyen információk tudhatók meg a készülékről és az alkalmazásokról. A harmadik fejezetben részletezem, hogy az alkalmazásnak milyen feladatokat kell ellátnia. Majd ezek alapján leírom a szabályok definiálásának módját illetve az alkalmazás felépítését. A negyedik fejezetben bemutatom a tervezés során bemutatott komponensek részletes felépítését, működését. Leírom a megvalósítás érdekesebb részleteit kódrészletekkel illusztrálva. Az ötödik fejezetben tesztelem az elkészült alkalmazást. A tesztelés során olyan példákat választottam, amik szemléltetik, hogy az alkalmazást milyen célokra lehet használni. Végül az utolsó fejezetben összegzem az elért eredményeket, leírom a továbbfejlesztési lehetőségeket.
8
2 Irodalomkutatás Ebben a fejezetben megvizsgálom, hogy milyen monitorozó alkalmazások érhetők el Androidra. Ezenkívül bemutatom magát a rendszert, majd megvizsgálom milyen tulajdonságait lehet megfigyelni annak és a rajta futó alkalmazásoknak.
2.1 Elérhető monitorozó alkalmazások Számos monitorozó alkalmazás érhető el az Android platformra, többségük kereskedelmi forgalomba szánt, de akad közöttük néhány nyílt forráskódú szoftver is. Elvárás, hogy a háttérben fussanak, minimális erőforrás felhasználása mellett. Ez a mobilkészülékek esetén különösen fontos, mert egy nagy erőforrás igényű alkalmazás jelentősen csökkentheti az eleve alacsony akkumulátor időt. Ezeket az alkalmazásokat két
fő
csoportra
lehet
bontani:
teljesítményfigyelő
alkalmazások,
illetve
kémalkalmazások.
2.1.1 Teljesítményfigyelő alkalmazások Az ilyen jellegű alkalmazások a hardver tulajdonságait figyelik, így betekintést nyerhet a felhasználó a készüléke állapotaira. Akkor van például ilyen alkalmazásokra szükség, ha a készülék nem az elvárt módon viselkedik: lassú, hamar lemerül az akkumulátor, hálózati problémák vannak. Ilyen nyílt forráskódú alkalmazás például az android-os-monitor. Ahogy sok hasonló alkalmazást, ezt is évekkel ezelőtt készítették, így nem használja az Android rendszer azóta bekerült szolgáltatásait. Az android-os-monitor monitorozza az egyes folyamatok CPU terhelését, ezenkívül monitorozza a teljes CPU terhelést, memória állapotát. Megjeleníti a hálózati interfészeket, hálózati kapcsolatokat. Hálózati forgalom rögzítésére is lehetőség van. Korábban ez a feladat csak rootolt készülékkel volt lehetséges. Android 4.0-tól viszont már nincs szükség root jogokra a hálózati forgalom megfigyeléséhez. Például a tPacketCapture alkalmazás rögzíti a hálózati csomagokat és azokat PCAP fájlokba menti el, így később számítógépen elemezhető. Lehetőség van szűrni is, hogy mely alkalmazások forgalma legyen rögzítve. 9
1. ábra OS Monitor [5]
2.1.2 „Kémalkalmazások” Ezek az alkalmazások a készüléken keresztül próbálnak meg minél több információt megtudni annak használójáról. Ilyen információ például a készülék helyzete, telefonbeszélgetéssekkel, szöveges üzenetekkel kapcsolatos információk. Egy ilyen hasznos alkalmazás például a magyar fejlesztésű Egérút, amely a készülékek helyzetét, sebességét monitorozva, a közutak járhatóságáról szerez információkat.
2. ábra Egérút [6]
10
Szintén ide sorolható a MobileMonitor nevű alkalmazás is, amit gyerekek illetve beosztottak megfigyelésére szántak. Az alkalmazás információkat gyűjt például a hívásokról, SMS-ekről, böngészési előzményekről, készülék helyzetéről.
2.1.3 TaintDroid A TaintDroid segítségével nyomon követhető, hogy mely alkalmazások milyen adatokat hogyan használnak fel működésük közben. A TaintDroid a virtuális gépbe épülve képes követni, hogy mely alkalmazások, milyen adatokat kérnek le, majd azokat miként használják fel. Amennyiben valamelyik alkalmazás érzékeny adatot küld el valahova, azt egy értesítés (notification) segítségével jelzi.
2.2 Az Android bemutatása Az Android napjaink egyik legsikeresebb és legelterjedtebb operációs rendszere. Az első változata 2008-ban jelent meg, jelenleg a 4.4-es (KitKat) verziónál járunk.
2.2.1 Az operációs rendszer felépítése
3. ábra Az Android operációs rendszer felépítése [7]
A rendszer a 2.6-os Linux kernelre épül, négy rétegre bontható fel. A legalsó rétegen a kernel helyezkedik el. A kernel feladata az ütemezés, memóriakezelés. Itt 11
találhatók még az eszköz meghajtók is. Az efölötti lévő rétegen helyezkednek el a programkönyvtárak, illetve az alkalmazásfuttató környezet. Az Androidra írt alkalmazások a Dalvik virtuális gépekben futnak. Minden alkalmazás egy külön virtuális gépen fut, így a többi alkalmazás és a rendszer védve van azok hibáitól. A következő rétegben helyezkedik el az alkalmazások keretrendszere. Ezen keresztül tudnak az alkalmazások hozzáférni a rendszer erőforrásaihoz. A legfelső rétegen helyezkednek el az alapvető, beépített alkalmazások: naptár, web böngésző stb.
2.2.2 Android alkalmazások felépítése Egy alkalmazás négyféle komponensből épülhet fel. Ezen komponensek különböző feladatok ellátására szolgálnak, különböző életciklussal rendelkeznek. Az Activity1 komponens egy felhasználói felületet reprezentál. Egy alkalmazás több activity-ből is felépülhet, de azok függetlenek egymástól. Amely alkalmazások engedélyezik, azoknak elindíthatja egy másik alkalmazás is az activity-jét. A Service komponensek nem rendelkeznek felhasználói felülettel, tipikusan olyan feladatot látnak el, amelyek huzamosabb futási időt igényelnek. A Contet provider-ek feladata az egyes alkalmazások által megosztott adatok biztosítása a többi alkalmazás felé. A Broadcast receiver-ek segítségével broadcast üzeneteket lehet fogadni, majd kezelni. A rendszer számos eseményről küld üzenetet, például ha az akkumulátor töltöttsége alacsony, de akár egyszerű alkalmazások is küldhetnek üzeneteket.
2.3 Biztonság Az okos telefonokon rengeteg fontos adat megtalálható, amiket védeni kell az illetéktelen felhasználástól, ezért különösen fontos, hogy a rendszer a lehető legbiztonságosabb legyen.
1
A komponensek nevére nem találtam magyar megfelelőt, ezekre angol nevükkel fogok
hivatkozni.
12
2.3.1 Fájlelérés Az alkalmazások a fájlokat két helyen tárolhatják, a külső és a belső tárolóban. A külső tároló minden alkalmazás számára elérhető, így itt olyan fájlokat szokás tárolni, amit a többi alkalmazással is meg akarunk osztani. Ide kerülnek a kamera felvételei, így azokat elérheti például a Galéria alkalmazás, illetve USB Mass Storage Módban a felhasználó számítógépéről is hozzá férhet. A belső tárhely Linux fájlrendszeren található meg, így az ott található fájlok elérése korlátozható a hozzáférési jogosultságok segítségével. Minden alkalmazáshoz egy Linux felhasználó tartozik, továbbá egy mappa a belső tárhelyen. A mappának ez a felhasználó a tulajdonosa, így az ott tárolt adatokat védve lehet tárolni. Természetesen az itt tárolt adatokat, fájlokat meg is lehet osztani más alkalmazásokkal erre több mód is van:
A már említett Content Provider komponensek segítségével elérhetőek a tárolt adatok. Ezt a megoldást a komplexitás elrejtésére szokás használni, például ha egy adatbázisból kell rekordokat lekérni, akkor így nincs szükség az adatbázis felépítésének ismeretére.
Az API-n keresztül módosíthatók a fájlok hozzáférési jogosultságai, így azok kívülről is olvashatók vagy akár írhatók is.
Lehetőség van arra is, hogy több alkalmazáshoz is ugyanaz a Linux felhasználó tartozzon. Erre a lehetőségre csak akkor van mód, ha az alkalmazáshoz ugyanaz az aláírás tartozik.
2.3.2 Engedélyek Minden olyan erőforrás használathoz, használati joghoz ami lehetőséget nyújt privát adatok hozzáféréséhez, adatok módosításához engedélyt kell kérni. Az engedélyeket már a telepítés közben meg kell adni, így futás közben nem fogja befolyásolni a felhasználói élményt. Az Android jelenlegi verziójában (4.4 KitKat) 145 féle engedély van. Ezek három csoportba sorolhatók az alapján, hogy mekkora kockázatot jelentenek.
Egyszerű: Ezekkel az engedélyekkel az alkalmazások nem jelentenek különösebb veszélyt a felhasználóra, a rendszerre és más alkalmazásokra. Csupán olyan jogokat kapnak, amikkel zavarhatják a felhasználói élményt. Ilyen például a rezgő motor használata, ébresztő beállítása. 13
Veszélyes: Az ilyen engedélyekkel lehetőségük van az alkalmazásoknak privát adatokhoz hozzáférni, és egyéb más cselekvéseket elvégezni, amikkel veszélyt jelenthetnek a felhasználóra. Ide tartozik például a kamera használat, SMS küldés, írás/olvasás a külső tárhelyre.
Aláírásos: Ezeket az engedélyeket csak akkor lehet megkapni, ha az igénylő alkalmazás aláírása megegyezik az engedélyt definiálóéval. A rendszerben az ilyen engedélyeket különösen veszélyes műveletekhez kötik, például a készülék kikapcsolásához.
A
third-party
alkalamzások
értelemszerűen
nem
is
birtokolhatják ezeket. Lehetőség van saját engedélyek definiálására is, ami akár lehet aláírásos is, így erősen korlátozható az alkalmazás szolgáltatásainak hozzáférése. Az alábbi táblázatban felsoroltam engedélyeket típusonként csoportosítva. Típus Egyszerű Veszélyes
Aláírásos
Név SET_ALARM SET_WALLPER SEND_SMS READ_CONTACTS ACCES_FINE_LOCATION INTERNET SHUT_DOWN BRICK
Leírás Ébresztő beállítása. Készülék háttérképének beállítása. SMS küldése Kontakt adatok olvasása. Helyzet meghatározás. Internet hozzáférés. Készülék leállítása Készülék deaktiválása
1. táblázat Példa engedélyek
Engedélyek betartatása A rendszernek biztosítani kell, hogy a védett erőforrásokat csak a megfelelő engedéllyel rendelkező alkalmazás használhassa. Az erőforrások elérése külön folyamatokban történik, amik távoli eljáráshívással érhetők el. A legtöbb esetben itt ellenőrzi a rendszer, hogy az alkalmazásnak engedélyezett-e az adott művelt. Néhány erőforrás elérése a Linux csoportok segítségével is korlátozható. Ilyen erőforrás a külső tárhelyre írás, internet hozzáférés, bluetooth használat. Például amennyiben az alkalmazás rendelkezik INTERNET engedéllyel, az azt futtató felhasználó bekerül az inet Linux csoportba. Amikor egy alkalmazás socketet próbál nyitni, a kernel csak akkor engedélyezi, ha tagja az inet csoportnak.
14
4. ábra Engedély vizsgálat [8]
2.4 A rendszer és az azon futó alkalmazások monitorozható jellemzői Ebben a fejezetben összegyűjtöttem, hogy a rendszer és az azon futó alkalmazások mely jellemzőit lehet megfigyelni, illetve honnan nyerhetők ki ezen információk.
2.4.1 Monitorozás rendszerfájlokon keresztül Az alkalmazások számára elérhető a /proc fájlrendszer, ahonnan kinyerhetők a legfontosabb információk a rendszerről és a futó alkalmazásokról. A
CPU
terhelés
megfigyeléséhez
a
/proc/stat
illetve
a
/proc/[pid]/stat fájlok tartalmát kell felhasználni. A /proc/stat fájlból kiolvasható, hogy mennyi időt töltött a CPU különböző állapotokban. A /proc/[pid]/stat vagy a /proc/[pid]/status fájlokból kiolvasható, hogy mennyi CPU időt töltött a folyamat user, illetve kernel módban. Ezen adatok ismeretében kiszámítható a teljes rendszer processzorterhelése, továbbá az egyes folyamatok terhelése is meghatározható. A memóriaterhelés a /proc/meminfo fájlból tudható meg. Innen kiolvasható az elérhető, illetve a szabad memória mérete. Az egyes folyamatok memória 15
felhasználása a /proc/[pid]/statm vagy a /proc/[pid]/status fájlokból olvasható ki.
2.4.2 Információk az API-n keresztül A hálózati forgalom méretének megfigyelése a TrafficStats osztály statikus metódusai segítségével lehetséges. Megtudható a készülék és az egyes alkalmazások hálózati forgalma. Az Android 4.0-tól kezdve lehetőség van VPN alkalmazás implementálására is, ami segítségével megfigyelhető a csomagszintű hálózati forgalom. Az ActivityManager segítségével lekérhetők a futó Activity-ről, Service-ről alapvető információk, mint például: pid, uid, memória információk.
2.4.3 Szenzorok megfigyelése A készülékekben különböző szenzorok találhatók, ezeket 3 fő csoportra lehet osztani.
Mozgásérzékelők: Ezek a szenzorok a készülékre ható gyorsulási és forgási erőket mérik. Ilyen szenzorok: gyorsulásmérő, giroszkóp stb.
Környezeti szenzorok: A készülék környezetéről biztosítanak információkat. Ebbe a csoportba tartozik: hőmérő, fénymérő stb.
Helyzet szenzorok: Meghatározzák a készülék fizikai elhelyezkedését. Ide tartozik az orientációs szenzor, illetve a magnetométer. A különböző készülékekben eltérő számú, típusú szenzorok találhatók,
szerencsére az Android rendszer ezen szenzorok detektálására, a méréseik beolvasására egységes interfészt nyújt.
2.4.4 Monitorozható jellemzők összegezve Az alábbi táblázatban a monitorozható jellemzők összefoglalása látható. Forrás Fájlrendszer
Jellemző CPU terhelése Fizikai memória státusza
16
Információk A CPU különböző módokban töltött ideje /proc/stat fájl A készülék teljes és szabad fizikai memóriája /proc/meminfo fájl
Hálózati forgalom
Futó folyamatok információi Szenzorok
Android API
Gyorsulási erők Forgási erők Fényerő Helyzet Hálózati forgalom Alkalmazások memória terhelése
Az egyes hálózati eszközökön küldött és fogadott csomagok száma /proc/net/dev fájl Információk a folyamatok CPU és memória terheléséről /proc/[pid] könyvtár gyorsulásmérő giroszkóp fényerősség mérő GPS, 3G adótornyok, Wi-Fi VPN service, csomagszintű hálózati forgalom ActivityManger, alkalmazás memória használata
2. táblázat Monitorozható jellemzők
2.5 Lehetséges beavatkozások Az alkalmazásnak képesnek kell lennie beavatkozások elvégzésére is. Ebben a alfejezetben a lehetséges beavatkozásokat gyűjtöttem össze.
Értesítés: Értesítéssel jelezhető, hogy mely alkalmazás milyen eseményfeltétele teljesült. Az értesítés az alkalmazás felhasználó felületén kívül megjeleníthető üzenet.
Naplózas: Az esemény bekövetkeztéről egy naplóbejegyzés készül, amiből megtudható, hogy mely alkalmazás, miért és mikor váltotta ki a cselekvést.
Alkalmazás
leállítása:
ActivityManager
killBackgroundProcesses
metódusa segítségével lehetőség van az alkalmazások leállítására, amennyiben ismert az alkalmazás package neve.
Hálózati forgalom letiltása: A VPN szolgáltatás segítségével letiltható az alkalmazások be- és kimenő hálózati forgalma.
17
3 Tervezés A feladat egy olyan alkalmazás készítése, amely képes a rendszert és a futó alkalmazásokat monitorozni. Feltételeket lehet definiálni, amik teljesülése esetén az alkalmazás elvégzi a megadott beavatkozásokat. Egy feltételek a rendszer vagy egy alkalmazás valamely monitorozható jellemzőjétől függ. A beavatkozás hatásai lehetnek rendszer szintűek, vagy alkalmazás szintűek.
3.1 Alkalmazás funkcionalitásai Az alkalmazás fő feladata a monitorozás és a cselekvések végrehajtása. Ezeket a feladatokat a háttérben futva kell majd elvégezni. Természetesen az alkalmazásnak felhasználó felülettel is rendelkezni kell.
5. ábra Use case diagram az alkalmazásról
3.1.1 Felhasználó felület Az alkalmazás a háttérben fog dolgozni, így csak alapvető feladatokhoz lesz szükség felhasználói felületre. Ezek a felhasználó használati esetei (5. ábra).
Szolgáltatás elindítása és leállítása: El kell tudni indítani, és ha szükséges, lehetősége lesz a felhasználónak a szolgáltatás leállítására is.
18
Szabályokkal kapcsolatos információk megjelenítése: Megjelenítésre kerülnek a futó szabályok, azok állapotai: még nem lett végrehajtva, lefutott, beavatkozás sikertelen volt.
Beállítások: Be lehet majd állítani a monitorozás felbontását, ezáltal szabályozni lehet, hogy mekkora terhelést okoz az alkalmazás. Illetve lehetőség
lesz
a
szolgáltatás
automatikus
indításának
engedélyezésére/letiltására.
3.1.2 Szabályok elemei A szabályok feltételek és cselekvések halmazából épülnek fel. Ebben a fejezetben összegyűjtöm, hogy pontosan milyen eleme lehetnek egy szabálynak. 3.1.2.1 Feltételek
Maximális CPU terhelés.
Maximális memóriaterhelés.
Maximális hálózati forgalom.
Minimális akkumulátor töltöttség
Készülék pozíciója
Az első három jellemző vonatkozhat a teljes rendszerre vagy egy alkalmazásra. A feltételekhez intervallum is köthető. 3.1.2.2 Beavatkozások A szabályokhoz a 2.5 fejezetben bemutatott beavatkozásokat lehet rendelni.
Alkalmazás leállítása
Értesítés küldése
Naplóbejegyzés készítése
Hálózati forgalom korlátozása
19
3.2 Szabályok definiálása Az alkalmazás által ellenőrzött szabályokat meg kell tudni adni és tárolni kell valamely formában. Ennek megoldása történhet a felhasználói felületen keresztül vagy egy konfigurációs fájl segítségével. Egy ilyen alkalmazásnál a monitorozáson és beavatkozás végrehajtásán van a hangsúly. A szabályokat többnyire hozzáértő felhasználók hozzák létre. Ezek alapján a konfigurációs fájl mellett döntöttem. A konfigurációs fájlnak szabályokat kell tartalmaznia. A szabályokon belül helyezkednek el a feltételek és a cselekvések. Több feltétel eseten logikai operátorokat (ÉS,VAGY) is meg kell adni, ami alapján megtörténhet a kiértékelés, továbbá a zárójelezésről is gondoskodni kell. Ezek után már csak a konfigurációs fájl formátumát kell meghatározni. Erre a célra létre lehetet volna hozni egy saját szöveges formátumot is. Viszont én az XML formátumot választottam. Így a felhasználónak könnyebb megérteni a szabályok megadásának módját. Az XML séma a függelékben megtalálható. Az alábbi példa egy olyan szabályt hoz létre, ami értesítést ad ki arról, ha az akkumulátor töltöttsége 50% alá esik.
50 Akkumulátor állapot, Az akkumulátor töltöttsége 50% alatt van
3.3 Alkalmazás alapvető felépítése Az alkalmazás elindításakor egy főmenü fog megjelenni, ahonnan el lehet jutni a beállításokért, szabály megjelenítéséért, szolgáltatás indításáért/leállításáért felelős ablakokba. A szolgáltatás a háttérben futva monitorozza a készüléket és végrehajtja a szabályokat. Az alkalmazás ezeket a feladatokat ellátó komponensekből áll (6. ábra). 20
6. ábra Magas szintű felépítése
A szolgáltatás kétféle komponensből fog felépülni szabályokból (Rule), illetve rendszereszközökből (SystemTool). A szabályok feladata a feltételek kiértékelése és a cselekvések végrehajtása. A feltételhez szükséges jellemzők megfigyelését, cselekvések tényleges végrehajtását azonban a rendszer eszközök végzik el (7. ábra). Ennek köszönhetően nem fordulhat elő, hogy a feltételek ugyanazokat a jellemzőket többször beolvassák ezáltal erőforrást pazarolnak. A felépítés másik előnye, hogy a monitorozás cselekvés végrehajtás erősen platform specifikus, miközben a jellemzők értékelése cselekvések kezdeményezése már csak a programozási nyelvtől függ. Az implementáció szétválasztása megkönnyíti az alkalmazás más platformra történő fejlesztését.
7. ábra Szolgáltatás felépítése
21
4 Megvalósítás Az előző fejezetben bemutatott tervek alapján elkészítettem az alkalmazást. Ebben a fejezetben bemutatom a komponensek felépítését, a fontosabb funkciónak megvalósítását részletesen is leírom.
4.1 Alkalmazás felépítése Az alkalmazás legfontosabb része a háttérben futó szolgáltatás. A szolgáltatás periódikusan beolvassa a szükséges adatokat és végrehajtja a szabályokat. A
monitorozás
implementációja
a
SystemTool
interfészt
megvalósító
osztályokba kerül. Ezek és a cselekvéseket implementáló osztályok a Singleton tervezési minta szerint lesznek megvalósítva, így biztosított az egyszeri példányosítás, könnyű elérés (8. ábra). A szolgáltatásban található szál a beállításoknak megfelelő időközönként le lesz futtatva. Ekkor először a rendszereszközök által megfigyelt jellemzőket kell eltárolni. Majd ezután végrehajtásra kerülhetnek a szabályok is (9. ábra).
8. ábra Alkalmazás felépítése
22
9. ábra Alapvető működés
A szabályok feltétel csoportokból (ConditionExpression) és cselekvésekből (Action) állnak (10. ábra). A szabály feladata eldönteni, hogy teljesülnek-e a feltételek, amennyiben igen, végre kell hajtani a cselekvéseket (11. ábra). A feltételcsoport feladata a benne található feltételek, további feltétel csoportok, igazságtartamának eldöntése. Egy csoporthoz egyféle logikai operátor tartozik, ami szerint ki kell értékelni a feltétel csoport igazságtartamát. Több feltételnél is szükségszerű lehet az állapot fennállását idő intervallumhoz kötni. Ennek biztosításáért a Decorator tervezési minta alapján létrehozott TimedCondition osztály felelős. A szükséges idő másodpercben kell megadni.
10. ábra Szabály felépítése
23
11. ábra Szabály végrehajtása
4.2 Alkalmazás komponenseinek megvalósítása Az alkalmazás alapvető építőelemei a komponensek. Ezeken keresztül végezhető el az alkalmazás elindítása, a rendszer eseményeinek kezelése.
4.2.1 Service-ek Az alkalmazás két szolgáltatást futtat. A monitorozó szolgáltatást, aminek a feladata a szabályok végrehajtása. Ezen kívül még fut egy VPN szolgáltatás, ami segítségével korlátozni lehet a hálózati hozzáférést. 4.2.1.1 Monitorozó szolgáltatás A monitorozó szolgáltatásban a szabályok végrehajtása egy külön szálon történik, aminek a futtatását a ScheduledExecutorService végzi. Ennek elindítása előtt először meg kell tudni, hogy milyen gyakran kell a szálat meghívni. A felhasználói beállítások kulcs-érték párokként vannak tárolva a készülék belső tárhelyén. Ennek elérését a SharedPreferences keretrendszer teszi lehetővé. SharedPreferences sharedPref = getSharedPreferences(PREF, MODE_PRIVATE); int seconds = sharedPref.getInt(TIMING_KEY,0);
Ezután el lehet indítani a monitorozást. executor = Executors.newScheduledThreadPool(1); ServiceAppThread thread = new ServiceAppThread();
24
executor.scheduleAtFixedRate(thread, 0, seconds, TimeUnit.SECONDS);
A felhasználó módosíthatja a beállításokat a szolgáltatás elindítása után is, ekkor módosítani kell a szál futtatásának ütemezését. Lehetőség van a beállítások változásáról értesítést kapni. Ehhez az OnSharedPreferencesChangeListener interfészt kell implementálni. Az onSharedSaredPrefernceChanged metódus paraméterül kapja, hogy mely kulcshoz tartozó érték változott meg és mi lett annak az új értéke. public void onSharedPreferenceChanged(SharedPreferences prefs, String key) { if (key.equals("timeing")) { executor.shutdown(); ServiceAppThread thread = new ServiceAppThread(); SharedPreferences sharedPref = getSharedPreferences( PREF_NAME, MODE_PRIVATE); int seconds = sharedPref.getInt("timeing", 0); executor.scheduleAtFixedRate(thread, 0, seconds, TimeUnit.SECONDS); } }
A monitorozó szál végigiterál a szükséges rendszer eszközökön és meghívja azoknak a tick() függvényét. Ezután a szabályokon is végigiterál és végrehajtja azokat. A szükséges rendszereszközök listába helyezéséről a szabályok feltétel és cselekvés komponensei felelősek. Ezt a szolgáltatás egy statikus függvényén kereszül kell elvégezni, ami ha még nem szerepel a listában a rendszereszköz, hozzáadja azt. Az alkalmazásnak meg kell tudnia jeleníteni a futó szabályokat. Ehhez lehetőséget kell biztosítani a szolgáltatáshoz történő kapcsolódáshoz. Implementáli kell az IBinder interfészt, amin keresztül elérhető a szolgáltatás. A szolgálatás és a szabály megjelenítés egy folyamatban vannak így a Binder-nek elegendő referenciát adnia a futó szolgátatásról. public class MyBinder extends Binder { ServiceApp getSerivce() { return ServiceApp.this; } }
Amikor az Activity kapcsolódni próbál a szolgáltatáshoz, akkor meghívódik annak az onBind callback függvénye, ahol át kell adni a Binder-t.
25
4.2.1.2 VPN szolgáltatás Az alkalmazás másik szolgáltatása egy VPN szolgáltatás. A szolgáltatás fogadja az elküldendő és bejövő IP csomagokat és továbbítja azt a tűzfal szerepet betöltő objektumnak, ami eldönti, hogy az adott csomag továbbküldhető-e/fogadható-e. A szolgáltatás az Android SDK-ban példakódként megtalálható ToyVpnService osztályra épül. A konfigurációt át kellett írni, hogy a teljes adatforgalom a szolgáltatáson keresztül menjen tovább. Egy csomag továbbküldése előtt engedélyt kell kérni arra a tűzfal objektumtól.
4.2.2 Activity-k Az alkalmazásban több Activity is található, ezek az alábbi feladatokat látják el:
Főmenü megjelenítése
Futó szabályok megjelenítése
Szolgáltatások leállításának/indításának kezdeményezése
Beállítások megjelenítése
Szolgáltatások elindítása
A főmenü segítségével lehet eljutni a további Activity-kbe. Ehhez létrehoztam a szükséges gombokat. A gombok eseménykezelő függvényében el kell indítani a megfelelő Activity-t. Button rules = (Button)findViewById(R.id.button_rules); rules.setOnClickListener(new View.OnClickListener() { @Override public void onClick(View v) { Intent intent = new Intent(StartActivity.this, RulesActivity.class); startActivity(intent); } });
A szabály lista megjelenítése ListActivity segítségével történik. A listaelemeket a ServiceApp szolgáltatástól kell lekérni. A bindService metódus segítségével, lehetőség van a futó szolgáltatás eléréséhez. Ehhez egy ServiceConnection interfészt implementáló osztályra van szükség. Intent intent = new Intent(this,ServiceApp.class); bindService(intent, serviceConnection, Context.BIND_ABOVE_CLIENT);
26
Az ilyen típusú objektum callback függvényben megkapja a szolgáltatás által létrehozott, IBinder interfészt implementáló objektumot, ami segítségével elérhető a szolgáltatás. @Override public void onServiceConnected(ComponentName name, IBinder service) { serviceApp = ((MyBinder) service).getSerivce(); rules = serviceApp.getRules(); showList(); }
Ezután már csak a lista megjelenítése van hátra. Minden szabályhoz létre kell hozni egy listaelemet ami megjeleníti a szabály nevét. Az elem háttér színe a szabály állapotától fog függeni. Ehhez létre kell hozni egy Adaptert, aminek az a feladata, hogy a szabály listából előállítja a listaelemeket. Az Adapterem ArrayAdapter<String> osztályból származik ami elkészíti a listaelemeket a szabályok neveivel. Még a getView függvényt kell felül definiálni, ahol beállítom az állapotnak megfelelő háttérszínt. A szolgáltatások elindítása két helyről történhet meg. A menüből és egy BroadcastReciever-ből ami a készülék bekapcsolásáról kap üzenetet. A VPN szolgáltatás elindításához felhasználói felületre is szükség van, ugyanis engedélyt kell kérni a felhasználótol. Ehhez létrehoztam egy Activity-t aminek a feladata a szolgáltatások elindítása. Az Activitynek először engedélyt kell kérnie a felhasználótol. El kell indítani egy újabb Activity-t ami megteszi ezt. Ehhez az intent-et a VpnService prepare metódusától kapjuk meg. A függvény null-al tér vissza, amennyiben a felhasználó korábban már engedélyt adott a VPN szolgáltatás futtatására. Az Activity-t startActivityForResult függvénnyel kell indítani. A felhasználó döntését callback függvényben kapom meg. @Override protected void onActivityResult(int request, int result, Intent data) { if (result == RESULT_OK) { Intent intent = new Intent(this, MyVpnService.class); startService(intent); intent = new Intent(this, ServiceApp.class); startService(intent); } finish(); }
27
4.2.3 BroadcastReceiver-ek Az alkalmazásnak két, a rendszertől érkező broadcast üzenetet kell feldolgoznia: a készülék bekapcsolásáról és a hálózatra történő kapcsolódás változásáról. Lehetőség
van
a
szolgáltatások
automatikus
elindítására
a
készülék
bekapcsolásakor. A BOOT_COMPLETED broadcast üzenetre kell feliratkozni az alkalmazás manifest állományában.
Amikor bekövetkezik az esemény, akkor a BroadcastReceiver onReceive függvénye meghívódik. Itt ki kell olvasni, hogy engedélyezve van-e az automatikus indítás. Amennyiben igen, el kell indítani a szolgáltatásokat. Amennyiben a készülék másik hálózatra kapcsolódik, újra kell indítani a VPN szolgáltatás. Erről a rendszer CONNECTIVITY_CHANGE broadcast üzenetet küld. Az üzenet feldolgozásakor megvizsgálom, hogy van-e internetelérés. Ha van, akkor újraindítom a VPN szolgáltatást. ConnectivityManager connectivityManager = (ConnectivityManager)context .getSystemService(Context.CONNECTIVITY_SERVICE); NetworkInfo networkInfo = connectivityManager.getActiveNetworkInfo(); if (networkInfo != null && networkInfo.isConnected()) { … }
4.3 Monitorozás megvalósítása Az alkalmazás monitorozását végző osztályoknak a SystemTool interfészt kell implementálniuk.
Az interfész egy függvényt tartalmaz (void tick()) amit a
monitorozó szál minden lefutáskor meghív. A monitorozó osztályok három forrásból olvassák szerezhetik meg a szükséges adatokat: a fájlrendszerből, listener-ek segítségével és az Android API függvényei segítségével.
28
4.3.1 Fájlból történő adatbeolvasás A Linux kernel által tárolt információk a /proc virtuális fájlrendszeren keresztül érhetők el. Innen kiolvashatók 2.4.1 fejezeten bemutatott jellemzők. A
fájlok
beolvasását
egy
segédosztály
végzi
el,
annak
tartalmát
List<String>-ként adja vissza. Ezután már csak ki kell olvasni a szükséges adatokat. A /proc/stat, /proc/[pid]/stat fájlokból kiolvasható, hogy mennyi időt töltött a processzor aktív és mennyit idle állapotban illetve az egyes folyamatok végrehajtásával. Ezekből a korábban mért értékeket kivonva megtudható mekkora volt az átlagos processzorterhelés a két mérés között. A memória terhelés a /proc/meminfo fájlból olvasható ki. A teljes elérhető memória méretét a MemTotal mező adja meg, a szabadot pedig a MemFree. Az egyes folyamatok által felhasznált memória méretét a /proc/[pid]/statm fájlokból a VmSize mező adja meg. A /proc/[pid]/net/tcp(6), /proc/[pid]/net/udp(6) fájlokból kilehet olvasni, hogy az egyes folyamatok mely hálózati portokon keresztül kommunikálnak. Itt a local_address mezőkből kell kiolvasni a portokat.
4.3.2 Listener-ek használata A szenzorok méréseinek eléréséhez listenerek-kel kell feliratkozni. Mivel a szenzorok használata meríti az akkumulátort, figyelni kell arra, hogy csak a szükségeses szenzorok eseményeire legyen feliratkozva az alkalmazás. Amennyiben a monitorozó szolgáltatás leállításra kerül vagy nincs már szükség az adott szenzor méréseire el kell végezni a leiratozást. A helyzet meghatározáshoz a LocationListener interfészt kell implementálni. Amennyiben a készülék helyzete megváltozott, akkor az onLocationChanged callback függvényben kapja meg a készülék új helyzetét. A LocationListener-t a LocationManager-en kell feliratkozni. Meg kell adni, hogy mi legyen a helyzet meghatározás adatforrása. A forrás lehet a GPS vevő, WiFi/3G hálózat. Ezen kívül még meg kell adni hogy mennyi időnek kell eltelnie és mekkora távolságváltozás szükséges a helyzetfrissítések között. LocationManager lm = (LocationManager)getSystemService(LOCATION_SERVICE); lm.requestLocationUpdates(LocationManager.GPS_PROVIDER,
29
1000, 10, locationListener);
A szenzorok méréseinek fogadásához a SensorEventListener interfészt kell megvalósítani. Itt a szenzorok megváltozott mérései és a szenzorok pontosságának változása kezelhető le. A SensorManager-en keresztül kell feliratkozni.
4.3.3 Egyéb monitorozható jellemzők A felsorolt jellemzőkön kívül még további információk tudhatók meg az Android API-n keresztül. A TrafficStats statikus osztályon keresztül lekérhető a teljes készülék vagy egy megadott felhasználó hálózati forgalma a készülék bekapcsolása óta. public long getDeviceTraffic(){ return TrafficStats.getTotalRxBytes() + TrafficStats.getTotalTxBytes(); } public long getUserTraffic(int uid){ return TrafficStats.getUidRxBytes(uid) + TrafficStats.getUidTxBytes(uid); }
A rendszer broadcast üzenetben küld információt az akkumulátor állapotának változásáról. Erre az üzenetre az eddigiektől eltérően futási időben iratkozok fel. Ennek az az előnye, hogy feliratkozáskor a rendszer azonnal információkat add az akkumulátor aktuális állapotáról. Az értékek egy intent-en keresztül érhetők el. Amit a feliratkozáskor visszatérési értékként kapok meg, új üzenet érkezésekor pedig paraméterként. private void storeBatteryLevel(Intent batteryStatus){ int level = batteryStatus.getIntExtra(BatteryManager.EXTRA_LEVEL, -1); int scale = batteryStatus.getIntExtra(BatteryManager.EXTRA_SCALE, -1); batteryLevel = level / (double)scale; } private void storeChargeState(Intent batteryStatus){ int status = batteryStatus.getIntExtra(BatteryManager.EXTRA_STATUS, -1); plugedIn = status == BatteryManager.BATTERY_STATUS_CHARGING; }
30
4.4 Végrehajtás megvalósítása Az alkalmazás négyféle cselekvést képes végrehajtani: naplózás, értesítés, alkalmazás leállítása, hálózati forgalom korlátozása. Utóbbi vonatkozhat alkalmazások egy csoportjára vagy akár a teljes készülékre. A naplózó fájl a külső tárhelyre kerül lementésre, hogy a felhasználó könnyedén hozzáférhessen. Egy bejegyzés tartalma az aktuális idő, esemény súlyossága, esemény leírása. Utóbbi kettőt a felhasználónak kell megadni a cselekvés definiálásakor. Értesítésés létrehozása a NotificationManager segítségével történik. Létre kell hozni egy intent-et ami megjeleníti az üzenetet. Az értesítés megjelenítését a NotificationManager végzi majd el. Ezért az intent-et be kell csomagolni egy pendingintet-be. Intent intent = new Intent(context,NotificationViewer.class); pendingIntent = PendingIntent.getActivity(context, 0, intent, 0);
Létre kell hozni az értesítés, aminek tartalmazni kell egy címet, leírást és egy ikont. Végül meg kell jeleníteni azt. Notification notification = new Notification.Builder(context).setContentTitle(message) .setContentText(text) .setSmallIcon(R.drawable.ic_dialog_alert) .setContentIntent(pendingIntent).build(); notificationManager.notify(0, notification);
Egy alkalmazás leállítása az ActivityManager segítségével történhet meg. A killBackgroundProcess metódus leállítja az adott alkalmazást. Paraméterül annak a csomag nevét kell megadni. A hálózati forgalom korlátozásánál lehetőség van a teljes IP forgalom blokkolására, vagy csak kijelölt alkalmazások forgalmának akadályozására. Ennek megvalósítása a VPN szolgáltatás segítségével történik, ami minden csomag továbbítása előtt engedélyt kér a tűzfaltól. Ha a teljes forgalmat kell blokkolni, akkor egyszerűen egyik csomagot se küldi tovább, és a bejövő csomagokat se továbbítja. Amennyiben egy kijelölt alkalmazás forgalmát kell akadályozni, meg kell vizsgálni, hogy melyik helyi porton történik a kommunikáció és az az alkalmazáshoz tartozik-e. Először az IP fejlécet kell feldolgozni. Az első négy bit a verziót határozza
31
meg, ennek ismeretében megtudható, hogy hol található a payload typusát tartalmazó mező, ami alapján eldönthető, hogy TCP vagy UDP portokat kell-e figyelni. Ezután már csak be kell olvasni a helyi port értékét. A cél és a forrás portokat TCP és UDP csomagoknál is az első 32 bit adja meg. Kimenő csomag esetén a forrás portra, bejövő esetén a cél portra van szükségem. Hogy az egyes alkalmazások mely portokon figyelnek 4.3.1 fejezetben leírt módon tudható meg.
4.5 Szabályok betöltése A szabályokat tartalmazó XML fájl a készülék külső tárhelyén található meg, ezt be kell olvasni és fel kell dolgozni a tartalmát. A fájl feldolgozása az XmlPullParser osztály segítségével történik. A létrehozott objektum segítségével végig kell iterálni az elemeken. Lekérhető az aktuális elem típusa ez után az alapján a további szükséges adatok is lekérhetők az elemről. A következő elemre a next() függvénnyel lehet tovább lépni. Az Action és a Condition objektumok példányosításakor a szükséges paraméterek a szöveg mezőben vannak. El kell távolítani a speciális karaktereket, utána fel lehet darabolni a szöveget. String value = parser.nextText().replaceAll("[\u0000-\u001f]", ""); String[] values = value.split(", ");
4.6 Összefoglalás A fejlesztést az Eclipse fejlesztői környezetben történt az Android Development Tool segítségével. Az elkészült alkalmazás futtatásához 4.0-ás, vagy afölötti Android szükséges. Az elkészül alkalmazást 44 osztályból és 1787 programsorból áll. Az alkalmazás aránylag sok osztályt tartalmaz. Ez a monitorozás és a monitorozott jellemzők kiértékelésének szétválasztására vezethető vissza.
32
5 Tesztelés Tesztelés elvégzése történhetett volna unit tesztekkel, ekkor az alkalmazás egyes függvényeit vizsgáltam volna meg, hogy a megadott paraméterekre a visszatérési érték az elvártaknak megfelelő-e. Modul tesztekkel az egyes komponensein végeztem volna el a tesztelést. Rendszerteszteléssel győződtem meg az alkalmazás működéséről. Ennek előnye, hogy meggyorsítja a tesztelés folyamatát, azonban így nehezebb megtalálni az estleges hibákat. Előre definiált forgatókönyvek mentén manuálisan elvégzem az egyes teszteket és megvizsgálom, hogy minden az elvártak szerint történik-e.
5.1 T1: egyszerű szabály Az első teszt során az alkalmazás a készülék hálózati forgalmát figyeli meg, ami, ha meghaladja az 1MB-ot akkor arról értesítést ad ki. Cél: a szabály betöltés, rendszer szintű monitorozás és cselekvés végrehajtás tesztelése. Bemenet: 1 1. Teszt, A készülék hálózati forgalma meghaladta az 1 MB-ot.
Eredmény: az 1 MB-os forgalom elérése után megjelenik, az értesítés. Minden az elvártak szerint történt, a teszt sikeresen lefutott.
33
12. ábra Értesítés
5.2 T2: időzített feltétel A második teszt esetben a szabály egy megadott alkalmazás processzor terhelését figyeli, ami ha 10 másodpercen keresztül meghaladja az 50%-ot leállításra kerül. Cél: egy alkalmazás monitorozásának és az időzített feltételnek a tesztelése. Bemenet: az alábbi szabály definíció, illetve még szükséges a StressCpu példaalkalmazás futtatása is. hu.bme.mit.stresscpu 50 hu.bme.mit.stresscpu
Eredmény: az alkalmazás néhány másodpercen belül bezáródik az elvártaknak megfelelően. A teszt sikeres volt.
34
5.3 T3: VPN szolgáltatás Ebben a tesztben az alkalmazásnak le kell tiltania a böngésző hálózati hozzáférését, amennyiben a forgalma meghaladja az 1MB-to. Cél: ezzel a tesztel a VPN szolgáltatás és a port szerinti szűrés működéséről győződök meg. A szabályt az alábbi módon kell megadni. com.android.browser, 1 com.android.browser
Eredmény: a szabály betöltése után, miután a böngésző forgalma elérte az 1 MB-ot, nem lehet újabb oldalakat betölteni, azonban más alkalmazásoknak az internet elérés még mindig működik. Minden az elvártak szerint történt.
5.4 T4: összetett szabály A negyedik tesztben egy összetett szabály működését vizsgálom meg. Az alkalmazásnak értesítést kell kiadnia, amennyiben a készülék megadott hely közelében található, a készülék nincs töltőre helyezve és az akkumulátor töltöttsége 20% alatt van, vagy az akkumulátor töltöttsége 50% alatt van és a processzor terhelés 40% fölött volt az elmúlt 1 percben. Cél: Az összetett szabályok kiértékelésének tesztelése. Bemenet: 10, 10, 20
35
false 20 50 40 Töltöttség alacsony, Helyezze a készüléket a töltőre
A szabály emulátoron teszteltem, így könnyedén módosítani lehetett a különböző paramétereket. Ehhez telneten keresztül csatlakoztam az emulátorhoz. Itt parancsokon keresztül beállítottam a pozíciót a szabályban definiáltra, ezután beállítottam hogy az akkumulátor ne legyen töltés alatt és 15%-on legyen. telnet localhost 5554 geo fix 10 10 power ac off power capacity 15
Ekkor az elvártaknak megfelelően megjelent az értesítés. Ezután az akkumulátort töltöttségét 30%-ra állítottam és elindítottam a StressCpu alkalmazást. Egy perc elteltével az értesítés újra megjelent. A teszt sikeresen lefutott.
5.5 Összefoglalás Az összes teszt sikeresen lefutott. A tesztek során előfordult XML séma összes eleme, azonban kódlefedettséget nem mértem. Nem lett kipróbálva az összes feltétel és beavatkozás, azonban ezek fontosabb változatai igen. Az összes forrásból történt monitorozás (fájlrendszer, API, listener) és a fontosabb beavatkozások is ki lettek próbálva a tesztek során.
36
6 Összegzés A feladatom egy monitorozó alkalmazás elkészítése volt, ami megfigyeli a készülék és az alkalmazások különböző jellemzőit. A dolgozat során megismerkedtem az Android operációs rendszerrel, annak alapvető működésével és az alkalmazásfejlesztés alapjaival. Megvizsgáltam, hogy milyen jellemzőit lehet megfigyelni a készüléknek és a futó alkalmazásoknak, milyen cselekvéseket lehet végrehajtani. Ezután megterveztem és megvalósítottam az alkalmazást, ami előre definiált szabályokat hajt végre. A szabályok monitorozzák a készülék és a futó alkalmazások jellemzőit. Amennyiben ezen jellemzők eleget tesznek a szabályban megadott feltételeknek, a megadott cselekvések végrehajtásra kerülnek. Az alkalmazás monitorozza a CPU és memóriaterhelést, hálózati forgalom méretét, akkumulátor állapotát, készülék tartózkodás helyét. A beavatkozások segítségével naplózni lehet az eseményeket, értesíteni a felhasználót, korlátozni a hálózati hozzáférést, bezárni az egyes alkalmazásokat. Végül leteszteltem az alkalmazás működését különböző példaszabályokon keresztül. A teszteset sikeresen lefutottak, amikkel az alkalmazás fontosabb funkcióit kipróbáltam. További tervek Az alkalmazás tesztelése során nem lett az összes funkció letesztelve. További tesztesetek segítségével meggyőződhetek arról, hogy minden megfelelően működik. Fontos az is, hogy az alkalmazás jól skálázódjon. Ennek vizsgálata is további tesztestek segítségével lehetséges. A szabályokat jelenleg konfigurációs fájlon keresztül kell megadni, a későbbiekben lehetőséget szeretnék biztosítani, hogy az alkalmazásban is lehetőség legyen a szabályok megadására, menedzselésére. Ezenkívül továbbfejlesztési lehetőség még a tűzfal VPN kapcsolat nélküli megvalósítása.
37
Köszönetnyílvánítás Ezúton is szeretném megköszönni konzulensemnek, Micske Zoltánnak a szakdolgozat elkészítése közben nyújtott segítségét.
38
Irodalomjegyzék [1]
Android Developers fejlesztői dokumentáció, http://developer.android.com
[2]
Ekler Péter - Fehér Marcell - Forstner Bertalan - Kelényi Imre: Android-alapú szoftverfejlesztés, ISBN 978-963-9863-27-9, 2012
[3]
Linuxmanpages.com: Proc, http://www.linuxmanpages.com/man5/proc.5.php
[4]
Adrienne Porter Felt - Erika Chin - Steve Hanna - Dawn Song - David Wagner: Android Permissions Demystified, http://dl.acm.org/citation.cfm?id=2046779
[5]
Google play/OSMonitor: https://play.google.com/store/apps/details?id=com.eolwral.osmonitor&hl=hu
[6]
Google play/Egérút: https://play.google.com/store/apps/details?id=com.antaresnav.egerut&hl=hu
[7]
Android Security Overview, http://source.android.com/devices/tech/security/
[8]
stackoverflow: Android: Create new System Permission in through AOSP source code., http://stackoverflow.com/questions/14887948/android-create-new-systempermission-in-through-aosp-source-code
[9]
Lars Vogel: Android Service Tutorial, http://www.vogella.com/articles/AndroidServices/article.html
[10] Lars Vogel: Android Location API Tutorial, http://www.vogella.com/articles/AndroidLocationAPI/article.html [11] Lars Vogel: Android ListView Turorial http://www.vogella.com/articles/AndroidListView/article.html
39
Függelék Konfigurációs fájl sémája <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="Rules" type="RulesType"/> <xs:complexType name="RulesType"> <xs:sequence> <xs:element name="Rule" type="RuleType"/> <xs:complexType name="RuleType"> <xs:sequence> <xs:element name="ConditionExpression" type="ConditionExpressionType"/> <xs:element name="Actions" type="ActionsType"/> <xs:attribute name="Name" type="xs:string" use="required"/> <xs:complexType name="ConditionExpressionType"> <xs:choice> <xs:element name="ConditionExpression" type="ConditionExpressionType" maxOccurs="unbound"/> <xs:element name="Condition" type="ConditionType" maxOccurs="unbound"/> <xs:attribute name="Op" type="xs:string"/> <xs:complexType name="ConditionType"> <xs:attribute name="Type" type="xs:string" use="required"/> <xs:attribute name="Timed" type="xs:decimal"/> <xs:complexType name="Actions"> <xs:element name="Action" Type="ActionType"
maxOccurs="unbound"/>
<xs:complexType name="Action"> <xs:attribute name="Type" type="xs:string" use="required"/>
40
