Allgemeine Beschimpfung endender Kompatibilität

Am 24. Oktober beendet Whatsapp die Unterstützung für Geräte mit Android-Versionen unter 5. Wer ein Smartphone besitzt, für das es keine neuere Android-Version als 4 Punkt irgendwas gibt, steht vor der Wahl, das Gerät wegzuschmeißen und ein neues zu kaufen, oder alle seine Freunde zu verlieren.

Whatsapp begründet den Schritt mit fehlenden Sicherheitsupdates für die alten Versionen, fehlender Unterstützung für App-Features (hier würden mich mal die Details interessieren) und weil kaum noch jemand solche alten Geräte verwendet.

Im Mülleimer ist noch Platz!

Natürlich verwenden nur noch 0,00000irgendwas Prozent aller Android-Nutzer so alte Geräte, aber in absoluten Zahlen dürften das trotzdem nicht wenige sein. Ein zwar altes, aber grundsätzlich noch funktionierendes Gerät muss also auf den Elektromüll geschmissen werden, weil die Whatsapp-Entwickler keine Lust mehr haben, die App-Unterstützung für Android 4 weiter zu gewährleisten, sprich: sich mit alten Bibliotheken oder Sicherheitslücken herumzuschlagen. Irgendwo verständlich, klar.

Denn die Ursache des Übels liegt natürlich nicht bei den Entwicklern von Whatsapp, sondern bei denen von Android.

Wie selbstverständlich muss jedes Jahr eine tolle neue better-than-ever Android-Version auf den Markt kommen! Und um zu kaschieren, dass diese für die meisten Nutzer eigentlich keine nennenswerten Verbesserungen bringt, ändert man immer wieder das Design und behauptet, dass die Version noch sicherer ist als die vorherige. Was ja auch stimmt.

Bloß: Es spräche ja nichts dagegen, die Sicherheitsprobleme der vorherigen Version einfach durch Updates zu beseitigen. Bei LTS-Versionen von Linux-Betriebssystemen funktioniert das ja auch schon viele Jahre lang (und Android ist ein Linux). Würde man effizienter, modularer programmieren (und keine Bloatware installieren), wäre auch auf älteren Geräten mit wenig Speicher noch genug Platz für alles. Sicherheitspatches erfordern wohl kaum Megabyteweise neuen Binärcode!

Hach, sie können ja nicht anders

Da bekanntermaßen Hardware-Hersteller überhaupt kein Interesse daran haben, ihren Kunden zu ermöglichen, ältere Geräte länger zu nutzen, verschwenden die natürlich keine Entwicklerressourcen an solche Upgrades. Lieber springen sie auf den Google-Zug auf und bringen jedes Jahr eine neue Geräte-Generation, die eine noch tolle Kamera hat, ein noch größeres Display, ein noch hübscheres Notch oder das man in den Pool mitnehmen oder falten kann, denn das ist es ja, was wir Menschen unbedingt brauchen. Inzwischen gibt es auf diesem Planeten grob geschätzt 14 Milliarden Smartphones, jeder erwachsene Mensch besitzt also längst weit mehr als zwei (plus Tablets). Mehr als die Hälfte ist also überflüssig.

Letztlich reden wir hier von einer Ressourcenverschwendung, die das Gegenteil von nachhaltig ist und einen Material- und Energieverbrauch mit sich bringt, der in einer Welt, die vor dem Klimakollaps steht, verboten gehört. Aber die Anbieter haben ja keine Alternative: Wenn sie keine neuen Betriebssysteme oder Geräte verkaufen können, entfallen schlicht die Einnahmen und sie müssen den Laden dicht machen. Helfen könnte bei Betriebssystemen ein Abo-Modell. Gibt’s ja in anderen Branchen auch. Neue, noch leistungsfähigere Hardware ist unnötiger Fortschritt auf Kosten des Planeten. Das ist krank.

Nur ein paar Beispiele

Bei Apple ist es übrigens nur ein bisschen besser. Für mein 11 Jahre altes, aber noch tadellos funktionierendes MacBook Air, gibt es kein aktuelles MacOS X mehr, und das anstehende Update für den Chrome-Browser installiert sich nicht unter dem alten OS. Folglich bin ich fürderhin gezwungen, einen veralteten Browser zu verwenden, mir einen anderen zu suchen oder das Gerät zu ersetzen.

Noch mehr Beispiele? Ein kleines noch aus eigener Erfahrung: Beim letzten größeren Linux-Kernel-Upgrade musste ich meinen tadellos funktionierenden, nur wenige Jahre alten WLAN-Stick ersetzen, weil der Treiber für den enthaltenen Chip aus dem Kernel entfernt worden war. Wer trifft eigentlich solche rücksichtslosen Entscheidungen, die letztlich beim Endkunden Kosten und Elektromüll verursachen?! Wer trägt die Verantwortung, wem kann ich die Rechnung schicken, wem das Altgerät zwecks umweltgerechter Entsorgung?

