Android Applikation zur Bestimmung der Genauigkeit von Smartphone Sensoren

Transkript

1 Android Applikation zur Bestimmung der Genauigkeit von Smartphone Sensoren Andreas Gabel Bachelor-Arbeit 22. August Lehrstuhl für Systemsicherheit. Erstgutachter: Zweitgutachter: Betreuer: Prof. Dr. Thorsten Holz Dr. Christopher Wolf Dipl. Inf. Sebastian Uellenbeck

2

3 Zusammenfassung Über die Genauigkeit von Smartphone Sensoren ist derzeit nicht viel bekannt, dabei ist sie von großer Bedeutung bei der Entwicklung von qualitativ hochwertigen sensorbezogenen Applikationen. Diese Arbeit thematisiert daher die Ermittlung der Präzision von Sensoren in Android Smartphones und Tablet-PCs. Hierzu wurde eine Android Applikation entwickelt, die gemessene Sensordaten analysiert und bewertet. Die gewonnen Ergebnisse werden schließlich in einem Vergleich mit weiteren Sensorergebnissen anderer Geräte angezeigt. Es hat sich herausgestellt, dass sich die Genauigkeit von Sensoren anhand der Voraussetzungen für eine präzise Messung bewerten lässt. Außerdem wurde festgestellt, dass technische Angaben von Sensoren kein Indiz bezüglich der Präzision liefern.

4 Erklärung Hiermit versichere ich, dass ich die vorliegende Arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, dass alle Stellen der Arbeit, die wörtlich oder sinngemäß aus anderen Quellen übernommen wurden, als solche kenntlich gemacht sind und dass die Arbeit in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegt wurde. Datum Autor

5 Inhaltsverzeichnis 1 Einführung Verwandte Arbeiten Gliederung Bewertung der Sensoren Sensoreigenschaften Initialisierung Benchmark Bewertungskategorien Benchmark-Szenarien SensMark: Struktur, Design und Usability Kompatibilität Struktur, Benutzeroberfläche und Handhabung Berechtigungen Evaluation Accelerometer Daten Gyroskop Daten Orientierungssensor Daten Fazit Vorteile präziser Sensoren Zukünftige Weiterentwicklungen A Akronyme 43 Abbildungsverzeichnis 45 Tabellenverzeichnis 47 Literaturverzeichnis 49

6

7 1 Einführung Die Entwicklung und Verbreitung von Smartphones schreitet rapide voran, sie verfügen über mehr Rechenleistung, neue Technologien und diverse Sensoren. Während sich die Rechenleistung in Form von Taktfrequenz messen und per Benchmarks prüfen lässt, gilt dies jedoch nicht für die verbauten Sensoren in den Geräten. Über die Leistung bzw. die Genauigkeit der Sensoren gibt es keine Angaben, selbst unter den technischen Details der Geräte auf den Hersteller Webseiten findet man keine Informationen über die jeweils verbauten Sensoren. Sensoren werden für unterschiedliche Zwecke eingesetzt, der Helligkeitssensor beispielsweise passt die Displaybeleuchtung abhängig von dem Umgebungslicht automatisch an, der Annäherungssensor deaktiviert beim Telefonieren das Display wenn man das Gerät nah ans Ohr hält, um versehentliche Eingaben durch Berührung mit der Wange zu verhindern. Bewegungssensible Sensoren wie der Accelerometer, Orientierungssensor und das Gyroskop werden zur Ausrichtung des Displays (Hochoder Querformat), zur Steuerung von Spielen, aber vorallem zur Untergrund- und Innenraum-Navigation genutzt. Beim Navigieren sind präzise Sensoren besonders vorteilhaft, da sie eine Person basierend auf gemessenen Beschleunigungs- und Orientierungsdaten sowie der aktuellen Position zu einem Ziel führen können, fehlerhafte Daten führen die Person jedoch an falsche Ziele. Solche sogenannten Pedestrian Dead-Reckoning (PDR) Systeme benötigen keine bestehende Infrastruktur wie zum Beispiel GPS oder andere stationäre Indoor Localization Systeme, die auf WLAN oder Bluetooth basieren. Das Prinzip der Lokalisierung des PDR funktioniert wie folgt: Von einem bekannten Startpunkt aus werden mittels Accelerometer, Gyroskop und Orientierungssensor Schrittlänge und Anzahl der Schritte des Fußgängers geschätzt und daraus die zurückgelegte Strecke und Richtung bestimmt [7]. Jedoch haben PDRs ein bekanntes und für Smartphone Sensoren typisches Problem namens Sensor Drift, es bezeichnet die ungenaue Schätzung der Distanz und Richtung, welche aus dem Drift Fehler entsteht, der im weiteren Verlauf exponentiell steigt [15]. Diese Ungenauigkeit entsteht zum einen dadurch, dass ein Smartphone nicht immer an der selben Stelle getragen wird, oft auch in der Hand, dort werden deutlich mehr Bewegungen registriert, welche dann verarbeitet werden müssen. Zusätzlich beeinträchtigt aber auch die Störanfälligkeit kostengünstiger Sensoren die Genauigkeit. Es gibt diverse Ansätze wie sich der Fehler reduzieren lässt, zum Beispiel durch den Austausch von Positionsinformationen unter den Geräten der Nutzer an einem Ort [7], durch Abstimmung der Laufstrecke mit dem jeweiligen Grundriss [15], oder durch die Positionsbestimmung mittels verfügbarer WLAN-Netze und deren Signalstärke [9]. Während davon auszugehen ist, dass Apples iphone Modelle jeweils baugleich sind

8 8 1 Einführung und es somit nur wenige verschiedene Sensoren in diesen Geräten gibt, so ist dies bei Geräten mit Googles marktführendem mobilen Betriebssystem Android gänzlich anders. Android ist eine freie Software, die größtenteils unter der Apache 2.0 Lizenz und zum Teil unter der GPLv2 Lizenz steht [2]. Hiermit ist es Smartphone und Tablet-PC Herstellern möglich das Betriebssystem mit ihren Geräten zu vertreiben, ohne dafür Lizenzgebühren an Google zahlen zu müssen. Durch die somit entstandene Vielzahl an Geräten unterschiedlicher Preisklassen, im Zusammenhang mit dem einhergehenden Erfolg von Android, entstand eine Fragmentierung des Betriebssystems mit fast 4000 verschiedenen Android Geräten, dies geht aus einer Studie von Staircase 3 Inc. hervor. Dazu wurden über einen Zeitraum von sechs Monaten die Modellbezeichnung, Marke, Bildschirmgröße und Android Version der Geräte erfasst, auf denen die Applikation OpenSignalMaps installiert wurde. Insgesamt haben in dem Zeitraum Nutzer die Applikation auf verschiedenen Geräten heruntergeladen [13]. Hierbei gilt jedoch zu beachten, dass die verwendete Variable android.build.model zum Auslesen der Modellbezeichnung durch sogenannte Custom-ROMs 1 überschrieben werden kann und somit Geräte durch Geräte mit Custom-ROMs oder durch seltene Geräte repräsentiert werden. Abbildung 1.1: Fragmentierung von Android, auf Basis der OpenSignalMaps Downloads nach einer sechs monatigen Studie im Mai Jedes Rechteck repräsentiert ein Android Gerät, die Größe des Rechtecks gibt Auskunft über die Verbreitung. Anhand Abbildung 1.1 lässt sich die Fragmentierung der Geräte sehr gut erkennen, es geht deutlich hervor, dass das Modell GT-I9100, besser bekannt als Samsungs Ga- 1 Ein Custom-Rom bezieht sich in diesem Fall auf ein Android-Betriebssystem, das nicht vom ursprünglichen Hersteller stammt, sondern dessen Originalversion ersetzt.

9 1.1 Verwandte Arbeiten 9 laxy S2, am meisten verbreitet ist. Bei einer so hohen Anzahl verschiedener Geräte mit unterschiedlichen Hardwarekomponenten liegt die Vermutung nahe, dass die Anzahl unterschiedlicher Sensormodelle gleichen Typs ähnlich hoch sein wird und die Sensoren jeweils etwas andere Daten messen. Aus diesem Grund wurde im Rahmen dieser Arbeit die Android Applikation SensMark entwickelt, sie bietet Aufschluss über die Genauigkeit der in Android Smartphones und Tablet-PCs verbauten Sensoren. Dabei dient SensMark als Sensor-Benchmark, es analysiert und bewertet die gemessenen Werte der Sensoren und präsentiert schließlich die gewonnenen Ergebnisse im Vergleich mit den Ergebnissen anderer Geräte. Als Entwicklungs- und Testgerät wurde das Samsung Galaxy S2 GT-I9100 mit Android Version eingesetzt, zu Kompatibilitätstests wurde der Lenovo Ideapad A1 Tablet-PC mit Android herangezogen. 1.1 Verwandte Arbeiten Es existiert eine Vielzahl an Arbeiten, die sich dem Gebrauch von Sensoren für diverse Zwecke annehmen. So thematisieren [6, 7, 9, 15] Ansätze für die Lokalisierung und Navigation von Personen in Gebäuden anhand von Smartphone Sensoren. Speziell wird in [6] der Accelerometer dafür eingesetzt die Etage zu ermitteln, auf der sich die Person befindet. In [14] werden Sensoren zur Nutzeridentifikation auf Smartphones benutzt, dabei wird über die erhaltenen Sensordaten ein Profil des Nutzers erstellt. Bedient ein anderer Benutzer das Smartphone, kann dies durch unterschiedliche Bewegungsabläufe erkannt werden und der Nutzer wird zu einer aktiven Authentifizierung aufgefordert. Mit einem vergleichbaren Ansatz beschäftigt sich [10], mit dem Ziel die aktive Nutzerauthentifizierung zu reduzieren und nur dann einzusetzen, wenn das Smartphone nicht vom Besitzer bedient wird. In einer ersten Studie mit 9 Probanden konnten benötigte aktive Authentifizierungen auf 42% gesenkt werden und dennoch konnte ausreichende Sicherheit garantiert werden. Dies ist besonders sinnvoll für Personen, die bisher gänzlich auf Sicherheitsmechanismen auf ihren Geräten verzichten. Obwohl bei all diesen Arbeiten Sensordaten von essentieller Bedeutung sind und der resultierende Sensor Drift Fehler bekannt ist, wird in keiner Arbeit die Genauigkeit von Sensoren behandelt. Nach bestem Wissen ist uns auch keine Arbeit bekannt, die sich bisher mit diesem Thema auseinandersetzt. 1.2 Gliederung Zu Beginn dieser Arbeit wird auf die Unterschiede physikalischer und virtueller Sensoren sowie deren Eigenschaften eingegangen. Im Anschluss wird die in der SensMark Applikation verwendete Bewertung der Sensoren beschrieben, welche sich in Initialisierung und Benchmark gliedert.

