Svagheter med denna algoritm

Då startvillkoren hårdkodats ställer det krav på användaren och hur acceleratio- nen genomförs. Algoritmen är inte heller särskilt robust; om signalen som följes tillfälligt dör ut alternativt om signalen är brusig kan målföljningen snabbt tappa sitt mål och då är det stor risk att den aldrig inner det igen.

4

Android

Källan bakom detta kapitel är Android Developer Pages (2013) och dess undersi- dor om inget annat anges.

Android är ett linuxbaserat operativsystem som ursprungligen utvecklades av Android Inc. och som sedermera köptes upp av Google (Elgin (2005)). Operativ- systemtet är i första hand designat för att användas på mobila enheter såsom mobiltelefoner och surfplattor. Ovanför operativsystemet arbetar Dalvik (aosp, 2013, tech/dalvik). Dalvik är en virtuell maskin som läser in och hanterar pro- gram som körs på applikationsnivå.

Nedan beskrivs det ytligt hur applikationer i Android är uppbyggda samt, mer djupgående, de delar av programmeringsgränssnittet som är av intresse för detta arbete.

4.1

Applikationsstruktur

En androidapplikation är uppbyggd enligt form av designmönstret Model-View- Controller (mvc, (Gamma m.l., 1995, sida 4-6)). I Androids design kan följande översättningar göras:

• Model → Model och Service, • View → Layout och

• Controller → Activity.

Detta är dock en förenkling, då en Activity också agerar som View i vissa fall; men mer om det i avsnitt 4.1.1.1.

24 4 Android MODEL VIEW CONTROLLER USER SEES UPDATES MANIPULATES RESPONDS USES

(a) Generell nomenklatur.

MODEL/SERVICE LAYOUT ACTIVITY USER SEES UPDATES MANIPULATES RESPONDS USES (b) Androids nomenklatur.

Figur 4.1: Flödesschema över hur information färdas i en applikation som implementerar designmönstret mvc.

mvcsärkopplar hur data visualiseras från själva datagenereringen. Detta gör att man kan byta ut det sätt som datan presenteras utan att behöva ändra i hur den tas fram. För att exemplifera detta kan man se en undersökning som en modell och olika diagram (tårt-, stapel- etc.) som visar resultatet för vyer. I igur 4.1 visas hur datalödet sker i mvc.

4.1.1

Resurser

Resurser är ett samlingsnamn för element som kan återanvändas eller föränd- ras beroende på hur applikationen används. Till exempel kan ordlistor för olika språk anges för att applikationen lätt ska kunna lokaliseras. Även bilder av olika storlek och upplösning kan läggas till för att sedan användas beroende av vilken skärmstorlek och upplösning som användarens plattform har. Nedan beskrivs hur en Layout deinieras och vad den måste innehålla.

4.1.1.1 Layout

För att skapa ett graiskt gränssnitt mot användaren deinieras olika element med märkspråket xml. För att inläsningsmotorn av layoutiler ska fungera måste ilen bestå av ett rotelement av typen View (Android api, 2013, View), ViewGroup (Android api, 2013, ViewGroup) eller någon underklass av dessa. ViewGroup är, som namnet antyder, en gruppering av graiska element och i layoutilen kan då ingående element deinieras. View å sin sida är ett enstaka graiskt ele- ment, till exempel ett textavsnitt (TextView). Layoutilerna kompileras och de- inierar därför bara statiska graiska element. För dynamiska element används Activityoch mer om det i avsnitt 4.1.2.1. En enkel deinition av en layout ses i källkod 4.1.1 och det graiska resultatet visas i igur 4.2.

Layoutilerna läses in i två olika steg: först läses javaklasserna in (mörkgröna tag- gar, se rad 20 i källkod 4.1.1) och sedan skickas attribut och dess värden (attribut →ljusgröna element, värden → röda element, se rad 7 i källkod 4.1.1) till klassen

4.1 Applikationsstruktur 25 1 <?xml version="1.0" encoding="UTF-8"?> 2 <RelativeLayout 3 xmlns:android= 4 "http://schemas.android.com/apk/res/android" 5 android:layout_width="fill_parent" 6 android:layout_height="fill_parent"

7 android:orientation="vertical" ><!-- Attribut -->

8 9 <TextView 10 android:id="@+id/splashText1" 11 android:layout_width="wrap_content" 12 android:layout_height="wrap_content" 13 android:layout_alignParentTop="true" 14 android:layout_centerHorizontal="true" 15 android:layout_marginTop="100dp"

16 android:text="Hello World!"

17 android:textAppearance=

18 "?android:attr/textAppearanceLarge" />

