Schlagwort-Archive: android

Eine freie GSM-Masten-Datenbank für offline Standortbestimmung

GPS erlaubt Nutzern von Smartphones und anderen Geräten, auf der ganzen Welt gebührenfrei ihren Standort zu bestimmen. Leider kann so eine Standortbestimmung je nach Witterung bzw. Sichtverhältnis zu den GPS-Satelliten mitunter mehrere Minuten dauern. Um dies zu beschleunigen, kann man auf das „A“ in „AGPS“ zurückzugreifen, das für „Assisted“ steht, die Miteinbeziehung der sichtbaren GSM-Masten in die Standortbestimmung. Welche Masten verfügbar sind, erlaubt praktisch verzögerungslos einen Rückschluss auf die ungefähre Position, die ggf. auch mit unvollständig vorliegenden GPS-Werten verfeinert werden kann.

Für diese Triangulation ist freilich erforderlich, dass man den Standort der jeweils sichtbaren GSM-Masten kennt. Um die Standorte abzurufen, greifen Smartphones ab Werk auf das Internet zu, doch dies bringt einige Probleme mit sich:

  • Es setzt voraus, dass eine Internet-Verbindung besteht.
  • Es erzeugt zusätzlichen, ggf. kostenpflichtigen Traffic.
  • Es öffnet eine Tür für Manipulationen der Standort-Daten.
  • Es ermöglicht dem Provider, den eigenen Standort festzustellen.

Die Lösung ist eine offline-Datenbank, also eine Datenbank aller GSM-Masten weltweit, die der Benutzer bei bestehender Internetverbindung, also z.B. im häuslich WLAN, herunterlädt zusammen mit einer Ersatz-App für den Standort-Dienst (Location Provider), welche anstelle der Internetverbindung die lokale Datenbank nutzt.

UnifiedNlp ist eine solche App und es gibt verschiedene Datenbanken für sie.

Tobias Kuban hat nun auf Github die Datenbanken von OpenCellId und Mozilla Location Services zu einer globalen Karte von GSM-Masten für UnifiedNlp zusammengeführt. Die Datenbank ist entpackt ca. 1 GB groß und kann hier heruntergeladen werden:

Nach dem Herunterladen des Archivs kann es mit xz (Linux) oder 7-Zip (Linux,Windows) entpackt werden:

und bei per microUSB angeschlossenem Smartphone mit adb rübergeladen werden:

Dazu muss noch das UnifiedNlp Frontend und Backend installiert werden, z.B. aus F-Droid.

Android Open Source Release Management Continuous Delivery

Release Management ist ein wichtiges Mittel um effizient der Nutzerschaft neue Versionen einer Software bereitzustellen. Ein Artefakt muss aus einem bestimmten Stand der Quellen erzeugt und in einem geeigneten Repository bereitgestellt werden. Normalerweise wird das Release mit einer informativen Release Note bestückt. Im Fall von Open Source Software gibt es zusätzliche Anforderungen, wie zum Beispiel eine Referenz auf den verwendeten Stand der Quellen und eine Dokumentation.

Ein gutes Release Management erlaubt es, jederzeit ein funktionierendes Artefakt veröffentlichen zu können. Ein solcher Aufbau soll im folgenden für Android  Apps unter Verwendung von Git als Versionsverwaltungssystem, Jenkins als Build Server, Javadoc als Dokumentationswerkzeug und Fdroid als Markplatz zur Veröffentlichung der Apps beschrieben werden.

Unterschiedliche Zielgruppen

Wir unterscheiden in unserem Fall zwischen zwei Gruppen von Nutzern, denen jeweils in unterschiedlichen Zyklen Updates bereitgestellt werden sollen.

Entwickler sollen immer mit dem neuesten Stand einer App und der dazugehörigen Dokumentation versorgt werden. Auf diese Weise kann innerhalb des Entwicklerteams jeder den aktuellen Stand einer App installieren und testen. Dabei muss nicht jeder Stand zwangsläufig ein komplett fertiggestelltes Feature enthalten.
Die Endanwender wiederum sollen nur in den Genuss von ausgewählten Versionen einer App kommen, in der sich mindestens eine spürbare Änderung im Vergleich zur Vorversion befindet.
Im folgenden verwenden wir die Begriffe Release und Dev um die beiden Zielgruppen auseinanderzuhalten.

