IzzyOnDroid

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

Werde Teil des F-Droid Teams: Aufgaben eines Reviewers

Du hast den Satz von der "permanenten Unterbesetzung" des F-Droid-Teams mindestens einmal pro Woche gelesen - und bist ihn genauso leid wie diejenigen, die ihn wiederholen, es bereits sind? Nun: willkommen im ... Team. Ja, Du. Wenn Du ein aktiver F-Droid-Nutzer bist, der die F/LOSS-Idee liebt und lebt, hast Du bereits das nötige Rüstzeug dafür. Zugegeben, es gibt komplizierte Dinge bei F-Droid, die ich selbst nicht verstehe - aber am anderen Ende der Skala gibt es auch einfache Aufgaben, die nicht viel "technisches Wissen" erfordern und leicht erlernt werden können.

Dieser Artikel soll Dir den Einstieg erleichtern und Dich mit den Aufgaben vertraut machen, die während der „App-Überprüfung“ bei RFP und bei fdroiddata Merge Requests durchgeführt werden. Er wird Dir hoffentlich auch als Referenz bei Deinen eigenen Reviews dienen. Aufzeichnungen von entsprechenden Workshops findest Du in meinem Peertube-Kanal.

Ich möchte Dich durch den "Lebenszyklus" einer Überprüfung führen, wie ich sie täglich durchführe – um Dir zu zeigen, welche Aufgaben damit verbunden sind. Als ich vor einigen Jahren anfing, war es ein kleiner Teil der einfachen Schritte, die ich abdecken konnte. Ich war kein Android-Entwickler (und bin es immer noch nicht), und ich war auch kein Paketierer (ähm, dieser Teil trifft immer noch größtenteils zu - obwohl ich inzwischen bei einigen neuen Apps und Updates selbst auf die Schaltfläche „Merge“ drücke). Ich wurde erfahrener, indem ich „einsprang“, versuchte zu helfen und diejenigen fragte, die schon da waren, wenn ich etwas nicht verstand. Heute bin ich einer der Maintainer und kann Dir eine grobe Anleitung geben, mir auf diesem Weg zu folgen.

Hier sind also die Schritte, die ich normalerweise durchführe, wenn eine neue App bei F-Droid gelistet werden soll. Dies beginnt in der Regel bei RFP als „Issue“ und geht dann weiter zu fdroiddata - aber manchmal beginnt es auch direkt als Merge Request (MR) in letzterem. Ich versuche, an beiden Stellen Licht ins Dunkel zu bringen. Das sind jetzt nur Aufzählungen, aber diesen sollte leicht zu folgen sein:

RFP/MR pre-check