19

20 </RelativeLayout><!-- Tagg -->

Källkod 4.1.1: Definition av en layout i xml_{. En relativ layout specificeras och den} innehåller ett textfält med värdet Hello World!.

Figur 4.2: Det grafiska re- sultatet av källkod 4.1.1. Temat (färgsättning) samt den översta delen av re- sultatet definieras i appli- kationens manifest, se av- snitt 4.1.4.

för att behandlas. För att särskilja de attribut som Google har deinierat används namnrymden android och liknande kan göras för egendeinierade attribut. Mer om detta designval förklaras av androidutvecklaren Hackborn (2008).

4.1.2

Activity

En Activity (aktivitet) har till uppgift att behandla om olika händelser som kan påverka vilken samt hur data ska presenteras. Dessa aktiviteter kan initieras av en fysisk användare genom att till exempel trycka på en knapp, men även genom att en aktivitet blir matad med data från automatiska källor såsom sensorer eller datalöden från internet. Att behandla händelser tar sig många former men de kan grovt delas upp i två kategorier:

• händelser som ändrar den data som presenteras för tillfället och • händelser som byter aktivitet.

Vid händelser av det första slaget följer händelseförloppet lödet i igur 4.1b och i andra fallet pausas den aktiva aktiviteten och och läggs på stacken och en ny startas.

En androidapplikation måste ha minst en aktivitet deinierad i sitt manifest, av- snitt 4.1.4. Den aktiviteten som är först deinierad kommer automatiskt köras när applikationen startas.

26 4 Android

En aktivitet är starkt kopplad till en Layout och vanligtvis en eller lera Models.

4.1.2.1 Dynamiska grafikelement

När applikationen kompileras, kompileras även layoutilerna. Detta gör att det inte går att deiniera dynamiska graikelement i dessa iler. Dynamiken i graiken skapas istället genom att man refererar till ett vyelement via dess id och sedan använder sig av gränssnittet för att ändra det.

Ett exempel på när detta används är när antalet element som ska visas inte är känt från början, som vid söktträffar. Då kan man använda ViewGroup och dess gränssnitt för att lägga till underelement.

4.1.3

Service

Serviceär designad för att ta hand om bakgrundsprocesser som inte behöver

hanteras av användaren, men samtidigt är nödvändiga för att applikationen ska fylla sin funktion. Detta kan till exempel vara att upprätthålla en blåtandsupp- koppling eller att ta hand om nedladdningen av en il.

En service är i stort sett samma sak som en aktivitet förutom att den inte har nå- gon layout kopplad till sig. Detta gör att en användare då inte kan kommunicera direkt med en service och det är därför upp till applikationsprogrammeraren att deiniera hur kommunikationen sker.

Android deinierar två typer av livscykler för en service: • Started service (startad service) och

• Bound service (bunden service).

Den första av dessa två kallas av någon (inte nödvändigtvis av sin egen) appli- kation på med startService() och avslutas sedan inte förens en applikation kallar på servicen med funktionen stopService() eller att servicen själv kallar på stopSelf().

En bunden service startas med funktionen bindService() och avslutas med unbindService(). En sådan service kan bindas samman med lera applikatio- ner samtidigt och avslutas inte förens den sista bindningen upphör.

Det inns klasser (AsyncTask och handlerThread m.l.) som är designade för att hantera bakgrundsprocesser vid androidprogrammering. Det är upp till pro- grammeraren att bedöma vilken av teknikerna som är bäst anpassad för att lösa ett visst problem.

4.1.4

Manifest

Varje applikation måste ha ett manifest. Detta manifest beskriver hur kompila- torn ska agera för just den speciika applikationen. Manifestet kan innehålla in- formation om vilket nivå av api som ska användas, vilket tema som applikatio- nen ska ha och mycket annat.

4.2 Ljudinspelning 27 I källkod 4.1.2 visas hur ett enkelt manifest skrivs. Det går inte att veta exakt vad en applikation gör genom att bara läsa igenom manifestet, men man kan se att applikationen kräver tillåtelse att spela in ljud från ljudkällor. Vanligtvis består en applikation av ett lertal aktiviteter, men denna enkla applikation skulle till exempel kunna vara en diktafon.

Källkod 4.1.2 Ett väldigt kort manifest. Namnet på applikationen inns sparat som en strängresurs och referensen anges på rad 7. Denna applikation begär tillå- telse att spela in ljud från de ljudkällor som inns tillgängliga (rad 4).

1 <?xml version="1.0" encoding="utf-8"?>

2 <!-- . . . visar att fler argument kan definieras. -->