Unterschiedliche Orte für Fdroid und Javadoc

Um Artefakte und Dokumentation für beide Zielgruppen zu trennen legen wir je ein Fdroid Repository und einen Ort für das Javadoc an. Um sie in Jenkins Jobs einfacher ansprechen zu können, legen wir die Orte in Umgebungsvariablen ab. Die folgenden Variablen werden in der weiteren Beschreibung verwendet:

  • FDROID_REPO_DEV
  • FDROID_REPO_RELEASE
  • JAVADOC_DEV
  • JAVADOC_RELEASE
Dev Konfiguration

Um die Konfiguration möglichst simpel zu halten, verwenden wir pro App einen Jenkins Job der auf jeden push in das Git Repositories reagiert. Im Abstand von wenigen Minuten fragt Jenkins das Git Repository ab und startet folgenden Gradle Aufruf.

  • clean assembleRelease  leert das build Verzeichnis und kompiliert das apk File
  • publishFdroid -Pfdroid=${FDROID_REPO_DEV} -Ppatch=${BUILD_NUMBER} veröffentlicht die App Fdroid Dev Repo und verwendet für den dritten Teil der Versionsnummer die Nummer des Builds
  • publishJavadocRelease -Pjavadoc=${JAVADOC_DEV}  erstellt die Javadoc Dokumentation in einem dafür vorgesehenen Verzeichnis

Als Post Build Action werden die folgenden beiden Artefakte archiviert. Diese werden benötigt um zu einen beliebigen Zeitpunkt einen Stand in das Fdroid Release Repository zu veröffentlichen.

  • app/build/outputs/apk/app-release.apk
  • gradle.properties

Zum einen handelt es sich dabei um das apk File selbst und zum anderen um eine Properties Datei, die weitere Informationen über die App enthält.

Die Werte werden unter anderem verwendet, um die Metadaten des Fdroid Repisitories zu füllen. Bei Bedarf kann die Liste natürlich um weitere Einträge erweitert werden. Wie oben beschrieben wird die Patch Version durch den Parameter patch  von außen gesetzt. Für das Setzen der Versionsanteile Major und Minor ist der Entwickler verantwortlich.

Release Konfiguration

Für die Realisierung der Release Konfiguration verwenden wir das Promoted Builds Plugin. Die Promotion soll nur manuell ausgelöst werden.

Die Release Notes können für die Veröffentlichung im Dev Repo direkt aus jeder Git Commit Message des Commits gezogen werden, der den Build getriggert hat (mehr dazu weiter unten). Für die Release Notes des Release Repos ist das nicht der Fall, da davon auszugehen ist, dass zur Fertigstellung eines Features mehrere Commits getätigt wurden. Aus diesem Grund fügen wir der Promotion den Textparameter RELEASE_MESSAGE hinzu. Auf diese Weise kann ein sprechender, für den Endanwender gedachter Text für das Release angegeben werden.

Da die Promotion zeitlich verzögert also auch erst nach weiteren Commits stattfinden kann, ist der Zustand des Workspace nicht stabil.
Daher müssen im ersten Build Step der Promotion die veröffentlichten Artefakte des ursprünglichen Builds wieder zurück in Workspace kopiert werden. Dafür verwenden wir das Copy Artifacts Plugin. Als Jobname wird der Name des Jobs angegeben dessen App veröffentlicht werden soll, als die Nummer des spezifischen Builds die Variable ${PROMOTED_NUMBER} . Auf die Weise ist sichergestellt, dass genau die Version der App verwendet wird, die zuvor beim automatischen Build erstellt wurde. Gleiches gilt auch für die Metadaten.

Der zweite Build Step der Promotion ist ein Gradle Aufruf, der sich nur minimal von dem des Dev Builds unterscheidet. Die Tasks clean  und assembleRelease entfallen, da das Artefakt schon vorhanden ist. Die Verzeichnisse für das Fdroid Repository und die Dokumentation werden mit den entsprechenden Umgebungsvariablen für die Variante Release angegeben. Zu beachten ist die Verwendung des Parameters message , der den Wert des Jenkins Text Parameters übergeben bekommt.

 Gradle Tasks

