Android Applikation zur Bestimmung der Genauigkeit von Smartphone Sensoren
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Android Applikation zur Bestimmung der Genauigkeit von Smartphone Sensoren Andreas Gabel Bachelor-Arbeit – 22. August 2012. Lehrstuhl für Systemsicherheit. Erstgutachter: Prof. Dr. Thorsten Holz Zweitgutachter: Dr. Christopher Wolf Betreuer: Dipl. Inf. Sebastian Uellenbeck
Zusammenfassung Über die Genauigkeit von Smartphone Sensoren ist derzeit nicht viel bekannt, da- bei 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 Sen- sorergebnissen anderer Geräte angezeigt. Es hat sich herausgestellt, dass sich die Genauigkeit von Sensoren anhand der Voraussetzungen für eine präzise Messung be- werten lässt. Außerdem wurde festgestellt, dass technische Angaben von Sensoren kein Indiz bezüglich der Präzision liefern.
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 AutorInhaltsverzeichnis
1 Einführung 7
1.1 Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Gliederung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Bewertung der Sensoren 11
2.1 Sensoreigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Initialisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3 Benchmark . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.1 Bewertungskategorien . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2 Benchmark-Szenarien . . . . . . . . . . . . . . . . . . . . . . 16
3 SensMark: Struktur, Design und Usability 19
3.1 Kompatibilität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Struktur, Benutzeroberfläche und Handhabung . . . . . . . . . . . . 20
3.3 Berechtigungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4 Evaluation 29
4.1 Accelerometer Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Gyroskop Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Orientierungssensor Daten . . . . . . . . . . . . . . . . . . . . . . . . 37
5 Fazit 41
5.1 Vorteile präziser Sensoren . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2 Zukünftige Weiterentwicklungen . . . . . . . . . . . . . . . . . . . . . 42
A Akronyme 43
Abbildungsverzeichnis 45
Tabellenverzeichnis 47
Literaturverzeichnis 491 Einführung Die Entwicklung und Verbreitung von Smartphones schreitet rapide voran, sie ver- fü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 bei- spielsweise passt die Displaybeleuchtung abhängig von dem Umgebungslicht auto- matisch 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 (Hoch- oder 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 Ori- entierungsdaten sowie der aktuellen Position zu einem Ziel führen können, fehlerhaf- te 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 ge- schä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, wel- che 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 beein- trä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 Aus- tausch 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 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 entstande-
ne Vielzahl an Geräten unterschiedlicher Preisklassen, im Zusammenhang mit dem
einhergehenden Erfolg von Android, entstand eine Fragmentierung des Betriebssys-
tems 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 er-
fasst, auf denen die Applikation OpenSignalMaps installiert wurde. Insgesamt haben
in dem Zeitraum 62.389 Nutzer die Applikation auf 3.997 verschiedenen Geräten
heruntergeladen [13]. Hierbei gilt jedoch zu beachten, dass die verwendete Varia-
ble android.build.MODEL zum Auslesen der Modellbezeichnung durch sogenannte
Custom-ROMs1 überschrieben werden kann und somit 1.363 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 Down-
loads nach einer sechs monatigen Studie im Mai 2012. Jedes Rechteck
repräsentiert ein Android Gerät, die Größe des Rechtecks gibt Aus-
kunft ü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.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 An- zahl 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 Sen- soren. Dabei dient SensMark als Sensor-Benchmark, es analysiert und bewertet die gemessenen Werte der Sensoren und präsentiert schließlich die gewonnenen Ergeb- nisse im Vergleich mit den Ergebnissen anderer Geräte. Als Entwicklungs- und Testgerät wurde das Samsung Galaxy S2 GT-I9100 mit An- droid Version 4.0.3 eingesetzt, zu Kompatibilitätstests wurde der Lenovo Ideapad A1 Tablet-PC mit Android 2.3.4 herangezogen. 1.1 Verwandte Arbeiten Es existiert eine Vielzahl an Arbeiten, die sich dem Gebrauch von Sensoren für diver- se 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 an- derer 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 Nut- zerauthentifizierung 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 Sen- soren sowie deren Eigenschaften eingegangen. Im Anschluss wird die in der SensMark Applikation verwendete Bewertung der Sensoren beschrieben, welche sich in Initia- lisierung und Benchmark gliedert.
10 1 Einführung Das darauffolgende Kapitel behandelt die Struktur, Benutzeroberfläche und Kompa- tibiltät der entwickelten SensMark App, außerdem werden die verwendeten Berech- tigungen 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.
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 Senso- ren durchgeführt werden. Die aus diesem Prozess gewonnenen Ergebnisse fließen dann bei der Benchmarkberechnung mit in die Beurteilung des Sensors ein. Voraus- setzung 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 Ac- celeration Sensor, Orientation Sensor und Rotation Vector Sensor liefern Werte, welche auf den gewonnen Ergebnissen physikalischer Sensoren beruhen. Der Ro- tation 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ück- gegriffen. Mittels des Rotation Vector eines Geräts lassen sich Gravitation (Gravity Sensor) und lineare Beschleunigung (Linear Acceleration Sensor) anhand der Accele- rometerdaten 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 imple- mentierten Algorithmen zur Berechnung der Werte [12]. Virtuelle Sensoren werden vom Betriebssystem bereitgestellt und lassen sich daher unter Android unabhängig
12 2 Bewertung der Sensoren
vom Typ vor allem an der Herstellerangabe „Google Inc.“ von physikalischen Sen-
soren 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 Sen-
sor messen nur auf einer Achse und geben den Wert in der jeweiligen SI Einheit aus
(Light Sensor: Lux, Proximity Sensor: Zentimeter, Temperature Sensor: Grad Cel-
sius). 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 (Hoch-
bzw. Querformat) ändert. Wie in Abbildung 2.1 zu sehen, verläuft die X-Achse ho-
rizontal 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 Angaben1 , die sich sehr
einfach auslesen lassen, darunter: Sensortyp, Sensorname, Hersteller des Sensors, Ver-
sion 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 (Resoluti-
on) und Stromverbrauch in Milliampere (Power ). Allerdings geben manche Sensoren
bei den letzten vier Angaben den Wert 0 aus, so dass sich diese Eigenschaften le-
diglich 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
http://developer.android.com/reference/android/hardware/Sensor.html [3]2.2 Initialisierung 13
2.2 Initialisierung
Der Initialisierungsprozess ist Voraussetzung für einen Benchmark, er muss mindes-
tens einmal pro Gerät durchgeführt werden, bevor man einen Sensor prüfen kann.
Aufgrund der Tatsache, dass Sensoren nicht zwingend in einem bestimmten Inter-
vall 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 ei-
ner Ruhephase zu vergleichen. Für die erzwungene Ausgabe dient die Initialisierung,
zehn Sekunden lang soll hierbei das Gerät bewegt werden, möglichst in verschie-
dene 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 Acce-
lerometer, Gyroskop, Orientierungssensor und Magnetic Field Sensor zur Ausgabe
von Werten provoziert werden. Alle ermittelten Werte und deren Zeitstempel wer-
den 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:
v 2
u
u
u 1 X 1 X
σ=t x2k − xk
n−1 n
1≤k≤n 1≤k≤n
(Standardabweichung, Knuth [8])
Je konstanter das Zeitintervall, desto mehr Punkte erhält der Sensor für das Bench-
markergebnis. Hierzu wird ein konstanter Wert durch das Ergebnis der Standard-
abweichung dividiert. Zusätzlich wird auch das arithmetische Mittel der Zeitdiffe-
renz gebildet, um das Durchschnittsintervall zu ermitteln. Diese Ergebnisse wer-
den später während des Benchmarkprozesses zur Berechnung des Gesamtergebnisses
wieder verwendet. Die Werte der Sensorachsen werden anschließend in die Daten-
bank 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 zwi-
schen zwei aufeinanderfolgenden Werten (Schrittweite) sowie die zeitliche Kontinui-
tät. Die Sensoren des Typs Light Sensor und Proximity Sensor werden zusätzlich14 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 ermit-
telt 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 Standardabwei-
chung mehr Punkte, unter Bewegung würde der Sensor jedoch eine höhere Standard-
abweichung erzeugen.
2.3.1 Bewertungskategorien
Eventanzahl Die Anzahl der zurückgelieferten Events (n) während des Benchmark-
prozesses 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 Standard-
abweichung, je mehr Werte erfasst werden, desto aussagekräftiger ist das Ergeb-
nis.
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.
1 X c
result = (Punktzahl)
a σi
1≤i≤a2.3 Benchmark 15
Schrittweite Die Schrittweite beschreibt die Differenz zweier aufeinanderfolgend ge-
messener 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 Schritt-
weiten auftreten, wenn das Gerät nicht bewegt oder beschleunigt wird. Die niedrigste
Schrittweite wird für jede Sensorachse gespeichert, zur Bewertung wird ein konstan-
ter 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.
1 X c , mit 2 ≤ k ≤ n und a = #Achsen
result =
a |min(xi,k − xi,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 Initiali-
sierung auf. Hierbei wird die durchschnittliche Zeitdifferenz t̄ ermittelt und durch
Division mit der aus der Initialisierung berechneten durchschnittlichen Zeitdiffe-
renz 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.
1 X
t̄ = tk − tk−1 (Durchschnittliche Zeitdifferenz)
n
2≤k≤n
t̄Initialization
v= (Relatives Verhältnis)
t̄Benchmark
Anschließend wird wie schon bei der Initialisierung die Standardabweichung σ der
Zeitdifferenzen berechnet und die Punktzahl der Standardabweichung für die Bench-
markwerte 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
2 v, wenn v < 1
result = res
σ,Initialization +resσ,Benchmark
2 , sonst
(Punktzahl: Zeitkontinuität)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 le-
diglich 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ück-
sichtigt.
Gravitations-Genauigkeit Hierbei wird der Durchschnittswert der Z-Achse des Ac-
celerometers und des Gravity Sensors bewertet. Unter der Voraussetzung, dass sich
das Gerät in waagerechter Position befindet, misst die Z-Achse jeweils die Erdbe-
schleunigung. Durch eine Divison wird die prozentuale Abweichung zur Normfallbe-
schleunigung g = 9,80665 m/s2 berechnet, hierzu wird ein Offset addiert, da nicht
alle Geräte durch ihre Gehäusebauform zwangsweise waagerecht liegen können. Zu-
letzt wird der Wert des Quotienten mit der erreichbaren maximal Punktzahl für
diese Kategorie multipliziert, um das Teilergebnis für die Gesamtbewertung zu er-
halten.
1 X
x̄ = xk (Arithmethisches Mittel)
n
1≤k≤n
(
4000( x̄g + 3), wenn g ≤ x̄
result = (Punktzahl)
4000( x̄g + 3), sonst
2.3.2 Benchmark-Szenarien
Standard Benchmark Alle Sensoren, außer Light Sensor und Proximity Sensor, sol-
len 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 Bewertungs-
kategorien 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 Vorausset-
zungen. Die beiden Sensortypen werden jeweils in einer weiteren Kategorie, Gravi-
tations-Genauigkeit, bewertet.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, Zeitkon- tinuität und Anzahl unterschiedlicher Werte. Während dem 20 sekündigen Bench- markprozess 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, 10.000 und 16.000. 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 er- scheint nicht sinnvoll, da für den Fall, dass im Testzeitraum nur wenige Werte zu- rückgeliefert werden oder gar viele gerundete Werte, die Standardabweichung den Wert 0 berechnet. Somit könnte ein schlechter Sensor gegebenenfalls eine hohe Ge- samtpunktzahl erzielen. Die Gesamtpunktzahl eines Sensors ergibt sich aus der Addition der Punktzahlen aus den jeweiligen Bewertungskategorien. Wichtig für die Entscheidung der Test- szenarien war es, dass sie möglichst einfach für jedermann zu rekonstruieren sind, damit sich die gewonnen Ergebnisse gut miteinander vergleichen lassen. Die vorge- stellten Benchmarks beurteilen lediglich die Präzision eines Sensors durch Analy- se der erhaltenen Gleitkommazahlen, nicht aber die Korrektheit der ausgegebenen Werte, hierzu müsste man die Sensoren jeweils mit geeichten Messgeräten verglei- chen.
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 Kom- patibilität zwischen verschiedenen Android Geräten und Versionen besondere Be- rü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 Bedie- nung sowie ein bekanntes Layout wiederfinden, daher ist die Applikation nach den Android Design Richtlinien konzipiert [1]. Diese wurden mit der Einführung der An- droid Version 4.0, alias Ice Cream Sandwich (ICS), im Oktober 2011 vorgestellt. Bei der Entwicklung von Android Applikationen gilt es besonders die Fragmentie- rung von Android Geräten zu berücksichtigen, da diese mit unterschiedlichsten Bild- schirmgrößen, diversen Auflösungen aber auch mit verschiedensten Hardwarekompo- nenten 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, weswe- gen 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 4.0.3 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 verwen- dete 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 3 SensMark: Struktur, Design und Usability
unterschiedliche Displaygrößen und Bildschirmauflösungen. Aus diesem Grund wur-
den alle in der Applikation verwendeten Symbole in 4 verschiedenen Größen hinter-
legt, mit jeweils entsprechender Punktdichte für LDPI (low density), MDPI (medium
density), HDPI (high density) und XHDPI (extra high density), letzteres wird aus-
schließlich auf Tablet-PCs verwendet. Die Benutzeroberfläche wurde für große Dis-
plays, 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 Ap-
plikation 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 Top-
Level 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 aufeinan-
derfolgende Ansichten von Top-Levels bis Detailansichten. Auswahl
jeweils dargestellt durch einen grauen Punkt, gelbe Elemente symbo-
lisieren 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 Senso-
ren 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 In-
itialization. Sofern der Initialisierungsprozess noch nicht ausgeführt wurde, öffnet3.2 Struktur, Benutzeroberfläche und Handhabung 21
sich unmittelbar nach dem Start ein Dialogfenster, welches den Nutzer darauf hin-
weist, 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 Initialisie-
rungsoption.
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 ge-
sammelt werden abgelaufen und das Gerät signalisiert dem Nutzer durch Vibration,
dass das Sammeln der Daten beendet wurde. In den verbleibenden 40% des Fort-
schritts 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.222 3 SensMark: Struktur, Design und Usability
(a) Anweisungen und Tipps zur (b) Initialisierungsfortschritt. (c) Initialisierung beendet.
Initialisierung.
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, meh-
rere 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 beispiels-
weise 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 Ab-
bildung 3.4), dabei wird der jeweilige Listener aktiviert und zeigt die gemessenen
Float Werte standardmäßig mit bis zu 50 Aktualisierungen pro Sekunde an. Gleich-
zeitig wird ein Graph gezeichnet, der pro Sensorachse die 50 zuletzt gemessenen
Werte darstellt. Auch der Graph aktualisiert sich mit einer Frequenz von standard-
mäß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 Maxi-
malwert 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 kleiner3.2 Struktur, Benutzeroberfläche und Handhabung 23
(a) Echtzeitwerte auf Smart- (b) Echtzeitwerte auf Tablet-PC mit deaktivierter Result Schalt-
phone. fläche, da der Benchmark noch nicht durchgeführt wurde.
Abbildung 3.4: Detailansicht der Sensordaten in Echtzeit auf Tablet-PC und Smart-
phone.
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 notwen-
dig, 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 Stan-
dardabweichung, das arithmetische Mittel sowie Minimum und Maximum aller erfass-
ten 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 Visualisie-
rung 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 und24 3 SensMark: Struktur, Design und Usability
Result. Die Schaltfläche Info blendet die angezeigten Echtzeitwerte inklusive Gra-
phen 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 Be- (b) Skizze der verwendeten Sensorachsen
schleunigungssensor. 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 an-
gezeigt, die es zu beachten gilt, darauf folgt die Fortschrittsanzeige und letztendlich
die Weiterleitung zur Ergebnisansicht. Dorthin gelangt man auch über die Schalt-
flä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 sich3.2 Struktur, Benutzeroberfläche und Handhabung 25
(a) Diese Ansicht beinhaltet al- (b) Benchmarkergebnis im Ver- (c) Alle gemessenen Werte pro
le ermittelten Informationen gleich mit anderen Geräten. Achse aufsteigend sortiert.
des Sensors.
Abbildung 3.6: Screenshots der drei Ergebnisfragmente: Zuerst bekommt der Nutzer
Abbildung (b) gezeigt, durch eine horizontale Wischgeste nach links
gelangt er auf Ansicht (a) bzw. nach rechts auf Ansicht (c).
mittels horizontaler Gesten oder einem Tab-Indikator navigieren. Das zuerst darge-
stellte Fragment Chart (Abbildung 3.6 (b)) zeigt die Gesamtpunktzahl des Bench-
marks an, darunter befindet sich ein horizontales Balkendiagramm. Dieses Diagramm
zeigt, absteigend nach Punktzahl sortiert, bis zu fünf Geräte im Vergleich an. Jeder
Balken ist farblich unterteilt, wobei jede Farbe für eine bestimmte Bewertungskate-
gorie steht, hierdurch lässt sich erkennen in welchen Kategorien der jeweilige Sensor
im Vergleich besser oder schlechter abgeschnitten hat. Unter dem Diagramm fin-
det man die Legende zu den verwendeten Farben mit den Bewertungskategorien.
Mögliche Kategorien sind: Standardabweichung, minimale Differenz zwischen zwei
aufeinanderfolgenden Werten, zeitliche Kontinuität, Anzahl der gemessenen Werte
und Genauigkeit der gemessenen Erdanziehungskraft.
Links neben dem Chart-Fragment ist das Fragment Values, hier werden alle berech-
neten Teilergebnisse sowie sonstige Daten, die während des Benchmarks erfasst wur-
den, angezeigt (nachzulesen in Kapitel 4). Auf der anderen Seite des Chart-Fragments
unter Output findet man alle aus Initialisierung und Benchmark erfassten Werte auf-
steigend sortiert pro Sensorachse. Da bei vielen gespeicherten Werten der generierte
String sehr groß wird, kann die UI für kurze Zeit einfrieren, dies lässt sich jedoch
nicht vermeiden, weil die Zuweisung des Strings an das entsprechende TextView auf
dem UI Thread geschehen muss. Um den Nutzer jedoch vorzuwarnen, gibt es einen26 3 SensMark: Struktur, Design und Usability entsprechenden Hinweis, außerdem muss er das Laden manuell durch Antippen der Schaltfläche Load Data bestätigen. Bei der Ergebnisansicht gibt es zwei neue Menüelemente in der Action Bar, eine Diskette und ein „Teilen“-Symbol. Die Diskette bewirkt, dass man alle gewonnenen Ergebnisse, die auch auf den drei Fragmenten zu betrachten sind, in einer Textdatei auf dem Gerät speichert. Zuvor öffnet sich noch ein Dialog, der den Nutzer fragt, ob er lediglich das Ergebnis dieses Sensors speichern möchte oder die Ergebnisse aller Sensoren des Geräts. Sobald die Datei auf die SD-Karte geschrieben wurde, öffnet sich ein Hinweis mit der Information in welchem Ordner die Textdatei abgelegt wur- de. Mit der Share Option über das „Teilen“-Symbol kann der Benutzer sein Ergebnis mit anderen Personen unter Verwendung anderer installierter Applikationen teilen. Es öffnet sich ein Dialog, bei dem der Nutzer die Wahl bekommt zwischen einer Nach- richt mit weniger als 140 Zeichen, oder einer langen Nachricht, die alle ermittelten Informationen des Sensors beinhaltet. Die kurze Nachricht ist hierbei überwiegend für das Teilen auf Social-Networkseiten gedacht und ist daher auch auf 140 Zeichen begrenzt, sie beinhaltet von dem Benchmarkergebnis nur die Gesamtpunktzahl. Als Beispiel der Kurznachricht das Ergebnis des Accelerometers: „The Accelerometer of my SAMSUNG GT-I9100 scores 15592 points with SensMark for Android.“ Nach Auswahl der Nachricht wählt man die Applikation aus einer Liste installlierter Apps mit der der entsprechende Text veröffentlicht bzw. verschickt werden soll. Die lan- ge Nachricht mit allen Informationen ist jedoch ausschließlich für E-Mails gedacht, hierbei ist die App-Auswahlliste deutlich kleiner und zeigt demenstprechend haupt- sächlich E-Mail Client Applikationen an. 3.3 Berechtigungen Bestimmte Funktionen benötigen unter Android die Akzeptanz des Benutzers. Aus diesem Grund hat Android ein Berechtigungssystem, das dafür sorgt, dass eine Appli- kation nur dann Zugriff auf Hardwarekomponenten oder Nutzerdaten erhält, wenn der Nutzer vor der Installation in Googles Play Store diesen Berechtigungen zu- stimmt. SensMark bedarf der Zustimmung von vier Berechtigungen, diese werde im Folgenden einzeln beschrieben und ihr Nutzen für die Applikation begründet. Hardware-Steuerelemente Vibrationsalarm steuern Die Vibrationsfunktion des Geräts wird jeweils nach der Initialisierung und dem Benchmark ausgeführt. Hierdurch bekommt der Nutzer haptisches Feedback über den Fortschritt des jeweiligen Prozesses. Bei manchen Durchläufen wird man auf- gefordert das Gerät zu bewegen, oder mit der Displayseite zu einer Lichtquelle ge- wandt zu halten, währenddessen ist davon auszugehen, dass der Benutzer den an- gezeigten Fortschrittsbalken nicht visuell erfasst und somit nicht bemerken würde,
3.3 Berechtigungen 27 wann der Prozess beendet ist. Mittels Vibration, die genau nach Beendingung der Erfassung von Sensordaten gestartet wird, erfährt der Nutzer somit, dass der Test vorüber ist und er die Bewegung einstellen kann. Es ist auch möglich in den Appli- kationseinstellungen diese Funktion zu deaktivieren, das Gerät vibriert dann nicht mehr. Netzwerkkommunikation Uneingeschränkter Internetzugriff Zugriff auf das Internet wird für Application Crash Report for Android (ACRA) benötigt. Für den Fall, dass die Applikation einmal abstürzt, kann mittels ACRA ein sogenannter Crash Report verfasst und an den Entwickler gesendet werden. Die Funktion des automatischen Versendens eines Crash Reports muss der Nutzer erst in den Einstellungen manuell aktivieren. Entwicklern hilft diese Funktion zur Ver- besserung der Applikation, auftretende Fehler werden geloggt, um sie anschließend einfacher beheben zu können. Speicher SD-Karten-Inhalt ändern/löschen Mit dieser Berechtigung wird der App schreibenden Zugriff auf die integrierte SD- Speicherkarte gewährleistet. Dies ermöglicht dem Nutzer seine gemessenen Daten und Benchmarkergebnisse in einer Textdatei auf dem Gerät zu speichern. System-Tools Standby-Modus deaktivieren Der Standby-Modus wird deaktiviert indem man dem System untersagt die Display- beleuchtung zu dimmen oder auszuschalten. Im Gegensatz zur Vibrationsberechti- gung dient diese Einstellung der visuellen Rückmeldung über den Fortschritt eines Prozesses. Die Initialisierung dauert mindestens 10 Sekunden, der Benchmark nimmt über 20 Sekunden in Anspruch, damit sich während dieser Zeitspanne das Display nicht abschaltet und man den Prozess verfolgen kann, wird für jeweils 30 Sekunden der Standby-Modus deaktiviert. Bei der Entwicklung wurde darauf geachtet die Berechtigungen auf ein notwendiges Minimun zu beschränken. Die durch die verwendeten Berechtigungen verfügbaren Funktionen dienen vorallem dem Nutzer, insbesondere steigern sie den Funktions- umfang und verbessern die User Experience.
4 Evaluation In dieser Evaluation werden die gewonnenen Ergebnisse, die durch SensMark er- mittelt wurden, anhand dreier Sensortypen dargestellt. Als Testgeräte dienen das Google Nexus S (erschienen im Dezember 2010) mit Android Version 4.1.1 alias Jelly Bean, das meistverbreitetste Android Smartphone Samsung Galaxy S2 GT- I9100 (erschienen im Mai 2011) mit ICS sowie Googles Galaxy Nexus (erschienen im November 2011) ebenfalls mit Jelly Bean. Alle Geräte wurden von Samsung ge- fertigt, besitzen aber unterschiedliche Sensoren. Die präsentierten Ergebnisse bezie- hen sich auf die Accelerometer, Gyroskope und Orientierungssensoren der Smart- phones. 4.1 Accelerometer Daten Tabelle 4.1 zeigt die Spezifikationen der unterschiedlichen Beschleunigungssensoren aus einer Auswahl getesteter Android Geräte, speziell dem Google Nexus S, Samsung Galaxy S2 GT-I9100 und dem Google Galaxy Nexus. Das Spektrum der messba- ren Daten reicht bei diesen Sensoren maximal bis 19,6133 m/s2 , aufgrund negativer Beschleunigung (Bewegung des Geräts in entgegengesetzter Richtung zu den Sen- sorachsen, siehe Abbildung 2.1), ist der Minimalwert hierbei somit -19,6133 m/s2 . Die Auflösung sowie die minimale Verzögerung des K3DH Acceleration Sensors vom GT-I9100 Smartphone ist bei diesem Gerät jeweils am geringsten, es lässt sich da- her annehmen, dass der Sensor im Vergleich zu den anderen Sensoren somit auch am präzisisten ist. Dieser Annahme widerspricht jedoch der Vergleich der ermit- telten Benchmark Ergebnisse. Aus Tabelle 4.2 geht hervor, dass das GT-I9100 der Gesamtpunktzahl nach nur den zweiten Platz belegt, mit großem Abstand zum Ers- ten. Schaut man sich die einzelnen Teilkategorien genauer an, so fällt auf, dass das GT-I9100 bezüglich der Standardabweichung eine hohe Punktzahl von 4.758 Punk- ten erreicht, im Gegensatz zur Konkurrenz fast das Vierfache. Allerdings erreicht Googles Galaxy Nexus bereits in einer einzigen Kategorie eine so hohe Punktzahl, dass es die Gesamtpunktzahl des GT-I9100 Modells deutlich übertrifft. So erzielt der MPL Accelerometer von Invensense des Galaxy Nexus’ allein bei der Schrittweite 166.242 Punkte und wird dadurch zum besten Sensor in diesem Vergleich. Auch im Bereich der Zeitkontinuität punktet das Galaxy Nexus. Im Bezug auf die Gravitati- onsgenauigkeit schließen alle drei Sensoren gleich gut ab.
30 4 Evaluation
Tabelle 4.1: Diese sensorspezifischen Daten, hier am Beispiel der jeweiligen Accele-
rometer, können auf Android Geräten einfach ausgelesen werden, aller-
dings stellt nicht jeder Sensor diese Daten zur Verfügung.
Geräte
Marke Google Samsung Google
Hersteller Samsung Samsung Samsung
Modell Nexus S GT-I9100 Galaxy Nexus
Beschleunigungssensoren
KR3DM K3DH
MPL
Name 3-axis Acceleration
Accelerometer
Accelerometer Sensor
Hersteller STMicroelectronics STMicroelectronics Invensense
1 1 1
Typ
(Accelerometer) (Accelerometer) (Accelerometer)
Version 1 1 1
Max. Spektruma 19,6133 19,6133 19,6133
Auflösung a 0,019153614 0,0047884034 0,038344003
Min. Verzögerung 20000 µs 5000 µs 10000 µs
Strom 0,23 mA 0,25 mA 0,139 mA
a
SI-Einheit der Werte in m/s2
Die Eventanzahl variiert je nach Sensor zwischen 1.008 Events beim Nexus S und
2.465 Events beim Galaxy Nexus. Während sich die Anzahl beim GT-I9100 (1.954
Events) und Nexus S noch im Bereich der zulässigen Anzahl durch die jeweiligen mi-
nimalen Verzögerungen (siehe Tabelle 4.1) befindet, so werden beim Galaxy Nexus
deutlich mehr Events registriert. In einem Testzeitraum von 20 Sekunden und einer
minimalen Verzögerung von 10.000 µs sollte der Sensor maximal 2.000 Events regis-
trieren können, diese Grenze wurde in mehreren Tests mit dem Galaxy Nexus um
über 460 Events überschritten. Dies zeigt, dass die Herstellerangaben, die aus den
Sensoren auszulesen sind, nicht immer korrekt sind. Bestätigt wird diese Erkenntnis
durch die Messung der mittleren Zeitdifferenz, diese beträgt rund 8.135 µs, wie aus
Tabelle 4.3 auf Seite 33 hervorgeht. Dort fällt auch auf, dass die durchschnittliche
Zeitdifferenz im Rahmen der Initialisierung bei diesem Sensor mit über 10.000 µs
größer ist als die während des Benchmarks. Dies ist außergewöhnlich, da der Sensor
unter Bewegung theoretisch mehr Ereignisse als im ruhenden Zustand registrieren
sollte.4.1 Accelerometer Daten 31
Tabelle 4.2: Benchmarkergebnisse der einzelnen Bewertungskategorien mit SensMark
am Beispiel der jeweiligen Accelerometer.
Geräte
Gerätemodell Nexus S GT-I9100 Galaxy Nexus
KR3DM K3DH
MPL
Sensorname 3-axis Acceleration
Accelerometer
Accelerometer Sensor
Benchmarkergebnisse (Punktzahlen)
Totala 9745 15186 178123
Standard-
1420 4758 1048
abweichung
Min. Schrittweite 1723 2423 166242
Zeitkontinuität 1594 2051 4368
Eventanzahl 1008 1954 2465
Gravitations-
4000 4000 4000
Genauigkeit
Unterschiedliche
360 503 977
Werte
a
Nicht alle gelisteten Bewertungskategorien fließen in die Gesamtbewertung ein. Im Falle des Ac-
celerometer Benchmarks wird die Punktzahl der unterschiedlichen Werte vernachlässigt.
Aber auch beim GT-I9100 gibt es große Abweichungen bezüglich der minimalen Ver-
zögerungsangabe von 5.000 µs, da die mittlere Zeitdifferenz bei Initialisierung und
Benchmark jeweils über 10.000 µs beträgt. Lediglich die Angabe bezüglich der Auf-
lösung des Accelerometers im Nexus S stimmt über mehrere Tests verglichen immer
mit der minimalen Schrittweite exakt überein.
In Tabelle 4.3 sind außerdem alle weiteren Zwischenergebnisse, die zur Berechnung
des Benchmarks verwendet werden nachzulesen, wie etwa Standardabweichung,
Schrittweite und die Teilergebnisse der Zeitdifferenzen. Bei der Schrittweite erkennt
man sehr deutlich die Überlegenheit des Galaxy Nexus Sensors im Vergleich zu den
Werten der beiden anderen Geräte, somit erklärt sich auch die große Differenz der
Punktzahl in dieser Kategorie. Zusätzlich werden auch die minimalen und maxi-
malen Werte sowie die Mittelwerte der Sensorachsen erfasst, welche während des
Benchmarkprozesses gemessen wurden, diese dienen jedoch lediglich Informations-
zwecken.
In weiteren Tests mit dem Samsung Galaxy S GT-I9000 fiel auf, dass die Standard-
abweichung den Wert 0 besaß, dies ist außergewöhnlich. Es stellte sich außerdem32 4 Evaluation heraus, dass das gemessene Minimum, Maximum und der Durchschnitsswert gleich waren, tatsächlich hat der Sensor je Achse knapp 460 mal den selben Wert gemes- sen. Aus diesem Ergebnis lassen sich zwei Theorien ableiten, zum einen, dass der Sensor perfekt ist und zum anderen, dass er sehr ungenau und extrem träge ist. Ein perfekter Sensor lässt sich allerdings schon durch die Tatsache ausschließen, dass in Smartphones und Tablet-PCs sehr preisgünstige Sensoren verbaut werden und somit nicht den exakten Wert bestimmen können. Dieses Teilergebnis wurde daher mit null Punkten bewertet, da anhand der gemessenen Werte keine Aussa- ge über die Korrektheit der Werte getroffen werden kann (mehr dazu in Kapitel 5, Seite 41).
4.1 Accelerometer Daten 33
Tabelle 4.3: SensMark Zwischenergebnisse der jeweiligen Accelerometer.
Gerätemodell Nexus S GT-I9100 Galaxy Nexus
Standardabweichung
X 0,06208044860 0,019835792579 0,09423100106
Y 0,06760053673 0,015177562223 0,10083207998
Z 0,08255973709 0,035868353054 0,08884605027
Minimum
X -1,1109096 -0,08172209 -0,53588563
Y -0,36391866 -0,040861044 -0,68916684
Z 9,442732 9,547864 9,311237
Maximum
X -0,7086837 0,13620348 0,15388
Y 0,05746084 0,19068487 0,03891907
Z 9,959879 9,888372 9,962683
Mittelwert
X -0,9124378657 -0,023260542 -0,17500621321
Y -0,1585303547 0,0222637619 -0,31987720481
Z 9,72009795431 9,7297794411 9,639952350098
Min. Schrittweite
X 0,019153595 0,013620347 5,9890747·10−4
Y 0,019153595 0,013620347 1,487732·10−4
Z 0,019153595 0,013619423 1,487732·10−4
Eventanzahl
518 873 995
(Initialisierung)
Minimale
15894000 8301000 9796142
Zeitdifferenz (ns)
Mittlere
Zeitdifferenz (ns) 1,9977589·107 1,1377923·107 1,0079817·107
(Initialisierung)
Mittlere
Zeitdifferenz (ns) 2,0118463285·107 1,0280380269·107 8126266,7484787
(Benchmark)
Standardabweichung
Zeitdifferenz (ns) 0,0317044348930 0,129106237762 0,0083888131335
(Initialisierung)
Standardabweichung
Zeitdifferenz (ns) 0,0153623845970 0,007700634457 0,0047793032421
(Benchmark)34 4 Evaluation
4.2 Gyroskop Daten
Betrachtet man die Sensorangaben der Gyroskope von den ausgewählten Geräten aus
Tabelle 4.4, so ergeben sich gleich mehrere Auffälligkeiten. Beim Nexus S und GT-
I9100 ließe sich aufgrund des gleichen Namens K3G Gyroscope Sensor auf den ersten
Blick vermuten, dass auch der gleiche Sensor verbaut ist, tatsächlich unterscheidet er
sich in der Schreibweise, beim Nexus S mit kleinem Anfangsbuchstaben bei „sensor“.
Bei der Angabe des Spektrums stellt sich dann doch offensichtlich heraus, dass es
sich um zwei komplett unterschiedliche Sensoren handelt, das maximale Spektrum
des GT-I9100 beträgt nur knapp ein viertel der beiden anderen Sensoren. Die Auf-
lösung des Galaxy Nexus Gyroskops hingegen ist deutlich höher als die Auflösungen
der anderen Gyroskope. Die minimale Verzögerung ist beim Nexus S mit 1.190µs be-
sonders gering, dies spiegelt sich auch in den Ergebnissen wieder (siehe Tabelle 4.5).
Mit 16.750 registrierten Events in 20 Sekunden misst der Sensor im Vergleich acht
mal so viele Werte, außerdem schneidet er bei der Zeitkontinuität ebenfalls gut ab,
hier übertrifft er die anderen Sensoren um das Vier- bis Fünffache.
Tabelle 4.4: Diese sensorspezifischen Daten, hier am Beispiel der jeweiligen Gyrosko-
pe, können auf Android Geräten einfach ausgelesen werden, allerdings
stellt nicht jeder Sensor diese Daten zur Verfügung.
Geräte
Marke Google Samsung Google
Hersteller Samsung Samsung Samsung
Modell Nexus S GT-I9100 Galaxy Nexus
Gyroskop
K3G K3G
MPL
Name Gyroscope Gyroscope
Gyroscope
sensor Sensor
Hersteller STMicroelectronics STMicroelectronics Invensense
4 4 4
Typ
(Gyroskop) (Gyroskop) (Gyroskop)
Version 1 1 1
Max. Spektruma 34,906586 8,726646 34,90656
Auflösung a 0,0012217305 3,0543262·10−4 0,57246757
Min. Verzögerung 1190 µs 5000 µs 10000 µs
Strom 6,1 mA 6,1 mA 6,1 mA
a
SI-Einheit der Werte in rad/secSie können auch lesen
