F-Droid

FAQ - App-Entwickler

Wie erreiche ich die Aufnahme meiner App?

Überprüfe die Aufnahmekriterien, um sicherzugehen, dass deine App zur Aufnahme in das offizielle F-Droid-Repo geeignet ist. Die einfachste Art, eine App aufnehmen zu lassen, ist das Erstellen einer Merge-Anfrage an fdroiddata, indem du diese Anweisungen befolgst. Es gibt auch eine Schnellstartanleitung dafür. Anfragen zur Paketerstellung können im Requests for Packaging Ticketsystem eingestellt werden.

Du kannst auch dein eigenes Repo einrichten und Apps selbst, außerhalb des F-Droid.org-Repos herausgeben.

Wie ändere ich die Beschreibung und füge Meta-Informationen wie Bildschirmfotos hinzu?

Es gibt drei Orte, von denen wir Metadaten beziehen:

Während letzterer nicht bearbeitet werden kann, sind Merge-Anfragen an das Metadaten-Repository zum Aktualisieren der Beschreibungen stets willkommen. Bildschirmfotos können andererseits momentan nur aus dem vorgeschalteten Repository verwendet werden.

Wir hoffen, zukünftig mehr Material (z. B. Änderungsprotokolle) direkt aus dem Upstream einzubeziehen, um App-Entwicklern mehr Kontrolle über die Darstellung ihrer App in F-Droid zu gewähren. Allerdings werden wir immer ein minimales, maßgebliches Metadaten-Repo für uns behalten.

Wie lizenziere ich meine App?

Allgemein gibt es zwei Kategorien: Copyleft und freizügig, mit der GPLv3 und der Apache 2.0 als jeweils beliebtestem Vertreter. Entscheide dich für Erstere, wenn du darauf bestehst, dass Derivate dieselbe Lizenz besitzen, und für Letztere, wenn du jede Art der Wiederverwendung gestattest.

Die Gesamtlizenz muss mit der Lizenz der Komponenten kompatibel sein. Wir garantieren jedoch ein gewisses Maß an Flexibilität, was Medieninhalte und Ressourcen betrifft; wenn du also, zum Beispiel Musik unter einer nicht kommerziellen (d. h. nicht freien) Creative Commons-Lizenz hast, werden wir das akzeptieren. Wichtig ist dabei, die Copyright-Informationen für die Medieninhalte genauso wie den Quellcode in die Dateikopfdaten und/oder die README-Datei einzuschließen. Eine Kopie der Lizenzen im Wurzelverzeichnis des Repo ist hierfür praktisch (LICENSE oder COPYING Dateien). Erstelle auch einen Vermerk zu Urheberrecht und Lizenzen, die zu externen Ressourcen oder Programmen gehören, und bei Verbindung mit einem freien Dienst, berücksichtige die Verwendung der Affero GPL. Siehe auch Aufnahmekriterien.

Wie werden Spenden gehandhabt?

Auf der Website und im F-Droid-Client, bieten wir Links an, um für dein Projekt zu spenden. Idealerweise solltest du eine zugehörige Seite haben, die erklärt, wie und warum für dein Projekt gespendet werden soll, damit wir direkt zu ihr weiterleiten können. Behalte im Auge, dass die meisten Nutzer wahrscheinlich direkt aus der F-Droid-App auf einem Android-Gerät auf sie zugreifen werden. Diese Informationen sollten auch aus deiner Anwendung heraus zugänglich sein.

Wir bieten Felder in unseren Metadaten für Spenden über Bitcoin, Litecoin, Open Collective und Liberapay. Bitte kontaktiere uns, wenn sich daran etwas ändert oder du diese Zahlungsmethoden nicht mehr akzeptierst. Wenn du neue Zahlungsmethoden akzeptierst, kannst du uns dies ebenfalls mitteilen.

Wenn deine App in unserem Repo ist und irgendeine der o. g. Informationen fehlt, setze uns bitte darüber in Kenntnis.

Wird meine App aus der Quelle hergestellt werden?

