OsmAnd Nightly builds - 3 Varianten - bitte um Erklärung

fireball2 · 2018-07-10T10:51:46.000Z

Hallo Leute,

kann mir bitte jemand die Unterschiede zwischen den 3 verschiedenen nightly builds von OsmAnd erklären? Für jeden Tag findet man dort u.a.:
OsmAnd-default-nb-2018-07-09.apk 77MB → OsmAnd Nightly 3.0.0#21737d, net.osmand.dev
OsmAnd-master-nb-2018-07-09.apk 76MB → OsmAnd~ 3.0.0#25353m, net.osmand.plus
OsmAnd-master-qt-nb-2018-07-09.apk 107MB → OsmAnd~ 3.0.0#10823mqta, net.osmand.plus

Dr. Google erzählt darüber nur sehr spärlich.
Das große master-qt-build soll sehr experimentell und sehr langsam sein, hauptsächlich weil es wohl ausschließlich im “safe mode” läuft?!
Beide master-builds (mit oder ohne “qt”) installieren sich unter Android als “OsmAnd~” (net.osmand.plus).
Das default-build installiert sich als “OsmAnd nightly” (net.osmand.dev).
Alle 3 Varianten dürften OsmAnd+ entsprechen. Die dev-Variante scheint aber darauf hinzudeuten, dass damit wirklich neue Funktionen getestet werden. Während das master-build dazu dienen könnte vorhandene Funktionen stabil hinzubekommen. Die QT-Variante könnte dafür vielleicht erweiterte Fehlermeldungen ausspucken bzw. eine debug-Version darstellen?!

Irgendwie ist das trotzdem etwas dürftig und hauptsächlich ins Blaue hinein geraten. Weiß vielleicht jemand mehr über Sinn und Zweck dieser 3 zeitgleich vorgehaltenen Varianten? Was bedeutet z.B. “nb” und “qt” in der Dateibezeichnung?

Zusatzfrage: Wenn man sich OsmAnd~ von f-droid.org herunterlädt (z.B. v3.0.3 mit 83MB vom 9.6.2018), müsste man dann nicht in den nightlys auf osmand.net eine halbwegs gleiche apk vorfinden? Vergleicht man aber Datum und Dateigröße, dann wird man nicht fündig. Für das ganze Jahr 2018 gibt es kein nightly-build in dieser Größe zum Download?
83MB 2018-06-09 OsmAnd~ v3.0.3 f-droid.org
79MB 2018-06-09 OsmAnd-default-nb-2018-06-09.apk
78MB 2018-06-09 OsmAnd-master-nb-2018-06-09.apk
109MB 2018-06-09 OsmAnd-master-qt-nb-2018-06-09.apk
Ist die f-droid-Variante deshalb ein anderer Entwicklungszweig oder wird die f-droid-Version nur anders kompiliert und resultiert vielleicht daraus auch die abweichende apk-Dateigröße? Ich bin verwirrt… .

Harald_Hartmann · 2018-07-10T14:23:52.000Z

Nur schonmal für den Fall, dass dir bei dieser ganz speziellen Frage hier niemand antwortet:

https://groups.google.com/forum/#!forum/osmand
https://github.com/osmandapp/Osmand

abrensch · 2018-07-10T14:48:40.000Z

fireball2:

Weiß vielleicht jemand mehr über Sinn und Zweck dieser 3 zeitgleich vorgehaltenen Varianten? Was bedeutet z.B. “nb” und “qt” in der Dateibezeichnung?

Hatte mir vor 3-4 solche Fragen mal gestellt, und was über den UN-Sinn gelernt…

Damals gab’s einen “nativen” build und einem “normalen”

“Nativ” heisst, dass, obwohl Android-Apps eigentlich in einer Java-VM laufen und daher auch in Java programmiert sind, die kritischen Prorammteile (also der Renderer und der Router) auch in einer C++ Version enthalten waren. Die C++ Version war etwas schneller, was nach Ansicht der Autoren in der Natur der Sache lag, nach meiner Ansicht aber eher an deren Vorlieben.