Im folgenden wollen wir näher die verwendeten Gradle Tasks und deren Konfiguration eingehen. Wie zuvor erwähnt wir beim Gradle Aufruf die Versionskompente patch von außen gesetzt.

Fdroid

Die Variable fdroidDir beschreibt das Verzeichnis des Fdroid Repositories. Sie muss beim Aufruf gesetzt werden, da sonst sämtlich Fdroid bezogene Tasks übersprungen werden.

Die Variable fdroidMessage kann durch den Parameter message beim Aufruf gesetzt werden, was wie schon erwähnt in unserer Konfiguration bei der Promotion genutzt wird. Sollte message nicht von außen gesetzt werden, wird die Commit Message des letzten Commits verwendet.

  • tidy  entfernt ein Artefakt selben Names aus dem Fdroid Repository
  • copy  kopiert das gebaute apk File in das Fdroid Repository und benennt es enstprechend der Versionsnummer um
  • writeMetadata  beschreibt die Metadata Datei der App. Dabei werden die Werte aus gradle.properties verwendet
  • updateMetadata  aktualisiert die Metadaten
  • publishFdroid  aktualisiert das Fdroid Repository

Javadoc

Die Variable javadocDir beschreibt das Verzeichnis, in das die Javadoc Dokumentation kompiliert werden soll. Das Verzeichnis kann beim Gradle Aufruf durch den Parameter javadoc überschrieben werden. Wird dieser Parameter nicht verwendet, landet das kompilierte Javadoc unterhalb des Projektverzeichnisses.

Er wird pro Build Variante ein Gradle Task in der Form publishJavadoc  erstellt, sodass ein möglicher Aufruf gradle publishJavadocRelease -Pjavadoc=/my/javadoc/dir  lauten könnte.

Fazit

Die Erstellung eines ausgeklügelten Build und Release Mechanismus erfordert meist einen hohen Aufwand, bis sämtliche Schritte funktionieren und alle Rädchen ineinander greifen. Jedoch lassen sich auf diese Weise zeitaufwändige Schritte automatisieren, und neue Versionen per Knopfdruck veröffentlichen. Erfahrungsgemäß lohnt sich die Einrichtung eines Release Mechanismus schon bei wenigen Projekten innerhalb von kürzester Zeit.

Android : Signieren von Apps How To

Android-Apps werden dem Benutzer bekanntermaßen in Form von APK-Dateien bereitgestellt. Weniger bekannt ist, dass diese APKs neben der Software selbst auch eine Signatur enthalten, die ihre Integrität und Authentizität garantieren soll.

APKs mit Entwicklungs-Versionen einer Software sind mit dem Android-SDK-Schlüssel signiert, der mit dem SDK ausgeliefert wird. Dieser ist jedoch nicht zur Verwendung in App-Repositorien gedacht bzw. zulässig. Um APKs veröffentlichen zu können, muss sich ein Entwickler selbst einen Signaturschlüssel anlegen, ein Zertifikat das seine Identität mit einem Schlüsselpaar verbindet. Bei Android-Apps muss dieses Zertifikat nicht von einer vertrauenswürdigen Stelle signiert sein. Das wäre ein vergleichsweise umständlicher Vorgang, der zudem mit Kosten verbunden wäre und die Entwicklung bzw. Veröffentlichung von Apps behindern würde. Die Signatur erfüllt damit aber auch nicht den Zweck für Dritte eine echte Vertrauenswürdigkeit herzustellen. Er verhindert jedoch, dass gefälschte Nachfolgeversionen einer App veröffentlicht werden. Der Schlüssel eines Entwicklers hat daher eine ausgesprochen lange Gültigkeit, wird aber beim ersten Hochladen einer App nicht auf Echtheit geprüft.

Die Verwendung eines Email-Schlüssels (PGP) ist (nach Konvertierung) möglich.

Bolyde : Schönes Boot ahoi #tt Session 2014/09/18

Neuer Donnerstag neues Glück. Nachdem wir letzte Woche das Fluppy zu Wasser gelassen haben, sollte in dieser Woche die Steuerung per App folgen. Auch diesmal hat uns die Technik einen Strich durch die Rechnung gemacht.

