Anstatt (oder zusätzlich zu) binäre APKs aus externen Quellen in ein Repository aufzunehmen, kannst du diese direkt aus dem Quellcode erstellen.

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.

Beim Erstellen von Anwendungen aus dem Quellcode sollte beachtet werden, dass du sie mit deinem eigenen Schlüssel signieren wirst (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 quellcodeerstellte Anwendungen ähneln denen, die im Kapitel „Einfaches Binärdateien-Repository“ beschrieben sind. Du musst nun allerdings:

1. Eintragungen zur Herstellung in die Metadatendateien 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ührst du den fdroid-Befehl aus, um alle Repository-Verwaltungsaufgaben auszuführen. Du musst 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, wirst du 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 dein 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, erhältst du 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 noch verschiedene andere Möglichkeiten. Wie bei allen Tools ist die Option --help dein Freund, aber im Folgenden findest du einige kommentierte Beispiele und Erläuterungen zu den gängigsten Verwendungsmodi:

Um eine Einzelversion einer einzigen Anwendung herzustellen, könntest du Folgendes ausführen:

fdroid build org.fdroid.fdroid:16

Dies ist ein Versuch, den Versionscode 16 (entspricht Version 0.25) des F-Droid-Clients zu erstellen. Viele der Tools erkennen Argumente als Pakete, sodass ihre Aktivität auf eine begrenzte Anzahl 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

Das erste ist die (nicht signierte) APK. Du kannst diese mit einem Debug-Schlüssel signieren und zum Testen direkt auf dein Gerät oder einen Emulator übertragen. Das zweite ist ein Quell-Tarball, der genau den Quellcode enthält, der zum Erstellen der Binärdatei verwendet wurde.

Beabsichtigst du diese Dateien zu veröffentlichen, könntest du nun Folgendes ausführen:

fdroid publish

Der Quell-Tarball würde ins repo-Verzeichnis verlagert (das Verzeichnis, das du auf deinem Webserver kopieren würdest). 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 nicht-quelloffene Bibliotheken gefunden wurden, erzwungen werden. Siehe auch — scanignore und scandelete im Abschnitt Builds.

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

Berücksichtige, 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 deiner App-Quelle

Eine weitere Möglichkeit, fdroid build einzusetzen, besteht, wenn lieber eine Metadatendatei genutzt werden soll, die in der App-Quelle selbst enthalten ist, als eine in einem metadata/-Ordner mit vielen anderen Apps. Die Metadatendatei .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öchtest du jede Einzelversion herstellen, ergänze --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.