Ja. Mit Ausnahme sehr weniger (technisch oder historisch begründeter) Fälle, erstellen wir alle Anwendungen direkt nach dem Quellcode. Das gewährleistet, dass der Quellcode für die von den Leuten installierte Version zur Verfügung steht. Obwohl wir davon abraten, dass dein Quellcode unvollständig, nicht öffentlich oder veraltet ist, kommt dies leider häufig vor.

Wie sieht die Versionierung aus?

Android kennt zwei Versionsinformationen, den VersionsNamen (eine auf den Anwender ausgerichtete Zeichenkette) und den VersionsCode (eine Ganzzahl, die zum Vergleich herangezogen wird, um zu ermitteln, was IST eigentlich eine Aktualisierung). Weitere Informationen dazu findest du in der Android Developer Documentation. Vergewissere dich, keine widersprüchlichen Informationen bereitzustellen (z. B. eine Diskrepanz zwischen AndroidManifest.xml und build.gradle).

Wir versuchen, nur das herzustellen, was du als zur Veröffentlichung bestimmte Versionen betrachtest. Diese sollten zu den Versionen, die du selbst herstellst und die aus demselben Code hergestellt werden, passende Versionsnamen und, noch wichtiger, passende Versionscodes besitzen. Die Entscheidung hierüber fällt deutlich leichter, wenn deine Quellcodeentwicklung klar ist - zum Beispiel, wenn zu veröffentlichende Versionen durch Tags oder anderweitige Beschreibungen gekennzeichnet sind. Wenn du die Veröffentlichung kennzeichnest, stellen bitte sicher, dass das Schema dafür dasselbe bleibt, z. B. wenn du ein „v“ als Präfix verwendest, behalte das bei.

Wir versuchen, nicht aus einer zufälligen Repository-Kopfversion zu bauen.

Muss ich Aktualisierungen bei Euch ankündigen?

Wir werden neue Versionen deiner App ermitteln und unsere Metadaten entsprechend aktualisieren, was dann wiederum die Prüfung des Codes und das Hinzufügen neuer Builds in unser System auslösen wird. Tags sind eine große Hilfe, um neue Versionen hinzuzufügen, vergiss also nicht, jedes Mal die Tags ins Originalrepo einzutragen. Natürlich solltest du uns mitteilen, wenn du den Quellcode auf eine andere Website verschiebst. Es gibt momentan einige Probleme bei der Bestimmung neuer Versionen, wenn AndroidManifest.xml verschoben wird, in dringenden Fällen solltest du uns darüber informieren, dass das geschehen ist.

Einige App-Entwickler senden Merge-Anträge mit allen relevanten Daten zum Build an uns ein, wenn sie Versionen veröffentlichen. Das ist nicht nötig, aber es kann die Angelegenheit beschleunigen. Aufgrund unserer Geschichte als kleines Community-Projekt sind wir in der Verarbeitung von Updates oftmals langsamer als wir es gerne wären, aber diese Situation verbessert sich kontinuierlich.

Unsere Aktualisierungsprüfungen sind stupid und kratzen lediglich Build-Dateien heraus: Bei uns läuft kein Build-Code, verwende also keine zeitgestützte Versionierung oder irgendeine Form der Berechnung einer Versionsinformation zum Herstellungszeitpunkt (z. B. durch Aufteilung in mehrere Unterversionen, die beim Build verkettet werden, oder sogar durch Einschluss komplexer Funktionsaufrufe, die das tun sollen).

Ich habe eine neue Version veröffentlicht. Warum ist sie nicht im Repository?

Wenn wir eine neue Version erkennen, kann es ein paar Tage dauern, bis sie im Repository erscheint, da der Build-Prozess mehrere Schritte beinhaltet und nur einmal am Tag läuft. Vor Abschluss des Build wird sie auf der Monitor-Seite deiner App in F-Droid Monitor - Need updating gelistet. Sobald der Text unter Versionen mit der Aussage “Die aktuelle (empfohlene) Version ist xxx (Versionscode yyy)” die Versionsnummer anzeigt, die deiner neusten Version entspricht, wurde sie erfasst und die APK sollte in Kürze abrufbar sein. Habe einfach etwas Geduld.

Ein anderer Grund könnte sein, dass die Herstellung der App fehlschlug. Du kannst den Build-Prozess im F-Droid Monitor - Running und den letzten Zyklus unter Build beobachten.