10 10 1 Einführung Das darauffolgende Kapitel behandelt die Struktur, Benutzeroberfläche und Kompatibiltät der entwickelten SensMark App, außerdem werden die verwendeten Berechtigungen erläutert. Sodann wird die Evaluation thematisiert, hier werden die gesammelten Ergebnisse von verschiedenen Smartphones dargestellt und Auffälligkeiten angeführt. Abschließend werden in einem Fazit die gewonnenen Erkenntnisse zusammenfassend wiedergegeben sowie ein Ausblick auf denkbare Weiterentwicklungen und mögliche Verbesserungen von SensMark gegeben.

11 2 Bewertung der Sensoren Die Bewertung der in Android Geräten verbauten Sensoren erfolgt in zwei Schritten. Bevor man einen Sensorbenchmark ausführt, muss die Initialisierung aller Sensoren durchgeführt werden. Die aus diesem Prozess gewonnenen Ergebnisse fließen dann bei der Benchmarkberechnung mit in die Beurteilung des Sensors ein. Voraussetzung für eine vergleichende Analyse der erzielten Resultate ist ein einheitliches Testszenario, das jeder mit jedem Gerät unter einfachen Bedingungen nachstellen kann. 2.1 Sensoreigenschaften Android Geräte besitzen eine unterschiedliche Anzahl an Sensoren. Das für diese Arbeit verwendete Entwicklergerät Samsung Galaxy S2 (GT-I9100) listet insgesamt sechs physikalische und fünf virtuelle Sensoren, das zu Testzwecken herangezogene Lenovo Ideapad A1 listet hingegen nur zwei physikalische und zwei virtuelle Sensoren. Physikalische Sensoren sind beispielsweise Accelerometer, Gyroscope, Magnetic Field Sensor, Light Sensor, Orientation Sensor, Pressure Sensor, Proximity Sensor und Temperature Sensor. Die von diesen Sensoren ausgegebenen Werte stammen direkt von der jeweils verbauten Hardwarekomponente, welche Änderungen bezüglich ihrer physikalischen Eigenschaft in ihrer Umgebung misst. Die Qualität der ausgegebenen Daten ist stark abhängig von der Genauigkeit, Auflösung, dem Rauschen sowie der Abtastrate des physikalischen Sensors. Virtuelle Sensoren wie der Corrected Gyroscope Sensor, Gravity Sensor, Linear Acceleration Sensor, Orientation Sensor und Rotation Vector Sensor liefern Werte, welche auf den gewonnen Ergebnissen physikalischer Sensoren beruhen. Der Rotation Vector Sensor zum Beispiel ermittelt den Winkel der Lage des Geräts im drei-dimensionalen Raum. Für diese Berechnung wird auf die gemessenen Werte des Accelerometers, Magnetic Field Sensors und zum Teil auf die des Gyroscopes zurückgegriffen. Mittels des Rotation Vector eines Geräts lassen sich Gravitation (Gravity Sensor) und lineare Beschleunigung (Linear Acceleration Sensor) anhand der Accelerometerdaten bestimmen. Die Qualität virtueller Sensoren ist nicht nur abhängig von der Qualität der physikalischen Sensoren, sondern auch von der Qualität der implementierten Algorithmen zur Berechnung der Werte [12]. Virtuelle Sensoren werden vom Betriebssystem bereitgestellt und lassen sich daher unter Android unabhängig

12 12 2 Bewertung der Sensoren vom Typ vor allem an der Herstellerangabe Google Inc. von physikalischen Sensoren unterscheiden. Gibt es mehrere Sensoren gleichen Typs in einem Gerät, so gibt es jeweils einen physikalischen und virtuellen Sensor. Pro Event, welches der Event-Listener eines Sensors registriert, wird für jede Sensorachse jeweils ein Wert vom Datentyp Float zurückgegeben. Der Light-, Proximity- und Temperature Sensor messen nur auf einer Achse und geben den Wert in der jeweiligen SI Einheit aus (Light Sensor: Lux, Proximity Sensor: Zentimeter, Temperature Sensor: Grad Celsius). Alle anderen physikalischen Sensoren besitzen mindestens drei Achsen, diese sind im Koordinatensystem der SensorEvent API definiert. Abbildung 2.1: Definition des Koordinatensystems der SensorEvent API [4]. Das Koordinatensystem ist relativ zum Display eines Smartphones festgelegt, die Achsen werden nicht vertauscht, wenn sich die Orientierung des Bildschirms (Hochbzw. Querformat) ändert. Wie in Abbildung 2.1 zu sehen, verläuft die X-Achse horizontal und zeigt nach rechts, die Y-Achse ist vertikal und zeigt nach oben, die Z-Achse zeigt aus dem Gerät heraus, ausgehend von der Displayseite des Geräts. Koordinaten hinter dem Bildschirm besitzen negative Werte auf der Z-Achse. Android Sensoren besitzen des Weiteren folgende technische Angaben 1, die sich sehr einfach auslesen lassen, darunter: Sensortyp, Sensorname, Hersteller des Sensors, Version des Sensormoduls, Maximales Spektrum in der jeweiligen SI Einheit (Maximum Range), Minimale zeitliche Verzögerung zwischen zwei aufeinanderfolgenden Werten in Mikrosekunden (Minimum Delay), Auflösung des Sensors in SI Einheit (Resolution) und Stromverbrauch in Milliampere (Power). Allerdings geben manche Sensoren bei den letzten vier Angaben den Wert 0 aus, so dass sich diese Eigenschaften lediglich als Information nutzen lässt, nicht aber für Berechnungen. Gibt ein Sensor bei Minimum Delay 0 zurück so bedeutet das, dass er nur dann einen Wert ausgibt, wenn sich die gemessenen Daten ändern. 1 [3]

