Build-Metadaten-Referenz

Von fdroid update verwendete Informationen, um das frei zugängliche Register zu kompilieren, stammen aus verschiedenen Quellen:

Diese Metadaten-Dateien sind einfache, leicht zu bearbeitende Textdateien, die immer nach dem „Paketnamen“ gefolgt vom Dateityp-Suffix benannt sind. Es stehen eine Vielzahl von Feldern zur Verfügung, um Informationen zur Beschreibung der Pakete und/oder Apps hinzuzufügen. Bei allen Feldern, wie AuthorName, die auf alle Versionen eines Pakets/einer App angewendet werden, wird CamelCase mit einem Großbuchstaben am Anfang verwendet. Alle anderen Felder verwenden camelCase mit einem Kleinbuchstaben am Anfang, einschließlich der per-build Felder, lokalisierter Felder, etc.

Als Metadaten-Dateien werden drei Dateitypen unterstützt:

  • .yml-Dateien im YAML-Format, das von f-droid.org verwendet wird
  • .txt-Dateien im veralteten, maßgeschneiderten, textbasierten Format von F-Droid
  • .json -Dateien im Format JSON

Beachten Sie, dass, obwohl die Metadaten-Dateien so gestaltet sind, dass sie für Menschen leicht les- und schreibbar sind, sie auch von verschiedenen Skripten verarbeitet und überschrieben werden. Sie können, wenn nötig, automatisch bereinigt werden. Die Struktur und Kommentare werden ordnungsgemäß erhalten bleiben, wenngleich die Reihenfolge der Felder standardisiert werden wird. (Für den Fall, dass die ursprüngliche Datei eine abweichende Reihenfolge besaß, werden Kommentare so betrachtet, als seien sie den ihnen folgenden Feldern zugeordnet). Tatsächlich können alle Pakete in einem Repository, ohne Änderung funktioneller Inhalte, vereinheitlicht werden, indem Sie Folgendes ausführen:

fdroid rewritemeta

Oder lediglich für eine bestimmte App:

fdroid rewritemeta org.adaway

Die folgenden Abschnitte beschreiben die in der Datei erkannten Felder.

Kategorien (Categories)

Eine beliebige Anzahl von Kategorien für die Anwendung, in denen sie eingestellt werden soll. Es gibt keine festgeschriebene Liste von Kategorien

  • sowohl der Client als auch die Webseite werden automatisch sämtliche, in allen Anwendungen enthaltene Kategorien anzeigen. Wenn Ihre Metadaten für das F-Droid-Hauptrepository bestimmt sind, sollten Sie allerdings eine der bestehenden Kategorien verwenden (Aussehen, Entwicklung, Geld, Grafik, Internet, Lesen, Multimedia, Navigation, Schreiben, Sicherheit, Spiele, Sport / Gesundheit, System, Telefon / SMS, Verbindung, Wissenschaft / Bildung, Zeit) oder die Einführung einer neuen anregen. Categories muss eine Liste von Einträgen sein, selbst wenn es nur einen gibt.

In der XML-Datei (index.xml) erfolgt die Umwandlung zu (<categories>).

Autorenname (AuthorName)

Der Name des Autors, ausgeschrieben, abgekürzt oder als Pseudonym. Wenn vorhanden, sollte er dem/den beim Upstream veröffentlichten Namen entsprechen, d. h. denen in der Copyright- oder Autoren-Datei. Kann weggelassen werden (oder unausgefüllt bleiben).

Achtung: Dies ist allen im App-Quellcode festgelegten AuthorName-Einträgen übergeordnet.

Umwandlung zu (<author>) in der XML-Datei (index.xml).

Autoren-E-Mail (AuthorEmail)

Die E-Mail-Adresse des Autors. Kann weggelassen werden (oder unausgefüllt bleiben).

Achtung: Dies ist allen im App-Quellcode festgelegten AuthorEmail-Einträgen übergeordnet.

Umwandlung zu (<email>) in der XML-Datei (index.xml).

Internetseite der Autoren (AuthorWebSite)

Die URL der Autorenwebseite. Kann weggelassen werden (oder unausgefüllt bleiben).

Achtung: Dies ist allen im App-Quellcode festgelegten AuthorWebSite-Einträgen übergeordnet.

Lizenz (License)

Die Gesamtlizenz für die Anwendung im Hinblick auf die ausführbare Datei, die der Nutzer installieren kann. Die Werte sollten den Kurzbezeichnungen aus der SPDX-Lizenzliste entsprechen. Es kann hier nur eine Lizenz aufgeführt werden. Wenn im Quellcode mehrere Lizenzen zur Anwendung kommen, dann sollte dieses Feld die am wenigsten restriktive Lizenz enthalten, unter der die ganze App verwendet werden kann. Werden mehrere Lizenzen kombiniert, bedeutet das normalerweise, dass sich die restriktivste durchsetzt.

Dieses Feld kann keine komplexen Lizenzstrukturen abbilden, wie Lizenzen, denen App-Teile unterliegen, oder Apps, die insgesamt unter mehr als einer Lizenz veröffentlicht wurden.

Umwandlung zu (<license>) in der XML-Datei (index.xml).

Automatischer Name (AutoName)

Der Name der Anwendung, wie er am besten aus dem Quelltext abgerufen werden kann. Dies erfolgt so, dass fdroid checkupdates einen bekannten Namen in die Commits-Beschreibung einsetzt, die erstellt wird, wenn eine aktualisierte Version der Anwendung gefunden wird. Der AutoName-Eintrag wird automatisch erzeugt, wenn fdroid checkupdates ausgeführt wird.

Name (Name)

Der Name der Anwendung. Normalerweise sollte dieses Feld nicht vorhanden sein, da der korrekte Name der Anwendung aus der APK-Datei bezogen wird. In Situationen, in denen ein APK einen fehlerhaften oder keinen Anwendungsnamen enthält, kann dies jedoch hiermit korrigiert werden. Zu beachten ist, dass damit lediglich der Name in der App-Liste, die im Client erscheint, korrigiert wird; der Name oder die App-Bezeichnung im Quelltext bleibt unverändert.

Achtung: Dies ist allen im App-Quellcode festgelegten Namenseinträgen übergeordnet.

Umwandlung zu (<name>) in der XML-Datei (index.xml).

Internetseite (WebSite)

Die URL für die Internetseite der Anwendung. Kann weggelassen werden (oder leer bleiben), wenn es keine entsprechende Internetseite gibt.

Umwandlung zu (<web>) in der XML-Datei (index.xml).

