freedzhost.cloud

Votre propre app Android, hors du Play Store, avec ses mises à jour

Niveau AvancéTemps estimé une demi-journéeÀ lire avant Homelab 6 : rejoindre la maison de partout sans ouvrir de portUn mot inconnu ? Lexique

Notre app de console pour le réseau d'agents tourne sur nos téléphones sans jamais passer par un magasin d'applications : nous la compilons, la signons et servons ses mises à jour nous-mêmes. C'est plus simple qu'il n'y paraît, à condition de respecter deux choses : la clé de signature et le numéro de version.

Dépôtversion montée dans la PRConteneur de buildSDK Android, rien à installerAPK signéeclé de publication, sauvegardéeVotre serveurAPK + latest.jsonLe téléphonecompare versionCodepar votre réseau privé
Compiler dans un conteneur, signer avec votre clé de publication, publier l'APK et un petit fichier de version sur votre propre serveur. L'app compare le numéro de version au sien et propose la mise à jour. Un numéro de version ne sert qu'une fois : publié ou non, plus jamais.

1. Compiler dans un conteneur

Pas besoin d'Android Studio sur votre machine. Une image de conteneur avec le SDK Android compile le projet en ligne de commande, et un dossier de cache pour Gradle garde les recompilations rapides :

docker run --rm -v "$PWD":/app -v ~/.cache/gradle:/root/.gradle -w /app \
  ghcr.io/cirruslabs/android-sdk:35 ./gradlew assembleRelease

2. Signer avec une clé de publication

Une APK signée en mode debug s'installe, mais Play Protect l'avertit ou la bloque, et sa clé diffère d'une machine à l'autre. Créez une fois un magasin de clés de publication, signez chaque build avec, et sauvegardez-le comme un mot de passe : une mise à jour signée avec une autre clé ne peut pas remplacer l'app installée, et vos utilisateurs devraient la désinstaller et perdre ses données.

3. Votre propre canal de mises à jour

À côté de l'APK, publiez sur votre serveur un petit fichier, par exemple latest.json, avec le numéro de version, le nom de version, l'adresse de téléchargement et l'empreinte du fichier. Au démarrage, l'app le lit, compare le numéro au sien, et propose la mise à jour. Servez les deux par votre réseau privé (Homelab 6) : votre app n'est pas publique, ses mises à jour n'ont pas à l'être.

Sur le téléphone, autorisez une fois l'app à « installer des applications inconnues », pour qu'elle puisse installer ses propres mises à jour.

La règle qui mord

L'app compare le versionCode, un entier, et rien d'autre. Publiez deux builds différents avec le même numéro et le second n'est jamais proposé : les téléphones se croient à jour. Un numéro de version est donc dépensé dès qu'il est publié, et vous ne le montez jamais avant une publication, car un numéro fusionné mais non publié est dépensé lui aussi. Montez-le dans le changement qui sera publié, compilez et publiez juste après la fusion.

Pièges

Testez le chemin de mise à jour, pas seulement l'installation : installez la version précédente, publiez la nouvelle, et vérifiez que le téléphone la propose et l'installe par-dessus l'ancienne, données intactes.

Gardez le magasin de clés et ses mots de passe hors du dépôt : dans votre coffre pour les mots de passe (Homelab 3), et le fichier dans vos sauvegardes (Homelab 5).

Utile ? Dites-nous ce qu'il faut mesurer ensuite.