Der Gipfel der Ressourcenverschwendung und des Hardware-Wegwerf-Wahns ist übrigens gar nicht Android, sondern Windows. Version 11 kann bekanntlich (normalerweise) nur auf Rechnern mit einem spezifischen Hardwaremodul installiert werden. Sobald also der Support für Windows 10 endet (14. Oktober 2025), müssen alle PCs ohne dieses Modul sicherheitshalber weggeschmissen werden, weil es keine Lücken-Updates mehr gibt (und Windows 10 ist voller Lücken, ach übrigens: Mit Linux kann man solche PCs noch lange weiter betreiben!). Wie viele Geräte da auf den Schrott wandern werden (oder willkommene Opfer für Verschlüsselungstrojaner werden), wage ich nicht zu schätzen.

EDIT: Inzwischen sind zwei weitere prominente Fälle aus dem Android-Bereich bekannt geworden: Die ZDF Mediathek und Youtube laufen nicht mehr unter Android 5. Immerhin verweisen beide Apps auf “Im Browser öffnen”. Was ein bisschen lächerlich ist, denn der läuft ja auch auf dem Gerät, warum dann nicht die Apps, die ja einfach in einem Chrome Webview laufen könnten?!

Diese Funktion ist @Deprecated, weil ich den Namen nicht mehr cool fand

Nicht unerwähnt bleiben soll der Aufwand, den uns als Entwickler jeder endende Software-Upgrade-Pfad aufzwingt. Jede Anwendung verwendet ja irgendwelche Bibliotheken, die ihrerseits gewisse Systemanforderungen haben. Schlicht ausgedrückt: Sobald eine neue Version von ir-gend-was.jar eine Änderung an unserem Code oder gar an den Systemvoraussetzungen unserer Anwendung ändert, müssen wir zwingend aktiv werden – aber niemand bezahlt diesen Aufwand! Diese Kosten – Zeit, Personal, Energie – müssen in unser Produkt von vornherein eingepreist werden, obwohl sie gar nicht seriös kalkuliert werden können, weil sie nicht einmalig anfallen wie der Kaufpreis, sondern laufend.

Und solche Anpassungen müssen wir dauernd machen: Nicht nur bei Android-Apps, wenn Google z.B. verlangt, dass wir die Billing-Library Version 5 für In-App-Käufe verwenden müssen, ansonsten dürfen wir unsere App nicht mehr updaten. Natürlich hat sich die API geändert, also müssen wir Dokus lesen und Codeanpassungen vornehmen, meist ohne dass unsere App dadurch auch nur einen Euro mehr Einnahmen erzeugt. Unverschämtheit!

Oder man denke an PHP-Skripts, die nicht mehr funktionieren, weil der Zugriff auf unbekannte Array-Keys seit PHP 8 standardmäßig eine Warnung statt eine Notice auswirft. Noch schlimmer waren nur die grundlegenden Änderungen am MySQL-Treiber, der alle vorherigen Funktionsnamen änderte. Welche Aufwände das weltweit verursacht hat, und wie viele PHP-Skripte seitdem einfach nicht mehr funktionieren, weil sich niemand darum kümmert, kann niemand schätzen. Nichts gegen Produktpflege, Refactoring, Bugfixing oder von mir aus Verschönerung einer API. Aber wenn man weiß, dass andere Entwickler davon abhängig sind, und eine abwärtsinkompatible Änderung Aufwände verursacht, die man selbst ja nicht hat und deshalb ein Problem anderer Leute sind, dann ist man schlicht ein rücksichtsloser Energieverschwender. Ach übrigens: Wenn man von vornherein seine Software sauber konzipiert, braucht man hinterher weniger zu ändern! Buchempfehlung siehe rechts. Und ansonsten hat man gefälligst die Bedürfnisse des Rests der Welt über die eigenen zu stellen.

Ich verlange daher zeitlich unbegrenzten Update-Support für alle Betriebssysteme wie Linux, Android, Windows, MacOS sowie für alle Open-Source-Software-Bibliotheken und -Plattformen. Neue Features können jederzeit hinzugefügt werden (bitte modular, so dass sie nur dann automatisch nachgeladen werden, wenn gewünscht bzw. wenn der Hardware-Support vorhanden ist), aber niemals dürfen vorhandene Funktionen entfernt oder geändert werden. Tatsächlich hat diese Herangehensweise einen immensen Vorteil: Es muss nur noch eine Software-Version gepflegt und mit Sicherheitsupdates versorgt werden, nämlich die aktuelle. Weniger Stress = mehr Zeit für besseres Coden!

tl;dr: Be smart, stay compatible.

In eigener Sache: Android-Sample-Code-Neuzugänge

Liebe Freunde von “Android-Apps entwickeln mit Java”!

Fans spaßiger App-Bastelei!

Hurra!

