Diese Seite dokumentiert, wie eine neue Anwendung ins F-Droid-Hauptrepository aufgenommen wird. Sie beinhaltet die technischen Einzelheiten, die ein Antragsteller berücksichtigen sollte.

Anwendungsaufnahmevorschlag

Um die Aufnahme einer neuen Anwendung im F-Droid-Hauptrepository vorzuschlagen, könnten die für die Anwendung relevanten Informationen an die Submission Queue gesendet werden. Die Alternative für Fortgeschrittene wäre, eine komplette Metadaten-Datei selbst zu schreiben, zu testen, und die Aufnahme direkt im fdroiddata Git-Repository vorzuschlagen (Merge-Anfrage); was den Vorgang beschleunigt. Beide Arten werden weiter unten im Detail beschrieben.

Zu beachten ist, dass Sie die Aufnahme selbst dann vorschlagen können, wenn Sie nicht selbst Entwickler oder Maintainer der vorgeschlagenen Anwendung sind. Im Hinblick auf Richtlinien in diesem Abschnitt, siehe Aufnahmekriterien und Repository-Aufbauanleitung.

Vorschlag über die Submission Queue

Dies ist die einfachste Art die Anwendung aufnehmen zu lassen. Aber aufgrund des Aufwands an Prüfarbeiten, die für jede Anwendung nötig sind, ist das die langsamste Methode.

Machen Sie das, indem Sie ein neues Ticket in der F-Droid Submission Queue auf GitLab erstellen, fügen Sie alle erforderlichen Details gemäß der Maske mit den Minimalanforderungen hinzu und warten Sie darauf, dass das F-Droid-Team die Anwendung prüfen und alle nötigen Schritte für Sie unternehmen wird.

Vorschlag als Metadaten-Merge-Anfrage

Eine fortgeschrittenere Alternative zur Anwendungsaufnahme ist es, eine F-Droid-Metadaten-Datei für die Anwendung selbst zu schreiben und die Aufnahme vorzuschlagen, indem eine Git-Merge-Anfrage im Metadaten-Repository der F-Droid-Anwendung (fdroiddata GitLab-Repository) ausgefüllt wird. Dies wird zu einer viel schnelleren Aufnahme führen, da die bereits verfügbare Metadaten-Datei die Arbeitsbelastung für die Prüfer bei Durchsicht Ihrer vorgeschlagenen Metadaten reduzieren wird; der Antragsteller übernimmt die Verantwortung, eine korrekte Metadaten-Datei einzureichen.

Bei Aufnahmevorschlägen auf diese Weise, wird vorausgesetzt, dass:

• Sie ein gutes Verständnis davon haben, was Free Software bedeutet und wofür F-Droid steht.
• Sie bereits die Aufnahmekriterien gelesen und verstanden haben.
• Sie die Repository-Aufbauanleitung gelesen und verstanden haben.
• Sie bereits die relevanten Teile des F-Droid-Handbuchs gelesen und verstanden haben.
• Sie wissen, wie Git VCS verwendet wird und wie generell eine Merge-Anfrage (in der GitHub-Terminologie auch als „pull request“ bekannt) funktioniert.
• Sie ein Konto bei GitLab haben.
• Sie über eine lokale Instanz der F-Droid-Server-Software verfügen, und Sie wissen, was Sie tun.

Die empfohlenen Schritte, um eine Aufnahme auf diese Weise vorzuschlagen, stehen im F-Droid-Anwendung-Metadaten-Repository.

Anwendungsprüfprozess

Ist der Aufnahmevorschlag übermittelt, wird die Anwendung in einen Prüfprozess eintreten, in dem F-Droid-Mitarbeiter einen Blick in den Anwendungsquellcode werfen und bestimmen, ob er zur Aufnahme geeignet ist (und wenn nicht, alle notwendigen Schritte festlegen, damit er es wird).

Da F-Droid ein Software-Repository ist, das den Nutzern freie Software zusagt, dient ein Prüfprozess dazu, sicherzustellen, dass alle Anwendungen, die aus dem F-Droid-Hauptrepository bezogen werden, Free Software sind.

Dies ist eine nicht abschließende Liste dessen, was Prüfer tun werden:

