Implementacija glasovne komunikacije z uporabo WiFi Direct tehnologij

Transkripcija

1 View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by University of Ljubljana Computer and Information Science eprints.fri Univerza v Ljubljani Fakulteta za računalništvo in informatiko Denis Fidel Implementacija glasovne komunikacije z uporabo WiFi Direct tehnologij DIPLOMSKO DELO INTERDISCIPLINARNI UNIVERZITETNI ŠTUDIJSKI PROGRAM PRVE STOPNJE RAČUNALNIŠTVO IN MATEMATIKA Mentor: prof. dr. Nikolaj Zimic Somentor: asist. dr. Mattia Petroni Ljubljana, 2018

2 Copyright. Rezultati diplomske naloge so intelektualna lastnina avtorja in Fakultete za računalništvo in informatiko Univerze v Ljubljani. Za objavo in koriščenje rezultatov diplomske naloge je potrebno pisno privoljenje avtorja, Fakultete za računalništvo in informatiko ter mentorja. Besedilo je oblikovano z urejevalnikom besedil L A TEX.

3 Fakulteta za računalništvo in informatiko izdaja naslednjo nalogo: Tematika naloge: Standard IEEE je doživel številne različice in nadgraditve. Ena izmed takšnih je tudi WiFi Direct, ki omogoča povezovanje naprav brez uporabe vstopne točke. Najpogosteje se uporablja pri prikazovanju slik iz mobilnih telefonov z operacijskim sistemom Android na modernejše televizorje. V diplomski nalogi izdelajte aplikacijo, ki bo omogočala govorno komunikacijo preko protokola WiFi Direct. Aplikacija naj bo samostojna in neodvisna od strežnikov in interneta. Aplikacija naj bo enostavna za uporabnika in naj deluje brez dodatnih sistemskih nastavitev, kot je na primer nastavitev IP številke.

4

5 Zahvaljujem se mentorju prof. dr. Nikolaju Zimicu in somentorju asist. dr. Mattii Petroniju za pomoč, odzivnosti in dostopnost v času izdelave diplomske naloge. Zahvaljujem se tudi družini in prijateljem za vso podporo v času študija in pomoč pri izdelavi diplomske naloge. Posebna zahvala gre tudi mami Tatjani in sestri Marijani za lektoriranje diplomske naloge.

6

7 Kazalo Povzetek Abstract 1 Uvod 1 2 Podobne aplikacije in cilji diplomske naloge Skype Viber FaceTime WhatsApp Messenger Wi-Fi Direct Arhitektura Odkrivanje naprav Oblikovanje skupine Odkrivanje storitev Android Arhitektura operacijskega sistema Android Osnove Android aplikacij Uporabljena orodja Android studio

8 6 Implementacija aplikacije Opis implementirane aplikacije Opis aktivnosti in fragmentov aplikacije Dodajanje pravic v datoteko manifest Aplikacija za pošiljanje zvoka v realnem času Aplikacija za pošiljanje zvoka iz datoteke Scenarij uporabe aplikacije Težave pri implementaciji aplikacije Sklepne ugotovitve Možne nadgradnje Zaključek 47 Literatura 49

9 Seznam uporabljenih kratic kratica angleško slovensko APK Android Package Manger upravitelj Android paketov VoIP Voice over Internet Protocol telefonija preko internetnega protokola ios iphone Operating System Applov operacijski sistem AP Access Point vstopna točka P2P Peer-to-peer točka-točka GO Group Owner upravitelj Android paketov SSID Service Set Identifier identifikator omrežja WPS Wi-Fi Protected Setup Wi-Fi zaščitena namestitev RTP Real-time Transport Protocol transportni protokol v realnem času API Application Programming Interface aplikacijski vmesnik TCP Transmission Control Protocol protokol za nadzor prenosa UDP User Datagram Protocol protokol za uporabniška sporočila HTTP Hypertext Transfer Protocol protokol za prenos obogatenega besedila DHCP Dynamic Host Configuration Protocol omrežni protokol za dinamično nastavitev gostitelja

10

11 Povzetek Naslov: Implementacija glasovne komunikacije z uporabo WiFi Direct tehnologij Avtor: Denis Fidel Večina že razvitih aplikacij, ki uporabnikom omogočajo zvočno komunikacijo, ne deluje brez povezave v internetno omrežje. Zato smo se v okviru diplomske naloge odločili za implementacijo aplikacije, ki bo uporabnikom omogočala zvočno komunikacijo preko protokola Wi-Fi Direct. Aplikacija bo omogočala izmenjavo zvočnih sporočil v realnem času, namenjena pa bo napravam z operacijskim sistemom Android. Problema smo se lotili tako, da smo najprej implementirali aplikacijo, ki omogoča pošiljanje zvoka s pomočjo shranjevanja v datoteko. Po uspešnem razvoju opisane aplikacije smo to nadgradili v končni izdelek. Obe različici aplikacije smo kasneje uporabili za primerjavo zakasnitev. Ključne besede: Wi-Fi Direct, Android, Walkie-Talkie, glasovna komunikacija, mobilna aplikacija.

12

13 Abstract Title: Implementation of voice communication using WiFi Direct technology Author: Denis Fidel The majority of existing applications that enable audio communication does not work without an internet connection. This led us to explore the possibilities for implementing an application that would enable users to use audio communication over Wi-Fi Direct protocol. The application, intended for devices with Android operational system, will enable real-time transfers of audio messages. The first step in addressing the problem was to implement an application that enables sending audio by saving to a file. After a successful development, the application was upgraded and developed into the end product. Later, we used both versions of the application to compare the delays. Keywords: Wi-Fi Direct, Android, Walkie-Talkie, voice communication, mobile aplication.

14

15 Poglavje 1 Uvod V današnjem času se pojavlja vse več mobilnih aplikacij, ki so namenjene medsebojni komunikaciji uporabnikov. Pojavljajo se aplikacije za medsebojno izmenjavo krajših in daljših tekstovnih sporočil, izmenjavo slikovnega gradiva in nenazadnje tudi zvočnih podatkov. Večina do sedaj implementiranih aplikacij uporabnikom ponuja komunikacijo na daljavo na podlagi dostopa do svetovnega spleta. V tej diplomski nalogi se bomo osredotočili na zvočno komunikacijo uporabnikov. Implementirali bomo aplikacijo za operacijski sistem Android, ki bo za prenos podatkov med napravami uporabljala protokol Wi-Fi Direct. Aplikacija bo omogočala tako prenos zvoka v realnem času kot tudi pošiljanje zvočnega posnetka v obliki datoteke. Oba načina bosta delovala brez uporabe svetovnega spleta ali oddaljenega strežnika za dostop do internetnega omrežja. Aplikacija, ki jo bomo implementirali v okviru te diplomske naloge bo temeljila na vzorčni aplikaciji. Namen vzorčne aplikacije je pošiljanje tekstovnih sporočil preko protokola Wi-Fi Direct. Poleg implementacije vzpostavitve neposredne povezave preko protokola Wi-Fi Direct vzorčna aplikacija vsebuje uporabniški vmesnik za pisanje, pošiljanje ter prikazovanje krajših tekstovnih sporočil. Za potrebe naše aplikacije bomo tega ustrezno prilagodili in dodali potrebno kodo za omogočanje snemanja, pošiljanja in predvajanja 1