Ich habe mein github-Repository um einen Haufen Beispielcode erweitert. Es handelt sich dabei durchweg um Android-Apps, die ein oder mehrere Best Practices in der Android-Entwicklung mit Java zeigen. “Best Practice” heißt natürlich: Was ich für empfehlenswert halte, die Geschmäcker sind halt verschieden. Teilnehmer meiner Trainings kennen diesen Code schon, weil ich ihnen den ausführlich erklärt habe. Jetzt können Sie nochmal draufschauen – oder sich was kopieren, ist ja alles Open Source!

Mit dabei sind Samples zu Themen wie Fragments und Master-Detail-Flow, aber auch die guten alten DialogDemos, die auch das Buch erklärt. Brandneu ist eine Demo der neuen (aktuell noch in Alpha-Version erhältlichen) CameraX-API von Jetpack. Diese wird wahrscheinlich durch irgendwelche API-Änderungen ziemlich schnell obsolet; ich kann noch nicht versprechen, ob oder wann ich sie aktualisiere.

Ebenfalls bekannt aus meinem Buch ist der Kompass, der die Nutzung des Magnetometers und einen selbst gezeichneten View demonstriert. Ferner gibt es einen MiniMiniEditor, der das Speichern von Dokumenten mit dem StorageAccessFramework zeigt. Und last but not least die 9352. Wetterfrosch-App, die die schlechteste UI aller Zeiten aber dafür auch die lehrreichste Retrofit-Implementierung der letzten 23 Minuten mitbringt. Übrigens: Für nächste Woche sind 16 Grad angesagt! Hier, schauen Sie:

Diese App ist tatsächlich sinnvoll nutzbar – also, falls Sie noch keine Lieblings-Wetterfrosch-App installiert haben, nehmen Sie doch diese!

Viel Spaß mit dem Code. Beachten Sie bitte, dass bei Erscheinen einer neuen Gradle- oder Android-SDK-Tools-Version ggf. Aktualisierungen in der build.gradle vorzunehmen werden, da ich es absehbar nicht schaffe, alle Repositories aktuell zu halten.

Entkopplung mit Events

Ein Ausweg aus der Multithread-Hölle (Sie wissen schon, die mit dem fröhlichen Bad in siedenden Race conditions) ist die Entkopplung mit Events. Statt einen linearen Programmablauf zu denken, der streckenweise aus wichtigen Gründen in verschiedenen Threads abläuft, denken Sie lieber an herumgereichte Events oder, allgemeiner: Nachrichten. Ein Message-Broker läuft dazu im Hintergrund und reicht Nachrichten herum. Das entspricht einem Publish-Subscribe-Entwurfsmuster. Der entscheidende Vorteil: Die Nachricht “gehört” immer nur jenem Programmteil (oder Thread), der gerade aktiv ist. Es gibt keinen gleichzeitigen Zugriff mehrerer Threads auf das gleiche Nachrichtenobjekt. Auch der Message-Broker interessiert sich nicht mehr für eine Nachricht, sobald er sie zugestellt hat. Am Ende der Verarbeitung wird einfach eine neue Nachricht mit dem Ergebnis der Berechnung auf gleiche Weise zurück geschickt.

Publish und Subscribe

Sie wissen sicher: Viele größere Software-Systeme arbeiten längst mit Microservices und Message-Brokern wie Apache Kafka, die Nachrichten herumreichen. Aber das geht auch in Android, und Sie können damit leicht und elegant Arbeit in den Hintergrund verlagern. Statt mit AsyncTask, Thread, Handler und runOnUiThread können Sie einfach EventBus verwenden – tun Sie vielleicht eh, denn die Library hat sich in unzähligen Apps bewährt:

dependencies {
implementation 'org.greenrobot:eventbus:3.2.0'
}

Meist verwenden Sie EventBus, um Nachrichten zwischen UI-Komponenten, Fragmenten und Activities oder Services auszutauschen. Aber da Sie per Annotation festlegen können, ob ein EventHandler im Vorder- oder Hintergrund aufgerufen wird, können Sie auch sehr einfach eine saubere Background-Task-Verarbeitung umsetzen:

EB ist eine Abkürzung für EventBus.getDefault()

Links, im Main Thread, schicken Sie (z.B. nach einem Knopfdruck des Nutzers) eine CalculationStartMsg los, nix weiter. Die Message ist ein POJO, das alle nötigen Daten enthält, um die gewünschte Berechnung zu starten. Diese Nachricht (oberer Kaffeefleck) stellt EventBus im Hintergrund zu (siehe @Subscribe-Annotation). Wohlgemerkt ist der UI-Thread völlig unbeteiligt, er macht nach dem EB.post() gar nichts mehr bzw. wartet auf weitere Eingaben.

Die Berechnung im Hintergrund erzeugt eine neue Nachricht mit dem Ergebnis der Berechnung, ResultMsg (unterer Kaffeefleck), und überstellt es dem EventBus. Dieser stellt es der passenden onMessageEvent-Funktion im Main-Thread zur Verfügung, die wiederum das Ergebnis in der UI darstellt.

Async im Pool