• Sie werden Ihr Quellcode-Repository besuchen und in den Lizenzdateien nach Copyright-Hinweisen suchen, einschließlich README, um zu überprüfen, ob die vorgeschlagene Anwendung unter einer anerkannten Freien Software und/oder OSI-Lizenz(en) veröffentlicht wird.
• Sie werden Ihr Build-Skript betrachten, um zu sehen welches Build-System Sie verwenden, und ob der F-Droid-Build-Server damit umgehen kann (Ant und Gradle sind die verbreitetsten und einfachsten).
• Sie werden versuchen, eine Kopie Ihres Quellcodes herunterzuladen.
• Sie werden in allen Quellcodedateien nachsehen, um nachzuprüfen, ob ihre Lizenzen mit den dazugehörigen Dateien in license/README übereinstimmen.
• Sie werden prüfen, ob Ihre Anwendung irgendwelche vorgefertigten Bibliotheken oder Binärdatei-Einsprengsel nutzt.
• Sie werden einen Blick auf Ihre Nicht-Quellcodedateien werfen, um unfreie Ressourcen herauszufinden, die in Ihrer Anwendung verwendet werden.
• Sie werden Ihren Quellcode überfliegen, um zu sehen, ob Ihre Anwendung unfreie Abhängigkeiten verwendet, Werbung einblendet, Nutzer überwacht, unfreie Dienste/Anwendungen bewirbt oder von ihnen abhängt oder irgendetwas anderes, für Anwender schädliches oder sonst unerwünschtes, tut.
• Sie werden eine Zusammenstellung aller AntiFeatures in Ihrer Anwendung auflisten.
• Sie werden versuchen Ihre Anwendung zu patchen, um die Verwendung proprietärer Drittanbieter-Software (so es die gibt) zu entfernen.
• Sie werden versuchen, einen geeigneten Aktualisierungsvorgang für Ihre Anwendung festzulegen (z. B. indem sie sich ansehen, wie Ihre Versionen VCS-Tags und/oder Versionsinformationen in AndroidManifest.xml zugeordnet sind).
• Sie werden versuchen eine passende Metadaten-Datei für Ihre Anwendung zu schreiben, und sie der lokalen F-Droid-Build-Server-Instanz hinzufügen. (fdroid rewritemeta, fdroid lint werden verwendet, um sicherzustellen, dass die Metadaten korrekt gebildet werden)
• Sie werden versuchen, Ihre Anwendung in einer abgeschirmten Umgebung herzustellen, um zu sehen, ob der Prozess erfolgreich abläuft und ein funktionierendes APK erbringt.
• Wenn alles reibungslos verläuft, werden sie eine neue Metadaten-Datei in ihr lokales fdroiddata-Git-Repository einfügen und die Änderung mit GitLab synchronisieren.

Für den Fall, dass die Anwendung einige Prüfschritte nicht besteht, wird im ursprünglichen Thread der Submission Queue, an die der Vorschlag gesendet wurde, eine Rückmeldung erfolgen.

Ist das fdroiddata-Repository auf GitLab aktualisiert, ist es eigentlich nur noch eine Frage der Zeit, bis der offizielle Build-Server von F-Droid Ihre Anwendung abruft, herstellt und im F-Droid-Hauptrepository veröffentlicht.

Sie können sich von der Aufnahme Ihrer Anwendung überzeugen, indem Sie sich den GitLab-fdroiddata-Revisionsverlauf ansehen.

Besondere Überlegungen zur Metadaten-Merge-Anfrage

Für den Fall, dass die Aufnahme über eine GitLab Merge-Anfrage erfolgt, ist der Prüfprozess theoretisch derselbe. Er wird hauptsächlich durchgeführt, um zu bestätigen, dass die vorgeschlagenen Metadaten mit denen übereinstimmen, die tatsächlich im Quellcode der Anwendung enthalten sind. Die Schritte zum Schreiben und Einstellen der Metadaten werden übersprungen, da die Metadaten-Originaldatei, die Sie vorgeschlagen haben, verwendet wird. Die Rückmeldung erfolgt im Original-Thread der Merge-Anfrage, in dem die Anwendung eingereicht wurde; und ist der Vorgang einmal abgeschlossen, geschieht das Merging mit der master-Branch des fdroiddata-GitLab-Repository.

In der Bestrebung, den Prozess zu optimieren, wenn Sie die Aufnahme über eine Metadaten-Merge-Anfrage vorschlagen, verlassen sich die F-Droid-Mitarbeiter auf einige Voraussetzungen, wie (oben ausgeführt). Somit wird der Prüfprozess in gewisser Hinsicht sehr viel weniger intensiv ausfallen und deutlich weniger Zeit in Anspruch nehmen. Um Richtlinien verletzende Anwendungen, die sich auf diesem Weg irgendwie einschleichen, wird sich nachträglich gekümmert.

Reproduzierbare Builds

Reproduzierbare Builds sind für Apps keine Voraussetzung, um auf F-Droid zu sein. Wir sehen ihre Verwendung aber als optimales Verfahren. Und unglücklicherweise, kann man nicht einfach später zu ihnen wechseln, weil Android keine Aktualisierungen mit unterschiedlichen Signierschlüsseln erlaubt, was bedeutet, dass Anwender neu installieren müssen. So empfehlen wir für neue Apps nachdrücklich sie einzusetzen.

Die Sache mit den reproduzierbaren Builds ist die, dass die Entwickler-Signatur (der von ihnen veröffentlichten APK) sicherstellt, dass unser Build mit deren übereinstimmt (und so nichts enthält, was er nicht sollte) und gleichzeitig unser Build-Server überprüft, dass der Build des Entwicklers zum veröffentlichten Quellcode passt (und so ebenfalls nichts enthält, was er nicht sollte).