16 2 Denis Fidel zvoka. V nadaljevanju diplomskega dela bomo v poglavju 2 podrobneje predstavili cilje diplomske naloge in predstavili aplikacije, ki že obstajajo na trgu in so sorodne naši aplikaciji. V poglavju 3 bomo opisali protokol Wi-Fi Direct in njegovo delovanje, sledilo pa mu bo poglavje o operacijskem sistemu Android, ki bo vsebovalo tudi osnove aplikacij za omenjen operacijski sistem. Poglavje 5 bo namenjeno predstavitvi orodij, ki bodo uporabljena za implementacijo zgoraj opisane aplikacije. Pred poglavjema, ki bosta namenjena sklepnim ugotovitvam in zaključku pa bomo v poglavju 6 podrobneje predstavili implementacijo obeh različic naše aplikacije. Na kratko bomo prikazali tudi scenarij uporabe naše aplikacije in težave, ki smo jih imeli pri implementaciji.

17 Poglavje 2 Podobne aplikacije in cilji diplomske naloge Glavni cilj diplomske naloge je izdelava aplikacije za prenos zvoka med dvema napravama. Prenos zvoka bo potekal v realnem času preko protokola Wi-Fi Direct, ki omogoča neposredno povezovanje naprav. Po uspešno vzpostavljeni povezavi preko Wi-Fi Direct bo na uporabnikovo zahtevo naprava posnela zvok iz mikrofona in ga v realnem času poslala drugi napravi, s katero bo povezana. Na ta način je končnim uporabnikom omogočena komunikacija, ki spominja na delovanje Walike-Talkie naprav. Izgled aplikacije lahko vidimo na Sliki 2.1. V tem poglavju si bomo podrobneje ogledali nekoliko bolj znane aplikacije, ki ravno tako omogočajo prenos zvoka med napravami. Med najbolj znanimi so npr. Skype, Viber, FaceTime, WhatsApp. Glavna razlika med našo aplikacijo in prej naštetimi bo, da bomo v našem primeru za prenos podatkov (t.j. okvirjev) uporabili protokol Wi-Fi Direct, kjer za delovanje ne potrebujemo internetne povezave, medtem ko vse naštete aplikacije za prenos potrebujejo dostop do internetnega omrežja. Za uporabo naštetih aplikacij je potrebna tudi ustrezna avtentikacija, medtem ko bo naša aplikacija delovala brez zahteve po preverjanju pristnosti. Aplikacija bo torej implementirana z namenom, da bosta lahko dve na- 3

18 4 Denis Fidel Slika 2.1: Na sliki je prikazan izgled aplikacije v dveh Android napravah, ki komunicirata preko Wi-Fi Direct [26]. pravi, ki sta na prostem oddaljeni največ 100 metrov in nista nujno povezani z zunanjim strežnikom za dostop do internega omrežja, vzpostavili neposredno povezavo in si med seboj v realnem času pošiljali zvok. Cilj je, da aplikacijo implementiramo na dva načina. V prvem načinu bomo implementirali pošiljanje podatkov v realnem času, torej brez predhodnega shranjevanja. Drugi način bo omogočal pošljanje zvoka s predhodnim shranjevanjem podatkov v datoteko, ki jo po končanem snemanju pošljemo drugi napravi. Namen implementacije obeh načinov je kasnejša primerjava zakasnitve ter primerjava kakovosti prejetega zvoka glede na način implementacije. 2.1 Skype Skype je aplikacija, ki omogoča avdio in video klice med več napravami (računalniki, pametnimi telefoni, tablicami...). Na trgu se je pojavila leta 2003, leta 2010 pa je presegla mejo 660 milijonov uporabnikov. Skype je eden od primerov t.i. VoIP aplikacije [22] (angl. voice over internet protocol). VoIP je metodologija in skupina tehnologij za zagotavljanje govornih komunikacij in multimedijskih sej preko internetnega protokola (IP). Temelj

19 Diplomska naloga 5 VoIP telefonije je prenos podatkov preko internetnega protokola (IP) ter pretvorba analognega signala v digitalnega. VoIP poleg pretvorbe signala vključuje še signalizacijo, nastavitev kanala in kodiranje [13], [17]. Aplikacija Skype za delovanje uporablja protokol Skype [18], ki temelji na arhitekturi odjemalec-strežnik, njegove specifikacije pa niso javno dostopne. Skype velja za prvi protokol, ki je implementiral povezovanje točka-točka (angl. peer-to-peer) pri IP telefoniji. Omenjen način povezovanja bo na nek način uporabljen tudi pri naši aplikaciji. Ravno tako kot pri Skypeu se namreč tudi pri naši aplikaciji uporabnika lahko povežeta v načinu točkatočka, in sicer preko protokola Wi-Fi Direct. Razlika je v tem, da lahko uporabniki Skypea komunicirajo tudi na občutno večjih razdaljah, medtem ko bo naša aplikacija delovala samo v okviru omejitev protokola Wi-Fi Direct. Tako kot ostale naštete aplikacije tudi Skype za prenos večpredstavnostnih datotek uporablja protokol UDP [9]. Slika 2.2: Na sliki lahko vidimo Skypeovo decentralizirano topologijo [19]. V primerjavi z ostalimi aplikacijami je posebnost Skypea uporaba decentraliziranega strežniškega modela. Kot je razvidno iz Slike 2.2 so v Skypeu naprave in strežniki razdeljeni na tri tipe: strežnik za avtentikacijo, strežniki Supernode in navadne naprave. Po uporabnikovi uspešni prijavi, je uporabnik povezan na enega izmed Supernode strežnikov, preko katerega se nato

20 6 Denis Fidel poveže v omrežje. Opazimo torej, da je centraliziran samo strežnik za prijavo v storitev, vsi ostali pa so decentralizirani. Tovrstnih težav nam pri implementaciji naše aplikacije ne bo potrebno reševati, saj aplikacija ne bo zahtevala prijave v storitev. Bo pa delovanje naše aplikacije centralizirano, saj ena od naprav deluje kot upravitelj skupine (angl. group handler) in s tem nadzoruje prenos podatkov med napravami. 2.2 Viber Ravno tako kot Skype je tudi Viber [8], [21] primer VoIP aplikacije. Ustanovljen je bil s strani japonskega podjetja Rakuten, in sicer kot neposredna konkurenca Skypeu. Podobno kot Skype tudi Viber za delovanje potrebuje dostop do svetovnega spleta in posledično omogoča komunikacijo pri večjih razdaljah. Najbolj opazna razlika v primerjavi z našo aplikacijo bo pri uporabi UDP protokola, ki ga Viber uporablja za potrebe realizacije VoIP komunikacije. Viber namreč za zagotavljanje dostave paketov v realnem času (ang. realtime) uporablja protokol UDP, medtem ko naša aplikacija v obeh podprtih načinih delovanja uporablja protokol TCP. TCP je bil v naši aplikaciji uporabljen predvsem zaradi zagotavljanja dostave paketov in boljše kvalitete storitve (angl. quality of service). 2.3 FaceTime Applova različica aplikacije, ki ponuja prenos zvoka in slike v realnem času se imenuje FaceTime in omogoča podobne funkcionalnosti kot že omenjene aplikacije. Obstaja tudi posebna različica FaceTime Audio, ki omogoča samo prenos avdio podatkov in je podobna zgoraj naštetim aplikacijam. Posebnost, ki jo opazimo pri Applovi rešitvi je, da ta ne omogoča skupinskih pogovorov in komunikacije več kot dveh naprav hkrati. Prednost njihove rešitve je delovanje v načinu brez povezave z zunanjim strežnikom, ki omogoča dostop