Falls Sie oft längere Berechnungen im Hintergrund durchführen, verwenden Sie statt ThreadMode.BACKGROUND lieber ThreadMode.ASYNC. Denn während erstere Variante nur einen Thread verwendet, und mehrere Operationen daher nacheinander verarbeiten muss, benutzt ASYNC einen ThreadPool und kann daher problemlos mehrfach und für länger dauernde Berechnungen (wie Netzwerkzugriff) eingesetzt werden.

Beachten Sie immer den Android-Lifecycle: Beide Klassen (die blaue und die orange) müssen bereits instanziiert sein, sonst können sie keine Events empfangen (). Entweder die Worker-Klasse wird in onCreate der Activity (blau) erzeugt, oder alle Funktionen liegen sogar in der gleichen Activity-Klasse. EventBus kann im Gegensatz zu (expliziten) Broadcasts keine neuen Objekte erzeugen. Natürlich müssen alle beteiligten Klassen sich bei EventBus registrieren (mit EventBus.getDefault().register(this)).

In den Messages können Sie beliebige serialisierbare Daten übertragen, auch größere Mengen. Die Latenz beträgt wenige Millisekunden.

tl;dr: EventBus-ähnliche Architektur löst auf elegante Weise viele Multithreading-Probleme, da sie auf gleichzeitige Zugriffe auf ein und dieselben Ressourcen prinzipiell verzichtet. Das bedeutet maximale Entkopplung, weniger Abhängigkeiten und weniger Probleme. Mit ganz einfachen Mitteln. Investieren Sie Ihre wertvolle Zeit lieber in wichtigere Dinge, zum Beispiel Vermeiden von Sicherheitslücken…

Schriftarten in Android

Jeder, der schonmal eine Urkunde für seinen Zimmeraufräum-Weltmeister (6-jähriger Sohn) designt hat, weiß, dass man da mit Times New Roman und Arial keine Begeisterung auslöst. Auf 1001freefonts.com gibt es deutlich mehr als 1001 Schriftarten – aber wie kriegt man die in seine App?

Wer schonmal im Layout-Editor in Android Studio etwas herumprobiert hat, wird zumindest auf das hier gestoßen sein:

So weit, so langweilig – mehr als diese vier einfachen Varianten lassen sich hier nicht auswählen. Sie können nicht einfach einen Truetype-Font in irgendein Verzeichnis legen und dessen Namen hier hinschreiben. Wie geht’s also sonst?

Tatsächlich gibt es eine klassische Methode und eine neuere, die ich Ihnen hier kurz zeige.

Typefaces aus Assets

Die klassische Methode klappt nicht ohne Code. Dazu legen Sie zunächst die gewünschte Schriftart im TTF-Format ins Verzeichnis assets/fonts. Damit sorgen Sie dafür, dass die Schrift in Ihr APK eingebaut wird. (Der Verzeichnisname fonts ist willkürlich, Sie können ihn auch irgendwie nennen.)

An dieser Stelle eine freundlich gemeinte Warnung: Es sieht nicht nur unprofessionell aus, wenn Sie auf einem Bildschirm 10 verschiedene Schnörkelschriften verwenden – es kostet auch Speicher und Rechenzeit. Achten Sie darauf, nicht zu viele und nicht zu komplexe Schriften zu verwenden. Letzteres erkennen Sie an der Größe der TTF-Datei.

Und noch eine Warnung: Viele im Netz auffindbare Schriften verfügen nicht über deutsche Umlaute. Und die wenigsten bieten Unterstützung auch für ausgefallene Zeichen. Wenn Sie ohnehin keine fremden Schriftsysteme oder Sprachen unterstützen wollen, können Sie das getrost ignorieren – bedenken Sie aber, dass ein griechischer Nutzer Ihres Spiels beim Eingeben seines Namens für Ihre Online-Highscore-Liste möglicherweise griechische Zeichen verwenden möchte. Wenn Sie dem zugehörigen EditText eine Schriftart ohne griechische Buchstaben zugewiesen haben, sieht der Nutzer bloß kleine Rechtecke.

Genug Warnungen, kommen wir zum Programmcode.

Die Schriftart eines TextViews (oder einer Ableitung davon, wie Button) setzen Sie wie folgt:

textView.setTypeface(typeface);

Das zugehörige Typeface-Objekt erzeugen Sie mit einer einfachen Create-Funktion:

Typeface typeface=Typeface.createFromAsset(am, path);

Dabei ist am der AssetManager Ihres Contexts, den Sie innerhalb einer Activity mit getAssets() erhalten.

Als Pfad path übergeben Sie den Dateinamen Ihrer Schriftart relativ zum Verzeichnis assets.

Schriften per FontFamily

Die moderne Variante funktioniert ohne Code. Font-Definitionen per XML wurde in Android 8 eingeführt und funktioniert dank Rückwärtskompatibilität per AndroidX bis hinunter zu Android 4.1 (API 16), was für ungefähr 99% der verwendeten Geräte auf der Welt genügt.

