FAQ - App-Entwickler

Wie erreiche ich die Aufnahme meiner App?

Überprüfen Sie die Aufnahmekriterien, um sicherzugehen, dass Ihre App zur Aufnahme in das offizielle F-Droid-Repo geeignet ist. Die einfachste Art, eine App aufnehmen zu lassen, ist die Erstellung eines Merge-Requests an fdroiddata, indem Sie diese Anweisungen befolgen. Es gibt auch eine Schnellstartanleitung dafür. Anfragen zur Paketherstellung können im Ticketsystem …Requests for Packaging eingestellt werden.

Sie können auch Ihr 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 Requests an das Metadaten-Repository zur Aktualisierung 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. Entscheiden Sie sich für Erstere, wenn Sie darauf bestehen, dass Derivate dieselbe Lizenz besitzen, und für Letztere, wenn Sie jede Art der Wiederverwendung gestatten.

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 Sie also, zum Beispiel Musik unter einer nicht kommerziellen (d. h. nicht freien) Creative Commons-Lizenz haben, 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). Erstellen Sie auch einen Vermerk zu Urheberrecht und Lizenzen, die zu externen Ressourcen oder Programmen gehören, und bei Verbindung mit einem freien Dienst, berücksichtigen Sie die Verwendung der Affero GPL. Siehe auch Aufnahmekriterien.

Wie werden Spenden gehandhabt?

Auf der Internetseite und im F-Droid-Client, bieten wir Links an, um für Ihr Projekt zu spenden. Idealerweise sollten Sie eine zugehörige Seite haben, die erklärt, wie und warum für Ihr Projekt gespendet werden soll, damit wir direkt zu ihr weiterleiten können. Behalten Sie 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 Ihrer Anwendung heraus zugänglich sein.

Wir bieten Felder in unseren Metadaten für Bitcoin-, Litecoin-, Flattr- und Liberapay-Spenden. Nehmen Sie auf jeden Fall Kontakt mit uns auf, wenn es Änderungen an irgendeiner davon gibt oder wenn Sie sie nicht mehr annehmen; wenn Sie neue Verfahren akzeptieren, können Sie uns ebenfalls kontaktieren.

Wenn Ihre App in unserem Repo ist und irgendeine der o. g. Informationen fehlt, setzen Sie 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 Ihr 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 finden Sie in der Android Developer Documentation. Vergewissern Sie sich, keine widersprüchlichen Informationen bereitzustellen (z. B. eine Diskrepanz zwischen AndroidManifest.xml und build.gradle).

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

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

Muss ich Aktualisierungen bei Euch ankündigen?

Wir werden neue Versionen Ihrer 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, vergessen Sie also nicht, jedes Mal die Tags ins Originalrepo einzutragen. Natürlich sollten Sie uns mitteilen, wenn Sie den Quellcode auf eine andere Website verschieben. Es gibt momentan einige Probleme bei der Bestimmung neuer Versionen, wenn AndroidManifest.xml verschoben wird, in dringenden Fällen sollten Sie 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, verwenden Sie 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?

When we detect a new release, it may take a few days to make it into the repository as the build process runs only once a day. Before the build has completed, the monitor page for your app will list it in F-Droid Monitor - Need updating. As long as the text under Versions stating “The current (recommended) version is xxx (version code yyy)” shows the version numbers corresponding to your latest release, we detected it and the APK should be available soon. Just give it some time.

Another reason could be that the app failed to build. You can watch the build process on F-Droid Monitor - Running and the previous cycle in Build.

Wie funktioniert das Signieren?