21 Diplomska naloga 7 do svetovnega spleta. To prednost ima tudi naša aplikacija. Od ios 7 dalje je namreč omogočena tudi komunikacija preko mobilnih omrežij (LTE in 3G) [11]. 2.4 WhatsApp Messenger WhatsApp Messenger je brezplačna VoIP storitev v lasti Facebooka, ki poleg glasovnih omogoča tudi video klice, pošiljanje besedil in slik ter ostalih dokumentov. Večpredstavnostna sporočila (angl. multimedia messages) so poslana s prenosom zvočne, slikovne ali video datoteke na HTTP strežnik in nadaljnjim pošiljanjem povezave do želenih podatkov. WhatsApp za izmenjavo sporočil med dvema uporabnikoma uporablja mehanizem store and forward [20], ki v osnovi deluje tako, da sporočilo shrani na WhatsApp strežnku, kjer ta počaka na uporabnikov prenos. Ko je sporočilo preneseno, izgine iz strežnika in ga ni mogoče ponovno prenesti. V naši aplikaciji bo delovanje implementirano nekoliko drugače, saj bo naprava ob uspešno vzpostavljeni povezavi ter uspešno posnetem zvoku, le-tega posredovala drugi napravi, ki bo posnetek prejela takoj in ga takoj tudi predvajala [23].

22 8 Denis Fidel

23 Poglavje 3 Wi-Fi Direct Leta 2009 je organizacija Wi-Fi Alliance ugotovila, da se pametne naprave vse več uporabljajo za shranjevanje in prenos večpredstavnostnih datotek. To je vodilo k uvedbi protokola Wi-Fi Direct, ki je bil postavljen na temeljih tradicionalnih Wi-Fi standardov. Nov standard je nadgradil prednosti tradicionalnih standardov kot so zmogljivost, varnost in enostavnost uporabe. Dodal je funkcionalnosti, ki uporabniku omogočajo enostaven in hiter prenos podatkov brez zahteve po dostopu do infrastrukturnega omrežja, tj. do omrežja vodenega s strani vstopne točke. Že omenjenim prednostim tradicionalnih standardov so bile dodane nove zmogljivosti, kot so samodejno odkrivanje naprav, prepoznavanje storitev naprave, s katero se povezujemo, boljši nadzor nad porabo energije in povezovanje naprav brez vzpostavljene povezave z internetnim omrežjem. V nasprotju s predhodnim povezovanjem v infrastrukturno omrežje, preko katerega se povežemo z drugo napravo, lahko pri protokolu Wi-Fi Direct naprave povežemo neposredno. Zaradi omogočanja neposredne povezave je standard Wi-Fi Direct poznan tudi pod imenom Wi-Fi Peer-To-Peer. Standard omogoča sočasno delovanje z ostalimi Wi-Fi standardi, kar pomeni da je lahko naprava hkrati povezana z vstopno točko in drugo napravo preko protokola Wi-Fi Direct. Poleg povezovanja v paru z drugo napravo protokol Wi-Fi Direct omogoča tudi povezovanje z več napravami hkrati [1]. 9

24 10 Denis Fidel Standard Wi-Fi Direct lahko poleg mobilnih telefonov, tablic in računalnikov uporabljajo tudi naprave kot so televizije, tiskalniki, kamere, skenerji ipd. Na začetku obstoja standarda je bil tipičen primer njegove uporabe povezovanje računalnika s tiskalnikom, z namenom pošiljanja datoteke v tisk. Eden izmed prvih standardov, ki je uporabljal protokol Wi-Fi Direct je bil tudi standard Miracast [14]. Wi-Fi Direct se pogosto uporablja tudi v Androidovih in BlackBerry napravah za medsebojno deljenje datotek (angl. file sharing) [25]. Slika 3.1: Sklad protokola Wi-Fi Direct. V naslednjih poglavjih bomo najprej predstavili arhitekturo protokola Wi-Fi Direct, nato pa si bomo podrobneje ogledali nekatere izmed njegovih novosti. Pogledali bomo postopek odkrivanja naprav, ki je nadgradnja postopka odkrivanja naprav pri tradicionalnih standardih Podrobneje bomo opisali tudi postopek oblikovanja P2P skupine, ki je nadomestila tradicionalno omrežje z vstopno točko. Nekaj več bomo povedali tudi o postopku odkrivanja storitev, ki jih ponuja naprava s katero se povezujemo. Največja novost protokola Wi-Fi Direct v primerjavi s starejšimi standardi je odkrivanje storitev, saj pri standardih omenjena funkcionalnost ni bila potrebna. V tradicionalnih omrežjih se je namreč naprava z vstopno

25 Diplomska naloga 11 točko vedno povezala z istim namenom, ki bil povezati se v svetovni splet. Omenjene novosti lahko vidimo na Sliki 3.1 in jih bomo podrobneje predstavili v nadaljevanju. 3.1 Arhitektura Kot posledica nadgradnje tradicionalnih standardov mora naprava, ki podpira Wi-Fi Direct protokol, delovanje omogočati v dveh različnih vlogah. Omogočati mora delovanje v vlogi vstopne točke (angl. access point - AP) in v vlogi odjemalca. Oba načina delovanja sta bila podprta že pri starejših standardih. Novost Wi-Fi Direct protokola je, da sta ti vlogi določeni dinamično in da lahko naprava teoretično opravlja naloge obeh vlog hkrati. Iz Slike 3.1 je razvidno, da protokol Wi-Fi Direct temelji na standardih Naprave v okviru standarda Wi-Fi Direct komunicirajo znotraj vzpostavljene P2P skupine (angl. P2P Group), ki ponuja enake funkcionalnosti kot tradicionalno Wi-Fi omrežje z vstopno točko. Vzpostavitev skupine si bomo podrobneje pogledali v razdelku 3.3. Naprava, ki v tako vzpostavljeni skupini opravlja naloge vstopne točke se imenuje P2P Group Owner (P2P GO), medtem ko naprave v vlogi odjemalca imenujemo P2P Clients. Kot že omenjeno sta vlogi dodeljeni dinamično, zato morajo naprave po postopku odkrivanja za vzpostavitev P2P skupine najprej doseči dogovor o opravljanju vloge P2P GO. Ko je vloga P2P GO dodeljena, je skupina vzpostavljena in odjemalci se lahko pridružijo skupini tako kot pri tradicionalnih omrežjih z vstopno točko. Naprave, ki delujejo kot odjemalci, lahko s P2P GO komunicirajo samo v primeru, da podpirajo ustrezen standard in zahtevane varnostne mehanizme. Naprave, ki tem pogojem ne zadostujejo, vidijo napravo P2P GO kot navadno vstopno točko in ne delujejo v okvirju protokola Wi-Fi Direct. Podobno kot vstopna točka v tradicionalnih omrežjih mora naprava, ki deluje kot P2P GO oddajati pakete beacon, s katerimi oglašuje SSID omrežja. Poleg tega pa mora podpirati mehanizme za delo v načinu majhne porabe