Wie funktioniert das Signieren?

Pakete, die nicht für reproduzierbare Builds eingerichtet sind, werden mit F-Droid-Schlüsseln signiert. F-Droid generiert für jede enthaltene App einen neuen Schlüssel. Alle verschiedenen APKs, die aus unterschiedlichen Versionen einer App erstellt wurden, werden mit demselben App-Schlüssel signiert. Beachte jedoch: Wenn eine App auch in einer vom Entwickler signierten APK verteilt wird, wie beispielsweise im Google Play Store, dann hat die F-Droid-APK eine davon abweichende Signatur.

Das Android-OS fordert, dass eine App, die an Ort und Stelle aktualisiert werden soll, dieselbe Signatur trägt wie die momentan installierte Version. Dies schützt vor unbeabsichtigter Installation nicht vertrauenswürdiger oder unerwünschter Versionen und bewahrt auch die App-Daten, auf die nur diese Anwendung (oder eine Anwendung, die Root-Rechte besitzt) Zugriff hat.

Dieser Umstand führt zu kleineren Unannehmlichkeiten für die Anwender, die von einer durch die eine Partei signierten Version zu einer durch eine andere Partei signierten Version wechseln wollen. Wenn z. B. Nutzer eine Anwendung verwenden, die über F-Droid installiert wurde und später zu einer Version wechseln möchten, die du signiert hast und selbst über andere Kanäle verbreitest, müssen sie einen zusätzlichen Schritt unternehmen, nämlich die App deinstallieren und neu installieren. Für sich genommen eigentlich nicht ausreichend, um es als kleinere Unannehmlichkeit zu werten - allerdings ist die Folge der Deinstallation die gleichzeitige Löschung der App-Daten (was wiederum aus Sicherheitsgründen geschieht). Sehr wahrscheinlich wird sich der Anwender wünschen, diese vorher zu exportieren und sie hinterher wieder zu importieren.

Wir unterstützen und ermutigen euch außerdem, eure Apps so einzurichten, dass sie für reproduzierbare Builds bereit sind, damit wir eine Version aus dem Quellcode erstellen und mit eurer offiziellen Version abgleichen können. Wenn diese übereinstimmen (abgesehen von der Signatur), können wir eure offizielle APK mit eurer Signatur veröffentlichen. Dies ist ein mühsamer Prozess, da wir die Build-Parameter und -Tools standardisieren müssen, aber langfristig sollte es sich lohnen. Wir versuchen auch, unsere eigenen Builds zu verifizieren und stoßen dabei auf eine Menge Binärdateiunterschiede, siehe unsere Verifikationsserver-Ergebnisse. Doch mit der Zeit wird sich das bessern.

Können mit meinem Schlüssel signierte APKs aufgenommen werden?

Ja, für reproduzierbare Builds nimmt F-Droid deine signierten APKs in das offizielle F-Droid-Repo auf, nachdem sie als solche verifiziert wurden. Wenn dies fehlschlägt (z. B. wenn deine App nicht reproduzierbar erstellt werden kann oder du eine App mit proprietären Komponenten oder API-Schlüsseln usw. verteilen möchtest), kannst du jede APK in dein eigenes „F-Droid-Binär-Repo” einfügen, und andere können dein Repo zu ihrem F-Droid-Client hinzufügen, um deine APKs zu erhalten.

Sind reproduzierbare Builds erforderlich?

Nein. Aber wir sehen sie als optimale Methode an und hoffen, dass du den Versuch in Erwägung ziehst, deine App reproduzierbar zu machen. Weitere Informationen dazu unter Einreichen bei F-Droid: Kurzanleitung.

Wie behandele ich „fsck-Fehler in gepacktem Objekt“ für meine App?

Um sicherzustellen, dass unser buildserver genau die gleichen Commits erhält, die du in git eingegeben hast, ist git fsck standardmäßig aktiviert, wenn neue Commits abgerufen werden. Die Aktivierung von git fsck stellt sicher, dass die Commits mit ihrer SHA1-Prüfsumme übereinstimmen. Manchmal haben git-Repos beschädigte, aber brauchbare Commits in sich, die nicht geändert werden können, da der gesamte Verlauf auf dem beschädigten Commit basiert. Für diese Fälle gibt es die Funktion der skipList in fdroiddata