Von F-Droid hergestellte Pakete sind von F-Droid signiert, somit sind alle Apps im offiziellen F-Droid-Repo mit F-Droid-Schlüsseln signiert. F-Droid wird für jede App einen neuen Schlüssel erzeugen, der in ihr enthalten ist. All die verschiedenen APKs, die aus verschiedenen Versionen einer App hergestellt werden, werden mit demselben App-Schlüssel signiert. Beachten Sie aber: Wenn eine App auch als ein vom Entwickler signiertes APK verbreitet wird, wie im Google Play Store, dann wird das F-Droid-APK eine davon abweichende Signatur besitzen.

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 Sie signiert haben und selbst über andere Kanäle verbreiten, 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 auch reproduzierbare Builds, wir können also eine Version aus der Quelle herstellen und sie gegen Ihre offizielle Veröffentlichung abgleichen. Stimmen beide überein (abgesehen von der Signatur) können wir Ihr offizielles, mit Ihrer Signatur versehenes APK veröffentlichen. Das ist ein mühsamer Prozess, da wir die Build-Parameter und -Werkzeuge vereinheitlichen müssen, aber auf lange Sicht 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?

Nur von F-Droid hergestellte APKs werden in das offizielle F-Droid-Repo aufgenommen. Wir können versuchen, Ihr APK, wie oben erwähnt, zu reproduzieren, misslingt das (oder wollen Sie z. B. eine App mit proprietären Komponenten und API-Schlüsseln oder Ähnlichem veröffentlichen), können Sie jede APK in Ihr eigenes „F-Droid-Binärdateien-Repo“ einstellen, und die Menschen können Ihr Repo zu ihren F-Droid-Clients hinzufügen, um so an Ihre APKs zu gelangen.

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

Ja! Sie können auch Ihr eigenes F-Droid-Repository mit Apps und anderen Paketen einrichten und betreiben. Wenn Sie Ihre eigene App auch in anderen App-Stores, wie Google Play, veröffentlichen, empfehlen wir, dass Sie diese Versionen ebenfalls in Ihr eigenes Binärdatei-Repo aufnehmen, weil so, neben anderen Gründen, eine Quelle für APKs für reproduzierbare Builds zur Verfügung steht. Dieses Repository kann ein “einfaches Binärdatei-Repo” sein, das nicht das Build-System des fdroidserver nutzt, oder Sie könnten Ihren eigenen Spiegel des kompletten F-Droid.org-Repos hosten.

Kann ich sehen, wer meine App installiert?

Nein. Obwohl Informationen und Zahlen zu Installationen für Sie 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 Sie weiterleiten.

Kann ich Anwender meiner App rückverfolgen?

Sie können, aber wenn Sie irgendeine Form der Überwachung oder Nutzungsanalyse (selbst den Versand von Absturzberichten) in Ihre Anwendung integrieren, 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 dem Kennzeichen „Überwachung“ 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ücksichtigen Sie 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 finden sie aufdringlich. Wir kennzeichnen Anwendungen, die Werbung beinhalten, damit die Leute wissen, was sie erhalten werden. Sie haben die Wahl, ob ihnen diese Apps angezeigt werden 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 Ihre App damit zur Aufnahme ungeeignet.

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

Um FLOSS zu sein, muss es Ihre ganze App sein, einschließlich aller Abhängigkeiten. Wenn Sie unfreie/proprietäre Bibliotheken verwenden, können wir Ihre 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änken Sie sich bitte auf „bekannte Repositorys“, z. B. mavenCentral oder JCenter (sehen Sie sich hierzu die komplette Liste im Abschnitt „srclib“ in der Build-Metadaten-Referenz an). Beachten Sie, dass z. B. Bintray nicht nur JCenter sondern auch Anwender-Repos anbietet. Diese sind nicht Teil der Liste der vertrauenswürdigen Repositorys.

Wenn Sie Abhängigkeiten benötigen, die nicht aus diesen Repositorys bezogen werden können, verwenden Sie bitte keine binären jar-Dateien direkt, sondern ermöglichen Sie, sie aus der Quelle herzustellen, z. B. durch Bereitstellung eines „pre-build“ Skripts durch ihre Integration in Ihren eigentlichen Build-Prozess (Gradle Task) und Aufnahme der Bibliothekquelle in Ihr Projekt (fest oder über ein Submodul).

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

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

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