26 12 Denis Fidel energije in omogočati delovanje prototokolu DHCP, ki skrbi za dodelitev IP naslovov med odjemalci. Ko je P2P skupina vzpostavljena, prenos vloge P2P GO med napravami ni več mogoč. Zato morajo v primeru, da P2P GO zapusti skupino, naprave ponovno vzpostaviti skupino [24]. Slika 3.2: Primer dolovanja naprav v različnih vlogah, ki jih omogoča Wi-Fi Direct [24]. Zgornji del Slike 3.2 prikazuje primer delovanja odjemalcev (P2P clients) v dveh P2P skupinah in hkratnem delovanju naprave v vlogi P2P GO in P2P Client. Spodnji del slike prikazuje delovanje Wi-Fi Direct ob tradicionalnem brezžičnem omrežju (IEE WLAN). 3.2 Odkrivanje naprav Novost protokola Wi-Fi Direct je torej odkrivanje naprav in oblikovanje P2P skupine. Pred vzpostavitvijo P2P skupine se mora izvesti postopek odkrivanja naprav, ki je nekoliko drugačen kot pri standardih Postopek odkrivanja naprav pri protokolu Wi-Fi Direct se začne s standardnim preiskovanjem in odkrivanjem omrežij v bližini, tako kot je pri odkrivanju navadnih Wi-Fi omrežij z vstopno točko. V postopku preiskovanja

27 Diplomska naloga 13 naprava poleg omrežij, ki jih oglašujejo tradicionalne vstopne točke, vidi tudi oglaševane P2P skupine v bližini. Po preiskovanju se postopek nadaljuje z izvedbo algoritma Discovery. Algoritem se prične z izbiro frekvenčnega kanala, na katerem bo naprava poslušala prihajajoče zahteve za povezavo (angl. Probe Requests). V nadaljevanju algoritma se izmenjujeta stanji iskanja in poslušanja. V stanju iskanja naprava izvaja aktivno preiskovanje s pošiljanjem Probe Requests preko kanalov 1, 6 in 11 na frekvenčnem pasu 2,4 GHz in preko izbranih kanalov na frekvenčnem področju 5 GHz. V stanju poslušanja preko prej izbranega kanala sprejema Probe Requests in odgovarja s Probe Response. Ko se napravi uspešno odkrijeta v skladu z opisanim algoritmom, se prične postopek oblikovanja skupine, ki je opisan v naslednjem poglavju. Postopek preiskovanja lahko vidimo na Sliki 3.3, in sicer v razdelku Discovery [24]. 3.3 Oblikovanje skupine Za oblikovanje skupine je potreben dogovor o prevzemu vloge P2P Group Owner. Obstaja več načinov, da se naprave dogovorijo, katera bo imela omenjeno vlogo. Podrobneje si bomo ogledali Standard način in Autonomous način. Vzpostavljanje skupine v naši aplikaciji bomo pogledali v poglavju 6 [24] Standard način V Standard načinu se po uspešnem postopku odkrivanja naprav, opisanem v prejšnjem podpoglavju, začne faza GO Negotiation. Ta je implementirana z uporabo tristranskega rokovanja (angl. three-way handshake), v katerem si po vrsti sledijo GO Negotiation Request, Response in Confirmation. Rezultat omenjene faze je dosežen dogovor o napravi, ki bo postala P2P Group Owner in določitev kanala, na katerem bo delovala P2P skupina. Po uspešni dodelitvi vloge P2P Group Owner sledi faza WPS Provisioning, v kateri naprave vzpostavijo varno komunikacijo z uporabo Wi-Fi Protected Setup. Postopek

28 14 Denis Fidel se zaključi z Address config fazo, v kateri je napravam s pomočjo protokola DHCP dodeljen IP naslov. Delovanje Standard načina lahko vidimo na Sliki 3.3 [24]. Slika 3.3: Primer oblikovanja skupine v Standard načinu [24] Autonomous način Nekoliko enostavnejši je Autonomous način. V tem primeru naprava sama vzpostavi P2P skupino in ima posledično že vlogo P2P GO. Na izbranem kanalu začne oddajati beacon pakete, ostale naprave pa po že znanem postopku odkrijejo P2P skupino ter se priključijo z izvedbo faz WPS Provisioning in Address config. V tem načinu torej ni potrebe po fazi GO Negotiation, saj naprava samodejno postane P2P Group Owner. Delovanje Autonomous načina lahko vidimo na Sliki 3.4 [24]. Slika 3.4: Primer oblikovanja skupine v Autonomous načinu [24].

29 Diplomska naloga Odkrivanje storitev Po uspešnem oblikovanju P2P skupine, ali že prej se začne postopek odkrivanja storitev (angl. Service discovery). Umestitev omenjenega postopka v Wi-Fi Direct sklad lahko vidimo na Sliki 3.1. Odkrivanje storitev je bilo pri protokolu Wi-Fi Direct dodano z namenom prepoznavanja storitev, ki jih ponuja naprava, s katero se povezujemo. Naprava lahko na podlagi pridobljenih informacij o storitvi, ki jo ponuja druga naprava, prekine ali nadaljuje postopek oblikovanja P2P skupine. Postopek je implementiran z izmenjevanjem poizvedb (angl. queries), s katerimi na posamezni napravi upravlja protokol Generic Advertisement Protocol, ki je del standarda u. Podrobnejše delovanje je opisuje vir [24].

30 16 Denis Fidel

31 Poglavje 4 Android Android je operacijski sistem, razvit s strani Googla, ki temelji na jedru operacijskega sistema Linux. Prva komercialna različica je izšla leta 2008, ko je Google izdal prvo napravo z nameščenim operacijskim sistemom Android. V začetku je bil razvit predvsem za naprave na dotik, in sicer pametne telefone in tablice, kasneje pa so nastale tudi različice za TV, avtomobile in ure. Leta 2011 je postal najbolj prodajan operacijski sistem za pametne telefone, za katerega je danes razvitih že več kot 3 milijone aplikacij. Na Sliki 4.1 lahko vidimo najpopularnejše različice operacijskega sistema Android v juliju Najnovejša različica je bila izdana avgusta 2018 in se imenuje Android Pie [3]. V nadaljevanju poglavja si bomo pogledali arhitekturo operacijskega sistema Android, nato pa se bomo podrobneje posvetili osnovam Android aplikacij. 4.1 Arhitektura operacijskega sistema Android V tem poglavju si bomo podrobneje pogledali zgradbo operacijskega sistema Android, ki je razdeljen na štiri plasti. Na vrhnji plasti so aplikacije, sledijo jim aplikacijska ogrodja in knjižnice, najnižjo plast pa predstavlja jedro operacijskega sistema Linux. Zaporedje omenjenih plasti lahko vidimo na Sliki 4.2. [3] 17

