F-Droid

Compiler les références des métadonnées

Les informations utilisées par fdroid update pour compiler l’index public proviennent de plusieurs sources :

Ces fichiers de métadonnées sont des fichiers de texte simples et faciles à modifier, toujours nommées le même que le paquet, avec le type de fichier joint. Il y a beaucoup de champs disponibles pour ajouter de informations pour décrire les paquets et/ou les applications. Pour tous les champs comme AuthorName qui s’appliquent à toutes les publications d’un paquet/application, les champs utilisent CamelCase commenceant avec une lettre majuscule. Tous les autres champs utilisent camelCase avec une lettre minuscule, incluant les champs par-compilation, les champs localisés, etc.

Notez qu’en dépit du fait que les fichiers de métadonnées sont conçus pour être facilement lus et modifiés par les humains, ils sont aussi traités et écrits par plusieurs scriptes. Ils peuvent être automatiquement nettoyés quand nécessaire. La structure et les commentaires seront préservés correctement, mais l’ordre des champs sera normalisé. (Dans le cas où le fichier original était dans un ordre différent, les commentaires sont considérés à être liés au champ les suivant directement). En fait, vous pouvez normaliser tous les paquets dans un dépôt en utilisant une seule commande, sans changer le contenu fonctionnel, en exécutant :

fdroid rewritemeta

Ou simplement l’exécuter sur une application spécifique :

fdroid rewritemeta org.adaway

Format du balisage et des données

Les fichiers de métadonnées F-Droid sont écrits en YAML et ont une extension de fichier “.yml”. La structure de données la plus élevée est une “carte” ou un “dictionnaire”, composé de paires clé/valeur. Toutes les clés sont des chaînes. Certains types de données internes sont utilisés pour valeurs :

  • TYPE_BOOL - Soit vrai ou faux.
  • TYPE_BUILD - Entrées de construction, qui sont des cartes de paires clé/valeur.
  • TYPE_INT - Un entier au format décimal.
  • TYPE_LIST - Liste de chaînes.
  • TYPE_MULTILINE - Bloc texte de plusieurs lignes.
  • TYPE_SCRIPT - Une chaîne ou une liste de chaînes à exécuter en tant que script bash.
  • TYPE_STRING - Une chaîne.
  • TYPE_STRINGMAP - Une carte des cartes, les clés internes sont des locales BCP 47 et les valeurs sont du texte lisible par l’homme.

Le format canonique est YAML 1.2. Le processus de lecture des fichiers de métadonnées est plus tolérant et effectuera des conversions de type automatiques lorsque cela peut fournir une transformation fiable. fdroid rewritemeta affichera YAML 1.2, il ne conservera donc pas les valeurs d’origine telles qu’elles sont écrites, si elles ont été converties.

Champs

Les sections suivantes décrivent les champs reconnus dans le fichier.

Catégories

N’importe quel nombre de catégories pour y placer l’application. Il n’y a pas de liste fixe de catégories — le client et le site vont automatiquement montrer toutes les catégories qui existent dans n’importe quelle application. Cependant, si vos métadonnées sont destinées au dépôt principal de F-Droid, vous devrez utiliser une des catégories actuelles (Connectivité,Développement, Jeux,Graphiques,Internet,Monnaie,Multimédia,Navigation,Téléphone & SMS, Lecture,Science & Éducation,Sécurité,Sports & Santé,Système,Thèmes, Temps,Écriture), ou discuter d’une proposition pour en ajouter une nouvelle. Categories doit être une liste d’items, même s’il n’y en a qu’un.

Ceci est converti à (<categories>) dans le fichier XML (index.xml).

AuthorName (Nom de l’auteur)

Le nom de l’auteur, soit plein, abbrévié, ou pseudonyme. Si présent, il doit représenter le(s) nom(s) comme publiés par avec le code original, p. ex. dans leur fichier d’auteurs ou de copyright. Ceci peut être omis (ou laissé vide).

Avertissement : Ceci annule toute entrée AuthorName réglée dans le code source de l’application.

Ceci est converti à (<author>) dans le fichier XML (index.xml).

AuthorEmail (Courriel de l’auteur)

L’adresse courriel de/des auteur(s). Ceci peut être omis (ou laissé vide).

Avertissement : Ceci annule tous les entrées AuthorEmail réglées dans le code source de l’application.

Ceci est converti à (<email>) dans le fichier XML (index.xml).

AuthorWebSite (Site internet de l’auteur)

L’adresse du site internet de le(s) auteur(s). Peut être omis (ou laissé vide).

Avertissement : ceci annule toute les entrées AuthorWebSite réglées dans le code source de l’application.

License (Licence)

La licence en général pour l’application pour le fichier binaire que l’utilisateur peut installer. Les valeurs devraient correspondre aux identifiants courtes de la liste SPDX. Il peut y avoir seulement une des licences listées ici. S’il y en a plusieurs qui s’appliquent au code source, ce champ doit alors contenir la licence la moins restrictive sous lequel l’application entière peut être utilisé. Quand plusieurs licences sont combinées, cela veut normalement dire que la plus restrictive l’emporte.

Ce champ ne peut pas représenter la complexité des licences qui s’appliquent aux parties de l’application, ou les applications qui publient l’entièreté sous plus d’une license.

Ceci est converti à (<license>) dans le fichier XML (index.xml).

AutoName (Nom automatique)

Le nom de l’application retrouvé automatiquement dans le code source. Ceci est fait pour que fdroid checkupdates puisse mettre un nom familier dans la description dans les archivages créées quand une nouvelle mise à jour de l’application est trouvée. L’entrée AutoName est générée automatiquement quand fdroid checkupdates est executé et c’est seulement utilisé pour ces messages d’archivages.

Name (Nom)