Dies stärkt das Vertrauen und macht Angriffe auf die Versorgungskette schwieriger. Es macht es auch unmöglich, dass sich nur in der F-Droid-Version ein Fehler zeigt (oder umgekehrt). Die Nutzung des Entwickler-Schlüssels bedeutet für sie, dass sie die Möglichkeit haben, Anwender selbst mit Aktualisierungen zu versorgen, wenn wir das aus irgendwelchen Gründen (vorübergehend) nicht können.

Einige Apps – insbesondere jene ohne nativen Code, die nur Kotlin/Java verwenden – lassen sich sehr leicht reproduzierbar machen. Andere erfordern etwas mehr Aufwand. Leider können bestimmte Apps überhaupt nicht reproduzierbar werden.

Wir hoffen, dass Entwickler uns zustimmen, dass es aufgrund der verschiedenen Vorzüge zumindest einen Versuch wert ist, ihre Apps reproduzierbar zu gestalten. Sollten sie hingegen nicht in der Lage oder nicht gewillt sein, Zeit und Arbeit darauf zu investieren, respektieren wir natürlich ihre Entscheidung.

Weitere Informationen finden Sie unter:

• Auf dem Weg zu einem reproduzierbaren F-Droid
• F-Droids Dokumentation zu reproduzierbaren Builds
• Reproducible Builds project
• HOWTO: diff & fix APKs for Reproducible Builds

Build-Prozess

Nachdem die Anwendungsmetadaten dem fdroiddata-GitLab-Repository hinzugefügt wurden, ist der nächste Schritt für den F-Droid-Build-Server den Quellcode der Anwendung und die dazugehörigen Komponenten abzurufen, die Anwendung herzustellen und sie im F-Droid-Hauptrepository zu veröffentlichen.

Dieser Build-Prozess geschieht täglich, und Anwendungen werden gesammelt verarbeitet. Die Schritte passieren im Hintergrund und weitestgehend automatisch; alles, was Antragsteller nun tun müssen, ist, auf den Abschluss des Vorgangs zu warten.

Eine Aufzeichnung eines erfolgreichen Build-Prozesses für eine Anwendung wird auf der Seite für diese spezielle App Seite auf der F-Droid-Website bereitgestellt (siehe z. B. das Build-Protokoll für den F-Droid-Client).

Bei Apps, die scheitern, steht das Protokoll während des Build-Zyklus auf der Seite F-Droid Monitor - Running oder, falls im vorhergehenden Zyklus, auf der Build-Seite zur Verfügung. Das ist praktisch bei der Diagnose von Problemen, wenn der Build unerwartet fehlschlägt.

Metadaten-Erneuerungsprozess

Bei Erreichen der für den Build festgelegten Zeit wird der F-Droid-Build-Server Änderungen aus dem fdroiddata GitLab-Repository beziehen und sie mit einem lokalen Repository zusammenführen. Danach werden für alle Anwendungen Aktualisierungsprüfungen durchgeführt. Wenn eine neue Version gefunden wird, werden deren Metadaten-Dateien aktualisiert und durch den Autor F-Droid checkupdates (@fdroidci) als Commit im Repository eingetragen.

Sind die Metadaten-Dateien einmal aktualisiert, wird der F-Droid-Server sie gegen eine Liste veröffentlichter APKs abgleichen, um eine Liste neuer Anwendungen und/oder Versionen aufzustellen, die hergestellt werden müssen. Er wird dann in den Prozess zur Vorbehandlung eintreten, gefolgt vom jeweiligen Build-Prozess pro Anwendung.

Vorbehandlung der Anwendung

Build der Anwendung

APK-Signiervorgang

Repository-Veröffentlichung

Womit zu rechnen ist

Wenn Ihre Anwendungsmetadaten genehmigt und im fdroiddata-Git-Repository auf GitLab angenommen wurden, erscheinen sie nicht unverzüglich im F-Droid-Hauptrepository.

Vorausgesetzt, dass Ihre Anwendung keine Herstellungsprobleme aufweist, werden zwischen fdroiddata-Merging und Erscheinen der Anwendung im Hauptrepository rund 24 bis 48 Stunden vergehen (1). Diese Zeitverzögerung ist dem APK-Signatur-Teil bei der Build-Verarbeitung geschuldet, der beim Zugriff auf den Schlüsselspeicher ein menschliches Eingreifen erfordert (2).

Dennoch wird Ihre Anwendung noch immer nicht in der Liste der neusten Apps von f-droid.org auftauchen, auch wenn die Leute jetzt bereits nach ihr suchen und sie herunterladen können: Sobald die Anwendung im F-Droid-Hauptrepository erscheint, dauert es einen weiteren Tag bis zum Erscheinen in der Liste der neusten Apps.

Externe Verknüpfungen

• Submission Queue für F-Droid-Anwendungen auf GitLab (für Neuanträge)
• Submission Queue für F-Droid-Anwendungen im Forum (zur Nachverfolgung alter Anträge)
• fdroiddata im GitLab-Repository
• Revisionsverlauf von fdroiddata