IzzyOnDroid

• Intro
• App-Listen
• Artikel
• Bücher
• Downloads
• App-Repo
• Impressum

F-Droid für fortgeschrittene Anwender und für Entwickler

Im vorigen Artikel haben wir F-Droid als einen App-Store vorgestellt, der die Privatsphäre seiner Nutzer schützt – sowohl was den Store und seine Android-App, als auch was die im Store verfügbaren Apps betrifft. Dieser Artikel nun wendet sich an fortgeschrittene Nutzer, die mehr aus F-Droid herausholen – und an Entwickler, die ihre Apps bei F-Droid bereitstellen wollen.

In dieser Artikel-Serie:

• Teil 1: Die Privatsphäre-freundliche Alternative zum Google Play Store
• Teil 2: für fortgeschrittene Anwender und für Entwickler
• Teil 3: Eigenes Repository mit Repomaker erstellen und verwalten
• Teil 4 (extern, von Nico Alt): Vertrauen ist gut, Kontrolle ist besser: Reproduzierbarkeit bei F-Droid

weitere F-Droid Artikel bei IzzyOnDroid:

• IzzyOnDroid’s F-Droid Repo mit zusätzlicher Funktionalität (1/2018)
• Inoffizielle (und unvollständige) Liste mit F-Droid Repositories (regelmäßig aktualisiert)

ebenfalls empfehlenswerte Lektüre zum Thema:

• Wie du eine App bei F-Droid veröffentlichst (4/2021)

Für fortgeschrittene Anwender: Die F-Droid PrivilegedExtension

Im vorigen Artikel wurde ausgeführt, dass die F-Droid App, sofern sie nicht vorinstalliert war, keine Updates selbst installieren darf – dies ist nämlich aus Sicherheitsgründen System-Apps vorbehalten. Daher fragt auch bei jeder manuellen Installation einer neuen App aus F-Droid immer der im Android-System integrierte Package Manager nach, ob die jeweilige App wirklich installiert werden soll – eine Rückfrage, die man etwa bei Verwendung der Google Play Store App nicht erhält, denn diese ist eine System-App.

Um nun F-Droid auch zu einer System-App zu machen, gibt es die F-Droid PrivilegedExtension. Diese ist natürlich bei Geräten, welche bereits mit vorinstalliertem F-Droid ausgeliefert werden, bereits integriert – und auch das Custom ROM LineageOS for microG hat sie bereits mit an Bord. Um sie nachträglich zu installieren, bedarf es einiger Voraussetzungen:

• der Bootloader muss entsperrt sein
• eine Custom Recovery (wie etwa TWRP) muss entweder installiert oder per fastboot boot geladen sein

Sodann ist die Installation nicht sonderlich schwer:

• das ZIP des F-Droid PrivilegedOTA Installers herunterladen,
• auf das Gerät kopieren
• und mittels der Custom Recovery „flashen“ (Menüpunkt „install from zip“)

Wurde die Installation erfolgreich abgeschlossen, startet man das Gerät neu („reboot system“) – und kann ab sofort die Vorzüge einer vollständig ins System integrierten F-Droid App genießen:

• die Installation von Apps wird sofort ausgeführt (ohne Rückfragen vom Package Manager)
• automatische Updates sind möglich: sofern in den Optionen der F-Droid App entsprechend eingestellt, können neue Versionen bereits installierter Apps automatisch installiert werden, sobald sie verfügbar sind – ohne dass man selbst aktiv werden muss.

Für fortgeschrittene Anwender, Entwickler, Firmen, Vereine und andere: Repositories von Drittanbietern

Im vorigen Artikel haben wir sie bei der Beschreibung der Optionen in der F-Droid App bereits angesprochen: Paketquellen. Standardgemäß ist hier nur das offizielle F-Droid Repository aktiviert, und drei weitere Paketquellen sind bereits vorkonfiguriert:

• F-Droid Archive: ältere App-Versionen
• Guardian: Das Repository des Guardian Projektes
• Guardian Archive: ältere App-Versionen des Guardian Projektes

Alle hier vorkonfigurierten Paketquellen stellen ausschließlich Apps zur Verfügung, welche den strengen Kriterien des F-Droid Projektes entsprechen (siehe unten). Jedoch bietet dieses Menü auch die Möglichkeit, weitere Repositories einzubinden. Diese werden etwa von Entwicklern für ihre Tester erstellt. Oder aber von anderen F-Droid Anwendern für Apps, die nicht in das offizielle Repository aufgenommen werden können, weil sie nicht alle Kriterien erfüllen.

Diese Paketquellen wurden bewusst nicht vorkonfiguriert. Wer eine „Drittquelle“ einbindet, muss sich der damit verbundenen Risiken bewusst sein: Die angelegten Aufnahmekriterien sind hier i. d. R. weit weniger streng. Das heißt nun nicht unbedingt, dass die Apps alle unsicher sind – aber dass sie dies durchaus in Einzelfällen sein könnten. Listen verfügbarer Drittanbieter-Paketquellen finden sich u. a.