Kann ich mein eigenes F-Droid-Paket-Repository betreiben?

Ja! Du kannst auch dein eigenes F-Droid-Repository mit Apps und anderen Paketen einrichten und betreiben. Wenn du deine eigene App auch über andere App-Stores wie Google Play veröffentlichst, empfehlen wir, diese Versionen ebenfalls in dein eigenes Binär-Repository aufzunehmen, unter anderem weil so eine Quelle für APKs für reproduzierbare Builds zur Verfügung steht. Dieses Repository kann ein „Einfaches Binärdateien-Repository” sein, das nicht das fdroidserver-Build-System verwendet, oder du kannst deinen eigenen Spiegelserver des kompletten F-Droid.org-Repositorys hosten.

Kann ich sehen, wer meine App installiert?

Nein. Obwohl Informationen und Zahlen zu Installationen für dich interessant und praktisch wären, würde dies auch die Überwachung und Beobachtung unserer Nutzer erfordern, etwas, was wir nicht tun werden. Wir verfügen über keinerlei Daten, welche Apps oder Versionen die Leute installieren, ob sie diese installiert lassen, welche weitere Software oder Betriebssystemversion in Betrieb ist oder überhaupt zu irgendetwas Anderem. Somit können wir keine dieser Informationen an dich weiterleiten.

Kann ich Anwender meiner App rückverfolgen?

Du kannst, aber wenn du irgendeine Form der Überwachung oder Nutzungsanalyse (selbst den Versand von Absturzberichten) in deine Anwendung integrierst, darf dies nur mit ausdrücklicher Zustimmung des Anwenders geschehen – d. h. er muss beim ersten Start der App danach gefragt werden, bevor irgendetwas irgendwohin versendet wird, oder es gibt eine Einstellung, deren Standardwert AUS ist. In allen anderen Fällen können wir die App zwar aufnehmen, sie wird aber mit „Tracking“ als unerwünschtes Merkmal versehen werden, was bedeutet, dass Anwender sie nur dann sehen werden, wenn sie die Anzeige solcher Apps ausgewählt haben.

Berücksichtige darüberhinaus, dass Analysebibliotheken von Drittanbietern, die in Form proprietärer Software vorliegen (zum Beispiel Google Analytics oder Flurry) hier inakzeptabel sind.

Kann ich Werbeanzeigen einbinden?

Ja, aber:

  1. Viele Nutzer mögen keine Werbung und empfinden sie als aufdringlich. Wir kennzeichnen Anwendungen, die Werbung enthalten, damit die Nutzer wissen, was sie bekommen. Sie können wählen, ob ihnen diese Apps angezeigt werden sollen oder nicht.
  2. Die Einbindung von Werbung in eine App erfolgt häufig durch Einschluss proprietärer Software in Form einer Binärdatei (jar-Datei). Offenkundig wäre deine App damit zur Aufnahme ungeeignet.

Welche Bibliotheken und Abhängigkeiten sollten am besten verwendet werden?

Um FLOSS zu sein, muss es deine ganze App sein, einschließlich aller Abhängigkeiten. Wenn du nicht-quelloffene/proprietäre Bibliotheken verwendest, können wir deine App nicht erstellen, und somit kann sie nicht in das Hauptrepository aufgenommen werden (siehe „Kann ich mein eigenes App-Repo betreiben?“ für diesen Fall). Damit sind leider alle Bibliotheken, die Teil des „Google Repository“ aus der SDK-Verwaltung sind, ausgeschlossen (z. B. Play-Services, Fabric, Firebase) – nur das „Android Support Repository“ ist zulässig.

Bei externen Ressourcen beschränke dich bitte auf „bekannte Repositorys“, z. B. Maven Central oder OSS Sonatype (sieh dir hierzu die komplette Liste im Abschnitt „srclib“ in der Build-Metadatenreferenz an). Beachte, dass diese Repos manchmal auch Anwender-Repos anbieten. Diese sind nicht Teil der Liste der vertrauenswürdigen Repositorys.

