Andreas Itzchak Rehberg proposait un sujet aussi intrigant qu’utile : la reproductibilité des builds (RB) pour les applications Android. Mais au-delà d’Android, on comprend très vite qu’un environnement de builds stable et capable de reproduire exactement le même comportement est quelque chose d’indispensable. Mais pour y parvenir, il faut une infrastructure RB définie et une méthodologie claire.

Pourquoi est-ce une bonne approche ? Par exemple, le RB permet d’avoir une application non altérée avec une confiance élevée car la build est garantie. D’autre part, le développeur sait que le code fonctionnera TOUJOURS de la même façon. Là encore, il s’agit d’avoir une confiance dans la build produite et d’avoir une stabilité de fonctionnement.

Une bonne RB permet aussi de détecter tout changement non prévu ou non autorisé durant le processus de build. Ce n’est pas une approche immutable, mais une bonne RB détectera ainsi tout changement qui ne devrait pas exister ou qui n’est pas autorisé. Et vous pouvez ainsi garantir que votre app soit conforme aux standards utilisés.

Andreas s’appuie sur la RB mise en avant pour IzzyOnDroid. Cette approche se définit ainsi :

• RB sur une track séparée de la branche principale et des autres builds
• utilisation de rbtlog
• toolchain open source uniquement
• conteneurs Podman avec différentes images Linux
• possibilité d’utiliser des builders différents
• les APK générés sont signés

Une bonne RB n’est pas simple à mettre en place. Les défis ne sont pas à sous-estimer. Actuellement, les équipes utilisent Java et Kotlin. Si Kotlin domine, une JDK doit être utilisée pour certains codes. Une autre complexité vient aussi des applications natives utilisant différents frameworks tels que Flutter, Node, React ou différents langages. Et il faut que la build embarque les chemins des librairies natives. Les chemins de build Windows ne peuvent pas être utilisés sur un build Linux. Et enfin, des SDK de versions différentes peuvent produire des sorties (= releases) différentes.

En plus des défis, il existe de nombreuses sources d’échecs d’une RB :
1 / les builds sales, c’est-à-dire des builds non nettoyées embarquant des assets qui ne devraient pas exister
2 / des commits différents
3 / des problèmes de builds entre Windows et Linux
4 / des problèmes liés à la signature des releases générées
5 / un système de build local ayant différents setups au lieu d’être plus spécifique
6 / utiliser une JDK qui n’est pas LTS : il faut éviter les versions intermédiaires, canary et toute version non LTS

IzzyOnDroid met à disposition une documentation et des bonnes pratiques : https://izzyondroid.org/docs/reproducibleBuilds/

IzzyOnDroid propose son propre framework RB avec un rbuild_setup pour faciliter les RB. Chaque éditeur, ou développeur, peut avoir sa propre approche RB.