Nebeneffekt ist dann halt auch, das solche nativen Apps nicht mehr im “safe mode” laufen. Wenn die dann zu viel Speicher brauchen, stürzt nicht mehr die App ab (sondern gleich das ganze Smartphone).

Jedenfalls war es fast unmoeglich, selbst einen nativen build herzustellen, die build-umgebung (inkl. dem “NDK” = native development kit) war einfach zu komplex und das Entwickerteam hat 0 Aufwand betrieben, die zu dokumentieren und zu konsolidieren.

“nb” könnte also immer noch “native build” heissen?

Und “qt” ist wohl eine andere, neue, ebenfalls native Implementierung fuer den Rederer, die auf dem QT-Framework basiert.

Auf die Idee, einfach die Java-Implementierung zu reparieren kommen die nicht.

whb · 2018-08-31T16:25:50.000Z

Hallo,

meine Antwort wird etwas länger, aber hoffentlich beantwortet sie die wesentlichen Fragen.

fireball2:

Das große master-qt-build soll sehr experimentell und sehr langsam sein, hauptsächlich weil es wohl ausschließlich im “safe mode” läuft?!

Etwas experimentell, aber kein “safe mode”.
Wenn es nicht läuft, dann wird auf die Java-Implementierung umgeschaltet, das wäre dann die Rückfalleben oder der “safe mode”.

fireball2:

Beide master-builds (mit oder ohne “qt”) installieren sich unter Android als “OsmAnd~” (net.osmand.plus).

Das ist dann die Plus-Version.

fireball2:

Das default-build installiert sich als “OsmAnd nightly” (net.osmand.dev).

Das war zumindest mal die Free-Version, also mit Download-Beschränkung.

fireball2:

Die dev-Variante scheint aber darauf hinzudeuten, dass damit wirklich neue Funktionen getestet werden. Während das master-build dazu dienen könnte vorhandene Funktionen stabil hinzubekommen.

master-nb und default-nb verwenden exakt den selben Code.
default ~~war mal für~~ ist die Free-Version ~~gedacht~~ (Plus- und Free-Version sind identisch, die Umschaltung erfolgt dann, bis auf die Icons und den App-Namen, zur Laufzeit anhand des App-Namens).
Für Experimente ist der “design”-build.
Die nightly-Builds sind übrigens alle Debug-Builds ~~(soweit ich mich erinnere)~~ und dementsprechend langsamer, als die Release-Builds.

fireball2:

Die QT-Variante könnte dafür vielleicht erweiterte Fehlermeldungen ausspucken bzw. eine debug-Version darstellen?!

Verwendet den neuen Qt-Kern (mit OpenGL und Qt).

fireball2:

Irgendwie ist das trotzdem etwas dürftig und hauptsächlich ins Blaue hinein geraten. Weiß vielleicht jemand mehr über Sinn und Zweck dieser 3 zeitgleich vorgehaltenen Varianten? Was bedeutet z.B. “nb” und “qt” in der Dateibezeichnung?

default-nb ist die Free-Version mit Download-Beschränkung, gebaut mit assembleFreedevLegacyFatDebug, Name “OsmAnd Nightly”
master-nb ist die Plus-Version ohne Download-Beschränkung, gebaut mit assembleFullLegacyFatDebug, Name “OsmAnd~”
qt-nb = neuer Qt-Kern
“nb” bedeutet"nightly build", nicht native build, wie von abrensch vermutet.

fireball2:

Zusatzfrage: Wenn man sich OsmAnd~ von f-droid.org herunterlädt (z.B. v3.0.3 mit 83MB vom 9.6.2018), müsste man dann nicht in den nightlys auf osmand.net eine halbwegs gleiche apk vorfinden? Vergleicht man aber Datum und Dateigröße, dann wird man nicht fündig. Für das ganze Jahr 2018 gibt es kein nightly-build in dieser Größe zum Download?
83MB 2018-06-09 OsmAnd~ v3.0.3 f-droid.org
79MB 2018-06-09 OsmAnd-default-nb-2018-06-09.apk
78MB 2018-06-09 OsmAnd-master-nb-2018-06-09.apk
109MB 2018-06-09 OsmAnd-master-qt-nb-2018-06-09.apk
Ist die f-droid-Variante deshalb ein anderer Entwicklungszweig oder wird die f-droid-Version nur anders kompiliert und resultiert vielleicht daraus auch die abweichende apk-Dateigröße? Ich bin verwirrt… .