13 2.2 Initialisierung Initialisierung Der Initialisierungsprozess ist Voraussetzung für einen Benchmark, er muss mindestens einmal pro Gerät durchgeführt werden, bevor man einen Sensor prüfen kann. Aufgrund der Tatsache, dass Sensoren nicht zwingend in einem bestimmten Intervall Werte zurückliefern, ist es in Bezug auf einen Benchmark sinnvoll Sensoren zur Ausgabe von Werten zu zwingen und die Frequenz später mit den Ausgabezeiten einer Ruhephase zu vergleichen. Für die erzwungene Ausgabe dient die Initialisierung, zehn Sekunden lang soll hierbei das Gerät bewegt werden, möglichst in verschiedene Richtungen und unterschiedlichen Bewegungsgeschwindigkeiten, um möglichst viele verschiedene Werte zu sammeln. Der Initialisierungsprozess beginnt mit der Aktivierung der Event-Listener aller sich im Gerät befindlichen Sensoren. Durch die Bewegung während dieses Zeitraums sollen bewegungssensible Sensoren wie Accelerometer, Gyroskop, Orientierungssensor und Magnetic Field Sensor zur Ausgabe von Werten provoziert werden. Alle ermittelten Werte und deren Zeitstempel werden zunächst in chronologischer Reihenfolge in Array Listen gespeichert. Aus den Zeitstempeln der einzelnen Werte wird jeweils der Zeitraum zwischen den Events bestimmt (im Folgenden Zeitdifferenz genannt) und über die Standardabweichung für auflaufende Messwerte deren Kontinuität berechnet. Die Standardabweichung berechnet sich wie folgt: σ = 1 x 2 n 1 k 1 2 x k n 1 k n 1 k n (Standardabweichung, Knuth [8]) Je konstanter das Zeitintervall, desto mehr Punkte erhält der Sensor für das Benchmarkergebnis. Hierzu wird ein konstanter Wert durch das Ergebnis der Standardabweichung dividiert. Zusätzlich wird auch das arithmetische Mittel der Zeitdifferenz gebildet, um das Durchschnittsintervall zu ermitteln. Diese Ergebnisse werden später während des Benchmarkprozesses zur Berechnung des Gesamtergebnisses wieder verwendet. Die Werte der Sensorachsen werden anschließend in die Datenbank geschrieben, wobei jeder Wert lediglich einmal in die Datenbank aufgenommen wird. 2.3 Benchmark Verschiedene Sensoren reagieren auf unterschiedliche Aktionen, daher wurden drei verschiedene Benchmarks entwickelt mit unterschiedlichen Bewertungskategorien und Testszenarien. Die Schnittmenge der Kategorien bildet die kleinste Differenz zwischen zwei aufeinanderfolgenden Werten (Schrittweite) sowie die zeitliche Kontinuität. Die Sensoren des Typs Light Sensor und Proximity Sensor werden zusätzlich

14 14 2 Bewertung der Sensoren anhand der Anzahl verschiedener Werte gemessen, welche während Initialisierung und Benchmark zurückgeliefert werden. Alle weiteren Sensoren werden zusätzlich zu den Kategorien der Schnittmenge anhand der Standardabweichung und der Anzahl gemessener Werte während des Benchmarkprozesses bewertet. Als Ausnahme gelten hier noch der Accelerometer und Gravity Sensor, die eine weitere Kategorie, namens Gravity Accuracy, besitzen, sie vergleicht den gemessenen Gravitationswert mit der Erdbeschleunigung. Auch das Testszenario, welches beim Benchmark 20 Sekunden beträgt, unterscheidet sich bei Light Sensor und Proximity Sensor von allen anderen Sensoren. Während bei Light und Proximity Sensor jeweils möglichst viele verschiedene Werte ermittelt werden sollen, im Falle des Light Sensors zum Beispiel durch Näherung an eine Lichtquelle und anschließendem Abdunkeln des Sensors, so sollen bei allen anderen Sensortests die Geräte horizontal auf einer möglichst ebenen Fläche liegen und nicht bewegt werden bis der Prozess beendet ist. Die Berücksichtigung dieser Anweisungen hat große Auswirkungen auf das jeweilige Benchmarkergebnis. Beim Accelerometer zum Beispiel misst die Z-Achse nur dann die Erdbeschleunigung, wenn das Gerät waagerecht auf der Rückseite liegt, außerdem ergibt eine geringere Standardabweichung mehr Punkte, unter Bewegung würde der Sensor jedoch eine höhere Standardabweichung erzeugen Bewertungskategorien Eventanzahl Die Anzahl der zurückgelieferten Events (n) während des Benchmarkprozesses geht direkt als Teilergebnis in die Gesamtpunktzahl ein. Dies wurde so festgelegt, aufgrund der Tatsache, dass die Qualität mancher Teilergebnisse stark von der Anzahl gemessener Werte abhängig ist, wie zum Beispiel die der Standardabweichung, je mehr Werte erfasst werden, desto aussagekräftiger ist das Ergebnis. result = n (Punktzahl) Standardabweichung Die Standardabweichung für auflaufende Messwerte bewertet die Streuung der gemessenen Werte pro Sensorachse. Es wird die selbe Formel wie in Kapitel 2.2 verwendet. Zur Bestimmung der Punktzahl wird eine Konstante c mit dem fest implementierten Wert 33 durch das Ergebnis der Standardabweichung jeweils pro Sensorachse dividiert, diese Teilergbnisse werden addiert und schließlich durch die Anzahl der Achsen a nochmals dividiert. result = 1 c (Punktzahl) a σ i 1 i a