Wenn du Abhängigkeiten benötigst, die nicht aus diesen Repositorys bezogen werden können, verwende bitte keine binären JAR-Dateien direkt, sondern biete eine einfache Möglichkeit, diese aus dem Quellcode zu erstellen: z. B. durch Bereitstellung eines „pre-build“-Skripts, durch Einbindung in deinen eigentlichen Build-Prozess (Gradle-Task) und durch Einbindung der Bibliotheksquelle in dein Projekt (fest oder per Submodul).

Ersatz für die bekannten „üblichen Verdächtigen“:

Berücksichtige, dass alles im Folgenden genannte nur subjektive, auf Beliebtheit beruhende Vorschläge sind; es mag weitere FOSS-Projekte geben, die deinen Bedürfnissen besser entsprechen.

  • Crittercism, BugSense — ACRA, Bugmenot, Sentry
  • Google Analytics — Piwik
  • Google Maps — OpenStreetMap, z. B. über Mapsforge, Osmdroid oder MapLibre

Sind Googles SDK und Programmbibliotheken keine Free/Libre Open Source Software (FLOSS)?

Obwohl vieles in Android freie und quelloffene Software ist, gilt das für vieles andere überhaupt nicht. Die Android-SDK-Binärdateien werden von Google unter einer proprietären Lizenz zur Verfügung gestellt, aber fast der gesamte Quellcode für das Android-SDK ist unter der Apache-Lizenz abrufbar. APIs von Google, die zur Herstellung von Apps verwendet werden, die Google-Dienste wie Maps, GCM usw. nutzen, sind dahingehend frei erhältlich, dass die Programmbibliotheken auf dem Gerät bereits vorinstalliert sind. Fast alle Google-Bibliotheken, wie Play Services, Google Admob und GCM, sind aber proprietär und können nicht in das F-Droid-Hauptrepository aufgenommen werden.

Welches Build-System sollte verwendet werden?

Wir bieten gute Unterstützung für „ant“- und „gradle“-basierte Builds, während „maven“ nur für kurze Zeit und für Abhängigkeiten verwendet wurde. Für andere Build-Systeme musst du uns möglicherweise detaillierte Informationen zur Handhabung bereitstellen, damit wir die App korrekt einrichten oder möglicherweise sogar in unsere Server-Tools integrieren können.

Besonderer Hinweis für Cordova/Phonegap/HTML-Apps:

Wir können Cordova-Apps nicht direkt erstellen, aber mit der aktuellen Version kannst du den plattformspezifischen Code exportieren, der mit „gradle” eigenständig erstellt werden kann. Daher benötigen wir derzeit diesen Code, der im Quellrepository vorhanden und auf dem neuesten Stand sein muss.

Wie kann ich meine App entfernen lassen?

Als bewährte Vorgehensweise stellt unser Packaging-Team normalerweise sicher, dass wir die Zustimmung der Upstream-Entwickler haben, bevor wir Apps zum offiziellen f-droid.org-Repository hinzufügen. Solltest du aus irgendeinem Grund wünschen, dass wir deine App aus dem offiziellen f-droid.org-Repository entfernen sollen, bitte unser Packaging-Team, dies zu tun. Der wahrscheinlich schnellste Weg, um deine Anfrage zu bearbeiten, ist das Eröffnen eines Tickets in unserem Data-Ticketsystem. Du kannst dich auch über unsere anderen Kommunikationswege mit unserem Team in Verbindung setzen.

Wie kann meine App entfernt werden?

Alle Änderungen an deiner Ap, die zu einer Verletzung unserer Aufnahmekriterien führen, bewirken das Entfernen oder Archivieren deiner App. Z. B. kannst du für zukünftige Versionen eine Lizenz verwenden, die jedem verbietet, sie zu verteilen, oder du kannst in deinem Quellcode proprietäre Binärdateien einfügen. Beides wird dafür sorgen, dass jene zukünftigen Versionen nicht in unserem Repository erscheinen, aber du musst noch ein ganzes Stück weitergehen (z. B. Sicherheitsmängel in vorherigen Versionen, in Kombination mit unveröffentlichtem Quellcode und einem unkooperativen Verhalten), damit wir tatsächlich die ganze Anwendung entfernen.