32 18 Denis Fidel Slika 4.1: Diagram prikazuje pregled deleža uporabe najpopularnejših različic operacijskega sistema Android. [3]. Na vrhu se nahaja aplikacijska plast, ki ponuja vrsto aplikacij, med katerimi so nekatere na napravo že nameščene skupaj z operacijskim sistemom. Medtem ko jih je večina nameščenih dodatno, glede na uporabnikove zahteve in potrebe. Primeri že nameščenih aplikacij so spletni brskalnik, aplikacije za elektronsko pošto, predvajanje glasbe, upravljanje imenika ter pošiljanje in prebiranje SMS sporočil. Operacijski sistem omogoča sočasno delovanje več aplikacij, kar pomeni, da je mogoče na primer predvajati glasbo in hkrati brati elektronsko pošto. Vse aplikacije za operacijski sistem Android so napisane v programskem jeziku Java. V opisano plast sodi denimo tudi aplikacija, ki jo bomo implementirali v okviru te diplomske naloge [12]. Aplikacijski plasti sledi aplikacijsko ogrodje (angl. Application framework), ki v obliki javanskih razredov punuja različne storitve aplikacijam na višji plasti. Sem sodi na primer javanski razred WifiP2pManager, ki je bil v naši aplikaciji uporabljen z namenom upravljanja z Wi-Fi peer-to-peer povezavo. Pri razvijanju novih aplikacij imajo razvijalci možnost uporabe

33 Diplomska naloga 19 Slika 4.2: Slika prikazuje plasti operacijskega sistema Android [3]. vseh že implementiranih javanskih razredov (API-jev), ki so že bili uporabljeni v do sedaj razvitih aplikacijah. Namen nastanka omenjenih API-jev je bila poenostavitev ponovne uporabe le-teh pri izdelavi novih Android aplikacij [10], [16]. Plast, ki se nahaja pod aplikacijskim ogrodjem predstavljajo knjižnice napisane v programskem jeziku C ali C++. Razvijalec do njih dostopa preko javanskih vmesnikov, ki so del aplikacijskega ogrodja. Primer tovrstne knjižnice je denimo MediaCodec (MPEG-4 in MP3 format), ki omogoča kodiranje ali dekodiranje podatkov. Pomemben del opisane plasti je tudi Android izvajalno okolje (angl. Android Runtime). Vanj je vključena večina knjižnic, v katerih so omogočene funkcionalnosti, ki jih ponujajo izvorne knjižnice programskega jezika Java. Kot lahko vidimo na Sliki 4.2 je del Android izvajalnega okolja tudi Dalvik navidezna naprava (angl. Dalvik virtual machine), ki ima pomembno vlogo v delovanju Android aplikacij. Vsaka aplikacija v operacijskem sistemu Android namreč deluje v svojem procesu z lastnim primerkom Dalvik navidezne naprave [10].

34 20 Denis Fidel Najnižjo plast operacijskega sistema Android predstavlja jedro, ki temelji na jedru operacijskega sistema Linux, zato je pogosto tudi imenovano kot slednje. Od leta 2018 Android uporablja verzije 4.4, 4.9 ali 4.14 Linuxovega jedra, dejanska uporabljena verzija pa je od naprave do naprave različna. Jedro operacijskega sistema skrbi za osnovne sistemske storitve, kot so varnost, upravljanje pomnilnika, upravljanje procesov, način delovanja gonilnika ipd. Jedro torej deluje kot abstraktni sloj med strojno opremo in ostalim skladom operacijskega sistema. Primer je gonilnik omrežne kartice, preko katerega operacijski sistem komunicira s strojno opremo kartice [3], [12], [16]. 4.2 Osnove Android aplikacij Aplikacije so del najvišje plasti operacijskega sistema Android in so najpogosteje napisane v programskem jeziku Java. Pogosto se uporabljata tudi jezika C++ in Kotlin. Celotna koda aplikacije je prevedena in arhivirana v datoteki Android package (.apk), na podlagi katere je aplikacija tudi nameščena na vseh napravah s podprtim operacijskim sistemom Android. Vsaka aplikacija je s strani operacijskega sistema Android podprta z več varnostnimi mehanizmi, del katerih je tudi ločena izvedba posamezne od ostalih aplikacij. Ta je realizirana z zagonom vsake aplikacije v svoji Dalvik navidezni napravi, ki smo jo omenili v podpoglavju 4.1. Za varnost je poskrbljeno tudi z načelom, imenovanim principle of least privilege, ki pravi, da ima vsaka aplikacija dostop samo do tistih komponent, ki ji potrebuje za svoje delovanje in nič več. V nadaljevanju bomo pogledali tri osnovne dele vsake Android aplikacije. V prvem delu bomo predstavili osnovne komponente. Sledila bo predstavitev datoteke manifest file, v kateri definiramo uporabljene komponente in zahtevane funkcije naprave, ki jih potrebujemo za delovanje aplikacije. V poglavju bomo na kratko predstavili tretji del aplikacije, to so njeni viri (angl. Resources) [15].

35 Diplomska naloga Komponente aplikacije Vsaka Android aplikacija je sestavljena iz več osnovnih komponent. Komponente aplikacij so bistveni gradniki Android aplikacij, saj predstavljajo vstopno točko (angl. entry point) skozi katero lahko sistem ali uporabnik vstopi v aplikacijo. Delimo jih na štiri različe tipe: aktivnosti (angl. activities), storitve (angl. services), sprejemnike dogodkov (angl. broadcast receivers) in ponudnike vsebin (angl. content providers). Aktivnosti so namenjene interakciji z uporabnikom, saj so predstavljene kot uporabniški vmesnik, ki je prikazan na zaslonu naprave. Ob zagonu vsake aplikacije se na začetku zažene glavna aktivnost aplikacije (angl. main activity), preko katere lahko uporabnik dostopa do vseh ostalih delov aplikacije. Poleg aktivnosti obstajajo tudi storitve, katerih namen je ohranjanje izvajanja aplikacije v ozadju. Za njih je značilno, da z omogočajo izvedbo dolgotrajnejših operacij. Tretji tip osnovnih komponent so sprejemniki oddajnih signalov, ki aplikaciji omogočajo odziv na sistemska obvestila. Kot zadnji tip delujejo ponudniki vsebin, ki upravljajo s skupnimi podatki aplikacije (npr. podatki shranjeni v podatkovni bazi). Posebnost sistema Android je, da lahko vsaka aplikacija poleg svojih zažene tudi komponente drugih aplikacij. Na ta način bi lahko naša aplikacija za zajemanje zvoka iz mikrofona uporabila drugo aplikacijo, ki omogoča enako funkcionalnost. Kot smo že omenili, v operacijskem sistemu Android vsaka aplikacija deluje kot ločen proces, zato neposreden zagon komponente iz druge aplikacije ni mogoč. Lahko pa posamezne komponente zažene operacijski sistem, kateremu namero zagona komponente druge aplikacije sporočimo z uporabo razreda Intent [2].