Nunmehr gehören Ihre Schriftartdateien ins Verzeichnis res/font.

Diese referenzieren Sie einfach im TextView-Attribut fontFamily:

Es lassen sich außerdem FontFamilies definieren, so dass für fette oder kursive Schrift automatisch die passende Schriftartdatei zum Einsatz kommt. Mehr zu Fonts erfahren Sie in der offiziellen Dokumentation:

https://developer.android.com/guide/topics/ui/look-and-feel/fonts-in-xml

Android-Speicher sparen mit Google Go

Ich wollte ja schon moppern: “Was hilft das Speicher sparende Google Go, wenn man die fette, große Google-App eh nicht deinstallieren kann?”
Aber es hilft tatsächlich, in Zahlen: Bei mir aufm Xperia 450 MB mehr freier Speicherplatz, wenn ich Google Go installiere und die Google-App deaktiviere (komplett deinstallieren geht ja nicht). Ob ich irgendwelche Features vermisse, oder ob Google Go sich mit der Zeit auch ein halbes Gigabyte reinpfeift, erzähl ich später …
Die Sache zeigt jedenfalls: Wenn man will (oder vom Boss dazu gezwungen wird), kann man durchaus speichersparend programmieren, liebe Entwickler!

(j)Box2d

Für unser neues Android-Gameprojekt (ist noch unter höchster Geheimhaltungsstufe) brauchte ich eine Physik-Engine. Natürlich trifft man als allererstes auf Box2D bzw. deren Java-Version jBox2D.

Ich griff zu letzterer, nachdem ich irgendwo gelesen hatte, der Performanceunterschied sei nicht allzu groß. Dass das Projekt seit 2014 kein Release mehr gesehen hat (aber durchaus Commits!), fand ich nicht weiter schlimm, es ist stabil, gut getestet, von recht hoher Codequalität und da die Physik selten Features hinzugewinnt, muss auch so eine Library nicht dauernd irgendwas nachziehen.

Ich litt etwas unter einem gewissen Mangel an Beispielcode – die meisten Programmierer verwenden heutzutage ja multiplattformhalber Unity und mühen sich nicht mit Android-Libraries ab. Ich bin da speziell – durch konsequente Nichtunterstützung von iPhones habe ich den Apfelkonzern schon an den Rand des Ruins gebracht.

Bei Levels mit etwas mehr physikalischen Objekten darin hatte die Engine merklich Probleme, die Framerate von mindestens 25fps zu halten, jedenfalls in Momenten mit vielen Kollisionen; teils flogen auch mal Teile durcheinander durch. Nun muss man wissen, dass jBox2Ds Funktion world.step() (die für die Physik zuständig ist) single-threaded ist, aber Phones und Tablets heutzutagen auch schon mit 2, 4 oder 8 Kernen daher kommen. Da wird eine Menge Potenzial nicht genutzt. Zwar gilt für die native C++-Version dasselbe, aber Maschinensprache ist eben per se schneller als Java.

Der große Aha-Effekt kam, als ich mir probeweise ein chinesisches Billig-Tablet beschaffte (XGody, 10 Zoll, knappe 70 Euro bei ebay, aber sogar mit OTG-Kabel in der Schachtel (zur hypercoolen Verwendung solcher Kabel in Kürze mehr an dieser Stelle)). Die Framerate sank bei Action im Bild auf unter 5 fps. Autsch.

Eine schnelle Messung ergab: Die Grafik ist nicht schuld, das komplette Zeichnen inklusive Debug-Hilfslinien etc. dauert (im TextureView) nur 25ms. Aber world.step() brauchte 40ms und mehr.

Also ging ich daran, jBox2D durch box2D zu ersetzen. Nun darf man sich das nicht zu einfach vorstellen, denn die Bibliothek gibt es nur im Quellcode, und übrigens auch auf dem Stand von 2014, wie gesagt: Seither hat sich an der Physik dieses Universums nichts verändert.

Die einzige praktikable Option heißt libgdx: Diese Multiplattform-Gameengine verfügt nämlich über ein Erweiterungsmodul, das die native box2D-Bibliothek enthält, und zwar verpackt in einen dünnen Java-Wrapper. Wie sich herausstellte, ließ sich jBox2D fast 1:1 durch libgdx-box2D ersetzen. Fast.

Ein paar Klassen heißen in box2D anders, z.B. Vector2 statt Vec2. Einige Attribute sind nur mit Gettern und nicht direkt zugreifbar. Und body.userdata lässt sich nicht über BodyDef setzen, nur direkt im Body. Eine Klasse AABB (zur Kollisionsberechnung) gibt es nicht, world.QueryAABB() nimmt direkt die Koordinaten des Rechtecks entgegen. Alles recht schmerzfrei.

