Aufnahmeverfahren






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

Application Inclusion Proposal

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.

Application Review Process

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 nach Copyright-Notizen in Lizenzdateien suchen, einschließlich README, um zu überprüfen, dass die vorgeschlagene Anwendung unter anerkannten Free Software-Lizenzen 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 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).
  • Sei 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.

Build Process

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 des Build-Prozesses für jede Anwendung wird im F-Droid-Wiki bereitgestellt, als Unterseite lastbuild der Informationsseite der Anwendung (z. B. hier die lastbuild-Seite für den F-Droid-Client). Dies ist praktisch beim Ermitteln von Problemen, wenn die Herstellung unerwartet fehlschlug.

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 Builder <admin@f-droid.org> 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

Wiki-Seiten-Erzeugung

Repository-Veröffentlichung

What to Expect

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.