Quelltext (SourceCode)

Die URL, um den Quelltext der Anwendung einzusehen oder zu beziehen. Dieser sollte von Menschen lesbar sein. Maschinenlesbarer Quellcode wird durch das Repo-Feld abgedeckt.

Umwandlung zu (<source>) in der XML-Datei (index.xml).

Ticketsystem (IssueTracker)

Die URL zum Ticketsystem der Anwendung. Optional, da nicht alle Anwendungen eines besitzen.

Umwandlung zu (<tracker>) in der XML-Datei (index.xml).

Übersetzung (Translation)

Die URL zum Übersetzungsportal für die App oder zumindest eine Orientierungshilfe. Optional, da nicht alle Anwendungen eines haben.

Umwandlung zu (translation) in der JSON-Datei (index.json).

Änderungsprotokoll (Changelog)

Die URL zum Änderungsprotokoll der Anwendung. Optional, da nicht alle Anwendungen eines haben.

Umwandlung zu (<changelog>) in der XML-Datei (index.xml).

Spenden (Donate)

Die URL, über die für das Projekt gespendet werden kann. Sollte die Spendenseite des Projekts sein, falls es eine gibt.

Es ist möglich, hier eine Direktverbindung zu PayPal zu verwenden, wenn nur das zur Verfügung steht. Man sollte jedoch im Hinterkopf behalten, dass der Entwickler von dieser Direktverknüpfung möglicherweise nichts weiß, und, sollte er später zu einem anderen PayPal-Konto wechseln oder das Format des PayPal-Links ändern, einiges schief gehen kann. Es ist immer am besten, einen Link zu nutzen, den der Entwickler ausdrücklich veröffentlicht hat, als irgendeinen automatisch generierten Code für einen ’Button’.

Umwandlung zu (<donate>) in der XML-Datei (index.xml).

Flattr-ID (FlattrID)