Le titre de l’application, avec une phrase descriptive facultative. Ce champ annule toute les autres sources du nom de l’application, incluant de l’APK et des métadonnées localisées. Le paramètre Name est souvent non-nécessaire, puisque le nom correct de l’application est pris du fichier APK. Cependant, dans une situation où un APK contient un nom manquant ou mauvais, il peut être annulé avec cela. Notez que cela annule seulement le nom dans la liste d’applications présentée dans le client ; il ne change pas le nom ou l’étiquette de l’application dans le code source.

Limite de 50 caractères

Attention : cela remplace toutes les entrées Name/title définies dans le code source de l’application.

Ceci est converti à (<name>) dans le fichier XML (index.xml).

Site Web

L’URL pour le site Web de l’application. S’il n’y en a pas, ceci peut être omis (ou laissé vide).

Ceci est converti à (<web>) dans le fichier XML (index.xml).

SourceCode (Code source)

L’URL pour voir ou obtenir le code source de l’application. Ceci devrait être lisible par les humains. Le code source lisible par les machines est dans le champ Repo.

Ceci est converti à (<source>) dans le fichier XML (index.xml).

IssueTracker (Traqueur de problèmes)

L’URL pour le traqueur de problèmes de l’application. Facultatif, puisque certaines applications n’en ont pas.

Ceci est converti à (<tracker>) dans le fichier XML (index.xml).

Translation (Traduction)

L’URL pour le portail de traduction de l’application, ou du moins un guide. Facultatif, puisque certaines applications n’en ont pas.

Ceci est converti à (translation) dans le fichier JSON (index.json).

Changelog (Journal des changements)

L’URL pour le journal des changements de l’application. Facultatif, puisque certaines applications n’en ont pas.

Ceci est converti à (<changelog>) dans le fichier XML (index.xml).

L’URL pour faire un don au projet. Ceci devrait être la page de donation du projet s’il y en a un.

Il est possible d’utiliser un lien direct à PayPal ici, si c’est tout ce qui est disponible. Cependant, il est possible que le développeur ne soit pas au courant de ce lien et s’il change plus tard à un autre compte PayPal, ou le format de lien PayPal change, ça pourrait ne pas fonctionner. Il est toujours meilleur d’utiliser un lien que le développeur rend explicitement public, plutôt que quelque chose qui est généré automatiquement.

Ceci est converti à (<donate>) dans le fichier XML (index.xml).

FlattrID

