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… .
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.
meine Antwort wird etwas länger, aber hoffentlich beantwortet sie die wesentlichen Fragen.
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”.
Das ist dann die Plus-Version.
Das war zumindest mal die Free-Version, also mit Download-Beschränkung.
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.
Verwendet den neuen Qt-Kern (mit OpenGL und Qt).
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.
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.
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”.
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.
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:
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.
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)…
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.
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.