36 22 Denis Fidel Datoteka Manifest Pred zagonom komponent aplikacije mora operacijski sistem vedeti, da te obstajajo oziroma so definirane. Potrebne informacije pridobi v datoteki AndroidManifest.xml, v kateri razvijalec aplikacije navede vse uporabljene komponente v aplikaciji. Poleg deklaracije komponent aplikacije ima datoteka Manifest še nalogo: prepoznavanja uporabnikovih dovoljenj, ki jih aplikacija zahteva (npr. dovoljenje za dostop do internetnega omrežja), določanja minimalne verzije operacijskega sistema, ki ga aplikacija potrebuje za pravilno delovanje, deklaracije strojne in programske opreme, ki jo aplikacija uporablja (npr. uporaba mikrofona). Več o datoteki Manifest file in njenih nalogah lahko najdemo na spletni strani [15] Viri (angl. Resources) Poleg kode, Android aplikacije za delovanje potrebujejo tudi vire (angl. resources), kot so slike, zvočne datoteke in vse, kar je povezano z vizualno predstavitvijo aplikacije. S pomočjo spreminjanja XML datotek viri omogočajo urejanje menijev, barv, animacij in kar je najpomembnejše, postavitev uporabniškega vmesnika posamezne aktivnosti. Z uporabo virov lahko torej spreminjamo izgled aplikacije brez poseganja v izvorno kodo. Uporaba dodatnih virov omogoča tudi optimizacijo aplikacije za delovanje v različnih napravah. Več o virih Android aplikacije je opisano na strani [15].

37 Poglavje 5 Uporabljena orodja Za razvoj aplikacije so uporabili Googlovo razvojno okolje Android studio, ki smo ga izbrali pred Microsoftovim Visual studijem predvsem zaradi obširne dokumentacije, ki je dostopna na spletnih straneh [4]. V nadaljevanju poglavja bomo podrobneje predstavili Android studio, njegove zmogljivosti, osnove delovanja ter izgled. 5.1 Android studio Za razvoj aplikacije smo uporabili razvojno okolje Android studio, ki temelji na programski opremi IntelliJ IDEA, razviti s strani podjetja JetBrains. Na voljo za prenos je za operacijske sisteme Windows, MacOS in Linux. Nastalo je kot nadomestitev razvojnega okolja Eclipse, ki je bilo primarno razvojno okolje za Android aplikacije [7]. Najnovejša različica razvojnega okolja Android studio zagotavlja veliko zmožnosti, med katerimi so tudi: Vizualni urejevalnik postavitve (angl. visual layout editor), ki omogoča hitro in enostavno urejanje postavitve po principu drag-anddrop, brez potrebe po ročnem urejanju XML kode. Urejevalnik omogoča tudi predogled izgleda v različnih napravah in različnih verzijah operacijskega sistema Android ter dinamično urejanje postavitve za različne 23

38 24 Denis Fidel velikosti zaslona. APK analizator (angl. Android Package Manager Analyzer), ki omogoča neposreden vpogled v sestavo APK-ja po končanem postopku izgradnje (angl. build) aplikacije. Upraba APK analizatora omogoča enostavnejše in hitrejše razhroščevanje. Zagon aplikacije z orodjem Android Emulator, ki simulira delovanje Android naprave. Android Emulator je namenjen testiranju aplikacije, ne da bi za to potrebovali fizično napravo. Prednost njegove uporabe je simulacija katere koli različice operacijskega sistema Android, kar omogoča testiranje aplikacije na različnih napravah. Pameten urejevalnik kode, ki omogoča samodejno dokončanje kode za vse podprte programske jezike (Java, Kotlin, C++) [5] Struktura projekta Pri razvoju Android aplikacije je v Android studiu ta predstavljena kot projekt, ki je podoben projektom v ostalih razvojnih okoljih kot recimo Eclipse. Vsak projekt v Android studiu je sestavljen iz enega ali več modulov, ki vsebuje datoteke z izvorno kodo in vire. Moduli so razdeljeni v tri tipe, med katerimi je največkrat uporabljen Android app module. Na Sliki 5.1 je prikazana struktura projekta v razvojnem okolju Android studio. Vse datoteke potrebne za gradnjo (podrobneje opisano v podpoglavju 5.1.3) so vidne znotraj mape Gradle Scripts, medtem ko je vsak app module sestavljen iz podmap manifests, java in res. V mapi manifest je shranjena datoteka AndroidManifest.xml, ki smo jo omenili v poglavju Mapa java vsebuje javansko izvorno kodo aplikacije, medtem ko mapa res vsebuje datoteke z viri aplikacije, o katerih smo govorili v poglavju [6].

39 Diplomska naloga 25 Slika 5.1: Slika prikazuje strukturo projekta v Android Studiu Uporabniški vmesnik Izgled Android studia in njegovo glavno okno lahko vidimo na Sliki 5.2. Glavno okno Android studia je sestavljeno iz več logičnih področij. Omenjeno razvojno okolje nam omogoča, da področja poljubno skrijemo in s tem pridobimo več prostora na področju, ki ga trenutno uporabljamo. Glavno okno je torej razdeljeno na sledeča področja, ki so prikazana na Sliki 5.2, kjer je pod zaporedno številko: 1. Orodna vrstica, ki omogoča izvedbo številnih dejanj, vključno z zagonom aplikacije in zagonom Android orodij. 2. Navigacijska vrstica, ki nam pomaga upravljati s projektom in z odpiranjem datotek za urejanje. 3. Okno urejevalnka, v katerem spreminjamo kodo. 4. Orodna vrstica, ki vsebuje gumbe, preko katerih aktiviramo želeno o- rodje. 5. Okno posameznega orodja.

40 26 Denis Fidel Slika 5.2: Glavno okno razvojnega okolja Android studio [6]. 6. Statusna vrstica, ki prikazuje status, obvestila in sporočila projekta ter razvojnega okolja [6] Gradnja aplikacije Po končanem urejanju izvorne kode in virov aplikacije in pred zagonom na napravi, jo je potrebno ustrezno prevesti in zapakirati s pomočjo APK. V Android studiu je postopek izveden s pomočjo orodja Gradle, ki je za namene Android aplikacij razvil tudi Android vtičnik. Postopku prevajanja in pakiranja na kratko rečemo tudi gradnja aplikacije (angl. build). Orodje Gradle nam med drugim omogoča, da na podlagi iste izvorne kode zgradimo aplikacijo za različne tipe naprav in različne verzije operacijskih sistemov Android [6].

41 Poglavje 6 Implementacija aplikacije 6.1 Opis implementirane aplikacije V okviru diplomske naloge bomo implementrirali Android aplikacijo (v nadaljevanju aplikacija), ki bo omogočala pošiljanje zvoka med dvema napravama preko protokola Wi-Fi Direct. Po uspešno vzpostavljeni povezavi, ki je bila implementirana že v okviru vzorčne aplikacije, opisane v uvodnem poglavju, je na zaslonu aplikacije prikazan gumb, ki ob kliku povzroči snemanje zvoka iz mikrofona. Do ponovnega klika na gumb se posneti podatki preko socketa pošiljajo napravi, s katero smo povezani, ta pa zvok sproti predvaja. Aplikacija torej spominja na komunikacijo pri Walkie-talkie napravah. Poleg delovanja v načinu pošiljanja zvoka v realnem času, pa smo aplikacijo implementirali še s pomočjo shranjevanja posnetega zvoka v datoteko. Tako kot v prej opisanem načinu, je tudi v tem primeru vzpostavljanje povezave Wi-Fi Direct enako kot pri vzorčni aplikaciji. Razlika med aplikacijama je ta, da so pri drugem načinu podatki po uspešnem zajemanju zvoka iz mikrofona najprej shranjeni v datoteko, ki jo nato preko socketa pošljemo drugi napravi. Opis implementacije obeh različic aplikacije bomo podrobneje predstavili v podpoglavjih 6.4 in 6.5. Apikacija je v Android studiu lahko sestavljena iz več javanskih razredov. Vse uporabljene razrede v naši aplikaciji lahko vidimo na Sliki

