Anwendungen herstellen

Anstelle (oder ebenso gut wie) binäre APKs externen Ursprungs in ein Repository aufzunehmen, können sie ebenso gut direkt aus dem Quellcode hergestellt werden.

Bei Verwendung dieser Methode, ist es möglich zu überprüfen, ob die Anwendung korrekt erstellt wird, mit dem Quellcode übereinstimmt und nur freie Software enthält. Bedauerlicherweise scheint es in der Android-Welt üblich zu sein, dass Anwendungen, die als binäre APKs angeboten werden, sich als Freie Software präsentieren, obwohl tatsächlich einige oder gar alle der folgenden Umstände zutreffen:

  1. Der Quellcode (entweder einer bestimmten Version oder sogar aller Versionen!) steht nicht zur Verfügung oder ist unvollständig.
  2. Der Quellcode ist nicht dazu geeignet, die angebotene, eigentliche Binärdatei zu erzeugen.
  3. Der ’Quellcode’ enthält Binärdateien unbekannter Herkunft oder mit proprietären Lizenzen.

Aus diesen Gründen werden für das F-Droid-Hauptrepository aus dem Quellcode erstellte Anwendungen bevorzugt, wenngleich gelegentlich, aus technischen oder historischen Gründen, Ausnahmen von diesem Grundsatz gemacht werden.

Bei der Herstellung von Anwendungen aus dem Quellcode sollte beachtet werden, dass Sie sie mit Ihrem eigenen Schlüssel signieren werden (alle APK-Dateien müssen zur Installation in Android signiert sein). Ist eine Anwendung auf einem Gerät bereits installiert, dann wird keine Aktualisierung möglich sein, wenn die neue Version mit einem davon abweichenden Schlüssel signiert ist, bevor nicht das Original deinstalliert wurde. Dies kann bei den Nutzern zu Unannehmlichkeiten führen, da mit dem Deinstallationsvorgang alle mit der ursprünglichen Installation verknüpften Daten verloren gehen.

Die Abläufe zur Verwaltung eines Repositorys für quelltexterstellte Anwendungen ähneln denen, die im Kapitel „Einfaches Binärdateien-Repository“ beschrieben sind. Sie müssen nun allerdings:

  1. Eintragungen zur Herstellung in die Metadaten-Dateien einschließen.
  2. fdroid build ausführen, um alle Anwendungen herzustellen, die noch nicht erstellt sind.
  3. fdroid publish ausführen, um die Konfektionierung abzuschließen und alle hergestellten APKs zu signieren.

App-Daten-Verzeichnis oder fdroiddata

Um alles zu erledigen, wird mindestens ein Repository-Datenverzeichnis benötigt. Innerhalb dieses Verzeichnisses führen Sie den fdroid-Befehl aus, um alle Repository-Verwaltungsaufgaben auszuführen. Sie können entweder ein ganz neues erstellen oder eine Kopie der Daten heranziehen, die im F-Droid-Hauptrepository verwendet werden:

git clone https://gitlab.com/fdroid/fdroiddata.git

Unabhängig von der beabsichtigten Verwendung der Werkzeuge, werden Sie immer einige grundlegende Konfigurationsdetails festlegen müssen. Dies geschieht durch Erstellung einer Datei namens config.yml im Datenverzeichnis. Es empfiehlt sich die Beispieldatei (./examples/config.yml) aus dem fdroidserver-Projekt in Ihr Datenverzeichnis zu kopieren und sie dann entsprechend der darin enthaltenen Anweisungen zu bearbeiten.

Ist die Konfiguration auf diese Weise einmal erfolgt, werden alle Werkzeugfunktionen durch Ausführung des fdroid-Befehls zugänglich. Wird der Befehl für sich allein ausgeführt, erhalten Sie eine Liste der zur Verfügung stehenden Unterbefehle.

Jeder Befehl kann mit --help ergänzt werden, um eine Liste zusätzlich verfügbarer Optionen für diesen Befehl zu erhalten.

fdroid update --help

Mehr zu fdroid build

Bei Ausführung ohne weitere Parameter wird fdroid build sämtliche Versionen von Anwendungen herstellen, die noch nicht im repo-Verzeichnis (oder genauer, im unsigned-Verzeichnis) enthalten sind. Es gibt zahlreiche weitere Dinge, die Sie tun können. Wie bei allen Instrumenten ist die --help-Option Ihr Freund. Es folgen lediglich einige erläuternde Beispiele und die Besprechung der meistgebrauchten Verwendungsarten:

Um eine Einzelversion einer einzigen Anwendung herzustellen, könnten Sie Folgendes ausführen:

fdroid build org.fdroid.fdroid:16

Es wird hier versucht Version Code 16 (entspricht Version 0.25) des F-Droid-Client herzustellen. Viele der Instrumente erkennen Argumente als Pakete, sodass ihr Aufgabenbereich genau auf einen begrenzten Satz von Paketen beschränkt werden kann.

Wenn die o. g. Herstellung erfolgreich war, werden zwei Dateien im unsigned-Verzeichnis eingestellt sein:

org.fdroid.fdroid_16.apk
org.fdroid.fdroid_16_src.tar.gz

Die erste ist das (unsignierte) APK. Sie könnte mit einem Debug-Schlüssel signiert und direkt auf Ihr Gerät oder einen Emulator zum Testen verschoben werden. Die zweite ist ein Quellcode-Tarball, der genau den Quelltext enthält, der zur Generierung der Binärdatei verwendet wurde.

Beabsichtigen Sie diese Dateien zu veröffentlichen, könnten Sie nun Folgendes ausführen:

fdroid publish

Der Original-Tarball würde ins repo-Verzeichnis verlagert (das Verzeichnis, das Sie auf Ihren Webserver kopieren würden). Eine signierte und zip-komprimierte Version des APK würde ebenfalls dort erscheinen und beide Dateien würden aus dem unsigned-Verzeichnis entfernt werden.

Erfolgt die Herstellung rein zu Testzwecken und sollen die Ergebnisse nicht, oder zumindest noch nicht, in ein Repository verschoben werden, kann die --test-Option verwendet werden, um die Ausgabe ins tmp-Verzeichnis statt ins unsigned umzuleiten. Der gleiche Effekt könnte erzielt werden, indem die Ausgabedateien aus unsigned nach der Herstellung einfach gelöscht werden, allerdings mit dem Risiko, dass dies vergessen wird!

In ähnlicher Weise (und nur in Verbindung mit --test), kann --force verwendet werden, um die Herstellung einer Gesperrten Anwendung zu erzwingen, für die es normalerweise völlig ignoriert werden würde. Ebenso kann die Herstellung einer Version, in der ELFs oder bekannte unfreie Bibliotheken gefunden wurden, erzwungen werden. Siehe auch — scanignore und scandelete im Abschnitt Builds.

Wenn die Erstellung fehlschlug, können Sie einen Blick auf die Ausgabe im logs/-Verzeichnis werfen, um herauszufinden warum. Ist das nicht erhellend, versuchen Sie die App auf herkömmlichem Weg, Schritt für Schritt, herzustellen: Android Update Project, NDK-Build, Ant Debug.

Berücksichtigen Sie, dass Quellcode-Repositorys oft vorgefertigte Programmbibliotheken enthalten. Wenn die App für das F-Droid-Hauptrepository bestimmt ist, ist es wichtig, dass alle diese Bibliotheken entweder über die Metadaten oder durch einen seriösen Drittanbieter hergestellt sind.

Ausführung von fdroid build in Ihrer App-Quelle

Eine weitere Möglichkeit, fdroid build einzusetzen, besteht, wenn lieber eine Metadaten-Datei genutzt werden soll, die in der App-Quelle selbst enthalten ist, als eine in einem metadata/-Ordner mit vielen anderen Apps. Die Metadaten-Datei .fdroid.yml sollte sich im Wurzelverzeichnis des Quellrepos befinden.

Sind diese Vorgaben erfüllt, kann die Herstellung der aktuellsten Version der App unter Nutzung des gesamten F-Droid-Funktionsumfanges folgendermaßen erfolgen:

fdroid build

Möchten Sie jede Einzelversion herstellen, ergänzen Sie --all.

Direktinstallation

Erstellung und Installation können auch direkt auf einem verbundenen Gerät oder Emulator erfolgen, indem der Befehl fdroid install angewendet wird. Geschieht das ohne Übergabe von Paketen als Argumente, dann wird jede verfügbare, zuletzt erstellte und signierte Version jedes Pakets installiert werden. In den meisten Fällen wird dies nicht erwünscht sein, daher bricht die Ausführung sofort ab. Sollte es tatsächlich gewünscht sein, kann dieses Verhalten allerdings durch Verwendung von --all wieder aufgehoben werden. Zu beachten ist, dass dabei momentan keine Plausibilitätsprüfungen erfolgen, sodass keine Benachrichtigungen stattfinden, wenn die Dateien im signierten Ausgabeverzeichnis verändert wurden.