Diese Seite ist in Arbeit und bedarf der Aufmerksamkeit von Experten zu diesem Thema, insbesondere zur Überprüfung der Fakten.

Dieser Leitfaden enthält detaillierte Informationen darüber, was in Metadatenfeldern gespeichert werden soll. Die meisten Artikel sind veraltet und werden im Laufe der Zeit mit dem Handbuch zusammengeführt.

Quellcode

• z. B. https://gitlab.com/fdroid/fdroidclient/tree/master

Der F-Droid Server veröffentlicht ein APK nicht direkt online, sondern der F-Droid Server benötigt eine build-fähige Quelle, um ein APK zu erstellen. Auf diese Weise garantiert der Server, dass das resultierende APK den Quellcode ohne versteckte Anti-Features korrekt darstellt.

Da F-Droid jede App aus deren Quellcode erstellt (über das Android SDK mit ant, gradle oder maven, manchmal mit Hilfe des Android NDK, Standard GNU/Linux Programmen und ein wenig Vorverarbeitung in der BASH-Shell), gibt es wahrscheinlich viele Möglichkeiten, dass F-Droid sie erstellen kann, wenn du eine Datei namens AndroidManifest.xml oder build.gradle in deinen Quellen findest.

Beachte, dass die meisten Projekte auf vorgefertigte Bibliotheken zurückgreifen. Der Quellcode dafür ist an anderer Stelle zu finden. Für ant werden diese im Ordner libs/ gefunden und externe in den project.properties Dateien erwähnt; für gradle werden diese in build.gradle erwähnt und normalerweise aus http://mvnrepository.com gezogen; für maven gibt es pom.xml-Dateien, welche die Abhängigkeiten beschreiben. Wenn nativer Code verwendet wird, werden diese oft in res/raw/ oder assets/ gefunden: es sollte etwas darüber in der README stehen. Das obige Beispiel hat eine JAR-Dateiabhängigkeit mit einer Textreferenz und verwendet keine externen Bibliotheken, sodass keine zusätzlichen Referenzen benötigt werden.

Lizenz

• Z. B. Insgesamt:

https://gitlab.com/fdroid/fdroidclient/blob/master/LICENSE (insgesamt ein Quellcode unter einer GPLv3+ Lizenz); - Z. B. Quellcode Header: https://gitlab.com/fdroid/fdroidclient/blob/master/app/src/main/java/org/fdroid/fdroid/AppDetails.java (Header einer Datei unter einer GPLv3+ Lizenz); - Z. B. Bibliotheken: https://gitlab.com/fdroid/fdroidclient/tree/master/libs (siehe die LICENSE Datei mit der Apache Lizenz, Version 2.0 Lizenz für diese Bibliothek); - Z. B. Artwork: https://f-droid.org/about (siehe die CC BY-SA 3.0 Lizenz für Kunstwerke)

Alle Apps im F-Droid-Repository müssen FOSS (Free and Open Source Software) sein. Wenn die Software nicht eindeutig eine Lizenz benennt, die als eine Freie-Software-Lizenz in der GNU Lizenzliste geführt wird, dann ist es wahrscheinlich keine.

Wenn im Quellcode der App weder README noch LICENSE enthalten sind, ist es für die F-Droid-Community sehr schwierig zu überprüfen, dass sowohl der gesamte Quellcode als auch Bibliotheken und Illustrationen unter einer geeigneten Free and Open Source Lizenz veröffentlicht werden. Es empfiehlt sich daher, zu prüfen, dass die App Kopfzeilen in jeder Quellcode-Datei, eine Textdatei im Bibliothekenordner und eine Erklärung im Quellcode oder auf der offiziellen Website der App hat, die eindeutig die Lizenz für alle zur App gehörenden Dinge beschreiben.

Hinweis: Zur Verwendung der GNU General Public License v2 ist eine kleine Präzisierung zu machen. Die Android Support Library und die meisten anderen Android-Bibliotheken sind unter der Apache Licence lizensiert. Aus formalrechtlichen Gründen kann diese nicht mit der GNU General Public License v2 kombiniert werden. Wenn eine App unter der GPLv2 veröffentlicht wird, wird das von Rechts wegen nur akzeptiert, wenn die Kopfzeilen des App-Quellcodes von «GPLv2 or later» nennen, dann können wir als Gesamtlizenz GPLv3 auswählen (da umgekehrt die GPLv3 mit der Android Support Library und den anderen Bibliotheken in vollem Umfang rechtlich kompatibel ist).

Zusammenfassungen

Die Zusammenfassung sollte die kürzest mögliche Erklärung sein, was die App macht oder dem Nutzer ermöglicht, z. B. anstelle von „E-Mail-Client“ besser „E-Mails empfangen und senden“.

Beschreibungen