42 28 Denis Fidel Slika 6.1: Na sliki je prikazan diagram razredov naše aplikacije. Glavna aktivnost, v kateri je implementirana vzpoztavitev Wi-Fi Direct povezave, je implementirana v razredu MainActivity, ki kot pomožne razrede za vzpostavitev povezave uporablja WiFiDirectBroadcastReceiver, WiFi- P2pService, GroupOwnerSocketHandler in ClientSocketHandler. Najpomembnejši med pomožnimi razredi je razred ChatManager, v katerem je implementirano zajemanje zvoka iz mikrofona in pošiljanje v socket. V omenjenem razredu je implementirano tudi branje in predvajanje podatkov, kar bomo podrobneje pogledali v podpoglavju 6.4. Poleg naštetih razredov pa aplikacijo sestavljata tudi fragmenta WiFi- DirectServicesList in AudioRecordFragment, ki ju bomo poleg glavne

43 Diplomska naloga 29 aktivnosti predstavili v naslednjem podpoglavju. 6.2 Opis aktivnosti in fragmentov aplikacije Ob zagonu aplikacije se zažene glavna aktivnost aplikacije, katere primarna naloga je vzpostavitev Wi-Fi Direct povezave s pomočjo pomožnih razredov, ki smo jih našteli v prejšnjem poglavju. Po uspešnem odkrivanju naprav v bližini, glavna aktivnost zažene fragment WiFiDirectServicesList, ki omogoča prikazovanje seznama vseh naprav, s katerimi se lahko uporabnik poveže. Prikaz seznama naprav lahko vidimo na Sliki 6.2. Ob kliku na eno od prikazanih naprav se iz fragmenta kliče ustrezna metoda, ki poveže napravi preko protokola Wi-Fi Direct. Slika 6.2: Izgred fragmenta WiFiDirectServicesList.java. Po uspešno vzpostavljeni povezavi med napravama, glavna aktivnost zažene fragment AudioRecordFragment. Ta je zadolžen za prikazovanje gumba Start streaming in izvajanje kode ob kliku na le-tega. Njegov izgled smo že videli na Sliki 2.1. Dodajanje gumba v fragment smo implementirali kot je prikazano na Sliki 6.3. Uporabljen je bil torej razred android.widget.linearlayout, ki vsebuje metodo addview (...). Z omenjeno metodo smo na fragment

44 30 Denis Fidel dodali gumb za začetek in konec snemanja podatkov, in sicer tako, da metodi kot parameter posredujemo objekt tipa RecordButton. Objekti razreda RecordButton razširjajo razred android.widget.button, ki je namenjen prikazovanju elementa na katerega lahko uporabnik klikne in s tem povzroči določeno akcijo. Razred android.widget.button torej implementira vse potrebne metode in konstruktorje za delo z gumbi. Slika 6.3: Slika prikazuje kodo za dodajanje gumba v fragment. 6.3 Dodajanje pravic v datoteko manifest Aplikacija v operacijskem sistemu Android mora imeti za uporabo občutljivejših sistemskih funkcij ustrezne pravice. V podpoglavju smo omenili, da je potrebno dovoljenja za delovanje aplikacije vključiti v datoteko AndroidManifest.xml. Aplikacija, ki jo bomo implementirali v okviru diplomske naloge za svoje delovanje zahteva sledeče pravice, ki jih lahko vidimo tudi na Sliki 6.4: ACCESS NETWORK STATE, CHANGE NETWORK STATE in IN- TERNET, za dostop in spreminjanje informacij o omrežju ter izvajanje omrežnih ukazov. ACCESS WIFI STATE in CHANGE WIFI STATE, za dostop in spreminjanje informacij o brezžičnih omrežjih. READ PHONE STATE, za dostop do informacij o mobilni napravi. RECORD AUDIO, za omogočanje snemanja zvoka iz mikrofona.

45 Diplomska naloga 31 WRITE EXTERNAL STORAGE, za pisanje na zunanji pomnilnik, ki ga bomo potrebovali za shranjevanje datoteke pri drugem načinu implementacije. MODIFY AUDIO SETTINGS, za spreminjanje zvočnih nastavitev. Slika 6.4: Vsebina datoteke AndroidManifest.xml. Brez naštetih dovoljenj nobena izmed različic naše aplikacije ne bi mogla delovati pravilno. Nekatere od naštetih pravic ob prvem zagonu aplikacije zahtevajo dodatno potrditev uporabnika. 6.4 Aplikacija za pošiljanje zvoka v realnem času Glavni cilj doplomske naloge je implementirati aplikacijo za pošiljanje zvoka v realnem času. Zato bomo v naslednjih podpoglavjih predstavili implementacijo snemanja zvoka iz mikrofona, pošiljanje in prejemanje podatkov preko socketa ter predvajanje zvoka.

46 32 Denis Fidel Snemanje zvoka Snemanje zvoka iz mikrofona se začne z uporabnikovim klikom na gumb Start streaming, ki povzroči klic metode startmic () iz razreda ChatManager. Njeno izvorno kodo lahko vidimo na Sliki 6.5. Slika 6.5: Implementacija metod void startmic () in void mutemic (). Snemanje je implementirano z uporabo knjižnice android.media.audiorecord. Ob kreiranju objekta tipa AudioRecord lahko preko parametrov konstruktorju posredujemo podatke o izvoru zvoka, frekvenci vzorčenja zvoka v hercih, formatu zvoka in velikosti medpomnilnika v bajtih. Po uspešni inicializaciji objekta lahko snemanje zvoka začnemo s klicom metode startrecording (). Snemanje zvoka je lahko potratna operacija v smislu, da mora nit, na kateri deluje, ostati ves čas aktivna. To je razlog, da smo za njegovo izvedbo uporabili ločeno nit (angl. thread) in ne nit glavne aktivnosti.