• im F-Droid Forum – mit Kommentaren und Diskussion. Dieser Artikel kann von jedem Forums-Mitglied bearbeitet werden.
• im F-Droid Wiki – hier handelt es sich um eine vom F-Droid Team kuratierte Liste.
• bei IzzyOnDroid – vom Autor dieses Artikels zusammengetragene Liste von Paketquellen

Keine dieser Listen erhebt Anspruch auf Vollständigkeit. Schließlich muss ein F-Droid Repository nirgendwo „gemeldet“ werden – jeder kann ein solches betreiben (mehr dazu später).

Für Entwickler: Prozess der Integration einer App in F-Droid

Hat jemand eine App erstellt, und möchte diese nun bei F-Droid unterbringen? Sofern die Aufnahmekriterien (s. u.) erfüllt sind, sollte dem nichts im Wege stehen.

Der erste Schritt ist das Erstellen eines Requests for Packaging – nachdem man sicher gestellt hat, dass dies nicht schon jemand getan hat oder die App gar bereits bei F-Droid gelistet ist. Dabei gilt es, ein Formular mit den für die Aufnahme nötigen Details zu befüllen. Keinesfalls also hier einfach die Vorlage entfernen und „irgend etwas formloses“ schreiben, sonst ist eine Aufnahme nicht möglich. Neben dem Ausfüllen möglichst aller Felder sollte auch darauf geachtet werden, eine aussagekräftige Beschreibung bereit zu stellen – so, dass es sich dem Anwender erschließt, warum er ausgerechnet diese App installieren sollte. Beschreibung und Screenshots können auch im Repository der App gepflegt und bereitgestellt werden; mehr dazu später. Außerdem müssen etwaige Spenden-Links (Liberapay, Bitcoin etc.) verifizierbar sein – indem sie sich auch im Repository der App oder auf der Website des Entwicklers wiederfinden. Dies schützt vor Missbrauch, könnte andernfalls doch jeder seine eigene Bitcoin-Adresse eintragen.

Nachdem der „Antrag“ gespeichert wurde, kommt binnen weniger Stunden der „F-Droid Bot“ vorbei und prüft das angegebene Quell-Repository. Das Ergebnis seiner Prüfung teilt er dann auch in einem Post mit – und gibt im Idealfall sein OK. Was bedeutet, dass er keinen „Show-Stopper“ gefunden hat. Häufig jedoch spürt er einiges auf: Bestandteile, die nicht den Aufnahmekriterien entsprechen – oder Sicherheitsprobleme in der Konfiguration (z. B. unsichere Gradlews, welche http URLs verwenden). Dann gilt es nachzuarbeiten. Das F-Droid Team steht dem Entwickler dabei hilfreich zur Seite, also bei Unklarheiten einfach fragen!

Ist diese Etappe erfolgreich absolviert, wird aus den gemachten Angaben eine „Metadaten Datei“ erstellt und in das Repository aufgenommen. Diesen Schritt übernimmt i. d. R. ein Mitglied des F-Droid Teams – das dabei auch prüft, ob sich die App überhaupt erstellen lässt; nur dann werden die Metadaten auch übernommen. Anschließend wird beim nächsten Build auch diese neue App erstellt.

Bevor sie nun aber für den Anwender sichtbar wird, muss sie noch signiert werden. Aus Sicherheitsgründen ist dies ein manueller Schritt, der zudem noch „offline“ erfolgt – um dem Risiko zu entgehen, dass die „Signing Keys“ in die „freie Wildbahn“ gelangen könnten. Das dies Fatal wäre, leuchtet sicher jedem Entwickler ein.

Der Entwickler kann auch von der Möglichkeit reproduzierbarer Builds Gebrauch machen. Dies erfordert ein wenig Mehraufwand – hat aber u. a. den Vorteil, dass anschließend auch „cross-updates“ möglich sind: Im Erfolgsfall wird die erstellte APK-Datei nicht von F-Droid signiert, sondern mit der Signatur des Entwicklers übernommen. Somit gibt es auch keinen Fehler bei der Signaturprüfung, wenn die App ursprünglich aus dem Play Store installiert und später aus F-Droid aktualisiert wird.

Wie lange es vom Zeitpunkt der Erstellung des RFP bis zur öffentlichen Verfügbarkeit der App dauert, lässt sich schwer vorhersagen. Wenn alles gut geht, können dies wenige Tage sein – bei Problemen kann es sich aber durchaus auch über mehrere Monate erstrecken.

David Boddy beschreibt in seinem Blog, dass sich der ganze Prozess einfacher gestaltete als erwartet – und hat dabei sogar Schritte selbst ausgeführt, die normalerweise das F-Droid Team übernimmt.

Die wichtigsten F-Droid GitLab Repositories und wofür sie verwendet werden:

Repo	Verwendung
rfp	Request for Packaging: Beantragen, eine neue App in den Katalog aufzunehmen
fdroiddata	Verwaltung der App Metadaten
fdroidclient	Entwicklung und Fehlerbehandlung der Android App
privileged-extension	Entwicklung und Fehlerbehandlung der PrivilegedExtension
fdroidserver	Entwicklung und Fehlerbehandlung der Server-Applikation
repomaker	Entwicklung und Fehlerbehandlung der RepoMaker Anwendung
fdroid-website	rund um die F-Droid Web-Präsenz

 

