Construire des applications

Au lieu (ou en plus) d’inclure des APK binaires provenant de sources externes dans un dépôt, vous pouvez les construire directement à partir du code source.

En utilisant cette méthode, il est possible de vérifier que l’application est construite correctement, correspond au code source, et ne contient que du logiciel libre. Malheureusement, dans le monde Android, il semble être assez fréquent pour une application fournie sous forme de fichier APK binaire de s’afficher comme étant un Logiciel Libre alors qu’en réalité, plusieurs voire toutes les affirmations suivantes sont vérifiées :

  1. Le code source (pour une version particulière, voire toutes les versions !) est indisponible ou incomplet.
  2. Le code source ne permet pas de reproduire le binaire fourni.
  3. Le « code source » contient des fichiers binaires d’origine inconnue, ou sous licences propriétaire.

Pour cette raison, les applications construites à partir du code source reste la méthode privilégiée pour le dépôt F-Droid, bien que pour des raisons techniques ou historiques, des exceptions sont parfois accordées.

Quand les applications sont construites à partir du code source, il est important de noter que vous les signerez (toutes les fichiers APK doivent d’être signés pour être installés sur Android) avec votre propre clé. Quand une application est déjà installée sur un périphérique, il est impossible de mettre à jour une application signée avec une autre clé sans désinstaller l’originale avant. Cela peut présenter une gêne pour les utilisateurs, dans la mesure où le processus de désinstallation provoque la perte de toutes les données liées à l’installation précédente.

La gestion d’un dépôt d’applications construites à partir du code source est très similaire à ce qui est présenté dans le chapitre « Simple dépôt de binaires », sauf que dorénavant vous aurez besoin :

  1. D’inclure les entrées de construction dans les fichiers de méta-données.
  2. D’exécuter fdroid build pour construire toute application n’ayant pas encore été construite.
  3. D’exécuter fdroid publish pour finaliser l’empaquetage et signer les APK construits.

Répertoire des données de l’application aka fdroidata

Pour faire quoi que ce soit, vous aurez besoin d’au moins un répertoire de données de dépôt. C’est à partir de ce répertoire que vous exécuterez la commande « fdroid » pour effectuer toutes les tâches de gestion du dépôt. Vous pouvez soit en créer un tout nouveau soit récupérer une copie des données utilisées par le dépôt F-Droid principal :

git clone https://gitlab.com/fdroid/fdroiddata.git

Indépendamment de l’utilisation prévue des outils, vous devrez toujours paramétrer certains détails de configuration de base. Cela se fait en créant un fichier config.yml dans le répertoire data. Vous devriez le faire en copiant le fichier d’exemple (./examples/config.yml) du projet fdroidserver vers votre répertoire data, puis en le modifiant en fonction des instructions qu’il comporte.

Une fois configuré de cette façon, toutes les fonctions des outils sont accessibles en exécutant la commande ‘fdroid’. Exécutez-la seule afin d’obtenir la liste de sous-commandes proposées.

Vous pouvez terminer n’importe quelle commande par ‘–help’ pour obtenir la liste d’options disponibles pour cette commande.

fdroid update --help

À propos de fdroid build

Exécuté sans paramètre, fdroid build compilera toutes les versions d’applications que vous n’avez pas déjà dans le répertoire repo (ou plus précisément, le répertoire unsigned). Plusieurs autres choix s’offrent à vous. Comme pour tous les outils, l’option --help est votre amie, mais voici quelques exemples annotés, ainsi qu’une discussion sur les modes d’utilisation les plus courants :

Pour compiler une seule version d’une seule application, vous pourriez exécuter :

fdroid build org.fdroid.fdroid:16

Cela tente de construire la version 16 du code (qui est la version 0.25) du client F-Droid. Plusieurs des outils reconnaissent les arguments comme des paquets, ce qui permet de limiter leur action à un ensemble réduit de paquets.

Si la compilation ci-dessus réussit, deux fichiers seront présents dans le répertoire ‘unsigned’ :

org.fdroid.fdroid_16.apk
org.fdroid.fdroid_16_src.tar.gz

Le premier est l’APK (non signée). vous pourriez le signer avec un clef de débogage et le pousser directement vers votre appareil ou un émulateur pour le tester. Le deuxième est une archive source contenant exactement la source utilisée pour générer le binaire.

Si vous voulez publier ces fichiers, vous pouvez lancer :

fdroid publish

Le tarball source va déplacer le dossier ‘repo’ (qui est le dossier que vous voulez envoyer sur votre serveur web). Une version signée et zip-alignée de l’APK va aussi apparaitre ici, et les deux fichiers vont être supprimés du dossier ‘unsigned’.

Si vous ne compilez qu’à des fins de test et que vous n’avez pas l’intention de pousser les résultats vers un dépôt, du moins pas encore, l’option --test peut être utilisée pour diriger la sortie vers le répertoire tmp au lieu d’unsigned. Un effet similaire pourrait être obtenu en supprimant simplement les fichiers de sortie d’unsigned après compilation, mais avec le risque d’oublier de le faire !

Along similar lines (and only in conjunction with --test, you can use --force to force a build of a Disabled application, where normally it would be completely ignored. Similarly a version that was found to contain ELFs or known Non-Free libraries can be forced to build. See also — scanignore and scandelete in the Builds section.

If the build was unsuccessful, you can find out why by looking at the output in the logs/ directory. If that isn’t illuminating, try building the app the regular way, step by step: android update project, ndk-build, ant debug.

Notez que les dépôts de code source contiennent souvent des bibliothèques pré-intégrées. Si l’application est envisagée pour le dépôt principal de F-Droid, il est important que tous ces pré-constructions soient construites soit via les métadonnées, soit par un tiers réputé.

Exécution de fdroid build dans les sources de votre application

Une autre option pour utiliser fdroid build est d’utiliser un fichier de métadonnées qui est inclus dans la source de l’application elle-même, plutôt que dans un dossier metadata/ avec beaucoup d’autres applications. Ce fichier de métadonnées devrait se trouver à la racine de votre dépôt source et s’appeler .fdroid.json, .fdroid.xml, .fdroid.yaml, ou .fdroid.txt, selon le format de données que vous préférez : JSON, XML, YAML, ou le format `.txt’ de F-Droid.

Une fois que vous avez cette configuration, vous pouvez construire la version la plus récente de l’application avec l’environnement complet de F-Droid en exécutant :

fdroid build

Si vous voulez construire toutes les versions, veuillez spécifier --all.

Installation directe

Vous pouvez également construire et installer directement sur un périphérique ou émulateur connecté en utilisant la commande fdroid install. Si vous faites cela sans passer les paquets comme arguments, alors toutes les dernières versions construites et signées disponibles de chaque paquet seront installées. Dans la plupart des cas, ce ne sera pas ce que vous voulez faire, donc l’exécution s’arrêtera immédiatement. Cependant, vous pouvez l’écraser si vous êtes sûr que c’est ce que vous voulez, en utilisant `–all’. Notez qu’actuellement, aucune vérification n’est effectuée avec ce mode, donc si les fichiers du répertoire de sortie signé ont été modifiés, vous ne serez pas notifié.