3 <manifest> <!-- . . . -->

4 <uses-permission android:name="android.permission.RECORD_AUDIO" /> <!-- -->

5 <application android:icon="@drawable/app_icon.png" > <!-- . . . -->

6 <activity android:name="com.i3tex.test.ExampleActivity"

7 android:label="@string/application_name" > <!-- . . . -->

8 </activity>

9 <!-- Definition av ytterligare Service eller Activity görs här. -->

10 </application>

11 </manifest>

4.2

Ljudinspelning

Detta avsnitt behandlar både de krav som ställs på en androidplattform samt de delar ur Androids api som är relevanta för ljudinspelning.

4.2.1

Plattformskrav

I Android Compatibility Deinition Document (cdd), (aosp, 2013, Compability), deinieras de krav som ställs på en plattform för att den ska vara kompatibel med Android. Varje större version av Android har sin egen kravspeciikation.

4.2.1.1 Ljudinspelning

För de nivåer på api som behandlas i detta dokument ställs följande krav för ljudinspelning:

When an application has used the android.media.AudioRecord api to start recording an audio stream, device implementations SHOULD sample and record audio with each of these behaviors:

• Noise reduction processing, if present, SHOULD be disabled. • Automatic gain control, if present, SHOULD be disabled. • The device SHOULD exhibit approximately lat amplitude ver-

sus frequency characteristics; speciically, ±3 dB, from 100 Hz to 4000 Hz

• Audio input sensitivity SHOULD be set such that a 90 dB sound power level (spl) source at 1000 Hz yields RMS of 5000 for 16-bit samples.

• pcm amplitude levels SHOULD linearly track input spl changes over at least a 30 dB range from -18 dB to +12 dB re 90 dB spl at the microphone.

28 4 Android

• Total harmonic distortion SHOULD be less than 1% from 100 Hz to 4000 Hz at 90 dB spl input level.

Från och med api 15 lades även följande till:

In addition to the above recording speciications, when an application has started recording an audio stream using the

android.media.MediaRecorder.AudioSource.

VOICE_RECOGNITIONaudio source:

• Noise reduction processing, if present, MUST be disabled. • Automatic gain control, if present, MUST be disabled.

4.2.1.2 Kodning

cddspeciicerar också vilka kodekar som en androidplattform, men dokumen-

tet är något tvetydigt gällande kodning via pcm upp till api 16. Innan dess ges det inte explicit att kodning av inspelat ljud ska kunna ske med pcm, men ett av kraven för ljudinspelning pekar mot det samt att AudioFormat, som är en stödklass till AudioRecord, har en konstant, ENCODING_PCM_16BIT (tillagd i api5), som enligt beskrivningen garanterar att kodning via 16 bitars pcm stöds av alla plattformar.

4.2.2

för ljudinspelning

I Androids api deinieras två klasser för inspelning av ljud som båda baseras på lågnivåbiblioteket openSLES 1.0.1 (Khronos Group (2013); Fornwall (2013)):

• MediaRecorder och • AudioRecord.

Dessa två klasser är frikopplade från varandra och delar endast deinitionsklas- sen MediaRecorder.AudioSource som deinierar tillgängliga mikrofonlägen.

4.2.2.1 MediaRecorder

MediaRecorderär en klass som hanterar både ljud- och videoinspelning samt

uppspelning av dessa. Den klarar även av att koda strömmarna i lertalet format i enlighet med cdd.

MediaRecorderär låst till att spela in ljud till en på förhand bestämd il. Detta gör att realtidsanalys av inspelningen omöjliggörs.

4.2.2.2 AudioRecord

AudioRecordskriver data till en buffert och kan även meddela när ett visst antal läsningar från ljudkällan har gjorts. Detta ger en frihet att analysera ljudinspel- ningen medan inspelningen är i gång. Större krav ställs dock på programmeraren, då det är upp till den att se till att all data hinner hanteras och att inte bufferten lödar över.

Del II

Experiment och framtagning av

ny algoritm

5

Deluppgifter

Då ett antal utredningar kring ursprungsproblemet behövde analyseras innan själva androidimplementationen gjordes kommer dessa presenteras i detta kapi- tel. Efter varje deluppgift drogs ett antal slutsatser och därför kommer de presen- teras med både resultat- och diskussionsdel.

5.1

Karakterisering av androidtelefoners mikrofoner

Då (aosp, 2013, Compability) enbart ställer krav på frekvenssvaret över 100 Hz behövs det utredas om hur detta kunde påverka resten av projektet då förbrän- ningsfrekvensen ligger inom ett intervall av 20 till 400 Hz.