Der neue Absatz sieht vor, das Signal der Fernbedienung zu reverse engineeren. Auf diese Weise sind wir von der gekauften Fernbedienung größtenteils unabhängig.

Sauvignon : Parallaxe #tt Session 2014/08/14

Da soll noch einer sagen wir starten ständig Projekte und bringen keins zu Ende. Der Auslöser für unser Android SVG Projekt Sauvignon gehört seit heute nicht mehr dazu.

Aber der Reihe nach : Um dem (zukünftigen) Anwender unserer Apps langweilige Wartezeiten beim Laden zu ersparen, kam uns Idee, den Splash Screen einer App während des Ladens zu animieren. Mittels Bewegung des Smartphones sollte durch Parallaxe der Eindruck von räumlicher Tiefe entstehen. Soweit die Theorie.

Lass uns doch dafür SVG verwenden …

-Matthias

Nach mindererfolgreicher Suche nach einer passenden Bibliothek für Android begann der steinige Weg zu Sauvignon, einer SVG Bibliothek, die neben einem Parser und einen Renderer mittlerweile auch eine rudimentäre Animationsengine beinhaltet.

Zurück ins jetzt : eben diese Engine ermöglicht es uns heute, SMIL basierte Animationen zu realisieren. Die Ursprungsgrafik stammt wie gehabt aus einer SVG Datei, die Animation wird zur Laufzeit hinzugefügt sodass zum Beispiel der Beschleunigungssensor oder Touch Eingaben für interaktive Animationen verwendet werden können.

Ersteres nutzen wir um grafische Elemente abhängig von ihrem z-Index um einen bestimmten Wert zu verschieben. Et voilà, ein parallaktischer 3D Effekt.

Sauvignon : Falsch positiv #tt Session 2014/07/10

In dieser Session mussten wir schmerzhaft feststellen, dass Anwendungen mit rein grafischem Output nur schwer automatisch zu testen sind.

Einige Fehler in unserer SVG Engine sind uns erst aufgefallen, nachdem wir die Ausgabe auf verschiedenen Geräten und damit mit unterschiedlichen Auflösungen getestet haben.

Hinzu gekommenen sind kleinere Features wie die Integration von Polygon und Polyline Elementen, die Interpretation von verschiedenen Line Caps bei Path Elementen und die Unterstützung von verschiedenen Farbformaten.

Sauvignon : Bounding Rects #tt Session 2014/06/30

Auch in dieser Woche stand die Arbeit an unserer SVG Engine Sauvignon im Vordergrund. Diesmal beschäftigten wir uns mit dem Thema Bounding Rects.

Ein Bounding Rect ist ein Rechteck, das ein zweidimensionales Objekte minimal umschließt. Nutzen wollen wir diese Rechtecke um insbesondere Animationen besser nachvollziehen zu können. Besonders wenn ein Element von einem anderen verdeckt wird, können Bounding Rects nützlich sein.

Bei der Umsetzung haben wir zwei Varianten berücksichtigt:

In der ersten Variante wird ein Bounding Rect um das untransformierte Objekt gelegt und anschließend auf die gleiche Weise transformiert, wie das Objekt selbst.

Bei der zweiten Variante wird das Bounding Rect erst erzeugt, nachdem sämtliche Transformationen auf das Element angewendet wurden. Es verhält sich somit parallel zu den Achsen des Bildschirms.

Sauvignon : SVG Animation #tt Session 2014/06/13

In der dieswöchigen Session haben wir uns Gedanken zum Thema SVG Animation gemacht und verschiedene Ansätze diskutiert. Dabei haben wir uns auf drei Varianten festgelegt.

Die erste besteht darin, die Animationen in Form von SMIL im SVG selbst zu definieren. Diese Form ist Teil der SVG Spezifikation und wird normalerweise auch durch Browser unterstützt.

Sauvignon : Path Element #tt Session 2014/05/29

Genau wie in der letzten Woche haben wir auch diesmal zusammen an unserem SVG Parser weitergearbeitet. Nachdem sich zuletzt eine gewisse Komplexität beim Rendering von Path Elementen angedeutet hat, haben wir und diesmal fast ausschließlich auf Path Segmente vom Typ arc konzentriert. Anders als bei anderen Segementtypen gibt es hier keine direkte Entsprechung in Android.