Sind Googles SDK und Programmbibliotheken keine Free & Open Source Software?

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 Builds auf Basis von „Ant“ und „Gradle“, während „Maven“ nur für einen kurzen Zeitabschnitt und für Abhängigkeiten genutzt wurde. Bei anderen Build-Systemen müssten Sie uns einige detaillierte Informationen darüber zur Verfügung stellen, wie mit ihnen umgegangen werden soll, damit wir die App korrekt konfigurieren oder möglicherweise sogar die Systeme in unsere Serverwerkzeuge integrieren können.

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

Wir können Cordova-Apps nicht direkt herstellen, aber die jüngste Version ermöglicht es Ihnen, den plattformspezifischen Code zu exportieren, sodass mit „Gradle“ ein eigenständiges Build erzeugt werden kann. Bis jetzt benötigen wir somit diesen Code, der im Quellrepository vorhanden und auf dem neusten Stand sein muss.

Wie kann ich meine App entfernen lassen?

In bewährter Manier vergewissert sich unser Packaging-Team normalerweise, dass eine Einwilligung der einspielenden Entwickler vorliegt, bevor Apps ins offizielle Repository von f-droid.org hinzugefügt werden. Sollten Sie, aus welchem Grund auch immer, von uns wollen, dass Ihre App aus dem offiziellen f-droid.org-Repository entfernt werden soll, beauftragen Sie bitte unser Packaging-Team das zu tun. Der wahrscheinlich schnellste Weg, dass Ihr Antrag umgesetzt wird, ist die Eröffnung eines Tickets in unserem Data-Ticketsystem. Sie können auch über unsere anderen Kommunikationswege Kontakt mit unserem Team aufnehmen.

Wie kann meine App entfernt werden?

Alle Änderungen an Ihrer Ap, die zu einer Verletzung unserer Aufnahmekriterien führen, bewirken die Entfernung oder Archivierung Ihrer App. Z. B. könnten Sie für zukünftige Versionen eine Lizenz verwenden, die jedem verbietet, sie zu verbreiten, oder Sie könnten in Ihren Quellcode proprietäre Binärdateien einfügen. Beides wird dafür sorgen, dass jene zukünftigen Versionen nicht in unserem Repository erscheinen, aber Sie müssten 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 Rücknahmewünschen 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 Sie keine Copyleft-Lizenz, wie die GPLv3, anwenden, können andere Menschen alles mit dem Quellcode anstellen, was sie möchten (obgleich sie verpflichtet werden können, das zu kennzeichnen). Unterliegt Ihre App einer GPLv3 und es wird von den Plagiatoren kein Quellcode veröffentlicht, enthalten deren Versionen offenkundig proprietäre Werbe-Bibliotheken oder wurden alle Zeichen Ihrer Urheberschaft einfach entfernt, dann verstoßen diese Kopien gegen das Gesetz, und Sie sollten Google auffordern, sie unverzüglich aus ihrem App-Store zu entfernen. Wenn Sie möchten, können Sie ihnen eine Klage wegen Verletzung des DMCA oder anderer Landesgesetze androhen. Wenn das alles nichts hilft, bevor Sie nun gleich proprietär werden, wiegen Sie den Schaden und die Verunsicherung für Anwender und Verfechter freier Apps gegen das Gerechtigkeitsgefühl auf, das Sie haben werden, wenn Sie mit ansehen, wie diese illegalen Klone ein paar Cents an Werbeeinnahmen verlieren werden, die sie erzielt hätten. Auf lange Sicht wollen wir die Spenden über F-Droid so vervollkommnen, dass Sie finanziell gefördert werden können, und schon jetzt unterstützen wir Bitcoin, Litecoin, OpenCollective, Flattr and Liberapay, sowie weitere Zahlungsmethoden, die Sie über eine Internetseite anbieten können.

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

git erlaubt haufenweise Flexibilität in den Arbeitsabläufen, so dass 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 Requests (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 Requests 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, liegt an dir, aber der endgültige Merge-Request 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/