47 Diplomska naloga 33 Podobno kot pri prvem uporabnikovem kliku na gumb Start streaming se ob naslednjem kliku, s katerim naznanimo zaključek snemanja zvoka, kliče metoda mutemic (). Ta nastavi vrednost spremenljivke mic na false in s tem povzroči prekinitev izvajanja zanke znotraj metode startmic (). Posledično se kličeta metodi stop () in release (), po izvedbi katerih je snemanje zaključeno. Na Sliki 6.5 lahko znotraj zanke opazimo klic metode write (...) iz razreda ChatManager, katere pomen bomo pojasnili v naslednjem podpoglavju Pošiljanje in prejemanje podatkov preko socketa Pri načinu implementacije aplikacije, ki ga trenutno opisujemo, je potrebno napravi na drugi strani posnete podatke pošiljati sproti. Odločili smo se, da za pošiljanje in prejemanje podatkov preko protokola Wi-Fi Direct uporabimo socket. Ta namreč omogoča branje in pisanje podatkov s pomočjo knjižnic java.io.inputstream in java.io.outputstream. Za pisanje podatkov v socket nam knjižnica java.io.inputstream ponuja metodo write (...), ki kot parametre sprejme posnete podatke v obliki tabele bajtov, podatek o odmiku ter podatek o številu bajtov, ki bodo poslani. Naprava na drugi strani bere podatke znotraj metode run () razreda ChatManager. Implementacijo metode v naši aplikaciji lahko vidimo na Sliki 6.6. Na začetku metode so bile inicializirane vse potrebne spremenljivke za branje in pisanje podatkov preko socketa. Inicializiran je bil tudi objekt tipa AudioTrack, ki je uporabljen za predvajanje zvoka in ga bomo opisali v naslednjem podpoglavju. Za branje podatkov smo uporabili metodo int read (...) razreda InputStream, ki sprejme enake argumente kot metoda write (...), s to razliko, da gre v tem primeru za prebrane podatke. Metoda nam vrne število uspešno prebranih podatkov iz socketa, ki jih posredujemo objektu tipa AudioTrack.

48 34 Denis Fidel Slika 6.6: Implementacija metode run () Predvajanje zvoka Glede na to, da poskušamo predvajati zvok v realnem času, moramo prebrane podatke iz socketa predvajati takoj, torej brez shranjevanja. Zaradi zmožnosti delovanja v t. i. streaming načinu smo za predvajanje zvoka uporabili knjižnico android.media.audiotrack. Želen način predvajanja smo določili preko konstruktorja, s katerim določimo tudi frekvenco vzorčenja v hercih, nastavitve prenosnega kanala, format zvoka in velikost medpomnilnika v bajtih. Predvajanja zvoka lahko začnemo s klicem metode play (), same podatke za predvajanje pa objektu tipa AudioTrack podamo s pomočjo metode write (). Ko so vsi podatki prebrani, predvajanje zaključimo z za-

49 Diplomska naloga 35 porednim klicem metod stop (), flush () in release (). Predvajanje zvoka je implementirano znotraj metode run (), ki je prikazana na Sliki Aplikacija za pošiljanje zvoka iz datoteke Drugi način, ki smo ga uporabili za implementacijo aplikacije prav tako omogoča pošiljanje zvoka preko protokola Wi-Fi Direct. Gre za način pošiljanja s pomočjo datoteke. Aplikacija v tem primeru deluje tako, da podatke posnamemo, jih shranimo v datoteko in jih po končanem snemanju preko socketa pošljemo drugi napravi. V nadaljnjih podpoglavjih bomo predstavili tudi slednji način implementacije. Slika 6.7: Implementacija metod startrecording () in stoprecording () Snemanje zvoka in shranjevanje v datoteko V tem načinu implementacije je na fragment AudioRecordFragment dodan gumb Start recording, ki je objekt tipa RecordButton. Ob kliku na gumb za začetek snemanja se kliče metoda startrecording (), ki implementira zajemanje zvoka iz mikrofona in sprotno shranjevanje v datoteko. Kot vidimo na

50 36 Denis Fidel Sliki 6.7 je snemanje zvoka v tem načinu implementirano s pomočjo knjižnice android.media.mediarecorder. Po kreiranem objektu tipa MediaRecorder najprej nastavimo izvor podatkov na mikrofon in nato določimo format izhodne datoteke. V naslednjem koraku določimo datoteko, v katero naj objekt shranjuje podatke (pred tem smo v spremenljivko mfilename shranili absolutno pot novo nastale datoteke), na koncu pa izberemo še tip kodiranja. S klicom metod prepare () in start () se začne snemanje in shranjevanje podatkov v datoteko. Ob uporabnikovem kliku na gumb za konec snemanja najprej kličemo metodo stoprecording (), ki s pomočjo metod vidnih na Sliki 6.7 zaključi snemanje iz mikrofona. V nadaljevanju sledita pretvorba datoteke v tabelo bajtov in pošiljanje, ki ju bomo predstavili v naslednjem podpoglavju Pošiljanje in prejemanje datoteke Pri tem načinu implementacije moramo datoteko pred pošiljanjem pretvoriti v tabelo bajtov, šele nato jo lahko posredujemo razredu ChatManager, ki podatke zapiše v socket. Prevorba datoteke je implementirana s pomočjo metode convert (String fname), ki preko parametra pridobi ime datoteke, vrne pa ustrezno generirano tabelo bajtov. Izvorno kodo metode za pretvorbo datoteke lahko preberemo na Sliki 6.8. Postopek implementacje je sledeč. Najprej na podlagi imena datoteke, ki jo pretvarjamo, kreiramo nov objekt tipa InputStream, s pomočjo katerega bomo brali podatke iz datoteke. Kreiramo tudi tabelo bajtov ustrezne velikosti, nato pa kličemo pomožno metodo tobytearray (InputStream in), ki nam vrne želeno tabelo. Za kreiranje tabele je v slednji metodi uporabljen objekt tipa ByteArrayOutputStream, kateremu posredujemo prebrane podatke iz datoteke. Na koncu s klicem metode tobytearray () kreiramo želeno tabelo. Ko je tabela bajtov usprešno kreirana, jo preko metode write (byte[] buffer) posredujemo razredu ChatManager. Ta s pomočjo DataOutput- Stream v socket najprej zapiše dolžino podatkov s klicem metode writelong

51 Diplomska naloga 37 Slika 6.8: Implementacija metod convert (String fname) in tobytearray (InputStream in). (len), kjer je len spremenljivka tipa long, ki hrani dolžino podatkov, za tem pa še podatke same. Implementacijo metode za pisanje v socket vidimo na Sliki 6.9. Slika 6.9: Implementacija metode write (). Prejemanje datoteke je implementirano znotraj metode run () v razredu ChatManager, podobno kot pri prvi različici aplikacije. Implementacijo metode v tej različici vidimo na Sliki V tem primeru je uporabljen razred

52 38 Denis Fidel Slika 6.10: Implementacija metode run (). DataInputStream, saj ta omogoča branje različnega tipa podatkov iz socketa. Metoda readlong () nam namreč omogoča, da najprej preberemo podatek o številu bajtov, ki jih pricakujemo (velikost datoteke), nato pa s pomočjo metode read (byte[] buffer) preberemo še podatke datoteke. Ko se število prebranih bajtov ujema z velikostjo datoteke, s pomočjo metode tobytearray () razreda ByteArrayOutputStream kreiramo tabelo in jo posredujemo fragmentu AudioRecordFragment. Ta iz tabele ponovno tvori datoteko in jo nato predvaja. Podatke razredu AudioRecordFragment posredujemo z uporabo metod obtainmessage (...) in sendtotarget (), ki podatke posredujeta glavni aktivnosti. Znotraj glavne aktivnosti je implementirana metoda handlemessage (Message msg), ki nato podatke po-