Interessante Beobachtung.
Inzwischen ist die Version bei F-Droid auf 73 MB geschrumpft.
Habe die Free-Version von OsmAnd mit der Plus-Version von F-Droid (beide 3.0.4) verglichen, sind nur ca. 100kB Unterschied:
https://f-droid.org/repo/net.osmand.plus_304.apk
https://download.osmand.net/releases/net.osmand-3.0.4-304.apk
Evtl. leicht andere Parameter oder Versionen der Build-Umgebungen.

abrensch:

“Nativ” heisst, dass, obwohl Android-Apps eigentlich in einer Java-VM laufen und daher auch in Java programmiert sind, die kritischen Prorammteile (also der Renderer und der Router) auch in einer C++ Version enthalten waren. Die C++ Version war etwas schneller, was nach Ansicht der Autoren in der Natur der Sache lag, nach meiner Ansicht aber eher an deren Vorlieben.

Java und C++ Versionen sind 1:1 “Übersetzungen”, also zu 99% gleich implementiert.
Google empfiehlt die Nutzung des NDK, wenn Java für die Aufgabe nicht performant genug ist.

abrensch:

Nebeneffekt ist dann halt auch, das solche nativen Apps nicht mehr im “safe mode” laufen.

Unklar, was du damit genau meinst.
Ein Unterschied ist, dass es mit JNI möglich ist nahezu unbegrenzt Speicher zu reservieren.
Bei der Android-JVM hingegen ist der Java-Heap je nach Gerät sehr beschränkt.
Als OsmAnd mit der nativen Bibliothek angefangen hat, waren das oft nur 16 oder 32 MB.
Inzwischen ist das deutlich mehr, auch dank “largeHeap”.

abrensch:

Wenn die dann zu viel Speicher brauchen, stürzt nicht mehr die App ab (sondern gleich das ganze Smartphone).

Eindeutig ein Gerätefehler, meistens irgendwelche schrottigen Treiber, die sonst was mit dem System anstellen…
Apps, welche zu viel Speicher beanspruchen (egal ob Java oder nativ), werden schlicht und einfach vom Betriebssystem beendet.

abrensch:

Jedenfalls war es fast unmoeglich, selbst einen nativen build herzustellen, die build-umgebung (inkl. dem “NDK” = native development kit) war einfach zu komplex und das Entwickerteam hat 0 Aufwand betrieben, die zu dokumentieren und zu konsolidieren.

Es existieren mehrere Anleitungen, die nicht alle aktuell sind, das ist nicht gerade optimal.
Dem Server kann man dafür live zuschauen, wie er OsmAnd baut.
https://builder.osmand.net:8080/view/OsmAnd%20Builds/

Nachdem das mit OSMfocus so gut funktioniert hat, hier eine kurze Anleitung, ist wirklich nicht schwer OsmAnd komplett, auch mit NDK zu bauen, mit Windows geht das aber nicht:

1.) Benötigte Daten herunterladen:

git clone https://github.com/osmandapp/Osmand.git android
git clone https://github.com/osmandapp/OsmAnd-resources.git resources
git clone https://github.com/osmandapp/osmandapp.github.io.git help
git clone https://github.com/osmandapp/OsmAnd-core.git core-legacy

OsmAnd empfiehlt dafür “repo” (gibt es irgendwo bei Google zum Herunterladen) zu verwenden (und verwendet das auch auf dem Server):
https://github.com/osmandapp/OsmAnd-manifest/blob/master/android_build.xml
Ich halte aber ein extra Programm wegen 5 Zeilen für etwas übertrieben.

2.) Auf den aktuell verwendeten nativen Kern umstellen (also nicht den neuen Qt-Kern verwenden):

cd core-legacy && git checkout legacy_core

3.) Die Pfade zu NDK (zzt. wird das aktuelle r17b verwendet) und SDK setzen:

export ANDROID_HOME=/path/to/Android/Sdk/ ANDROID_NDK=/path/to/Android/Sdk/ndk-bundle/

4.) In android/OsmAnd/build.gradle noch die “signingConfigs” anpassen, damit die Pakete mit den eigenen Signaturen signiert werden können.

5.) Dann OsmAnd bauen:

export LANG=en_US.utf8
cd ~/osmand/osmandapp/android/OsmAnd
../gradlew --info --no-daemon clean cleanNoTranslate assembleFullLegacyFatRelease

Anstatt Fat (enthält alle Versionen der nativen Bibliothek, wie Armv7, x86,…) kann z.B. auch nur Armv7 verwendet werden, für die Emulator-Beschleunigung ist aber auch X86 sehr zu empfehlen.
Anstatt Release ist entsprechend auch Debug möglich.
Anstatt Full auch Free ~~oder Dev~~, Fulldev, Free, Freedev oder …
“export LANG=en_US.utf8” wird benötigt, damit der OpeningHoursParserTest nicht fehlschlägt.

abrensch:

Und “qt” ist wohl eine andere, neue, ebenfalls native Implementierung fuer den Rederer, die auf dem QT-Framework basiert.

Stimmt, wird zurzeit aber nur für die iOS-Version von OsmAnd verwendet.
Die Qt-Version verwendet OpenGL, schreibt das Ergebnis dann aber nur in eine Bitmap, welche dann angezeigt wird…
Da fehlt also noch etwas, damit das richtig schnell wird.
Außerdem werden Kacheln erzeugt, die dann nach und nach, sobald diese fertig sind, eingeblendet werden, das wirkt etwas gewöhnungsbedürftig.
Beim bisherigen Kern wird das Bild “live” aufgebaut, da kann man dann zusehen, wie die Schichten nach und nach gezeichnet werden, insofern das Gerät nicht zu schnell ist.
Die Qt-Version wird für Android noch nicht verwendet, hat einfach keine entscheidenden Vorteile, dafür aber Probleme mit fehlerhaften Grafiktreibern.
Z.B. bei einem meiner Android-Geräte hat der Grafiktreiber, wenn von einer App per OpenGL eine neue Textur erstellt wurde, immer mehrere MB Luft zwischen den Texturen gelassen, so dass der virtuelle Adressraum der App relativ schnell voll war und diese dann abstürzte (Fehler wurde inzwischen vom Gerätehersteller per Update behoben)…

abrensch:

Auf die Idee, einfach die Java-Implementierung zu reparieren kommen die nicht.

Ich glaube die funktioniert sogar.
Ich hatte mal vergessen die native Bibliothek zu bauen, da lief dann nur die Java-Implementierung und es kam eine Meldung, die native Bibliothek würde nicht unterstützt.
Das Rendering war etwas langsamer und sah in einigen Details leicht anders aus, hat aber funktioniert.

Viele Grüße,
whb

whb · 2018-08-31T22:18:34.000Z

Habe es gerade nochmals überprüft:
default-nb ist die Free-Version mit Download-Beschränkung, gebaut mit assembleFreedevLegacyFatDebug, Name “OsmAnd Nightly”
master-nb ist die Plus-Version ohne Download-Beschränkung, gebaut mit assembleFullLegacyFatDebug, Name “OsmAnd~”
Beides sind Debug-Versionen.
Ich vermerke das gleich noch im Beitrag oben.

Kurz zusammen gefasst:

default ist die Testversion für die Free-Version
master ist die Testversion für die Plus-Version
qt ist die Testversion für den neuen Qt-Kern
diese 3 Builds sind Debug-Builds
nb bedeutet nightly build