In einigen seltenen Fällen müssen wir uns auch nach Takedown-Anfragen gemäß unserer weitergehenden Regeln richten. Im Allgemeinen empfehlen wir, Marken- und Urheberrechtsverletzungen zu vermeiden.

Ich finde in den großen App-Stores Apps, die augenscheinlich Kopien sind. Wäre es nicht besser, meine App wäre proprietär?

Zunächst einmal hängt es von der Lizenz ab: Solange du keine Copyleft-Lizenz wie die GPLv3 anwendest, können andere Leute mit dem Quellcode machen, was sie wollen (obgleich sie verpflichtet werden können, das zu kennzeichnen). Unterliegt deine App GPLv3 und es wird von den Plagiatoren kein Quellcode veröffentlicht, enthalten deren Versionen offenkundig proprietäre Werbe-Bibliotheken oder es wurden alle Zeichen deiner Urheberschaft einfach entfernt, dann verstoßen diese Kopien gegen das Gesetz, und du solltest Google auffordern, sie unverzüglich aus ihrem App-Store zu entfernen. Wenn du möchtest, kannstdu ihnen eine Klage wegen Verletzung des DMCA oder anderer Landesgesetze androhen. Wenn das alles nichts hilft, bevor du nun gleich proprietär wirst, wiege den Schaden und die Verunsicherung für Anwender und Verfechter Freier Apps gegen das Gerechtigkeitsgefühl auf, das du haben wirst, wenn du mit ansiehst, wie diese illegalen Klone ein paar Cents an Werbeeinnahmen verlieren werden, die sie erzielt hätten. Längerfristig wollen wir die Spendenmöglichkeiten über F-Droid verbessern, damit du finanziell unterstützt werden kannst. Wir unterstützen bereits Bitcoin, Litecoin, Open Collective und Liberapay sowie jede andere Zahlungsmethode, die du über eine Website vorschlagen kannst.

Wie ist der Client-Git-Workflow von F-Droid aufgebaut?

git erlaubt haufenweise Flexibilität in den Arbeitsabläufen, sodass es wichtig ist, den Arbeitsablauf dieser Gemeinschaft klar zu definieren, damit die Leute wissen, was sie zu erwarten haben. Der git Workflow, den die F-Droid Client App verwendet, ist relativ einfach und basiert auf dem von github.com, gitlab.com und anderen etablierten Workflow. Hier ist eine Aufschlüsselung dessen, was das bedeutet:

  • Alle Entwicklungsarbeiten finden im master-Zweig statt.
  • Code wird über Merge-Anfragen (MRs) zur Aufnahme eingereicht
  • Releases erfolgen in einem kurzlebigen, stabilen Release-Zweig pro Hauptversion (z. B. stable-0.95, stable-0.96, stable-0.97, usw.)
  • die Arbeiten, die in die stabilen Release-Zweige einfließen, müssen zielorientiert und so gering wie möglich sein, um den Versionszyklus so kurz wie möglich zu halten
  • der Master-Zweig darf niemals mit einem stabilen Release-Zweig zusammengeführt werden
  • stabile Release-Zweige dürfen niemals mit dem master-Zweig zusammengeführt werden
  • Merge-Anfragen für einen stabilen Release-Zweig können Commits von master enthalten
  • nicht alle Commits, die ein stabiler Release-Zweig enthält, sind zwingend auch im master
  • was du in deinen Git-Forks machst, bleibt dir überlassen, aber die endgültige Merge-Anfrage sollte keine Merge-Commits enthalten

Hier ist die Diskussion von dem Treffen, wo wir das festgeklopft haben: https://web.archive.org/web/20171220230923/https://botbot.me/freenode/fdroid-dev/2015-08-04/?msg=46407489&page=1

Dieser Artikel enthält eine gute Besprechung von „feature branches“ gegenüber „release branches“ und kurz- bzw. langlebigen Branches: http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows/

Apps finden

Spenden

Deine Spenden machen F-Droid möglich!

Connect

mastodon
@fdroidorg@floss.social

Neuigkeiten