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

[whb]

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