Die Flattr-ID (http://flattr.com) des Projekts, wenn eine vorliegt. Sollte eine numerische ID sein, so dass (zum Beispiel) https://flattr.com/thing/xxxx direkt auf die Spendenseite des Projekts weiterleitet.

Umwandlung zu (<flattr>) in der XML-Datei (index.xml).

Liberapay

Nutzer- oder Gruppenname des Projekts bei Liberapay (https://liberapay.com), wenn vorhanden. Sollte ein alphanumerischer Name sein, so dass (zum Beispiel) https://liberapay.com/xxxxx direkt auf Ihre Kontenseite weiterleitet. Wird als LiberapayID verwendet, die eine numerische ID darstellte, die von der Liberapay-Website bezogen wurde, indem /public.json an Ihre Teamseite angefügt wurde.

Umwandlung zu (<liberapay>) in der XML-Datei (index.xml).

OpenCollective

Nutzer- oder Gruppenname des Projekts bei OpenCollective (http://opencollective.com), wenn vorhanden. Sollte ein alphanumerischer Name sein, so dass (zum Beispiel) https://opencollective.com/xxxx direkt auf die Kontenseite weiterleitet.

Bitcoin (Bitcoin)

Eine Bitcoin-Adresse für Projektspenden.

Umwandlung zu (<bitcoin>) in der XML-Datei (index.xml).

Litecoin (Litecoin)

Eine Litecoin-Adresse für Projektspenden.

Umwandlung zu (<litecoin>) in der XML-Datei (index.xml).

Zusammenfassung (Summary)

Eine Kurzbeschreibung, um was es bei der Anwendung geht. Da die Zusammenfassung in der Liste des F-Droid-Clients nur eine Zeile lang sein darf, sollten 80 Zeichen nicht überschritten werden, um die Anzeige auf den meisten Bildschirmen zu gewährleisten.

Achtung: Dies ist allen im App-Quellcode festgelegten Zusammenfassungen übergeordnet.

Umwandlung zu (<summary>) in der XML-Datei (index.xml).

Beschreibung (Description)

Eine komplette Beschreibung der Anwendung entsprechend ihrer aktuellsten Version. Sie kann mehrere Zeilen umfassen (, die auf 80 Zeichen begrenzt sein sollten,) und wird mit einer Zeile, die nur einen ’.’ enthält, abgeschlossen.

Die Formatierung der Beschreibung folgt den eingeführten Konventionen, die über viele App-Stores hinweg funktionieren:

  • Eine grundlegende HTML-Formatierung kann verwendet wird.
  • Zeilenvorschübe bleiben erhalten.
  • Links zu weiteren Paketen auf f-droid.org werden auf der Webseite anklickbar dargestellt, andere Links als einfacher Text.

Es kann hilfreich sein Informationen zu vermerken, die Änderungen gegenüber einer Vorversion betreffen; ob die App von vorgeschalteten Entwicklern erstellte, vorgefertigte Elemente enthält oder ob unfreie Bestandteile entfernt wurden; ob die App sich rasch weiterentwickelt oder ob die neuste Version gegenüber der momentanen lange auf sich warten ließ; ob die App mehrere Architekturen unterstützt oder ob ein Mindest-SDK festgelegt ist (derartige Infos, die im Index nicht verzeichnet werden).

Auf 4000 Zeichen begrenzt

Achtung: Dies ist allen im App-Quellcode festgelegten Beschreibungen übergeordnet.

Umwandlung zu (<desc>) in der XML-Datei (index.xml).

Wartungsnotizen (MaintainerNotes)

Ein mehrzeiliges Feld, das dieselben Regeln und dieselbe Syntax wie die Beschreibung verwendet. Es wird dazu genutzt Hinweise für die F-Droid-Maintainers zu vermerken, die sie bei der Pflege und Aktualisierung der Anwendung im Repository unterstützen.

Diese Informationen werden auch im Wiki veröffentlicht.

Repo-Typ (RepoType)

Die Art des Repositorys - zur automatischen Herstellung aus der Quelle. Ist sie nicht festgelegt, kann für die Anwendung keine automatische Herstellung erfolgen. Mögliche Werte sind:

  • ‘git’
  • ‘svn’
  • ‘git-svn’
  • ‘hg’
  • ‘bzr’
  • ‘srclib’

Repo (Repo)

Der Ort des Repositorys. Für gewöhnlich beispielsweise eine git: oder svn: URL.

Die git-svn-Option verbindet zu einem SVN-Repository und die URL wird in genau der selben Weise angegeben, aber Git fungiert als Backend. Das ist aus Leistungsgründen zu bevorzugen und auch weil eine lokale Kopie des gesamten Verlaufs erhältlich ist, sollte das vorgeschaltete Repository verlorengehen. (So etwas passiert!). Um für diesen VCS-Typ Tags als UpdateCheckMode zu verwenden, muss die URL den speziellen Argumentesatz ‚tags=‘ enthalten. Wenn das RepoManifest/branch-Schema verwendet werden soll, kann in gleicher Weise zusätzlich ‚branches=‘ spezifiziert werden. Schließlich kann noch ‚trunk=‘ hinzugefügt werden. Alle diese speziellen Argumente werden der Reihe nach an „git svn“ übergeben, und ihre Werte müssen relative Pfade zum SVN-Repo-Root-Verzeichnis sein. Hier ein Beispiel für eine komplexe Repo-URL von git-svn: http://svn.code.sf.net/p/project/code/svn;trunk=trunk;tags=tags;branches=branches

Wenn RepoType srclib ist, müssen Sie den Namen der entsprechenden srclib .txt-Datei angeben. Wenn zum Beispiel scrlibs/FooBar.txt existiert und Sie diese srclib verwenden wollen, dann müssen Sie Repo auf FooBar setzen.

Binärdateien (Binaries)

Der Ort der Binärdateien, die im Prüfprozess verwendet werden.

Wenn angegeben, wird F-Droid die ausgegebene APK-Datei eines Build gegenüber der aufgeführten abgleichen. Es kann %v und %c verwendet werden, um auf den Versionsnamen und den Versionscode des aktuellen Build zu verweisen. Um den F-Droid-Client selbst zu überprüfen, könnte Folgendes verwendet werden: Binaries:https://f-droid.org/repo/org.fdroid.fdroid_%c.apk

F-Droid verwendet die Original-APKs, wenn die Verifizierung erfolgreich ist.

Builds (Builds)

Es kann eine beliebige Anzahl von Untereinträgen vorhanden sein, von denen jeder eine Version angibt, die aus der Quelle automatisch erstellt werden soll. Zum Beispiel:

Builds:
  - versionName: 1.2
    versionCode: 12
    commit: v1.2

  - versionName: 1.3
    versionCode: 13
    commit: v1.3-fdroid

versionName: xxx

versionCode: yyy

Bestimmt die Erstellung der Version xxx, die den Versionscode yyy besitzt.

commit: xxx

Der Parameter commit bestimmt den Tag, Commit oder die Revision-Nummer, ab der die Erstellung im Quell-Repository erfolgen soll.

Neben den drei oben beschriebenen, immer erforderlichen Parametern, können weitere Parameter (im Format: name: value) hinzugefügt werden, um weitere Build-Konfigurationsmerkmale anzuwenden. Diese sind (grob in der Reihenfolge ihrer Anwendung):

disable: <message>

Deaktiviert diesen Build und gibt einen Grund dafür an. (Aus Rückwärts- Kompatibilitätsgründen kann dies auch durch Voranstellen eines ‚!’ vor die Commit-ID erzielt werden)

Der Zweck dieses Merkmals ist es, eine Kennzeichnung von Ausgaben zu ermöglichen, die kein Build zulassen (z. B. bei unveröffentlichtem Quelltext), damit die Skripte nicht wiederholt Meldungen dazu auslösen. (Aber auch um die Information für eine spätere Überprüfung zu protokollieren). Wenn ein APK bereits erstellt wurde, bewirkt die Deaktivierung dessen Löschung, sobald fdroid update ausgeführt wird; dies entspricht dem Vorgehen, wann immer eine Version ersetzt werden muss.

subdir: <path>

Gibt ein Unterverzeichnis des ausgecheckten Quellcodes an, aus dem erstellt werden soll. Normalerweise erfolgt der Wechsel in dieses Verzeichnis vor der Herstellung.

submodules: yes

Wird verwendet, wenn das Projekt (ausschließlich Git) Untermodule besitzt - bewirkt die Ausführung von git submodule update --init --recursive nachdem die Quelle geklont wurde. Untermodule werden, wie das App-Hauptrepository selbst, vor jeder Herstellung zurückgesetzt und bereinigt.

sudo: xxxx

Gibt ein Skript an, dass mittels sudo bash -x -c "xxxx" in der Buildserver-Gast-VM ausgeführt werden soll. Dieses Skript läuft mit Root-Privilegien, aber die VM wird nach jedem Build zurückgesetzt. Die große Mehrheit der Apps wird in einer Standard-Debian-Stable-Umgebung kompiliert. Dieser Parameter ist sinnvoll, um den Buildserver auf komplexe Vorgänge vorzubereiten, die sehr spezifische Dinge benötigen, bei denen es nicht angemessen wäre, sie für alle Builds zu installieren; oder für Dinge, die andere Builds stören würden.

timeout: <seconds>

Zeitliche Begrenzung für diesen Build (in Sekunden). Nach Ablauf der Zeit wird die Beendigung der Buildserver-VM erzwungen. Standardwert ist 7200 (2 Stunden); 0 bedeutet ohne Begrenzung.

Die Begrenzung wird nur im Servermodus angewandt, d. h. wenn fdroid build mit der Option --server aufgerufen wird.

init: xxxx

Wie ‚prebuild’, wird aber auf den Quellcode angewandt BEVOR irgendeine andere Verarbeitung stattfindet.

Es kann $$SDK$$, $$NDK$$ and $$MVN3$$ verwendet werden, um die Pfade zu den Android-SDK- und NDK-Verzeichnissen bzw. zur ausführbaren Maven 3 zu ersetzen. Die folgenden Variablen pro Build stehen ebenfalls zur Verfügung: $$VERSION$$, $$VERCODE$$ und $$COMMIT$$.

oldsdkloc: yes

Der SDK-Ort im Repo ist in einem alten Format, oder „build.xml“ erwartet ein solches. Das ‚neue’ Format ist „sdk.dir“, während das SEHR ALTE Format „sdk-location“ ist. Wird beim Herstellungsversuch eine Meldung
ähnlich wie: „com.android.ant.SetupTask cannot be found“ ausgegeben, dann sollte typischerweise die Aktivierung dieser Option versucht werden.

target: <target>

Gibt eine bestimmte SDK-Zielvorgabe für die Kompilierung an, der im eingespielten Code festgelegte Wert wird nicht berücksichtigt. Abhängig vom verwendeten Build-System hat dies verschiedene Auswirkungen — dieses Kennzeichen beeinflusst momentan nur Ant-, Maven- und Gradle-Projekte. Zu beachten ist, dass es nicht das Ziel-SDK in „AndroidManifest.xml“ verändert, das das Ausmaß der Funktionen, die ins Build eingeschlossen werden können, bestimmt.

Im Falle eines Ant-Projekts modifiziert es project.properties der App und eventueller Unterprojekte. Dies bewirkt wahrscheinlich, dass build.xml komplett neu geschrieben wird, was in Ordnung ist, wenn es eine ’Standard’- Android-Datei ist oder noch nicht existiert, aber keine gute Idee ist, wenn sie intensiv bearbeitet wurde.

androidupdate: <auto/dirs>

In Ant-Builds wird standardmäßig „android update“ verwendet, um das Projekt und alle Projekte, auf die es verweist, zu erzeugen oder zu aktualisieren. Die Angabe von „update=no“ umgeht das. Zu beachten ist, dass das in Builds, die kein Ant verwenden, nutzlos ist.

Der Standardwert ist ’auto’, der rekursiv die Pfade in project.properties nutzt, um alle zu aktualisierenden Unterprojekte zu finden.

Ansonsten kann der Wert eine durch Komma getrennte Liste von Verzeichnissen sein, in denen „android update“ relativ zum Anwendungsverzeichnis ausgeführt werden soll.

encoding: xxxx

Fügt eine „java.encoding“-Eigenschaft mit dem angegebenen Wert in „local.properties“ ein. Im Allgemeinen wird der Wert ’utf-8’ sein. Dieser wird von den Ant-Regeln des SDK übernommen, und zwingt den Java-Compiler, die Quelldateien mit dieser Kodierung zu interpretieren. Werden während der Kompilierung Warnungen zur Zeichenkodierung ausgegeben, wird dies möglicherweise benötigt.

forceversion: yes

Falls angegeben, wird die Paketversion in dem AndroidManifest.xml durch die in den Metadaten des Builds festgelegte Versionsbezeichnung ersetzt.

Das ist in folgenden Fällen sinnvoll, wenn im Quell-Repository kein spezieller Tag für die Version gesetzt wurde; um eine willkürliche Version zu erstellten; um darauf hinzuweisen, dass die Version große Unterschiede zum Upstream aufweist; oder um zu zeigen, für welche Architektur das APK gedacht ist.

forcevercode: yes

Wenn festgelegt, wird der Paketversionscode in AndroidManifest.xml durch den Versionscode für den Build ersetzt. Siehe auch „forceversion“.

rm: <path1>[,<path2>,...]

Gibt die relativen Pfade zu Dateien oder Verzeichnissen an, die zu löschen sind, bevor die Herstellung erfolgt. Die Pfade sind relativ zum Build-Grundverzeichnis, d. h. dem Wurzelverzeichnis in der Verzeichnisstruktur des ausgecheckten Quell-Repository - nicht notwendigerweise zum Verzeichnis, das AndroidManifest.xml enthält.

Es können mehrere Dateien/Verzeichnisse angegeben werden, die durch ’,’ getrennt werden. Verzeichnisse werden rekursiv gelöscht.

extlibs: <lib1>[,<lib2>,...]

Komma-getrennte Liste externer Bibliotheken (jar-Dateien) aus der build/extlib-Bibliothek, die im libs-Verzeichnis des Projekts abgelegt werden.

srclibs: [n:]a@r,[n:]b@r1,...

Komma-getrennte Liste der Quellbibliotheken oder Android-Projekte. Jeder Eintrag hat die Form „name@rev“, wobei „name“ der vorgegebene Name der Quell- bibliothek ist und „rev“ die Revision bzw. das Kennzeichen, das in der entsprechenden Versionsverwaltung verwendet werden soll.

Bei Ant-Projekten kann optional eine Zahl gefolgt von einem Doppelpunkt am Anfang des srclib-Eintrags angefügt werden, um ihn automatisch als eine Bibliothek mit der festgelegten Nummer in project.properties einzutragen. Zum Beispiel wird F-Droid bei Angabe von 1:somelib@1.0 automatisch ausführen, was der altbekannten Methode: prebuild=echo "android.library.reference.1=$$somelib$$">>project.properties entspricht.

Jede srclib besitzt eine Metadaten-Datei in srclibs/ im Repository-Verzeichnis und der Quelltext wird in build/srclib/ gespeichert. RepoType und Repo werden in gleicher Weise wie für Apps festgelegt; „Subdir:“ kann eine komma-getrennte Liste sein, falls Verzeichnisse beim Upstream umbenannt werden; „Update Project:“ aktualisiert die Projekte im Arbeitsverzeichnis und eine Stufe darunter; „Prepare:“ kann für jede Art der Vorbereitung genutzt werden, insbesondere wenn die Projektaktualisierung ein bestimmtes Ziel braucht. Es kann dann auch „$$name$$“ im Befehl „init/prebuild/build“ verwendet werden, um die relativen Pfade zum Bibliotheken- Verzeichnis zu ersetzen. Bei einem Wechsel des Verzeichnisses könnten allerdings Anpassungen notwendig werden.

Momentan sind „srclibs“ nötig, wenn der Upstream jar-Dateien verwendet oder aus nicht vertrauenswürdigen Repositorys Abhängigkeiten bezieht. Solange nicht garantiert ist, dass jene Binärdateien frei sind und dem Quellcode entsprechen, erlaubt F-Droid die folgenden bekannten Repositorys bis eine aus dem Quellcode erstellte Alternative zur Verfügung steht:

  • ‘mavenCentral’ - das Original-Repo, festprogrammiert in Maven und Gradle.
  • ‘jCenter’ - festprogrammiert in Gradle, dieses Repo von Bintray ist bemüht, eine einfachere Bedienung anzubieten. Es sollte von Zeit zu Zeit mit mavenCentral synchronisiert werden.
  • ‘OSS Sonatype’ - betrieben von den Leuten hinter mavenCentral, konzentriert sich dieses Repository auf Hosting-Dienste für Binärdateien von Open-Source-Projekten.
  • ‘OSS JFrog’ - betrieben von den Leuten hinter jCenter. Der Schwerpunkt dieses Repositorys liegt auf Hosting-Diensten für Binärdateien von Open-Source-Projekten.
  • ‘JitPack.io’ - erstellt Builds direkt aus GitHub-Repositorys. Sie bieten allerdings keine Optionen, die Ausgabebinärdateien zu reproduzieren oder verifizieren. Erstellt in manchen Fällen Builds von Pre-release-Versionen.
  • ‘Clojars’ - Clojure-Bibliotheken-Repo.
  • ‘CommonsWare’ - Repo, das eine Sammlung von Open-Source-Bibliotheken bereithält.
patch: x

Patch(es) anwenden. ’x’ bezeichnet eine Datei (oder mehrere, durch Kommas getrennt) innerhalb eines Verzeichnisses unterhalb der Metadaten, mit dem selben Namen wie die Metadaten-Datei aber ohne deren Erweiterung. Jeder dieser Patches wird der Reihe nach auf den Code angewendet.

prebuild: xxxx

Gibt einen Shell-Befehl (oder -Befehle - verkettet mit &&) an, der vor der Durchführung der Herstellung ausgeführt wird. Ein Backslash kann als Maskierungszeichen verwendet werden, um Kommazeichen einzufügen, oder um, als letztes Zeichen einer Zeile, diese mit der nächsten zu verbinden. Er besitzt keine spezielle Bedeutung in anderen Zusammenhängen; im Besonderen, eigentliche Backslash-Zeichen sollten nicht maskiert werden.

Zur Ausführung des Befehls wird die Bash verwendet.

Beachten Sie, dass während dieser Prebuild-Phase nichts erstellt werden sollte - Scannen des Codes und Erstellen des Quelltext-Tarballs, zum Beispiel, finden danach statt. Für gebräuchliche Tätigkeiten, die tatsächlich Dinge erstellen oder Binärdateien produzieren, verwenden Sie stattdessen ’build’.

Es kann $$name$$ verwendet werden, um den Pfad zu einer eingetragenen „srclib“ zu ersetzen - Einzelheiten hierzu unter: das srclib-Verzeichnis.

Sie können $$SDK$$, $$NDK$$ und $$MVN3$$ verwenden, um die Pfade zu den Android-SDK- und NDK-Verzeichnissen bzw. zur Maven-3-
Routine zu ersetzen, z. B. wenn es ausdrücklich erforderlich ist android update project auszuführen. Die folgenden vom Build abhängigen Variablen stehen gleichermaßen zur Verfügung: $$VERSION$$, $$VERCODE$$ und $$COMMIT$$.

scanignore: <path1>[,<path2>,...]

Ermöglicht den Ausschluss von Dateien/Pfaden beim Scan-Vorgang Sollte nur verwendet werden, wenn es dafür einen triftigen Grund gibt, und möglichst von einem Vermerk begleitet sein, der erklärt, warum es notwendig ist.

Beim Durchsuchen der Quellverzeichnisstruktur nach Problemen, werden entsprechende Dateien, deren relative Pfade mit einem der hier angegebenen Pfade beginnen, übergangen.

scandelete: <path1>[,<path2>,...]

Bei Ausführung des Scan-Vorganges werden alle Dateien, die Fehler auslösen

  • wie Binärdateien - entfernt. Funktioniert genau wie scanignore, aber statt die Dateien zu überspringen, werden sie gelöscht.

Nützlich wenn ein Quelltext-Repository Binärdateien oder andere unerwünschte Dateien beinhaltet, die für den Build nicht erforderlich sind. Anstatt sie über rm von Hand zu löschen, ist die Verwendung von scandelete einfacher.

build: xxxx

Wie bei ’prebuild’, läuft aber während der eigentlichen Build-Phase (aber vor dem Hauptbuild durch Ant/Maven). Nur für tatsächliche Build- Maßnahmen verwenden. Alle Vorbereitungen des Quelltextes sollten über ’init’ oder ’prebuild’ stattfinden.

Jeder build, der vor build stattfindet, wird ignoriert, da entweder Ant, Maven oder Gradle ausgeführt wird, um die Build Umgebung direkt bevor build (oder dem endgültigen Build) ausgeführt wird, zu bereinigen

Es kann $$SDK$$, $$NDK$$ and $$MVN3$$ verwendet werden, um die Pfade zu den Android-SDK- und NDK-Verzeichnissen bzw. zur ausführbaren Maven 3 zu ersetzen. Die folgenden Variablen pro Build stehen ebenfalls zur Verfügung: $$VERSION$$, $$VERCODE$$ und $$COMMIT$$.

buildjni: [yes|no|<dir list>]

Ermöglicht die Erstellung nativen Codes über das NDK-Build-Skript vor Ausführung des Ant-Hauptbuild. Der Wert kann entweder eine Ordnerliste relativ zum Anwendungshauptverzeichnis sein, in dem ndk-build ausgeführt werden soll, oder ’yes’, was ’.’ entspricht. Die Verwendung einer expliziten Liste kann bei Builds von mehrteiligen Projekten praktisch sein.

Die Build- und Scan-Prozesse werde sich beschweren (sie weigern sich zu bauen), wenn dieser Parameter nicht definiert ist, aber es ist ein jni Verzeichnis vorhanden. Wenn der native Code mit anderen Mitteln wie z.B. eines Gradle-Tasks, gebaut werden, können Sie hier nein angeben, um das zu vermeiden. Wenn jedoch der native Code nicht benötigt oder verwendet wird, entfernen Sie stattdessen das Verzeichnis (zum Beispiel mit rm=jni). Mit buildjni=no wenn der jni-Code nicht verwendet oder gebaut wird, führt zu einem Fehler, der besagt, dass native Bibliotheken in dem resultierenden Paket erwartet wurden.

ndk: <version>

Version des NDK für diesen Build. Standardmäßig wird das letzte NDK verwendet, das Legacy-Toolchains (r12b) enthält, sodass Builds, die Toolchains benötigen, die in aktuellen NDK-Versionen nicht mehr enthalten sind, nicht abbrechen.

Der Buildserver unterstützt r10e, r11c, r12b, r13b, r14b, r15c, r16b, r17b, r18b, r19c, r20b und r21. Sie können die Unterstützung weiterer Versionen hinzufügen, indem Sie sie in Ihrer Konfigurationsdatei unter ‘ndk_paths’ ergänzen.

gradle: <flavour1>[,<flavour2>,...]

Mit Gradle statt Ant bauen, mit Festlegung der zu verwendenden Flavours. Bei Flavours ist die Groß- und Kleinschreibung zu beachten, da sie auch für den Pfad zum ausgegebenen APK gilt.

Wenn nur eine Variante gegeben ist und sie “ja” ist, wird keine Variante verwendet. Beachten Sie, dass Sie bei Projekten mit Varianten mindestens ein gültiger Geschmack angegeben werden muss, da “ja” alle getrennt erstellt.

maven: yes[@<dir>]

Mit Maven statt Ant bauen. Ein zusätzliches @<dir> teilt F-Droid mit, Maven innerhalb dieses relativen Unterverzeichnisses auszuführen. Manchmal ist es erforderlich, @.. zu verwenden, damit Builds korrekt stattfinden.

preassemble: <task1>[,<task2>,...]

Liste der Gradle-Aufgaben, die vor der Assemblierung in einer Gradle-Projekterstellung ausgeführt werden sollen.

gradleprops: <prop1>[,<prop2>,...]

Liste der Gradle-Eigenschaften, die über die Kommandozeile an Gradle übergeben werden. Eine Eigenschaft kann die Form foo oder key=value haben.

Zum Beispiel: gradleprops=enableFoo,someSetting=bar liefert das Ergebnis gradle -PenableFoo -PsomeSetting=bar.

antcommands: <target1>[,<target2>,...]

Geben Sie einen alternativen Satz von Ant-Befehlen (Ziel) an anstelle des Standard-‘release’. Es können keine Flags angegeben werden, wie z.B. der Pfad zu einer build.xml.

output: glob/to/output.apk

Geben Sie einen Glob-Pfad an, in dem sich das resultierende unsignierte Release-APK des Builds befinden sollte. Dies kann verwendet werden in Kombination mit Build- Methoden wie gradle=yes oder maven=yes, aber wenn keine Build-Methode angegeben ist, ist der Build manuell. Sie sollten Ihre Build-Befehle ausführen, z.B. make in build.

novcheck: yes

Keine Überprüfung, ob Versionsname und Code in dem resultierenden APK korrekt sind, indem die Build-Ausgabe betrachtet wird - korrekte Metadaten vorausgesetzt. Dadurch wird eine nützliche Stufe der Plausibilitätsprüfung entfernt, sollte daher nur verwendet werden, wenn die Werte nicht extrahiert werden können.

antifeatures: <antifeature1>[,<antifeature2>,...]

Liste der Anti-Features für diesen speziellen Build. Sie werden in AntiFeatures beschrieben.

Unerwünschte Merkmale (AntiFeatures)

Dies ist optional - wenn vorhanden, enthält es eine durch Komma getrennte Liste mit jedem der folgenden Werte, die ein unerwünschtes Merkmal beschreiben, das die Anwendung besitzt. Es empfiehlt sich, die Gründe für unerwünschte Merkmale in der Beschreibung zu erläutern:

  • ‘Ads’ - die Anwendung enthält Werbung.
  • ‘Tracking’ - Informationen zu Nutzer oder Aktivitäten werden standardmäßig verfolgt oder abgezweigt. Wahr, wenn die App oder eine Funktion nicht verwendet werden kann, ohne solche Daten zu sammeln und weiterzugeben oder Anfragen an einen Datensammeldienst im Netz zu stellen (unerheblich, ob der Dienst auf freier Software basiert oder nicht). Zum Beispiel, auf Aktivitäten beruhendes Herunterladen von Wetterdaten, Karten, Avataren usw. (Hosting und Auslieferungsdienste von Daten) oder Hochladen von Absturzprotokollen usw.
  • ‘NonFreeNet’ - Die Anwendung enthält eine Funktion, die einen proprietären Netzwerkdienst nutzt, der nicht oder nicht leicht ersetzt werden kann. Ein Ersatz erfordert Änderungen an der App oder am Service. Dieses unerwünschte Merkmal käme nicht zur Anwendung, wenn es eine einfache Konfigurationsmöglichkeit gäbe, die es möglich macht, die App auf eine laufende Instanz einer alternativen, öffentlich zugänglichen, auf freier Software beruhender Serverlösung umzuleiten.
  • ‘NonFreeAdd’ - die Anwendung bewirbt proprietäre Erweiterungen, so dass die App gewissermaßen zum Werbeträger für andere nicht freie Software wird.
  • ‘NonFreeDep’ - die Anwendung hängt von einer proprietären Anwendung ab (z. B. Google Maps) - d. h. deren Installation auf dem Gerät ist erforderlich, sie ist aber nicht enthalten.
  • ‘UpstreamNonFree’ - die Anwendung ist proprietäre Software oder hängt von ihr ab. Das bedeutet nicht, dass die App nicht freie Software beinhaltet: Am wahrscheinlichsten erfolgte in irgendeiner Weise ein Patch, um den nicht freien Code zu entfernen. Allerdings könnten Funktionen abhanden gekommen sein.
  • ‘NonFreeAssets’ - die Anwendung enthält oder bedient sich unfreier Medieninhalte. Der gebräuchlichste Fall ist, dass Apps Kunst - Bilder, Klänge, Musik usw. - verwenden, die einer nicht kommerziellen Lizenz unterliegt.
  • ‘KnownVuln’ - die Anwendung hat bekannte Sicherheitslücken.
  • ‘ApplicationDebuggable‘ - APK-Datei wird zum Debuggen kompiliert (application-debuggable), was sie normalerweise für normale Benutzer und Anwendungsfälle ungeeignet macht.
  • ‘NoSourceSince’ - Die Upstream-Quelle für diese App ist nicht mehr erreichbar. Entweder wurde die App kommerziell, das Repo wurde eingestellt oder es ist an einen Ort umgezogen, der uns derzeit unbekannt ist. Das bedeutet, dass es keine weiteren Updates geben wird, es sei denn, die Quelle taucht wieder auf.

Umwandlung zu (<antifeatures>) in der XML-Datei (index.xml).

Deaktiviert (Disabled)

Ist dieses Feld vorhanden, wird die Anwendung nicht in das der Öffentlichkeit zugängliche Register eingetragen werden. Dadurch wird die Sicherung von Metadaten ermöglicht, solange eine Anwendung vorübergehend von der Veröffentlichung ausgeschlossen ist. Der Wert sollte eine Beschreibung sein, warum die Anwendung deaktiviert ist. Es werden keine APKs oder Quelltextarchive gelöscht: um ein APK zu beseitigen, sehen Sie im Abschnitt „Build Version“ nach oder löschen Sie sie bei Entwickler-Builds manuell. Das Feld wird daher verwendet, wenn eine App ihren Nutzwert verloren hat, weil der Quellcode-Tarball zurückgehalten wird.

Benötigt Root (RequiresRoot)

Dieses optionale Feld sollte „Yes“ enthalten, wenn die Anwendung Root-Rechte benötigt, um nutzbar zu sein. Dadurch kann der Client sie aussortieren, wenn der Nutzer dies so wünscht. Egal ob Root zwingend erforderlich ist oder nicht, empfiehlt es sich, bei Verwendung von Root-Zugriffen in der Beschreibung einen Absatz zu ergänzen, der die Bedingungen und den Grund dafür nennt.

Umwandlung zu (<requirements>) in der XML-Datei (index.xml).

Archivrichtlinie (ArchivePolicy)

Legt die Richtlinien fest, nach der alte Versionen einer App ins Archiv-Repo verschoben werden, wenn eines eingerichtet ist. Die Konfiguration legt den Standardwert für die maximale Anzahl von im Haupt-Repo aufbewahrten Versionen fest, nach dem ältere Versionen ins Archiv verschoben werden. Diese app-spezifische Richtlinienfestlegung kann den Wert überschreiben.

Die über CurrentVersionCode festgelegte Version wird immer als die neuste Version angesehen, wenn zu entscheiden ist, welche Versionen ins Archiv verschoben werden. Das bedeutet, wenn ArchivePolicy auf “1 Version” eingestellt ist, wird nur das APK behalten, das dem CVC entspricht, was nicht notwendigerweise das mit dem höchsten Versionscode ist.

Momentan ist das einzige unterstützte Format „n versions“, wobei n die Zahl der zu erhaltenden Versionen ist. Standard sind „3 versions“.

Aktualisierungsprüfmethode (UpdateCheckMode)

Bestimmt die verwendete Ermittlungsmethode, wann neue Versionen zur Verfügung stehen. - in anderen Worten, die Aktualisierung der Felder CurrentVersion und CurrentVersionCode in den Metadaten durch den Vorgang fdroid checkupdates.

Gültige Methoden sind:

  • None - Es erfolgt keine Überprüfung, weil es keinen geeigneten, automatisierten Weg dafür gibt. Es muss manuell auf Aktualisierungen geprüft werden. Zum Beispiel zu verwenden, wenn instabile oder gepatchte Versionen eingesetzt werden; wenn Builds in einem anderen Verzeichnis erfolgen, als dem in dem sich AndroidManifest.xml befindet; falls die Entwickler das Gradle-Build-System verwenden und Versionsinfos in einer separaten Datei speichern; falls die Entwickler für jede Version einen neuen Zweig erstellen aber keine Kennzeichen; oder wenn die Paketnamen- oder Versionscode-Logik verändert wurde.
  • Static - Es findet keine Überprüfung statt - entweder wurde die Weiterentwicklung eingestellt oder neue Versionen werden nicht gewünscht. Diese Methode wird auch verwendet, wenn es keine andere verfügbare Prüfmethode gibt, und der vorgeschaltete Entwickler uns neue Versionen bekanntgibt.
  • RepoManifest - Nach dem neusten Commit, wird nach den Dateien AndroidManifest.xml und build.gradle in den Verzeichnissen gesucht, in denen sie sich beim aktuellsten Build befanden. Die Eignung dieser Methode hängt vom Entwicklungsprozess ab, den die App-Entwickler verwenden. Wenn nicht sicher ist, ob sie sich eignet, sollte sie nicht festgelegt werden. Zum Beispiel stoßen einige Entwickler Versionen zu Beginn der Entwicklung an anstatt vor der Veröffentlichung. Das Verschieben von AndroidManifest.xml in ein anderes Verzeichnis oder das Ändern des Paketnamens wird einen Fehler auslösen. Die zurückgegebene aktuelle Version wird nicht korrekt sein, da nicht alle Versionen zur Veröffentlichung taugen. Daher ist es häufig, vor der Herstellung, notwendig, zu überprüfen, ob die aktuelle Version irgendwo von den Upstream-Entwicklern publiziert wurde, entweder durch Kontrolle der von ihnen verbreiteten APKs oder der Tags im Quellcode-Repository.

    Es funktioniert derzeit für jeden Repository-Typ in unterschiedlichem Umfang, mit Ausnahme des srclib-Repo-Typs. Für die Typen git, git-svn und hg, können Sie „RepoManifest/IhrBranch“ als UpdateCheckMode verwenden, so dass „IhrBranch“ in diesem Fall der Zweig wäre, der anstelle des Standard-Branches verwendet wird. Die Standardwerte sind „master“ für git und „default“ für hg, git-svn hat keinen (es bleibt im gleichen Branch). Andererseits ist der Branch-Support in bzr und svn noch nicht implementiert, RepoManifest kann aber immer noch ohne ihn verwendet werden.

  • RepoTrunk - Für svn und git-svn Repositorys, besonders für diejenigen, die keine mitgelieferte AndroidManifest.xml Datei haben, werden Prüfungen auf Tags und RepoManifest nicht funktionieren, da keine Versionsinformationen erhältlich sind. Aber für die Apps, die ihren Build-Prozess mit dem auf HEAD verweisenden Commit-Ref automatisieren, wird RepoTrunk CurrentVersion und CurrentVersionCode nach diesen Werten festlegen.
  • Tags - Die Dateien AndroidManifest.xml und build.gradle in allen getaggten Revisionen im Quellrepository werden überprüft, indem nach dem höchstem Versionscode gesucht wird. Die Eignung dieser Methode hängt vom Entwicklungsprozess ab, den die App-Entwickler verwenden. Wenn nicht sicher ist, ob sie sich eignet, sollte sie nicht festgelegt werden. Sie sollte nicht verwendet werden, wenn die Entwickler gerne instabile Versionen taggen oder dafür bekannt sind, Tags für Releaseversionen zu vergessen. Wie bei RepoManifest wird ein falscher Wert zurückgegeben werden, wenn AndroidManifest.xml verschoben wurde. Trotz dieser Vorbehalte ist es oft der UpdateCheckMode.

    Zurzeit funktioniert es nur für Git, Hg, Bazaar und Git-SVN Repositorys. Bei letzterem muss die URL zum Repository den Pfad zum Stamm und Schlagwörter enthalten, sonst werden keine Schlagwörter gefunden.

    Optional kann am Ende - durch ein Leerzeichen getrennt - ein regulärer Ausdruck angehängt werden, um allein die Schlagwörter auf Übereinstimmung mit dem regulären Ausdruck zu überprüfen. Dies ist von Nutzen, wenn Apps unveröffentlichte Versionen, wie X.X-alpha enthalten. Diese können somit aussortiert werden, indem etwa .*[0-9]$ angehängt wird, was Schlagwörter voraussetzt, die mit einer Ziffer enden.

  • HTTP - Es werden HTTP-Requests verwendet, um den aktuellen Versionscode und -namen zu ermitteln. Dies wird durch das Feld UpdateCheckData gesteuert, das in Form von urlcode|excode|urlver|exver vorliegt.

    Zuerst wird, wenn urlcode nicht leer ist, das Dokument von dieser URL bezogen und gegen den regulären Ausdruck excode abgeglichen, so dass die erste Gruppe der Versionscode wird.

    Danach wird, wenn urlver nicht leer ist, das Dokument von dieser URL geholt und gegen den regulären Ausdruck exver abgeglichen, wodurch die erste Gruppe zum Versionsnamen wird. Das Feld urlver kann einfach auf ’.’ gesetzt werden, was besagt, dasselbe Dokument wieder zu verwenden, das für den Versionscode zurückkam, bevor ein Weiteres bezogen wird.

Versionscodeberechnung (VercodeOperation)

Rechnung, die auf den Versionscode angewendet werden soll, der über den festgelegten UpdateCheckMode bezogen wird. %c wird durch den tatsächlichen Versionscode ersetzt und die gesamte Zeichenkette an Python’s eval-Funktion übergeben.

Insbesondere bei Apps hilfreich, die für verschiedene Binärschnittstellen kompiliert werden sollen, deren Versionscodes aber nicht immer auf Null enden. So können, zum Beispiel, durch Festlegen von VercodeOperation auf beispielsweise %c*10 + 4 bis zu vier verschiedene Versionen jeder Upstream-Version erstellt und Updates dafür verfolgt werden.

Aktualisierungsprüfung ignorieren (UpdateCheckIgnore)

Kann bei der Prüfung auf Aktualisierungen (über UpdateCheckMode) verwendet werden, um eine Zeichenfolge festzulegen, die bei Übereinstimmung mit einem Teil des Versionsnamens, dazu führt, dass diese Version ignoriert wird. Zum Beispiel kann „beta“ angegeben werden, damit Versionsbezeichnungen, die diesen Text beinhalten, ignoriert werden.

Name für Aktualisierungsprüfung (UpdateCheckName)

Kann bei der Prüfung auf Aktualisierungen (über UpdateCheckMode) verwendet werden, um den Paketnamen festzulegen, nach dem gesucht werden soll. Praktisch, wenn Apps einen festen Paketnamen besitzen, er sich aber für bestimmte App-Varianten programmatisch ändert, beispielsweise durch Anhängen von “.open” oder “.free” an den Paketnamen.

Es kann auch Ignore verwendet werden, um die Suche nach Paketnamen zu überspringen. Dies sollte nur in einigen bestimmten Fällen angewendet werden, zum Beispiel wenn die build.gradle-Datei der App keinen Paketnamen enthält.

Daten zur Aktualisierungsprüfung (UpdateCheckData)

Wird in Verbindung mit UpdateCheckMode für bestimmte Methoden verwendet.

Automatische Aktualisierungsmethode (AutoUpdateMode)

Dies bestimmt die Methode zur automatischen Erzeugung neuer Builds, wenn neue Releases verfügbar sind, d.h. das Hinzufügen einer neuen Build-Versionszeile zu den Metadaten. Dies geschieht in Verbindung mit der Funktionalität UpdateCheckMode - d.h. wenn ein Update von diesem erkannt wird, wird es auch von diesem verarbeitet.

Gültige Methoden sind:

  • None - Es erfolgt keine automatische Aktualisierung
  • Version - Identifiziert den Ziel-Commit (d.h. Tag) für den neuen Build basierend auf der angegebenen Versionsspezifikation, die einfach aus einem Text besteht, in dem %v und %c durch den gewünschten Versionsnamen bzw. Versionscode ersetzt werden.

    Zum Beispiel, wenn eine App immer einen Tag „2.7.2“ hat, der Version 2.7.2 entspricht würden Sie einfach „Version %v“ angeben. Wenn eine App immer einen Tag „ver_1234“ für eine Version mit dem Versionscode 1234 hat, würden Sie „Version ver_%c“ angeben.

    Zusätzlich kann dem Versionsnamen an dieser Stelle ein Suffix hinzugefügt werden, um den F-Droid-Build vom Original zu unterscheiden. Um das erste Beispiel oben anzusetzen, würden Sie als Suffix „Version +-fdroid %v“ - „-fdroid“ angeben.

Aktuelle Version (CurrentVersion)

Der Name der Version, die empfohlene Version. Es kann neuere Versionen der Anwendung geben (z.B. instabile Versionen) und es wird mit ziemlicher Sicherheit ältere Versionen geben. Diese sollte diejenige sein, die für den allgemeinen Gebrauch empfohlen wird. Für den Fall, dass es keinen Quellcode für die aktuelle Version gibt oder dass unfreie Bibliotheken verwendet werden, wäre dies idealerweise die neueste Version, die noch frei ist, obwohl es sinnvoll sein kann, die automatische Update-Prüfung beizubehalten - siehe NoSourceSince.

Dieses Feld wird normalerweise automatisch aktualisiert, siehe UpdateCheckMode.

Umwandlung zu (<marketversion>) in der XML-Datei (index.xml).

Aktueller Versionscode (CurrentVersionCode)

Der Versionscode entsprechend dem Feld CurrentVersion. Beide Felder müssen sachgemäß sein und zueinander passen, da es der aktuelle Versionscode ist, der gleichwohl von Android zur Bestimmung der Versionsreihenfolge und vom F-Droid-Client zur Ermittlung der empfohlenen Version verwendet wird.

Dieses Feld wird normalerweise automatisch aktualisiert - siehe UpdateCheckMode.

Wenn nicht angegeben, werden Clients die höchstmögliche Version empfehlen, als ob der CurrentVersionCode unendlich wäre.

Umwandlung zu (<marketvercode>) in der XML-Datei (index.xml).

Keine Quelle seit (NoSourceSince)

Für den Fall, dass der Quellcode zur vom Upstream gemeldeten CurrentVersion fehlt, oder dass unfreie Bestandteile eingeführt wurden, wird hiermit die erste Version bestimmt, mit der das Fehlen des Quellcodes begann. Apps, deren Quellcode nur für eine oder einige wenige Versionen fehlt, die aber für neuere einen Quelltext zur Verfügung stellen, werden hier nicht berücksichtigt - dieses Feld dient dazu, aufzuzeigen, welche Apps momentan keinen Quellcode veröffentlichen und seit wann sie das tun.

Überholte oder entfernte Felder

Beliefert (Provides)

Kommagetrennte Liste mit App-IDs, unter denen diese App ausgeliefert wird. Dieses Feld war immer schon ein Stub und wurde niemals für irgendetwas genutzt. Es wurde weder in index-v1.json noch in _.yml Metadaten-Dateien unterstützt.

Umwandlung zu (<provides>) in der XML-Datei (index.xml).