Natürlich wollte ich nicht das ganze Projekt auf libgdx umstellen, deshalb konnte ich nicht den libgdx-eigenen Project-Wizard verwenden, der auf Wunsch direkt ein Gradle-Projekt mit Box2D-Unterstützung erzeugt. Und wie man das per Hand hinbekommt, steht nirgendwo. Also war probieren angesagt. Entscheidend sind ein paar Änderungen in der build.gradle. Als da wären:

android {
  ...
  defaultConfig {
    ...
    ndk {
      abiFilters "armeabi-v7a", "x86", "armeabi", "x86_64", "arm64-v8a"
    }
  }
}

Dies sorgt dafür, dass die App später die aufgeführten Architekturen unterstützt. Wichtig dabei: Ab 1. August ist Unterstützung der 64-Bit-Architekturen seitens Google Play obligatorisch!

sourceSets {
        main {
            jniLibs.srcDirs = ['lib']
        }
    }

Hiermit wird das Verzeichnis für die nativen Libs festgelegt. Aber woher kommen die?

task copyAndroidNatives {
    doFirst {
        file("lib/armeabi/").mkdirs()
        file("lib/armeabi-v7a/").mkdirs()
        file("lib/arm64-v8a/").mkdirs()
        file("lib/x86_64/").mkdirs()
        file("lib/x86/").mkdirs()

        configurations.natives.files.each { jar ->
            def outputDir = null
            if (jar.name.endsWith("natives-arm64-v8a.jar")) outputDir = file("lib/arm64-v8a")
            if (jar.name.endsWith("natives-armeabi-v7a.jar")) outputDir = file("lib/armeabi-v7a")
            if(jar.name.endsWith("natives-armeabi.jar")) outputDir = file("lib/armeabi")
            if(jar.name.endsWith("natives-x86_64.jar")) outputDir = file("lib/x86_64")
            if(jar.name.endsWith("natives-x86.jar")) outputDir = file("lib/x86")
            if(outputDir != null) {
                copy {
                    from zipTree(jar)
                    into outputDir
                    include "*.so"
                }
            }
        }
    }
}

tasks.whenTaskAdded { packageTask ->
    if (packageTask.name.contains("package")) {
        packageTask.dependsOn 'copyAndroidNatives'
    }
}

So wird Gradle beigebracht, die nativen Bibliotheken an Ort und Stelle abzulegen. (Man kann das später in Android Studio mit Analyze/APK… nachschauen.)

Fehlt noch:

configurations {
    natives
}
dependencies {
   ...
    implementation "com.badlogicgames.gdx:gdx-box2d:$gdxVersion"
    natives "com.badlogicgames.gdx:gdx-box2d-platform:$gdxVersion:natives-armeabi"
    natives "com.badlogicgames.gdx:gdx-box2d-platform:$gdxVersion:natives-armeabi-v7a"
    natives "com.badlogicgames.gdx:gdx-box2d-platform:$gdxVersion:natives-arm64-v8a"
    natives "com.badlogicgames.gdx:gdx-box2d-platform:$gdxVersion:natives-x86"
    natives "com.badlogicgames.gdx:gdx-box2d-platform:$gdxVersion:natives-x86_64"
}

Tatsächlich binde ich hier NUR gdx-box2d ein, und nicht die Hauptbibliothek libgdx selbst, die ich nicht brauche.

Die zu verwendende gdxVersion lege ich in der hierarchisch obersten build.gradle fest:

allprojects {
    repositories {
        google()
        jcenter()
        mavenCentral()
    }
    ext {
        gdxVersion = '1.9.9'
    }
}

Und nun zur Pointe: Die native Version der Bibliothek ist grob geschätzt um einen Faktor 25 schneller. Sogar das lahme-Ente-Tablet aus China erreicht damit eine spielbare Framerate:

Mit ins Bild geschummelt hat sich das mitgelieferte OTG-Kabel

Ein schnelleres Tablet oder Phone kommt locker auf 1ms Rechenaufwand für die Physik (also world.step()), während das Zeichnen “nur” um einen Faktor 3 schneller ist. Aber da lässt sich sicher auch noch was optimieren, das soll ein andermal erzählt werden.

Der Teufel steckt aber mal wieder im Detail. Während jBox2D und box2d selbst ihre physikalischen Objekte (bodies) in verketteten Listen verwalten, benutzt der libgdx-Wrapper zusätzlich eine LongMap. Deren Schlüssel sind aber nicht sortiert, daher geht die Reihenfolge der Bodies zwischen Hinzufügen und Zeichnen verloren! Da keine Möglichkeit vorgesehen ist, eine z-Ebene mitzugeben, kann es passieren, dass Objekte vor anderen (also später) gezeichnet werden, die eigentlich dahinter gezeichnet werden sollen (also früher). Da hat wohl jemand tief geschlafen, als er den Wrapper implementiert hat. Mal sehen, wie ich das löse. Es bleibt spannend.

TILT: Hier geht die Reihenfolge verloren, in der die Bodys hinzugefügt werden, da der Schlüssel der verwendeten LongMap keine Reihenfolge kennt (World.java).