15 2.3 Benchmark 15 Schrittweite Die Schrittweite beschreibt die Differenz zweier aufeinanderfolgend gemessener Werte je Sensorachse. Dadurch erhält man eine Aussage über die Auflösung des jeweiligen Sensors. In der Regel sollten besonders dann möglichst niedrige Schrittweiten auftreten, wenn das Gerät nicht bewegt oder beschleunigt wird. Die niedrigste Schrittweite wird für jede Sensorachse gespeichert, zur Bewertung wird ein konstanter Wert c (33) mit dem jeweiligen Minimum einer jeden Sensorachse dividiert. Sofern der Sensor mehr als eine Achse besitzt, werden die jeweiligen Ergebnisse addiert und schließlich durch die Anzahl der Achsen a dividiert. result = 1 c, mit 2 k n und a = #Achsen a min(x i,k x i,k 1 ) 1 i a (Berechnung der Benchmarkpunkte für Schrittweite) Zeitkontinuität Die Kontinuität der zeitlichen Aufeinanderfolge erhaltener Events vom Event-Listener eines Sensors baut auf den gewonnenen Ergebnissen der Initialisierung auf. Hierbei wird die durchschnittliche Zeitdifferenz t ermittelt und durch Division mit der aus der Initialisierung berechneten durchschnittlichen Zeitdifferenz verglichen. Dabei wird durch das bekannte Sensorverhalten vorausgesetzt, dass bei der Initialisierung durch die Bewegung mehr oder gleich viele Events erfasst werden, je nachdem ob dem Sensor ein festes zeitliches Intervall zu Grunde liegt oder nicht. Es ergibt sich somit ein relatives Verhältnis v mit einem Wert zwischen 0 und 1. t = 1 t k t k 1 (Durchschnittliche Zeitdifferenz) n 2 k n v = t Initialization t Benchmark (Relatives Verhältnis) Anschließend wird wie schon bei der Initialisierung die Standardabweichung σ der Zeitdifferenzen berechnet und die Punktzahl der Standardabweichung für die Benchmarkwerte ermittelt. Der Wert der Konstanten c beträgt hier 3,3 Milliarden, da die Zeitdifferenz in Nanosekunden berechnet wird und somit entsprechend groß ist. c res σ,benchmark = σ Benchmark (Zwischenergebnis: Punkte für Standardabweichung) Schließlich wird die Gesamtpunktzahl in Abhängigkeit des Teilergebnisses aus dem Initialisierungsprozess und dem Verhältnis der durchschnittlichen Zeitdifferenzen aus Initialisierung und Benchmark berechnet. {( ) resσ,initialization +res σ,benchmark v, wenn v < 1 result = 2 res σ,initialization +res σ,benchmark 2, sonst (Punktzahl: Zeitkontinuität)