L’identifiant Flattr (https://flattr.com), s’il y en a un. Ceci devrait être un identifiant numérique, pour que (par exemple) https://flattr.com/thing/xxxx mène directement à la page de donation du projet.

Ceci est converti à (<flattr>) dans le fichier XML (index.xml).

Liberapay

Le nom d’utilisateur ou nom de groupe Liberapay (https://liberapay.com), s’il en a un. Ceci devrait être alphanumérique, pour que (par exemple) https://liberapay.com/xxxxx dirige vers votre page de compte. Ceci était LiberapayID auparavant, qui était un identifiant numérique trouvé du site Liberapay en ajoutant /public.json derrière votre page d’équipe.

Ceci est converti à (<liberapay>) dans le fichier XML (index.xml).

OpenCollective

Le nom d’utilisateur ou nom de groupe OpenCollective (https://opencollective.com), s’il en a un. Ceci devrait être un nom alphanumérique, pour que (par exemple) https://opencollective.com/xxxxx mène à votre page de compte.

Bitcoin

Une adresse bitcoin pour faire un don au projet.

Ceci est converti à (<bitcoin>) dans le fichier XML (index.xml).

Litecoin

Une adresse litecoin pour faire un don au projet.

Ceci est converti à (<litecoin>) dans le fichier XML (index.xml).

Summary (Résumé)

Un bref résumé de ce qu’est l’application. Le Résumé est utilisé dans les vues en liste et en aperçus des applications sur F-Droid, et en tant que sous-titre dans d’autres vues.

Limite de 80 caractères

Attention : cela remplace toutes les entrées Summary alias « description courte » définies dans le code source de l’application.

Cela est converti en (<summary>) dans le fichier XML (index.xml).

Description

Une description complète de l’application, pertinente à la version actuelle. Ceci peut être sur plusieurs lignes (qui ont un maximum de 80 caractères) et elle est terminée par une ligne contenant un seul .’.

Le format de la description suit les conventions établies qui fonctionnent sur plusieurs magasins d’applications :

  • Les formats de base HTML peuvent être utilisés.
  • Les retours à la ligne seront préservés.
  • Les liens à d’autres paquets sur f-droid.org seront cliquables sur le site, d’autres liens seront du texte ordinaire.

Il peut être utile de noter les informations relatives à la mise à jour d’une version antérieure ; si l’application contient des pré-compilations construites par les développeurs en amont ou si des éléments non-libres ont été supprimés ; si l’application est en développement rapide ou si la dernière version est en retard par rapport à la version actuelle ; si l’application supporte plusieurs architectures ou si une trousse SDK maximum est spécifiée (ces informations n’étant pas enregistrées dans l’index).

Limite de 4000 caractères

Warning : cela remplace toutes les entrées de Description définies dans le code source de l’appli.

Cela est converti en (<desc>) dans le fichier XML (index.xml).

MaintainerNotes (Notes du responsable)

Ceci est un champ multi-ligne utilisant les mêmes règles et la même syntaxe que la description. Il sert à enregistrer des notes pour les mainteneurs de F-Droid afin de les aider à maintenir et à mettre à jour l’application dans le dépot.

Cette information est aussi publiée sur le wiki.

RepoType (type de dépôt)

Le type de dépôt — pour une construction automatique depuis la source. Si ce n’est pas spécifié, la construction automatique est désactivée pour cette application. Les valeurs possibles sont :

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

Repo (dépôt)

L’emplacement du dépôt. Souvent un URL git : ou svn : par exemple.

L’option git-svn connecte à un dépôt SVN et vous spécifiez l’URL de la même façon, mais git est utilisé en backend. Ceci est préférable pour des raisons de performance, mais aussi car une copie locale de toute l’historique est disponible dans le cas ou un dépôt avec le code source original disparait. (Ça arrive !). Pour utiliser Tags en tant que UpdateCheckMode pour ce type de VCS, l’URL doit avoir l’ensemble d’arguments spécial tags=. De même, si vous voulez utiliser le schéma RepoManifest/branche, vous voudriez spécifier branches= aussi. Finalement, trunk= peut aussi être ajouté. Tous ces arguments spéciaux seront passés au « git svn » en ordre et leurs valeurs doivent être des chemins relatives au dossier racine du dépôt svn. Voici un exmple d’un URL complexe de Repo git-svn : http ://svn.code.sf.net/p/project/code/svn ;trunk=trunk ;tags=tags ;branches=branches

Si le RepoType est srclib, vous devez alors spécifier le nom du fichier .yml lui correspondant. Par exemple, si srclibs/FooBar.yml existe et vous voulez utiliser ce srclib, vous devez alors régler Repo à FooBar.

Binaries (Fichiers binaires)

L’emplacement des fichiers binaires utilisés dans le procédé de vérification.

­Si spécifié, F-Droid vérifiera les données de sortie d’un fichier APK d’une compilation contre celui spécifié, Vous pouvez utiliser %v et %c pour remplacer le nom de version et le code de version. Pour verifier le client F-Droid lui-même vous pouvez utiliser : Binaries : https ://f-droid.org/repo/org.fdroid.fdroid_%c.apk

F-Droid utilisera les fichiers binaires d’en amont si la vérification réussit.

Builds (Compilations)

N’importe quel nombre de sous-entrées peuvent être présentes, chacun specifiant une version à compiler automatiquement à partir du code source. Par exemple :

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

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

versionName : xxx (Nom de version)

versionCode : yyy (code de version)

Specifie à la version de compilation xxx, qui a un code de version yyy.

commit: xxx

­: Le paramètre commit spécifie le tag, l’archivage ou le nombre de révision duquel on peut le compiler dans le dépôt de code source.

En plus des trois paramètres obligatoires décrits au-dessus, plus de paramètres peuvent être ajoutés (en format nom : valeur) pour appliquer plus de configuration à la compilation. Ceux-ci sont (à peu près en ordre d’application) :

disable: <message>

Désactive cette compilation, en donnant une raison pourquoi. (pour la compatibilité vers l’arrière, ceci peut aussi être fait en commenceant l’identifiant d’archivage avec ‘!’)

L’utilité de cette fonction est de permettre des publications non-compilables (p. ex. la source n’est pas publiée) d’être marquées, pour que les scriptes ne génèrent pas des messages répétés à propos d’eux. (Et aussi pour enregistrer l’information pour la revue plus tard). Si un APK a déjà été compilé, le désactiver fait qu’il est supprimé quand fdroid update est exécuté ; cela est la procédure si jamais une version doit être remplacée.

subdir: <chemin>

Spécifie qu’on doit compiler d’un sous-dossier du code source. C’est le dossier où les programmes de compilation sont exécutés.

submodules: true

Utiliser seulement si le projet (git seulement) a des sous-modules - cause l’exécution de git submodule update --init --recursive après le clonage du code source. Les sous-modules sont réinitialisés et nettoyés comme le dépôt d’applications principal lui-même avant chaque compilation.

sudo: xxxx

Spécifie un scripte qui est executé avec sudo bash -x -c "xxxx" dans le l’invité de VM buildserver. Ce scripte est executé avec les privilèges de racine, mais l’état sera réinitialisé après chaque compilation. La vaste majorité d’applications est compilé avec l’environnement de base standard Debian/stable. Ceci est utile pour configuret le buildserver pour les compilations complexes qui ont besoin de choses très spécifiques qui ne sont pas appropriés à installer pour toutes les compilations, ou qui auront un conflit avec d’autres compilations.

timeout: <secondes>

Limite de temps pour cette compilation (en secondes). Après ce temps, la VM buildserver est arrêté par force. Le defaut est de 7200 secondes (2 heures) ; 0 signifie aucune limite.

Limitation est appliqué seulement en mode serveur, p. ex. quand fdroid build est exécuté avec l’option --server.

init: xxxx

Comme ‘prebuild’, mais ça exécute sur le code source AVANT le déroulement de n’importe quel autre traitement.

Vous pouvez utiliser $$SDK$$ et $$NDK$$ pour substitutuer les chemins aux dossiers du SDK et NDK Android respectivement Les variables suivantes sont disponibles par compilation de cette façon : $$VERSION$$, $$VERCODE$$ et $$COMMIT$$.

Cela s’exécute dans subdir: si défini.

oldsdkloc: true

L’emplacement du SDK dans le dépôt est en un vieil format, ou build.xml s’attend à cela. Le « nouveau » format est sdk.dir tandis que le TRÈS VIEUX format est sdk-location. Typiquement, si vous avez un message qui ressemble à : “com.android.ant.SetupTask cannot be found” quand vous essayez de compiler, activez cette option.

target: <cible>

Spécifie un SDK cible particulier de compilation, ce qui annule la valeur défininie dans le code source d’origine. Ceci a des effets différents dépendant de quelle système de compilation est utilisée — cette option affecte en ce moment les projets Ant, Maven et Gradle. Notez que cela ne change pas le SDK cible dans AndroidManifest.xml, ce qui détermine le niveau des fonctions qui peuvent être incluses dans la compilation.

Dans le cas d’un projet Ant, il modifie project.properties de l’application et possiblement les sous-projets. Ceci causera probablement la réécriture complete de build.xml, ce qui est correct si c’est un fichier Android « standard » ou si elle n’existe pas, mais ce n’est pas une bonne idée si c’est personalisé en profondeur.

androidupdate: <auto/dirs>

Par défaut, « android update » est utilisé dans les compilations Ant pour générer ou mettre à jour le projet et tous les projets référencés. Spécifier androidupdate: no annule cela. Notez que cela n’est pas utile dans les compilations qui n’utilisent pas Ant.

La valeur par défaut est ‘auto’, qui utilise récursivement les chemins dans project.properties pour trouver tous les sous-projets à mettre à jour.

Sinon, la valeur peut être une liste séparée par des virgules de dossiers dans lequel on exécute ‘android update’ relativement au dossier d’application.

encoding: xxxx

Ajoute une propriété java.encoding à local.properties avec la valeur donnée. Généralement la valeur sera ‘utf-8’. Ceci est vu par les règles ant du SDK, puis ça force le compilateur Java à interpréter les fichiers de code source avec cet encodage. Si vous avez des avertissement lors de la compilation à propos des encodages de caractères, vous avez probablement besoin de cela.

forceversion: true

Si spécifié, la version de paquet dans AndroidManifest.xml est remplacé avec le nom de version pour la compilation comme spécifié dans les métadonnées.

Ceci est utile pour les cas où un dépôt d’en amont ne le met pas à jour pour un tag spécifique ; pour compiler une révision quelconque ; pour rendre apparent que la version diffère significativement d’en amont ; ou pour rendre apparent quelle architecture ou platforme sur lequel l’APK est fait pour exécuter.

forcevercode: true

Si spécifié, le code de version de paquet dans AndroidManifest.xml est remplacé avec le code de version pour la compilation. Voir aussi forceversion.

binary: URL

L’emplacement du fichier binaire utilisé dans le procédé de vérification pour cette compilation.

­Si spécifié, F-Droid vérifiera les données de sortie d’un fichier APK d’une compilation contre celui spécifié. Vous pouvez utiliser %v et %c pour remplacer le nom de version et le code de version. Pour vérifier le client F-Droid lui-même vous pouvez utiliser : binary : https ://f-droid.org/repo/org.fdroid.fdroid_%c.apk

F-Droid utilisera le fichier binaire d’en amont si la vérification réussit.

rm : <chemin1>[,<chemin2>,...]

Spécifie les chemins relatifs des fichiers ou dossiers à supprimer avant que la compilation commence. Les chemins sont relatifs à la base du dossier de compilation — p. ex. la racine de la structure de dossier pris du dépôt d’origine — et pas nécessairement au dossier qui contient AndroidManifest.xml.

Plusieurs fichiers/dossiers peuvent être spécifiés en les séparant avec ‘,’. Les dossiers seront supprimés récursivement.

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

Liste séparée avec des virgules de bibliothèques extérieures (fichiers jar) du bibliothèque build/extlib, qui sera placé dans le dossier libs du projet.

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

Liste séparée de virgules de bibliothèques de source ou de projets Android. Chaque item est sous la forme nom@rév où nom est la source de bibliothèque prédéfinie et rév est la révision ou tag à utiliser dans le système de contrôle de source respective.

Pour les projets Ant, vous pouvez facultativement ajouter un nombre avec deux-points au début d’un objet srclib pour le placer automatiquement dans project.properties en tant que bibliothèque sous le numéro spécifié. Par exemple, si vous spécifiez 1:libquelconque@1.0, F-Droid va automatiquement faire l’équivalent de l’ancien procédé prebuild: echo "android.library.reference.1=$$libquelconque$$" >> project.properties.

Chaque srclib a un fichier de métadonnées sous srclibs/ dans le dossier de dépôt et le code source est entreposé dans build/srclib/. RepoType et Repo sont spécifiés dans la même façon que pour les applications ; Subdir : peut être une liste séparée de virgules, pour quand les dossiers sont renommés d’en amont ; Update Projet : met à jour les projets dans le dossier de travail et un niveau dessous ; Prepare : peut être utilisé pour n’importe quel type de préparation : en particulier si vous avez besoin de mettre à jour le projet avec une cible particulière. Vous pouvez alors utiliser $$name$$ dans la commande init/prebuild/build pour substituer le chemin absolu au dossier de bibliothèque.

Les srclibs sont utilisées lorsque le code en amont utilise des fichiers jar ou pour tirer les dépendances depuis des dépôts non fiables. Le sous-module git est un meilleur choix parce que les srclibs ne peuvent pas être mises à jour automatiquement.

patch: x

Applique le(s) correctif(s). « x » est les noms des fichiers (séparés par une virgule) dans un répertoire situé sous les métadonnées, avec le même nom que le fichier de métadonnées sans l’extension. Ces correctifs sont appliqués un par un au code.

prebuild: xxxx

Spécifie une commande shell (ou des commandes – séparés par &&) à exécuter avant la compilation. Une barre oblique inversée (antislash) peut être utilisée comme caractère d’échappement pour insérer des virgules littérales, ou comme dernier caractère d’une ligne pour joindre cette ligne avec la suite. Elle n’a pas de signification particulière dans d’autres contextes, en particulié les barres obliques inversées littérales ne doivent pas être des caractères d’échappements.

La commande exécutée en utilisant bash.

Notez que rien ne doit être compilé pendant cette étape de précompilation, l’analyse du code et la compilation de l’archive tar source, par exemple, se déroule après cette étape. Pour des actions personnalisées qui compilent des éléments ou produisent des fichiers binaires, utilisez plutôt « compilation ».

Vous pouvez utiliser $$name$$ pour remplacer le chemin d’accès vers un srclib référencé — regardez le répertoire srclib pour plus de détails.

Vous pouvez utiliser $$SDK$$ et $$NDK$$ pour remplacer respectivement les chemins d’accès vers les dossiers du SDK et du NDK d’Android, par exemple quand vous avez besoin d’exécuter android update project explicitement. Ces variables suivantes sont aussi disponible par compilation : $$VERSION$$, $$VERCODE$$ et $$COMMIT$$.

Cela s’exécute dans subdir: si défini.

scanignore: <chemin1>[,<chemin2>,…]

Permet d’exclure des fichiers ou des dossiers de l’analyse. A n’utiliser que si il y a des bonnes raisons et sûrement accompagné d’un commentaire qui explique en quoi ces exclusions sont nécessaires.

Lors de l’analyse des problèmes dans l’arbre source, les fichiers contenus dans les dossiers relatifs indiqués ici sont ignorés.

scandelete: <chemin1>[,<chemin2>,…]

Lors de l’exécution du processus d’analyse, tous les fichiers qui déclenchent des erreurs — comme les fichiers binaires — seront supprimés. Il agit comme scanignore, mais au lieu d’ignorer les fichiers, il les enlève.

Utile lorsque le dépôt du code source contient des fichiers binaires ou d’autres fichiers non désirés qui ne sont pas requis pour la compilation. Il est plus facile d’utiliser scandelete au lieu de les supprimer manuellement avec rm.

build: xxxx

Fonctionne de la même manière que « prebuild », mais est utilisé durant la phase de compilation (néanmoins avant la compilation principale de Ant/Maven). Utilisation uniquement pour les actions qui font la réelle compilation. Toute préparation du code source doit être fait en utilisant « init » ou « »prebuild ».

Les compilations qui ont lieu avant build seront ignorées, étant donné que Ant, mvn ou gradle seront exécutés pour nettoyer l’environment de la compilation juste avant que build (ou que la version final) soit exécuté.

Vous pouvez utiliser $$SDK$$ et $$NDK$$ pour remplacer respectivement les chemins d’accès vers le SDK et le NDK d’Android. Les variables de compilation suivantes sont aussi disponible : $$VERSION$$, $$VERCODE$$ et $$COMMIT$$.

Cela s’exécute dans subdir: si défini.

buildjni: [yes|no|<dir list (liste de dossiers)>]

Permet de compiler le code natif par le script ndk-build avant de faire la compilation principale de Ant. La valeur peut être une liste de dossiers relatif au dossier principal de l’application dans lequel est exécuté ndk-build, ou « yes » qui correspond à « . ». Utiliser une liste explicite peut être utile pour compiler des projets à plusieurs composants.

Les processus de compilation et d’analyse vont se plaindre (refuser de compiler) si ce paramètre n’est pas défini, sauf si un dossier jni est présent. Si le code natif est en train d’être compiler par d’autres moyens comme une tâche Gradle, vous pouvez indiquer no ici pour éviter ça. Cependant, si le code natif n’est pas nécessaire ou pas utilisé, supprimez plutôt le dossier (par exemple en utilisant rm: jni). L’utilisation de buildjni: no lorsque le code jni n’est ni utilisé ni compilé va donner lieu à une erreur indiquant que les bibliothèques natives étaient attendu par le paquet résultant.

ndk: <version>

La version du NDK utilisée pour compiler. La valeur est la version du NDK en une chaîne de caractères dans l’un des deux schéma de version officiel, par exemple r21e ou 21.4.7075529. Le NDK r10e ou ultérieur est supporté. La valeur peut aussi être une liste de chaînes de version, cela installera toutes les versions de la liste. La variable d’environnement ANDROID_SDK_ROOT serait alors mis à la première valeur de la liste.

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

Compiler avec Gradle plutôt que Ant, spécifiant quelles variantes (flavours) utiliser. Les variantes sont sensibles à la casse puisque le chemin d’accès vers l’APK de sortie l’est aussi.

Si une seule saveur est donnée et que c’est ‘oui’, aucune saveur ne sera utilisée. Notez que pour les projets avec des saveurs, vous devez précisez au moins une saveur valide car ‘oui’ les construira toutes séparément

maven: yes[@<dossier>]

Compiler avec Maven au lieu de Ant. Un @<dir> supplémentaire dit à F-Droid d’exécuter Maven dans ce sous-répertoire. Parfois il est nécessaire d’utiliser @.. pour que l’installation se passe correctement.

preassemble: <tâche1>[,<tâche2>,…]

Liste des tâches Gradle à exécuter avant la tâche d’assemblage dans une compilation de projet Gradle

gradleprops: <proposition1>[,<proposition2>, …]

Liste des propriétés Gradle à lui faire passer via la ligne de commande. Une propriété peut être de l’une des formes suivantes, foo ou key=value.

Par exemple : gradleprops=enableFoo,someSetting=bar va aboutir à gradle -PenableFoo -PsomeSetting=bar.

antcommands: <cible1>[, <cible2>, …]

Spécifie un ensemble de commandes Ant (cible) de substitution à la place du « release » par défaut. On ne peut pas lui indiquer de marqueurs (flags) tel que le chemin vers un build.xml.

output: glob/to/output.apk

Spécifie un chemin global où devrait se trouver l’APK non signé issue de la compilation. Ceci peut être utilisé avec des méthodes de compilation comme gradle: yes ou maven: yes. Si aucune méthode n’est précisée la compilation est manuelle. Vous devrez exécuter vos commandes de compilation tel que make dans build.

Cela s’exécute dans subdir: si défini.

postbuild: xxxx

Fonctionne de la même manière que « prebuild », mais est utilisé après la phase de compilation (la compilation principale de Ant/Maven). Son utilisation est réservée aux actions qui réalisent des post-traitements sur le résultat de la compilation.

Vous pouvez utiliser $$name$$ pour remplacer le chemin d’accès vers un srclib référencé — regardez le répertoire srclib pour plus de détails.

Vous pouvez utiliser $$SDK$$ et $$NDK$$ pour substitutuer les chemins aux dossiers du SDK et NDK Android respectivement Les variables suivantes sont disponibles par compilation de cette façon : $$VERSION$$, $$VERCODE$$ et $$COMMIT$$.

Le chemin vers l’APK résultant est disponible avec $$OUT$$.

Cela s’exécute dans subdir: si défini.

novcheck: true

Ne vérifie pas que le nom de la version et le code de l’APK resultant sont corrects en regardant le produit de la compilation — suppose que les métadonnées sont correctes. Ceci enlève un niveau utile de vérification, et ne devrait être utilisé seulement si les valeurs ne peuvent pas être extraites.

antifeatures: <antifonction1>[,<antifonction2>, …]

Liste d’antifonctions pour cette version particulière. Elles sont décrites dans Antifonctions.

AllowedAPKSigningKeys(clés autorisées à signer les APK)

Lorsque les dépôts binaires automatiques sont marqués fdroid update, c’est généralement facile de trouver la clé de signature pour les APK. AllowedAPKSigningKeys laisse l’opérateur du dépôt entrer la clé de signature attendu, alors fdroid update va vérifier que les APK sont signés par l’une de ces clés. Les APK dont ce n’est pas cas ne seront pas inclue dans le dépôt. Si fdroid update --delete-unknown est spécifié, les APK qui ne correspondent pas seront supprimés. Ensuite un processus automatique peut être utilisé pour télécharger les nouvelles APK dans le dépôt, et seront seulement inclue s’ils ont une bonne signature connue. La valeur est en hexadécimal minuscule de empreinte digitale SHA-256 du certificat de la signature. Ceci peut être traité avec :

apksigner verify --print-certs exemple.apk | grep SHA-256

Antifonctions

Ceci est optionnel — s’il est présent, il contient une liste des valeurs suivantes separées par des virgules, décrivant les antifonctions que l’application possède. Ça peut être bien de mentionner dans la description les raisons de ces antifonctions :

  • « Ads » — l’application contient des publicitées.
  • « Tracking » — les données de l’utilisateur ou de son activité sont traquées ou fuitées, par défaut. Vrai (True) si l’application ou la fonctionnalité ne peut pas être utilisé sans collecter et partager de telles données, ou fait des demandes à un service de collecte de données (peu importe que service soit libre). Par exemple, le téléchargement de la météo, de cartes, d’avatars, etc. basé sur l’activité (hébergement de données et services de livraisons), ou la mise en ligne des journaux de plantages, etc.
  • « NonFreeNet » — l’application contient une fonctionnalité qui promeut ou dépend d’un service réseau non libre qui est impossible, ou difficile à remplacer. Le remplacement demande de changer l’application ou le service. Cette antifonction ne s’appliquerait pas s’il existerait une configuration simple qui permettrait que l’application pointe vers une instance de substitution, disponible publiquement, auto-hébergeable et libre.
  • « NonFreeAdd » — l’application promeut des extensions non libres, de sorte que l’application est en faite une publicité pour d’autres logiciels non libre.
  • « NonFreeDep » — l’application dépend d’une application non libre (par exemple Google Maps) — i.e. elle a besoin que l’application non libre soit installée, mais elle ne l’inclue pas.
  • ‘NSFW’ - l’application possède du contenu que l’utilisateur ne souhaite pas rendre public ou visible partout, provient de “Non Sécurisé”.
  • ‘UpstreamNonFree’ - l’application est ou dépend d’un logiciel non libre. Cela ne signifie pas qu’un logiciel non libre est inclus dans l’application : très probablement, il a été corrigé de manière à supprimer le code non libre. De ce fait, des fonctionnalités peuvent être manquantes.
  • ‘NonFreeAssets’ - l’application contient et utilise des ressources non libres. Applications utilisant des illustrations - images, sons, musique, etc. - sous une licence qui limite l’utilisation commerciale ou la création d’œuvres dérivées (par exemple, toute licence Creative Commons avec un “Non-Commercial” (NC) ou “No Dérivés” (restriction ND)).
  • ‘KnownVuln’ - Application présentant des failles de sécurité connues.
  • ‘ApplicationDebuggable’ - Le fichier APK est compilé pour le débogage (application-debuggable), ce qui rend normalement l’application inadaptée aux utilisateurs non techniques.
  • ‘NoSourceSince’ - La source en amont pour cette application n’est plus disponible. L’application est, soit devenue commerciale, soit le repo a été abandonné, soit déplacée vers un emplacement inconnu pour nous. Pas de mise à jour à moins que la source ne réapparaisse.

Ceci est transformé en (<antifeatures>) dans le fichier XML (index.xml).

Disabled (désactivé)

Si ce champ est présent, l’application n’est pas placée dans l’index public. Cela permet de conserver les métadonnées pendant que la publication d’une application est temporairement désactivée. La valeur doit être une description de la raison pour laquelle l’application est désactivée. Aucun fichier APK ou archive de code source n’est supprimé : pour purger un fichier APK, consultez la section Version de build ou supprimez-le manuellement pour les builds de développeur. Le champ est donc utilisé lorsqu’une application a perdu son utilité mais l’archive source est conservée.

RequiresRoot (superutilisateur nécessaire)

Définissez ce champ facultatif sur “true” si l’utilisation de l’application nécessite des privilèges root. Cela permet au client de filtrer selon les choix de l’utilisateur. Que root soit obligatoire ou non, il est bon de décrire, dans le paragraphe description, les conditions dans lesquelles root peut être demandé et à quelles fins.

Ceci est transformé en (<requirements>) dans le fichier XML (index.xml).

ArchivePolicy (Politique d’archive)

Détermine la politique de déplacement des anciennes versions d’une application vers le référentiel d’archives, si celui-ci est configuré. Ce paramètre peut-être écrasé par une stratégie spécifique à l’application.

La version spécifiée via CurrentVersionCode est toujours considérée comme la version la plus récente lors du choix des versions à mettre dans l’archive. Cela signifie que lorsque ArchivePolicy est défini sur 1 seul l’APK correspondant à CVC est conservé (ce n’est pas nécessairement l’APK avec la version de code la plus élevée).

Actuellement, le seul format pris en charge est n où n est le nombre de versions à conserver, par défaut 3. Pour les applications avec une liste de VercodeOperation la valeur par défaut est calculée comme 3 x nombre d'opérations, par ex. pour une application à deux opérations, pour deux ABI, 6 versions seront conservées.

UpdateCheckMode (Mode de vérification des mises à jour)

Définit la méthode utilisée pour déterminer quand de nouvelles versions sont disponibles - en d’autres terme : définit la mise à jour des champs CurrentVersion et CurrentVersionCode dans les métadonnées du processus fdroid checkupdates.

Les modes valides sont :

  • None - Aucune vérification n’est effectuée car il n’existe aucun moyen automatisé approprié de le faire. Les mises à jour doivent être vérifiées manuellement. Utilisez ceci, lors du déploiement de versions instables ou corrigées ; lorsque les builds sont effectuées dans un répertoire différent de celui où se trouve AndroidManifest.xml ; si les développeurs utilisent le système de construction Gradle et stockent les informations de version dans un fichier séparé ; si les développeurs créent une nouvelle branche pour chaque version et ne créent pas de balises ; ou si vous avez modifié le nom du package ou la logique du code de version.
  • Static - Aucune vérification n’est effectuée - soit le développement a cessé, soit de nouvelles versions ne sont pas souhaitées. Cette méthode est aussi utilisée lorsqu’il n’y a aucune autre méthode de vérification disponible et que le développeur en amont doit nous tenir au courant des nouvelles versions.

  • RepoManifest - Lors de la validation la plus récente, les fichiers AndroidManifest.xml et build.gradle sont recherchés dans le répertoire où ils ont été trouvés dans la version la plus récente. La pertinence de cette méthode dépend des développeurs de l’application. Vous ne devez pas spécifier cette méthode à moins d’être sûr qu’elle est appropriée. Par exemple, certains développeurs augmentent la version au début du développement plutôt qu’au moment de la publication. Il renverra une erreur si AndroidManifest.xml a été déplacé vers un autre répertoire ou si le nom du package a changé. La version actuelle qu’il donne peut ne pas être exacte, car toutes les versions ne sont pas aptes à être publiées. Par conséquent, avant de construire, il est souvent nécessaire de vérifier si la version actuelle a été publiée quelque part par les développeurs en amont, en vérifiant soit les APK qu’ils distribuent, soit les balises dans le référentiel de code source.

    fonctionne actuellement pour chaque type de référentiel à des degrés différents, sauf le type de référentiel srclib. Pour les types de dépôt git, git-svn et hg, vous pouvez utiliser “RepoManifest/yourbranch” comme UpdateCheckMode afin que “yourbranch” soit la branche utilisée à la place de celle par défaut. Les valeurs par défaut sont “master” pour git, “default” pour hg et none pour git-svn (il reste dans la même branche). D’autre part, le support de branche n’a pas été encore implémenté dans bzr et svn, mais RepoManifest peut encore être utilisé sans elle.

  • Tags - Les fichiers AndroidManifest.xml et build.gradle dans toutes les révisions étiquetées du dépôt source sont vérifiés, à la recherche du code de version le plus élevé. La pertinence de cette méthode dépend du processus de développement utilisé par les développeurs de l’application. Vous ne devez pas spécifier cette méthode à moins d’être sûr qu’elle est appropriée. Il ne doit pas être utilisé si les développeurs aiment étiqueter les versions instables ou sont connus pour oublier de étiqueter les versions. Comme RepoManifest, il ne renverra pas la valeur correcte si le répertoire contenant le AndroidManifest.xml a été déplacé. Malgré ces mises en garde, c’est souvent le UpdateCheckMode préféré.

    Ne fonctionne actuellement que pour les dépôts git, hg, bzr et git-svn. Dans ce dernier cas, l’URL du dépôt doit contenir le chemin vers les tronc et balises, sinon aucune balise ne sera trouvée.

    Ajoutez éventuellement un motif regex à la fin - séparé par un espace - pour ne vérifier que les balises correspondant au dit modèle. Utile quand les applications nomment les versions non publiées telles que X.X-alpha, afin que vous puissiez filtrer avec quelque chose comme .*[0-9]$ qui nécessite des noms de balises terminant par un chiffre. Exemple : UpdateCheckMode: Tags .*[0-9]$

    UpdateCheckData Peut être optionnellement spécifié pour extraire le code de version et le nom des fichiers du dépôt spécifié (au lieu de vous fier aux valeurs par défaut utilisé pour correspondre autrement, qui dans la plupart des cas est build.gradle ou AndroidManifest.xml).

  • HTTP - Les requêtes HTTP sont utilisées pour déterminer le code et le nom de la version actuelle . Ceci est contrôlé par le champ UpdateCheckData, de forme urlcode|excode|urlver|exver.

    Premièrement si urlcode n’est pas vide, le document de cette URL est récupéré et mis en correspondance avec l’expression régulière excode, avec le premier groupe devenant le code de version.

    Deuxièmement, si urlver n’est pas vide, le document de cette URL est récupéré et mis en correspondance avec l’expression régulière exver, avec le premier groupe devenant le nom de la version. Le champ urlver peut être défini simplement sur ‘.’ qui dit d’utiliser le même document retourné pour nouveau le code de version, plutôt que d’en récupérer un autre.

VercodeOperation

L’opération à appliquer au code de version obtenu par le UpdateCheckMode défini. %c sera remplacé par le code de version réel, et la chaîne entière sera passée à la fonction eval de python.

Especially useful with apps that we want to compile for different ABIs, but whose vercodes don’t always have trailing zeros. For example, with multiple VercodeOperation we can track updates and build up to four different versions of every upstream version, say for 4 architectures:

VercodeOperation:
  - 100 * %c + 1
  - 100 * %c + 2
  - 100 * %c + 3
  - 100 * %c + 4

So 4 build blocks are copied from above and added as an update with their vercode calculated by doing each math operation.

UpdateCheckIgnore (Ignorer la vérification des mises à jour)

Peut être utilisé lors de la vérification des mises à jour (via UpdateCheckMode) pour spécifier une expression régulière qui, si elle correspond au nom de la version, entraîne l’ignorance de cette version. Par exemple, ‘beta’ peut être spécifié pour ignorer les noms de version l’incluant.

Exclusivement disponible avec UpdateCheckMode HTTP.

UpdateCheckName (Nom pour la vérification de mise à jour)

Peut être utilisé lors de la recherche de mises à jour (via UpdateCheckMode) pour spécifier le nom du paquet à rechercher. Utile lorsque les applications ont un nom de package statique mais qu’il est programmé pour changer dans certaines versions d’application, par exemple en ajoutant « .open » ou « .free » à la fin du nom du paquet.

Vous pouvez utiliser Ignore pour ignorer la recherche de nom de paquet. Cela ne doit être utilisé que dans certains cas spécifiques, par exemple si le fichier build.gradle de l’application ne contient pas le nom du paquet.

UpdateCheckData (Données pour la vérification des mises à jour)

Utilisé conjointement avec UpdateCheckMode Tags ou HTTP.

UpdateCheckData : <vercode-location>|<RegEx-for-versionCode>|<versionName-location>|<RegEx-for-versionName>
  • vercode-location - URL (avec UpdateCheckMode : HTTP) ou chemin/fichier relatif à la racine du dépôt, laissez vide pour vérifier le nom de balise à la place (avec UpdateCheckMode : Tags).
  • RegEx-for-versionCode - Expression régulière correspondant à versionCode.
  • versionName-location - Identique à vercode-location uniquement pour versionName. Un . signifie prendre l’emplacement du vercode, laisser vide pour vérifier le nom de balise à la place (exclusivement avec UpdateCheckMode: Tags).
  • RegEx-for-versionName - Similaire à RegEx-for-versionCode, pour versionName.
  • Pour le moment, l’opérateur barre verticale n’est pas pris en charge pour les expressions régulières.

Examples for UpdateCheckMode: Tags:

  • Flutter app with the pubspec.yaml in the repo root: pubspec.yaml|version:\s.+\+(\d+)|.|version:\s(.+)\+
  • Use the git tag as version name: app/build.gradle|versionCode\s(\d+)||
  • Optionally a regex to extract the version name from the tag can be specified: app/build.gradle|versionCode\s(\d+)||Android-([\d.]+)
  • If no file for the version code was specified, code and name can be extracted from the tag: '|\+(\d+)||Android-([\d.]+)'
  • Note: Be sure to use single quotes around the entire value if you leave vercode-location empty: UpdateCheckData: '|\+(\d+)||Android-([\d.]+)'

Exemple pour UpdateCheckMode: HTTP:

  • https://foo/version.json|"version_code":.*"(.*)"|.|"version_name":.*\"(.*)\",
  • https://foo/version_fdroid.txt|versionCode=(.*)|.|versionName=(.*)

AutoUpdateMode (Mode de mise à jour automatique)

This determines the method used for auto-generating new builds when new releases are available - in other words, adding a new Build Version line to the metadata. This happens in conjunction with the UpdateCheckMode functionality - i.e. when an update is detected by that, it is also processed by this.

Les modes valides sont :

  • None - Auto-updating is disabled

  • Version - Auto-updating is enabled.

    If UpdateCheckMode is set to Tags, this should be set to Version without any pattern. The checked tag is used directly.

    If UpdateCheckMode is set to HTTP, a pattern should be added after the Version. The pattern is used to generate a value (tag name) used for the commit: property of new build blocks. It is simply text in which %v and %c are replaced with the required version name and version code respectively. The resulting string must match an existing tag in the app’s repo, which then will be used by F-Droid to build the corresponding version.

    For example, if an app always has a tag 2.7.2 corresponding to version 2.7.2, you would simply specify Version %v. If an app always has a tag ver_1234 for a version with version code 1234, you would specify Version ver_%c.

    Continuing the first example above, you would specify that as Version +-fdroid %v - -fdroid is the suffix F-Droid will then append to the versionName specified in e.g. build.gradle when building the APK.

    Additionally, a suffix can be added to the version name at this stage, to differentiate F-Droid’s build from the original. Continuing the first example above, you would specify that as Version +-fdroid %v - -fdroid is the suffix.

For apps with a list of VercodeOperation the number of builds is equal to the number of items in the list.

CurrentVersion

The name of the version that is the recommended release. There may be newer versions of the application than this (e.g. unstable versions), and there will almost certainly be older ones. This should be the one that is recommended for general use. In the event that there is no source code for the current version, or that Non-Free libraries are being used, this would ideally be the latest version that is still free, though it may still be expedient to retain the automatic update check — see No Source Since.

This field is normally automatically updated - see UpdateCheckMode.

This is converted to (<marketversion>) in the XML file (index.xml).

CurrentVersionCode

The version code corresponding to the CurrentVersion field. Both these fields must be correct and matching although it’s the current version code that’s used by Android to determine version order and by F-Droid client to determine which version should be recommended.

This field is normally automatically updated - see UpdateCheckMode.

If not set, clients will recommend the highest version they can, as if the CurrentVersionCode was infinite.

This is converted to (<marketvercode>) in the XML file (index.xml).

NoSourceSince

In case we are missing the source code for the CurrentVersion reported by Upstream, or that Non-Free elements have been introduced, this defines the first version that began to miss source code. Apps that are missing source code for just one or a few versions, but provide source code for newer ones are not to be considered here - this field is intended to illustrate which apps do not currently distribute source code, and since when have they been doing so.

Deprecated or Removed Fields

Provides

Comma-separated list of application IDs that this app provides. This field was only ever a stub and was never used for anything. It was never supported in index-v1.json nor .yml metadata files.

This is converted to (<provides>) in the XML file (index.xml).

Rechercher des applications

Faire un don

F-Droid est financé par vos dons !

Connect

mastodon
@fdroidorg@floss.social

Actualités

Mises à jour récentes

FairEmail

Client de courriel complet. Net et conviviale. Favorise la confidentialité

EasySync

Synchronisez votre téléphone avec votre serveur DAV, facilement.

Nextcloud Dev

Client de synchronisation

Dernières applications

EasySync

Synchronisez votre téléphone avec votre serveur DAV, facilement.

Nextcloud Passwords

Secure app for viewing passwords for the Nextcloud Passwords app

OpenAthena™ for Android

OpenAthena™ permet aux drones courants de repérer des emplacements précis