Fazit: Finger weg von jBox2D, sondern gleich die native Version nehmen. Schneller ist schöner.

Ich bedanke mich für die Aufmerksamkeit und gehe mal besser coden.

Android: Speichern ohne Genehmigung

Ein Appetizer aus meinem in Kürze erscheinenden Buch: Android-Apps entwickeln für Einsteiger (8. Auflage).

Von Ihrem PC kennen Sie den »Speichern unter«-Dialog. Jede installierte Anwendung funktioniert in dieser Hinsicht gleich: Sie überlässt Ihnen als Nutzer die Entscheidung, wo ein Dokument landen soll und unter welchem Namen.

Tatsächlich existiert ein solcher Dialog auch unter Android, bloß verwenden ihn nur wenige Apps. Dabei hat das sich dahinter verbergende Storage Access Framework sogar einen immensen Vorteil: Es kommt ohne die Genehmigung zum Speichern von Dateien auf der SD-Karte aus!

Lassen Sie uns als Beispiel einen Mini-Editor schreiben, der es dem Nutzer erlaubt, einen Text einzugeben und ihn mittels Storage Access Framework zu speichern. Dieser bescheidene Funktionsumfang rechtfertigt eigentlich nur den Projektnamen MiniMiniEditor.

Achten Sie darauf, beim Anlegen des Projekts die minSdkVersion auf 19 zu stellen (Android 4.4), denn zuvor existierte das Storage Access Framework noch nicht.

Schalten Sie außerdem die Unterstützung für Java 8 ein, da die folgenden Codezeilen eine Methodenreferenz verwenden.

Verwenden Sie im Layout activity_main.xml ein vertikales LinearLayout, und setzen Sie einen Speichern-Button und ein EditText hinein. Damit letztere View den gesamten verfügbaren Platz ausfüllt und mehrzeiligen Text entgegennimmt, setzen Sie die Attribute wie folgt:

 <EditText android:id="@+id/text"  android:layout_width="match_parent" android:layout_height="0dp"  android:gravity="top|left"  ndroid:layout_weight="1" android:inputType="textMultiLine" />

In der Klasse MainActivity verknüpfen Sie zunächst den EditText mit der festgelegten ID text mit einem Attribut editText und den Button mit einem Listener:

editText = findViewById(R.id.text); 
findViewById(R.id.save).setOnClickListener(this::onSaveClicked);

Wenn der Nutzer auf den Speichern-Button drückt, basteln Sie ein spezielles Intent-Objekt:

Intent intent = new Intent(Intent.ACTION_CREATE_DOCUMENT); 
intent.addCategory(Intent.CATEGORY_DEFAULT); intent.setType("text/plain");
intent.putExtra(Intent.EXTRA_TITLE, "");
startActivityForResult(intent, REQUESTCODE_SAVE);

Entscheidend ist hier die Action ACTION_CREATE_DOCUMENT. Als EXTRA_TITLE können Sie einen Dateinamen vorgeben, den der Nutzer noch ändern kann.

Was Sie hier nicht sehen, ist der eingegebene Text: Der wird nicht etwa an den Intent gehängt, sondern in einem zweiten Schritt gespeichert. Dadurch erhält die Dateiauswahl nie Zugriff auf die fraglichen Daten. Für das eigentliche Speichern sind Sie selbst zuständig.

Deshalb starten Sie den Intent mit startActivityForResult() und übergeben einen frei definierbaren Request-Code.

Der Storage Access Provider horcht mit einem Intent-Filter darauf und präsentiert dem Nutzer einen Auswahldialog.

Standardmäßig zeigt der Speichern unter-Dialog nicht viele mögliche Ziele an: meist nur das Downloads-Verzeichnis und Ihr Google Drive, falls vorhanden. Aber hinter dem Zahnrad rechts oben erreichen Sie den Einstellungen-Dialog, wo Sie mit Erweiterte Geräte anzeigen dafür sorgen können, dass auch Ihr interner Speicher sowie eine eventuell eingesetzte SD-Karte erscheinen. Die meisten neueren Android-Geräte zeigen hier auch USB-Speichermedien an, die Sie einstöpseln.

Sobald der Nutzer das gewünschte Ziel ausgewählt hat, sendet das Storage Access Framework Ihrer Activity ein Ergebnis. Das nehmen Sie entgegen, indem Sie die Methode onActivityResult() überschreiben:

 public void onActivityResult(int requestCode, int resultCode, Intent resultData) { }

Da an dieser Stelle grundsätzlich ganz unterschiedliche Mitteilungen eintreffen können, müssen Sie den requestCode mit Ihrer Definition vergleichen. Der resultCode verrät Ihnen, ob der Nutzer den Vorgang erfolgreich beendet hat – nur dann möchten Sie etwas speichern:

if(requestCode==REQUESTCODE_SAVE
&& resultCode==Activity.RESULT_OK) {
}

Das Storage Access Framework übergibt Ihnen im Intent resultData das Ziel für Ihre Datei, und zwar in Form einer URI:

Uri
uri = resultData.getData();

Diese URI zeigt auf einen Dateipfad, aber dessen genauer Ort muss Sie nicht interessieren. Sie verwenden lediglich den ContentResolver, um sich einen OutputStream zu beschaffen, der Ihre Daten an die richtige Stelle schreibt. Das Storage Access Framework sorgt dafür, dass Sie temporär die nötigen Schreibrechte besitzen, obwohl Ihre App keinerlei Genehmigung zum Schreiben auf den Datenträger besitzt.

Der Schreibvorgang funktioniert im Fall von Textdaten am einfachsten über einen PrintWriter:

 try {
OutputStream stream = getContentResolver().openOutputStream(uri);
PrintWriter writer = new PrintWriter(stream);
writer.write(editText.getText().toString());
writer.flush();
stream.close();
} catch (java.io.IOException e) {
Log.e(getLocalClassName(),"caught IOException",e);
}

Das war schon alles. Natürlich können Sie dem Nutzer jetzt noch eine Erfolgsmeldung zeigen (und im Fehlerfall eine Fehlermeldung), aber das überlasse ich Ihnen.

Das Storage Access Framework kann auch dazu dienen, vorhandene Dateien zum Öffnen auszuwählen, z. B? Mediendateien. Als Intent-Action verwenden Sie dann ACTION_OPEN_DOCUMENT, der Rest funktioniert analog – ebenfalls ohne irgendwelche Permissions. Letztlich entscheidet der Nutzer im Einzelfall darüber, auf welche Dateien Ihre App zugreifen darf, deshalb ist die allgemeine Permission verzichtbar – das ist durchaus manchmal ein Vorteil, denn viele skeptische Nutzer installieren nur Apps, die möglichst wenige Genehmigungen einfordern.

Diese und viele andere nützliche Tipps finden Sie in meinem Buch: Android-Apps entwickeln für Einsteiger (8. Auflage), erschienen im Rheinwerk-Verlag

DeltaCam auf F-Droid

Nach und nach bringe ich einige meiner Open Source-Apps bei F-Droid.org online. Den Anfang macht die DeltaCam, die Bewegungen im Bild festhält. So hinterlassen laufende Ameisen schwarze Spuren auf dem Foto.

Es ist wirklich nicht ganz trivial, eine App bei F-Droid online zu bringen. Deshalb wird es in der nächsten (8.) Auflage von Android Apps entwickeln für Einsteiger ein eigenes Kapitel mit einer Schritt-für-Schritt-Anleitung geben.

Als nächstes soll der “Malkasten für Kids” erscheinen. Wird aber noch ein paar Tage dauern.

Ach ja: F-Droid kann man als zusätzliche Shop-App installieren. Alle angebotenen Apps sind kostenlos und (soweit ich weiß) werbefrei. Eine Wohltat! Und somit die einzige echte Alternative zu Google Play, zumindest für einfache Apps wie Notizblock, Karten, Dateimanager, Mail, Multimedia, Cryptowährungen, Cloud-Synchronisation.

Mining auf Android

Ein Artikel in der letzten c’t hat mich dazu gebracht, ein brandaktuelles Thema in Angriff zu nehmen: Crypto-Currency-Mining auf Android.

Android-Geräte sind natürlich viel zu rechenschwach, um relevante Mengen Kryptowährung zu erzeugen. Aber man stelle sich vor: Ein Spiel finanziert sich nicht über Werbung, sondern über Mining. Der Spieler bezahlt für das Spiel (oder ingame-Items) nicht mit Geld oder durch Genervtwerden mit Werbung, sondern schlicht mit Akkuladung – denn die verbraucht das Mining natürlich. Wenn dann nicht 10 oder 100 oder 1000, sondern 10000 Spieler mal hier, mal da einige Minuten zocken und solange Mining betreiben, kommen ein paar digitale Münzen zusammen.

Dieses Konzept habe ich nun umgesetzt, indem ich die für ARM64-Architekturen verfügbare Version des Miners xmrig in ein Android-Projekt gepackt habe. Wer sich für die Details interessiert, kann den unter GPLv3 veröffentlichten Code anschauen. (Übrigens erlaubt GPLv3, eine Binärdatei auch in proprietärer, kommerzieller Software mitzuliefern, solange sie nicht direkt verlinkt ist – also ist der Vertrieb einer App wie das als Beispiel genannte Game erlaubt).

Oder einfach die App ausprobieren (Installation aus Drittquellen muss auf dem Android-Gerät erlaubt sein, funktioniert nur auf ARM64-Geräten): MoneroMiner.apk

Standardmäßig ist übrigens meine gähnend leere Monero-Wallet eingestellt – man muss also keine eigene haben, um die Technologie auszuprobieren.

Schließlich sei vermerkt, dass eine solche App wirklich ziemlich heißer Scheiß ist, ich bin wohl einer der ersten, der sowas gebaut hat. Daher gönne ich mir jetzt ein schönes Wochenende!