16 16 2 Bewertung der Sensoren Anzahl unterschiedlicher Werte Die Punktzahl für diese Kategorie ergibt sich aus der Anzahl unterschiedlicher Werte, die auf der X-Achse des Sensors während der Initialisierung und des Benchmarks gemessen wurden. Diese Bewertung fließt lediglich bei dem Light- und Proximity Sensor ins Gesamtergebnis mit ein, da diese beiden Sensoren nur Werte auf der X-Achse ausgeben, wird auch nur diese berücksichtigt. Gravitations-Genauigkeit Hierbei wird der Durchschnittswert der Z-Achse des Accelerometers und des Gravity Sensors bewertet. Unter der Voraussetzung, dass sich das Gerät in waagerechter Position befindet, misst die Z-Achse jeweils die Erdbeschleunigung. Durch eine Divison wird die prozentuale Abweichung zur Normfallbeschleunigung g = 9,80665 m/s 2 berechnet, hierzu wird ein Offset addiert, da nicht alle Geräte durch ihre Gehäusebauform zwangsweise waagerecht liegen können. Zuletzt wird der Wert des Quotienten mit der erreichbaren maximal Punktzahl für diese Kategorie multipliziert, um das Teilergebnis für die Gesamtbewertung zu erhalten. x = 1 n 1 k n x k (Arithmethisches Mittel) { 4000( g x result = + 3), wenn g x 4000( x g + 3), sonst (Punktzahl) Benchmark-Szenarien Standard Benchmark Alle Sensoren, außer Light Sensor und Proximity Sensor, sollen während des 20 Sekunden andauernden Benchmarks idealerweise auf einer festen, waagerechten Fläche liegen. Diese Voraussetzung ist bei diesen Sensoren von hoher Bedeutung für ein gutes Ergebnis. Erschütterungen könnten vereinzelte Bewertungskategorien negativ beeinflussen. Die Kategorien, die in die Bewertung des Standard Benchmarks miteinfließen sind Eventanzahl, Standardabweichung, Schrittweite und Zeitkontinuität. Gravitations-Benchmark Der Benchmark für Accelerometer und Gravity Sensor basiert auf dem Standard Benchmark, daher gelten hier auch die selben Voraussetzungen. Die beiden Sensortypen werden jeweils in einer weiteren Kategorie, Gravitations-Genauigkeit, bewertet.

17 2.3 Benchmark 17 Light- und Proximity Sensor Benchmark Dieser Benchmark ist speziell für den Light- und Proximity Sensor. Er basiert auf den Kategorien Schrittweite, Zeitkontinuität und Anzahl unterschiedlicher Werte. Während dem 20 sekündigen Benchmarkprozess sollen hierbei möglichst viele verschiedene Werte erfasst werden, um die Qualität des Sensors bewerten zu können. Der Grund für diese Variante liegt darin, dass vor allem der Proximity Sensor auf allen Testgeräten nur zwei Werte misst und der minimale Verzögerungswert jeweils 0 beträgt. Der Light Sensor verhält sich auf den Entwicklungsgeräten ähnlich, Werte werden nicht in einem bestimmten Intervall ausgegeben, sondern nur nach Registrierung einer Veränderung in der Umgebung. Außerdem fällt auf, dass der Light Sensor des Samsung Galaxy S2 lediglich fünf verschiedene Werte zurückliefert, diese sind 10, 100, 1.000, und Dies bedeutet, dass manche Sensoren dieses Typs gerundete Werte zurückgeben, daher wurde für diesen Benchmark die Anzahl der unterschiedlichen Werte berücksichtigt und in die Bewertung mitaufgenommen. Die Eventanzahl und Standardabweichung mit in die Bewertung aufzunehmen erscheint nicht sinnvoll, da für den Fall, dass im Testzeitraum nur wenige Werte zurückgeliefert werden oder gar viele gerundete Werte, die Standardabweichung den Wert 0 berechnet. Somit könnte ein schlechter Sensor gegebenenfalls eine hohe Gesamtpunktzahl erzielen. Die Gesamtpunktzahl eines Sensors ergibt sich aus der Addition der Punktzahlen aus den jeweiligen Bewertungskategorien. Wichtig für die Entscheidung der Testszenarien war es, dass sie möglichst einfach für jedermann zu rekonstruieren sind, damit sich die gewonnen Ergebnisse gut miteinander vergleichen lassen. Die vorgestellten Benchmarks beurteilen lediglich die Präzision eines Sensors durch Analyse der erhaltenen Gleitkommazahlen, nicht aber die Korrektheit der ausgegebenen Werte, hierzu müsste man die Sensoren jeweils mit geeichten Messgeräten vergleichen.

18

19 3 SensMark: Struktur, Design und Usability Dieses Kapitel thematisiert Aspekte des Designs, Aufbaus sowie der Usability der im Rahmen dieser Arbeit entwickelten Applikation SensMark. Hierbei galt der Kompatibilität zwischen verschiedenen Android Geräten und Versionen besondere Berücksichtigung. Außerdem werden verwendete Berechtigungen beschrieben, durch die man Zugriff auf bestimmte Funktionen erhält, die dem Funktionsumfang sowie der User-Experience der App dienen. 3.1 Kompatibilität Nutzer der SensMark App sollen eine einheitliche, gewohnte und persistente Bedienung sowie ein bekanntes Layout wiederfinden, daher ist die Applikation nach den Android Design Richtlinien konzipiert [1]. Diese wurden mit der Einführung der Android Version 4.0, alias Ice Cream Sandwich (ICS), im Oktober 2011 vorgestellt. Bei der Entwicklung von Android Applikationen gilt es besonders die Fragmentierung von Android Geräten zu berücksichtigen, da diese mit unterschiedlichsten Bildschirmgrößen, diversen Auflösungen aber auch mit verschiedensten Hardwarekomponenten hergestellt werden. Es ist dadurch nicht gegeben, dass eine Applikation auf verschiedenen Geräten immer gleich aussieht und funktioniert. Zudem stellen viele Hersteller keine Updates für ältere oder günstigere Modelle zur Verfügung, weswegen eine breit gefächerte Masse an Android Versionen im Umlauf ist und daher im Entwicklungsprozess beachtet werden sollte. SensMark ist gezielt angepasst für die Version ICS, dennoch ist sie abwärtskompatibel zu älteren Android Versionen bis mindestens 2.1 alias Eclair. Durch die oben genannte Einführung der Design Richtlinien mit ICS wurde auch die aus Honeycomb (Version 3.x) bekannte Action Bar eingeführt, dies ist eine Leiste am oberen Bildschirmrand, die das App-Symbol, den Applikationsnamen sowie die wichtigsten Menüsymbole des Optionsmenüs anzeigt. Für Pre-Honeycomb Versionen wie Eclair, Froyo (2.2) und Gingerbread (2.3.x) ist die Action Bar und das verwendete Theme Holo Light so angepasst, dass es sich kaum vom Look and Feel eines ICS Geräts unterscheidet. Eine weitere wichtige Eigenschaft der Fragmentierung, die es zu beachten gilt, sind

20 20 3 SensMark: Struktur, Design und Usability unterschiedliche Displaygrößen und Bildschirmauflösungen. Aus diesem Grund wurden alle in der Applikation verwendeten Symbole in 4 verschiedenen Größen hinterlegt, mit jeweils entsprechender Punktdichte für LDPI (low density), MDPI (medium density), HDPI (high density) und XHDPI (extra high density), letzteres wird ausschließlich auf Tablet-PCs verwendet. Die Benutzeroberfläche wurde für große Displays, welche in Tablet-PCs verbaut sind, speziell angepasst. 3.2 Struktur, Benutzeroberfläche und Handhabung SensMark ist für Smartphones so strukturiert, dass es eine Top Level Ansicht und untergeordnete Detailansichten besitzt. Das bedeutet je tiefer man sich in der Applikation befindet, um so detailliertere bzw. spezifischere Informationen erhält man bezüglich eines Sensors, siehe hierzu Abbildung 3.1. Für Tablet-PCs gibt es eine besondere Anpassung der Applikation, aufgrund der größeren Displays wird die TopLevel Ansicht links neben der ersten Detailansicht dargestellt (siehe Abbildung 3.4). Abbildung 3.1: Struktur und Aufbau der SensMark Applikation für Smartphones am Beispiel des Accelerometers. Blaue Pfeile symbolisieren aufeinanderfolgende Ansichten von Top-Levels bis Detailansichten. Auswahl jeweils dargestellt durch einen grauen Punkt, gelbe Elemente symbolisieren Gestensteuerung. Startet man die Applikation bekommt man eine Liste aller im Gerät befindlichen Sensoren angezeigt, wie in Abbildung 3.2 zu sehen. Die Listeneinträge der Sensoren unterscheiden sich abhängig von Gerät und Android Version in Sensortyp und Anzahl. Zusätzlich befindet sich bei allen Geräten an oberster Stelle die Option Initialization. Sofern der Initialisierungsprozess noch nicht ausgeführt wurde, öffnet

21 3.2 Struktur, Benutzeroberfläche und Handhabung 21 sich unmittelbar nach dem Start ein Dialogfenster, welches den Nutzer darauf hinweist, dass die Initialisierung der Sensoren Voraussetzung für die Durchführung des Benchmarks ist. Außerdem kann der Benutzer wählen, ob er die Initialisierung sofort oder zu einem späteren Zeitpunkt starten möchte. (a) Hinweis Dialog zur Initialisierung. (b) Liste aller Sensoren mit Initialisierungsoption. Abbildung 3.2: Screenshot der Top-Level Ansicht auf Smartphones. Nachdem man die Initialisierung gestartet hat, öffnet sich ein neuer Dialog, der dem Nutzer Anweisungen gibt, die es während des Prozesses zu beachten gilt, möglichst das Gerät in verschiedene Richtungen mit unterschiedlicher Intensität zu bewegen. Des Weiteren wird er darüber informiert, dass das Gerät vibriert, sobald es nicht mehr bewegt werden muss. Während der Initialisierung wird ein Fortschrittsbalken angezeigt, nach 60% sind die 10 Sekunden, in denen Sensordaten aller Sensoren gesammelt werden abgelaufen und das Gerät signalisiert dem Nutzer durch Vibration, dass das Sammeln der Daten beendet wurde. In den verbleibenden 40% des Fortschritts werden die gemessenen Werte evaluiert und anschließend in der Datenbank gespeichert. Ist die Initialisierung abgeschlossen, wird der Nutzer darüber informiert und gelangt durch Bestätigung per OK-Schaltfläche zurück zur Top Level Ansicht. Bilder des Initialisierungsablaufs befinden sich in Abbildung 3.3. Ein Listeneintrag besteht aus der Typbezeichnung eines Sensors (in Abbildung 3.2

22 22 3 SensMark: Struktur, Design und Usability (a) Anweisungen und Tipps zur Initialisierung. (b) Initialisierungsfortschritt. (c) Initialisierung beendet. Abbildung 3.3: Screenshots des Initialisierungsprozesses. mit großer Schriftgröße) sowie dem Herstellernamen (graue Schriftfarbe, kleinere Schriftgröße). Die Sortierung nach Typ listet gleiche Sensoren untereinander, mehrere Sensoren selben Typs entstehen vor allem durch virtuelle Sensoren, die vom Betriebssystem zur Verfügung gestellt werden, wie zum Beispiel der Gravity Sensor, Corrected Gyroscope Sensor, Linear Acceleration Sensor und der Rotation Vector Sensor. Die Angabe von Typ und Name ist sinnvoll, da aus manchen Namen nicht unmittelbar hervorgeht um welchen Sensortyp es sich genau handelt, wie beispielsweise bei dem Licht Sensor des Lenovo Ideapad A1 namens cm3217 im Gegensatz zu dem des Samsung Galaxy S2 (GT- I9100) namens CM3663 Light Sensor. Aus der Liste der vom jeweiligen Gerät bereitgestellten Sensoren wird ein Sensor durch Antippen ausgewählt. Es öffnet sich die Detailansicht eines Sensors (siehe Abbildung 3.4), dabei wird der jeweilige Listener aktiviert und zeigt die gemessenen Float Werte standardmäßig mit bis zu 50 Aktualisierungen pro Sekunde an. Gleichzeitig wird ein Graph gezeichnet, der pro Sensorachse die 50 zuletzt gemessenen Werte darstellt. Auch der Graph aktualisiert sich mit einer Frequenz von standardmäßig bis zu 50 Hz. Diese Frequenz ist abhängig von der gewählten Rate der Sensor Manager Klasse und einer Drosselung, die man in den Einstellungen der Applikation vornimmt. Die Sensorrate ist auf Fastest eingestellt, sofern nicht vom Nutzer über die Action Bar geändert, weitere Geschwindigkeitsoptionen sind Normal, UI und Game. In den Einstellungen lässt sich unabhängig der gewählten Listener-Rate ein Maximalwert der Frequenz in Hertz festlegen, der Standardwert beträgt 50 Hz, kann aber zwischen 2 und 500 frei angepasst werden. Ist der gewählte Drosselungswert kleiner

23 3.2 Struktur, Benutzeroberfläche und Handhabung 23 (a) Echtzeitwerte auf Smartphone. (b) Echtzeitwerte auf Tablet-PC mit deaktivierter Result Schaltfläche, da der Benchmark noch nicht durchgeführt wurde. Abbildung 3.4: Detailansicht der Sensordaten in Echtzeit auf Tablet-PC und Smartphone. als die Anzahl zurückgelieferter Werte des Sensors pro Sekunde, so werden manche Zwischenwerte vernachlässigt. Diese Drosselung bewirkt das die Applikationen stets Interaktionen des Nutzers zeitlich verarbeiten kann. Diese Begrenzung ist notwendig, da manche Sensoren wie das Gyroskop des Google Nexus S weit mehr als 500 Werte pro Sekunde liefern, somit würde die Applikation ohne Drosselung einfrieren und das Gerät wäre nicht bedienbar, bis das Betriebssystem einen enstprechenden Dialog zum Beenden der App anbietet. Zusätzlich zu den angezeigten Echtzeitwerten werden alle drei Sekunden die Standardabweichung, das arithmetische Mittel sowie Minimum und Maximum aller erfassten Werte berechnet und tabellarisch für jede Sensorachse dargestellt. Diese Tabelle lässt sich auf kleinen Displays durch horizontale Swipe oder Fling Gesten komplett lesen, für eine bessere Gesamtübersicht bietet es sich an per Action Bar Symbol die Orientierung zu ändern und sich die Tabelle im Querformat anzeigen zu lassen. Bei diesem Vorgang wird die UI jedoch komplett zerstört und neu aufgebaut, wodurch auch die bisher gemessenen und berechneten Werte verloren gehen. Dies ist auch der Grund warum die Bildschirmausrichtung nicht wie gewohnt durch einfaches Drehen des Geräts geändert wird, denn es ist davon auszugehen, dass durch die Visualisierung der gemessenen Werte im Graphen der Nutzer das Gerät bewegen wird, um die Veränderung des Graphen als Reaktion seiner Bewegung zu beobachten. Würde er das Smartphone während der Bewegung auch drehen, so würde sich die UI jedesmal beenden und neu aufbauen, eine Beobachtung des Graphen wäre somit nicht möglich. Diese Ansicht bietet dem Nutzer drei weitere Optionen: Info, Run Benchmark und

24 24 3 SensMark: Struktur, Design und Usability Result. Die Schaltfläche Info blendet die angezeigten Echtzeitwerte inklusive Graphen aus und zeigt sensortypische Informationen sowie technische Angaben über die verbaute Hardwarekomponente an, siehe Abbildung 3.5. Die Informationen teilen dem Nutzer mit, was der jeweilige Sensor genau misst und welche SI Einheit die ausgegebenen Werte besitzen. Des Weiteren wird er, sofern vom Sensor unterstützt, über die maximale Reichweite, minimale zeitliche Verzögerung, Auflösung, Version, den Stromverbrauch und über den Hersteller informiert. (a) Allgemeine Informationen zum Beschleunigungssensor. (b) Skizze der verwendeten Sensorachsen und spezifische Informationen des K3DH Acceleration Sensors Abbildung 3.5: Informationsansicht anhand des Accelerometers. Über Run Benchmark wird der Benchmark gestartet. Sofern die Initialisierung bis zu diesem Zeitpunkt noch nicht durchgeführt wurde, wird man darauf hingewiesen und kann diese sofort starten. Anschließend lässt sich der Benchmark durchführen, ähnlich wie beim Initialisierungsprozess wird erst ein Dialog mit Anweisungen angezeigt, die es zu beachten gilt, darauf folgt die Fortschrittsanzeige und letztendlich die Weiterleitung zur Ergebnisansicht. Dorthin gelangt man auch über die Schaltfläche Result, vorausgesetzt ein Benchmarkergebnis ist vorhanden, ansonsten ist die Schaltfläche deaktiviert. Die Ergebnisansicht ist auf drei Fragmente verteilt, durch diese Fragmente lässt sich