Beschreibungen sollten in einem objektiven, neutralen Stil verfasst sein, wobei mindestens der erste Absatz der Beschreibung der Anwendung und ihrer Funktionen gewidmet sein sollte. Darauf können kurze Hilfestellungen zu bestimmten Funktionen/Problemen und Links zu externen Ressourcen für weitere Informationen folgen. Zusätzliche Informationen wie Links zu verwandten/kompatiblen/erforderlichen (aber nicht alternativen) Anwendungen sollten ebenfalls gegebenenfalls enthalten sein.

Einige weitere Hinweise:

• Sätze wie „eine bemerkenswerte Android-App“ sollten niemals auftauchen. Klar ist es für Android. Klar ist es eine App.
• In ähnlicher Weise, sage nicht „es ist Freie Software“ oder „es ist Open Source“, weil das offenkundig ist.
• Es sollten keine Dinge zur Kompatibilität (z. B. „für Android 2.3+“) darin enthalten sein, da dies automatisch bearbeitet wird. Schließe nur Kompatibilitätshinweise ein, wenn der Client sie nicht automatisch erkennt.
• Die Zusammenfassung wird immer mit der Beschreibung angezeigt, vermeide also, sie zu wiederholen.
• Wenn es zwischen dem F-Droid-Build verglichen mit einem Standard-Build irgendwelche Unterschiede gibt, sollte das beschrieben werden.
• Es sollte nie etwas aus der Sicht des Entwicklers geschrieben werden, z. B. „Ich habe diese Katzengalerie-App geschrieben, weil ich Katzen mag“.

Weitere Informationen, die einer Erwähnung wert sind:

• Benötigt die App Root-Rechte?
• Kann sie mit anderen Apps interagieren?
• Wie leicht lässt sie sich bedienen?

Spenden

Nimmt ein Projekt Spendenzahlungen entgegen, führt der Spenden-Link idealerweise auf eine spezielle Seite, die das Projekt zu diesem Zweck unterhält. Gibt es keine, ist es vertretbar, einfach auf die Projektseite weiterzuleiten, die irgendwo ein Spendensymbol oder etwas Ähnliches enthält, was aber kein gutes Nutzererleben schafft, wenn, zum Beispiel, jemand in der F-Droid-App „Spenden“ wählt und dann eine Seite nach den Einzelheiten dazu durchsuchen muss. Versuche die Entwickler davon zu überzeugen, möglichst eine dafür ausgewiesene Seite zu erstellen.

Anti-Features

Darüber hinaus kann sich bestimmte Software, selbst solche, die Free and Open Source ist, Praktiken bedienen, die als unerwünscht angesehen werden und die wir als „AntiFeatures“ einstufen. Wenn möglich, wird die F-Droid-Gemeinschaft diese Anwendungen weiter im Repository behalten, diese Merkmale aber kennzeichnen und katalogisieren, um Nutzer (im F-Droid-Client und im App-Browser auf der Website) vor allen, in der App vorhandenen, unerwünschten Merkmalen zu warnen. Auch wenn Software selbst mit unerwünschten Bestandteilen in F-Droid aufgenommen werden kann, ist es häufig so, dass Software mit diesen Merkmalen eigentlich nicht vollständig FOSS ist (zum Beispiel wird Werbung und Verfolgung von Nutzeraktivitäten oft über nicht freie Binär-Bibliotheken erzielt) und auf diese Weise die Aufnahme der App ins F-Droid-Repository beeinträchtigt wird.

Aktualisiere

• https://gitlab.com/fdroid/fdroidclient/graphs/master
• https://gitlab.com/fdroid/fdroidclient/network/master
• https://f-droid.org/news-and-reviews

Die App in das Repository zu bekommen ist nicht das Ende vom Lied: wir müssen die Versionen, Beschreibungen und URLs aktuell halten.

Das Wichtigste ist zu wissen, wann neue Versionen veröffentlicht werden. Wir haben drei automatische Methoden und eine manuelle: von Tags; durch Überprüfung der AndroidManifest.xml bei der letzten Revision im Repository und durch Überprüfung bei Google Play. Wenn dies nicht zutrifft, müssen wir uns die Version des Pakets ansehen, die von den Upstream-Entwicklern veröffentlicht wurde, indem wir entweder die Google-Play-Webseite laden oder ein APK herunterladen und dessen Version überprüfen. Repository-Tags sind die übliche Art, neue Versionen zu kennzeichnen (siehe unter „Releases“ in einem Beispiel auf github.com oder unter dem Verzeichnis „Tags“ bei SVN Repos). Wenn du keine Tags finden kannst, hilft es, ein „Issue” damit im IssueTracker anzulegen. Im Beispiel zeigen wir auf eine Changelog-Seite als Backup-Check; andere Möglichkeiten sind eine Google-Code-Downloadseite oder ein Google-Play-Link.