• Ist der Quellcode verfügbar? F-Droid baut alles aus dem Quellcode - ohne den Quellcode können wir also nichts tun.
• Sind die Metadata vollständig? (URLs, AuthorName etc; vergleiche mit Upstream-ReadMe und anderen verfügbaren Quellen)
• oft übersehen: Spenden-Links sollten auf beiden Seiten verfügbar sein (d.h. sowohl in unseren Metadaten als auch im Upstream-Repository) oder gar nicht
• oft vergessen: Links zum Übersetzungssystem der App (Weblate, Transifex, Crowdin, …) - achte auf die Tags des Bots, wenn er welche entdeckt hat
• Sind Fastlane oder Triple-T im Repo der App verfügbar? Ist die Struktur korrekt? Gibt es Probleme damit (ist z. B. short_description.txt länger als 80 Zeichen, fehlt full_description.txt oder ist ein Krautsalat, hat die featureGraphic falsche Abmessungen)?
• Finden sich Fastlane/Triple-T am aktuellen Tag? (sonst erkennt der Buildprozess sie nicht)
• Enthält die Beschreibung genügend Details (kann ein Anwender ihr entnehmen, wofür die App gedacht ist)?
• Sind Releases „getagged“? Ensprechen die Tag-Namen entweder dem versionName oder dem versionCode? Stehen beide als „literale Werte“ in der build.gradle (Flutter Apps: pubspec.yaml)?
• Gibt es in der build.gradle verdächtige Einträge? Normalerweise findet der IssueBot diese – ab und an übersieht er aber auch einmal etwas. => Halte Ausschau nach Dingen wie Firebase, GMS, Crashlytics/andere-Analytics, andere non-FOSS Bibliotheken, Maven-Repos (diese findet IssueBot für gewöhnlich zuverlässig und bringt sie zur Anzeige)
• Die verwendete Lizenz muss FSF- oder OSI-kompatibel sein; wenn Du unsicher bist, kannst Du bei SPDX nachschauen. Beachte auch, dass es insbesondere beim Mischen von Bibliotheken zu Lizenzinkompatibilitäten kommen kann (z. B. kann eine Apache-2.0 lizensierte App keine Bibliotheken verwenden, die unter einer restriktiveren Lizenz wie GPL-2.0 stehen)
• Wenn Du Dich damit ein wenig auskennst: prüfe den Quellcode auf mögliche Probleme (oh, habe ich noch nicht erwähnt, dass der Quellcode verfügbar sein muss? Hey, wir sprechen hier von F/LOSS Apps, das heißt Free und Libre Open Source Software. Ohne diesen F/LOSS Code kann F-Droid nichts machen

RFP: IssueBot-Ergebnisse

• Prüfe die vom Bot gesetzten „Labels“, ob folgendes gefunden wurde: git-url, gradle, fastlane oder triple-t, ein „Paketname“ (wie de.beispiel.app), eine (oder mehrere) Programmiersprache(n). Halte Ausschau nach „roten Labels“ (diese weisen auf Probleme hin).
• Nennt der Bot „scanner-errors“ – wie die „üblichen Verdächtigen“ (GMS, Firebase, Crashlytics)? Diese sind Showstopper.
• Nicht von „insecure-gradlew“ (gelbes Label) irritieren lassen. Dies kann getrost ignoriert werden, da es sich nicht auf unsere Builds auswirkt (aber Upstream sollte es für ihre eigenen beheben).
• Wurde eine Lizenz gefunden? Das „no-license“ Label bedeutet lediglich, dass der Bot keine Lizenz finden konnte, sie könnte dennoch spezifiziert sein (schau im Repo der App nach).
• Idealereise hat der Bot bereits Fastlane oder Triple-T identifiziert. In diesem Fall prüfe, ob er zumindest Summary (Kurzbeschreibung) und Description (Beschreibung) korrekt ausgelesen hat – zu finden im Bot-Report unter Fastlane › by locale
• Sollten Ergebnisse von Exodus angezeigt werden, beziehen sich diese auf die im Play Store verfügbare Version der App (da die App noch gar nicht bei F-Droid gelistet ist). Sie treffen daher nicht zwangsläufig auf die von uns erstellte App zu (es könnte verschiedene „Build Flavors“ geben) – weisen jedoch hin, wonach z. B. in der build.gradle der App Ausschau gehalten werden sollte (siehe auch den folgenden Punkt).
• Wurden unzulässige Bibliotheken gemeldet? Prüfe ob in der build.gradle der App ein spezielles „foss Build-Flavor“ definiert wurde, welches selbige ausschließt. Ist dies nicht der Fall, schlage deren Implementierung (oder einen generellen Verzicht auf diese Bibliotheken) vor. Andernfalls können wir die App nicht aufnehmen.

Am Ende dieses Prozesses werden die Metadaten vorbereitet (es sei denn, es gibt bereits einen zugehörige MR, der sie enthält; in diesem Fall werden sie auf Korrektheit/Vollständigkeit geprüft). Du findest eine Beispiel-Metadaten-Datei weiter unten.

MR: IssueBot-Ergebnisse, weitere CI-Pipelines

Die Ergebnisse unserer CI finden sich direkt unter dem „Eröffnungs-Kommentar“, eingeleitet von einem Text wie „pipeline #128817296 passed for e5a357b5 on johndoe:master“. Ein „grünes Häkchen“ zeigt an, dass alles glatt gelaufen ist – ein „rotes x“ hingegen, dass es Probleme gab. Tippt man das Symbol auf der rechten Seite des Textes an erhält man ein Popup, in dem alle Pipelines gelistet sind. Jetzt diejenige antippen, an der man interessiert ist – und man gelangt zu den Logs. Nicht erschrecken, wenn diese zunächst wie Kauderwelsch aussehen – mit der Zeit gewöhnt man sich daran… irgendwie. Und lernt, die passenden Stellen zu finden.

• Hat sich lint beschwert? Dann hält man nach „rotem Text“ Ausschau. lint gibt für gewöhnlich auch Diffs (im „unified format“, bei Wikipedia ein wenig nach unten scrollen) mit den empfohlenen Änderungen aus (hier bitte keine Leerzeichen, füge hier eine Leerzeile hinzu, verschiebe diese Zeile nach da…)
• War der Build erfolgreich? Falls nicht: finden sich hilfreiche Hinweise, die dem Ersteller des MR mitgeteilt werden können?
• Hat der Bot „interessante Strings“ ausgespuckt? Hat er Fastlane/Triple-T korrekt übernommen?
• Auch das Repo der App nach möglichen „Blobs“ (*.jar, *.aar, *.bin etc) durchsuchen, die unsere Scanner evtl. übersehen haben.
• Wie auch schon am Ende unserer RFP-Analyse gilt es, die YAML Metadaten auf Vollständigkeit zu prüfen (weiter unten findet sich eine Beispiel Metadaten Datei). Interessant sind hier insbesondere auch die Links (Übersetzungen, Changelogs, Issue-Tracker etc).
• Besteht ein MR aus mehreren Commits, wird er „gesquashed“ (die Commits werden zusammengefasst). Hier sollte sichergestellt werden, dass eine vernünftige Commit-Message (etwa „new app XYZ“) gesetzt wurde.

MR: APK-Test

Nach einem erfolgreichen Build kann eine APK-Datei heruntergeladen werden. Der IssueBot gibt den direkten Download-Link am Ende seines Reports an. Bei der CI muss man das entsprechende Log öffnen (siehe oben) und dort den mit „Browse“ beschrifteten Button am rechten Rand betätigen; die APK-Datei findet sich dann im Verzeichnis unsigned.

• Lade die APK-Datei herunter und lass sie von VirusTotal prüfen (achte dabei auch auf „Interestring Strings“ im „Details“-Reiter und schaue, sofern vorhanden, auch im „Behavior“ Reiter vorbei). Die Berechtigungen klopfst Du besser am IssueBot-Report ab (VT ist diesbezüglich unzuverlässig) oder verwendest aapt d badging <DateiName>. Sofern vorhanden, jage die Datei auch gern durch weitere Scanner.
• Signiere die APK, installiere sie per adb install auf Dein Testgerät bzw. in einen Emulator und…
  • aktiviere Netzwerk-Protokollierung/Logging – z. B. via Netguard, Net Monitor, PCAPdroid (nutze ich mittlerweile am liebsten hierfür) oder AFWall+ (benötigt root)
  • teste ob die App startet
  • behalte gleich den Netzwerk-Traffic im Auge:
    • gleich nach dem Start, ohne jedwede Benutzer-Interaktion? Uh-oh…
    • während der Nutzung? In „unerwarteten Zusammenhängen“?
    • in „erwarteten Zusammenhängen“?
    • wohin? Kritisch? Manchmal sind es triviale Dinge, die der Entwickler einfach beheben kann (so können beispielsweise Fonts, die von Google & Co geladen werden, auch direkt in der App integriert oder interaktiv als Download angeboten werden, sodass der Anwender über die Verbindung entscheiden kann). Es kann sich auch um ein „notwendiges Übel“ handeln, welches dann mittels des NonFreeNet Anti-Features markiert werden muss. Es könnten aber auch Dinge sein, die wir lieber nicht „an Bord haben“ wollen.
• Tut die App in etwa das, was die Beschreibung verspricht? Wir machen zwar keinen vollständigen Funktionstest inklusive Bug-Tracking – aber die App sollte schon zumindest sauber starten, und nicht gleich beim Öffnen absürzen

Zusammenfassung

• Ein Großteil der Vorabprüfung erfordert keine großen technischen Kenntnisse und ist recht schnell erlernt – ein „Durchschnittsnutzer“ kann sie durchführen (wenn ein „Durchschnittsnutzer“ die Beschreibung einer einfachen Anwendung nicht verstehen kann, ist sie verbesserungsbedürftig, oder?)
• Die Interpretation von CI-Logs ist etwas gewöhnungsbedürftig, aber nicht allzu schwer. Wenn man etwas entdeckt und den Autor darauf hinweist, können einige Probleme gelöst werden und „fressen“ nicht die Zeit von erfahreneren Reviewern – die sich dann auf die „Reste“ konzentrieren können.
• Niemand ist gezwungen, alles abzudecken - wir sind ein TEAM, das zusammenarbeitet, also hilft jedes kleine bisschen Gemeinsam als Team können wir auch der Verantwortung gerecht werden, die wir auf uns genommen haben (die Nutzer erwarten von uns, dass wir die Apps gut überprüfen, damit die Dinge so sicher wie möglich sind).
• Scheue Dich nicht, einen „Senior“ um Einblicke/Hilfe zu bitten. Die Senioren werden gerne helfen – in der Hoffnung, dass ihnen dadurch langfristig eine gewisse Last von den Schultern genommen wird

Egal, ob Du ein Geek, ein Nerd oder einfach nur ein Enthusiast bist – Du bist herzlich eingeladen, bei uns mitzumachen und uns dabei zu helfen, die (Antwortzeiten bei) F-Droid zu verbessern. Danke, dass Du darüber nachdenkst!

---

Anhang

Hilfreiche Links

Ich habe in den letzten Jahren einige Details gesammelt. Einige dieser Links sind bereits oben integriert worden, aber ich möchte sie hier noch einmal zusammenfassen:

• Fastlane Cheat Sheet
• Triple-T Cheat Sheet
• Lizenzen und ihre Abkürzungen: SPDX
• Hilfreiche Details rund um F-Droid Themen, einschließlich
  • Tipps für trusted maven repos
  • Fastlane/Triple-T/Description: forbidden html tags
  • Diskussion der Guidelines for merging new apps
  • und mehr
• Metadata Reference einschließlich der Liste von AntiFeatures
• GitLab Permissions – was kannst Du alles tun, wenn Du einmal den Status reporter, developer oder gar maintainer erreicht hast?
• Video Tutorials / Training Sessions
  • Part 1: Request for Packaging
  • Part 2: Creating Metadata

Beispiel Metadaten-Datei

So würde eine vollständige Metadaten-Datei aussehen; wofür jedes Feld steht und was es enthalten sollte, wird auf der Seite Metadata in der F-Droid-Dokumentation erklärt. Nehmen wir an, wir haben eine App mit dem Namen „My Example App“, die den Paketnamen com.example.app trägt - unsere Datei heißt also com.example.app.yml:

AntiFeatures:
  - NonFreeNet
Categories:
  - Theming
License: Apache-2.0
AuthorName: John Doe
AuthorEmail: johndoe@example.com
AuthorWebSite: https://www.example.com/
WebSite: https://www.example.com/myApp
SourceCode: https://github.com/johndoe/my_example_app
IssueTracker: https://github.com/johndoe/my_example_app/issues
Translation: https://github.com/johndoe/my_example_app/wiki/Translation
Changelog: https://github.com/johndoe/my_example_app/releases
Donate: https://github.com/johndoe/my_example_app/wiki/Donate
Liberapay: johndoe
Bitcoin: <BitcoinAddressHere>

RepoType: git
Repo: https://github.com/johndoe/my_example_app.git

Builds:
  - versionName: 1.0.1
    versionCode: 2
    commit: v1.0.1
    subdir: app
    gradle:
      - yes

AutoUpdateMode: Version v%v
UpdateCheckMode: Tags
CurrentVersion: 1.0.1
CurrentVersionCode: 2

Beachte, dass nicht alle Felder obligatorisch sind - wenn es keine AntiFeatures gibt, würde der gesamte AntiFeature-Block einfach weggelassen werden. Obligatorisch sind jedoch: mindestens eine Kategorie, die Lizenz, SourceCode Link, RepoType & Repo. Zusammenfassung & Beschreibung sollen über Fastlane kommen, daher fehlen sie hier. Vom Builds-Block müssen VersionName und VersionCode mit CurrentVersion bzw. CurrentVersionCode am Ende übereinstimmen, commit sollte der Tag-Name sein. In diesem Beispiel ist der Tagname der Versionsname mit einem vorangestellten v, so dass AutoUpdateMode zu v%v wird (wobei %v für Versionsname steht).

Es gibt komplexere Definitionen (z.B. bei Flutter-Projekten) – aber diese können getrost „fortgeschrittenen Mitwirkenden“ überlassen werden. Denke daran, dass die Paketierer Deine vorbereiteten Metadaten gegenprüfen werden, also mach Dir keine Sorgen, wenn sie „nicht perfekt“ sind. Und obwohl der Builds-Block sowie die letzten 4 Zeilen ebenfalls erforderlich sind, können sie mit dem MR eingerichtet werden – da oftmals bereits neue Versionen erstellt wurden, bevor der MR abgeschlossen werden kann, müssen sie dann normalerweise sowieso aktualisiert werden.