Für Entwickler: Aufnahmekriterien für Apps

Damit eine App in das Repository von F-Droid aufgenommen werden kann, muss sie bestimmte Kriterien erfüllen. Es genügt nicht, wie etwa beim Playstore oder bei Aptoide einfach die APK Datei zur Verfügung zu stellen: F-Droid akzeptiert ausschließlich Open Source Apps. Das heißt: alle Bestandteile der App müssen im Quelltext öffentlich einsehbar sein. Insbesondere schließt dies ein:

• proprietäre Bestandteile wie Crashlytics, Firebase etc. sind ein K.O.-Kriterium. Ein Ausweg ist hier, ein separates „Build Flavor“ bereitzustellen, welches diese Bibliotheken ausschließt.
• „Blobs“ (wörtlich: „Binary Large OBjects“, wobei die Größe hier keine Rolle spielt)¹ wie z. B. JARs werden nicht akzeptiert. Ein möglicher Ausweg hierfür ist das Einbinden der zugehörigen Quellen als Git Submodul, sodass F-Droid auch hier selbst aus den Quellen kompilieren kann.
• „Maven Repositories“: Hier wird auch nur eine Auswahl vertrauenswürdiger Repositories unterstützt.
• es dürfen keine unfreien Build-Werkzeuge (Toolchains, SDKs) zur Erstellung der App nötig sein.
• Die App muss eine eindeutige Android-Paket-ID verwenden. Das gilt auch bei Forks.
• Markenzeichen dürfen nicht verletzt werden und sämtliche juristischen Vorgaben sind einzuhalten. Darauf ist auch bei der Einbindung von Medien (Bildmaterial, Icons etc.) zu achten.
• F-Droid meldet sich nicht für irgendwelche API-Schlüssel an. Ein solcher darf daher nicht für die Erstellung der App notwendig sein. Wird er später bei der Nutzung der App nötig, führt dies ggf. zu einem AntiFeature.

Für Entwickler: Beschreibung und Screenshots in eigener Hand

„Alles über Beschreibungen, Grafiken und Screenshots“ heißt ein Dokument, welches F-Droid in seinem Fundus an Dokumentationen bereit stellt. Es beschreibt die verschiedenen Möglichkeiten, die es für die Integration dieser „Metadaten“ gibt:

• per Default ist die Beschreibung Bestandteil der Metadaten-Datei, und es sind keine Screenshots oder anderen Bilder zur App verfügbar. Pro: einfach einzustellen. Con: für jede Änderung der Beschreibung muss erst ein Issue in fdroiddata erstellt werden; ohne Screenshots kann sich der Anwender nur ein sehr eingeschränktes Bild von der App machen.
• Beschreibung und Screenshots sowie FeatureGrafik können in fdroiddata verwaltet werden. Pro: Screenshots helfen dem Anwender, die App-Beschreibung besser zu verstehen. Con: jede Änderung an Text und Bildern erfordert wiederum ein separates Issue (siehe voriger Punkt).
• Ebenso kann der Entwickler diese Daten im Quell-Repository der App selbst verwalten. Wer seine App im Google Play Store bereit stellt, hat wahrscheinlich auch bereits von den zugehörigen Werkzeugen gehört: Fastlane und Triple-T. Details finden sich im verlinkten Dokument. Pro: wie beim vorigen Punkt; zusätzlich kann der Entwickler Änderungen leicht selbst vornehmen, die dann bei Veröffentlichung der nächsten Version automatisch übernommen werden. Con: einmaliger Mehraufwand bei der Einrichtung der Strukturen im Repo der App.

Es ist auf jeden Fall eine gute Idee, zumindest Screenshots bereitzustellen – sei es im Repo der eigenen App oder in fdroiddata. Daher sei dies jedem Entwickler empfohlen. Die Strukturen erlauben unterschiedliche Screenshots je nach Display-Größe. Und auch Beschreibungen in verschiedenen Sprachen.

Wie kann man F-Droid das Leben leichter machen und eine Veröffentlichung beschleunigen?

• Releases „taggen“. Damit kann F-Droid automatisch neue Versionen erkennen und weiß auch, auf welchen Commit sie sich beziehen – und beschleunigt somit auch Updates.
• Gradle nutzen. Mit diesem Standard kann F-Droid am besten umgehen.
• Von vorn herein darauf achten, dass sich die App an die „Inclusion Criteria“ hält – und die App Beschreibung aussagekräftig ist. Das spart Ping-Pong beim „RFP“.
• Zusatz-Informationen, Hilfestellungen, eine FAQ: Beschreibungen werten die App auf. Hierzu bedarf es nicht zwangsweise einer eigenen Website; Github, GitLab, NotABug etc. bieten dafür Wiki-Funktionalität an.
• Screenshots und Übersetzungen per Fastlane/Triple-T im Repo der App pflegen. Eine ansprechende Präsentation in eigener Sprache spricht neue Nutzer besser an.