Android und MSVC 2017

Schon sein einiger Zeit beinhaltet das GATE Projekt eine separate Visual Studio 2017 Solution mit einem C++ Build für das Android NDK (Native Development Kit).

Man lernt doch so einiges, wenn man Quellcodes durch unterschiedliche Compiler oder Platformen schickt.

Hier mal ein Bericht von der Front:


Vorgeschichte

Mein Kontakt mit dem Android NDK liegt schon über 5 Jahre zurück und war nicht besonders positiv. Da Android auf mich wie eine andere Linux Distribution wirkte, vermutete ich, dass keine sonderlich große Portierung meiner POSIX Sourcen notwendig war.

Leider Falsch! Denn Android unterstützt einige Standard POSIX Features wie z.B. Shared Memory nicht und somit laufen solche API-Aufrufe ins Leere. Auch die C++ STL und korrektes Exception Handling waren nicht Teil des ursprünglichen Konzeptes und somit wird die Portierung von nativen Code enorm erschwert.
Anstatt dessen wurden neue Non-Standard C-APIs publiziert, die auf dieser Plattform zu nutzen sind.

Die Kompatibilität verbesserte sich zwar von NDK Release zu Release und es kamen nach und nach Wrapper-Bibliotheken ins Netz, die APIs wie shmget auf Android Äquivalente hin und her übersetzten … doch ein solches Abhängigkeitschaos wollte ich eigentlich nicht in meiner Code-Base haben.

Installation mit Studio 2017

Mit Microsofts Entscheidung, Android in Visual Studio zu integrieren, stieg meine Hoffnung, dass es nun einfacher werden könnte, mit dieser Plattform zu experimentieren.
Denn früher musste man eine Google Installation mit deren eigenen Tools durchführen und Projekte auf das dort vorherrschende Format konvertieren bzw. neu anlegen.

Nun übernimmt das alles der Studio Installer und nachdem eine Vorlage und ein Ziel System gewählt wird, richtet die Solution alles bis zum Emulator hin ein.

Kein X86 64 bit

Nun, für Android wird ohnehin meist nur für die ARM Architektur entwickelt, trotzdem lassen sich X86 32 und 64 bit Ziele anlegen. Leider werden aber für 64-bit keine Header mitinstalliert.
Im Setup wurde 64-bit aktiviert doch Builds finden dann keine Header, weil das benötigte Verzeichnis nicht vorhanden ist.

C-locale und math nicht implementiert

Dass System-Funktionen wie shmget() wie fehlen … naja OK, aber dass der C-Header <locale.h> leer implementiert ist, gefällt mir nicht. Die im GATE Framework integrierte Script-Sprache LUA macht hier einen Aufruf zu localeconf() in einem Makro, der nicht aufgelöst werden kann.

Nun gut, hier geht es um ein alternatives Dezimalkommazeichen.
Das kann man zum Glück per vordefiniertem Maktro in den Projekteinstellungen überschreiben, z.B. mit: "lua_getlocaledecpoint()='.'"

Und dann fehlt auch noch die C99 Funktion log2, obwohl der Compiler diesen Standard voll abdecken sollte. Nun gut, auch hier kann man auf das ältere log aufweichen und result = log(value) / log(2.0) nutzen. In LUA wird das z.B. durch das Makro LUA_USE_C89 aktiviert.

Emulator mit unterschiedlichen Halbwertszeiten

Das mit Visual Studio mitgelieferte Hyper-V VM Image mit Android in unterschiedlichen API-Leveln ist eigentlich genial. Man kompiliert ein X86 Android Paket und das Resultat wird von der IDE in die VM Sitzung geladen um dort live getestet zu werden.

Leider ist dieses Setup aus meiner Sicht instabil, denn mir passiert es stets, dass nach einiger Zeit (1 - 5 Monte) Android Projekte zwar kompilieren aber nicht mehr zum Emulator hochgeladen werden können.
Ich vermute, dass Studio-Updates wie auch die halbjährlichen Windows Updates jedes mal etwas kaputt machen und dann hilft nur noch eine Neuinstallation oder vollständige Reparaturinstallation von Visual Studio.

Und so etwas nervt über die Jahre hinweg tierisch und wurde bis heute nicht vollständig gefixt.

Fazit

In Summe waren die Probleme gar nicht so groß und im GATE Framework konnte ich die meisten nicht-exisitierenden System-APIs einfach per #ifdef auf den Result-Code NOTIMPLEMENTED umleiten.

Die Emulatorsache ist lästig, aber wenn er wieder läuft, dann hält es auch für einige Zeit.

In Summe muss ich dem Visual Studio Team ein großes Lob aussprechen. Mit der Möglichkeit Windows und Android Apps in einer Umgebung zu entwickeln, wurde die IDE enorm aufgewertet.

Mein nächstes Ziel wird es sein, ganze Android Apps mit dem GATE Framework zu erstellen. Bin gespannt, was sich da noch alles zeigen wird.


Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!

Meine Dokus über:
 
Externe Links zu: