Chapitre 12.4 — Installer sur TON téléphone : le sideload

Où on en est : des APK release signés sortent de ta machine et du cloud. Reste la logistique du quotidien : les faire entrer dans le téléphone, les mettre à jour, les partager — proprement et sans peur.

⏱️ TL;DR — Trois canaux d’installation : adb (câble/WiFi — le canal du builder), le lien EAS (QR code — le canal sans câble), le fichier partagé (Drive, mail — le canal des copains). « Sources inconnues » : Android demande d’autoriser L’APP qui installe (navigateur, gestionnaire de fichiers) — une fois chacune. Mise à jour = installer par-dessus (même signature, versionCode ≥) : les données SURVIVENT.

🎯 Objectifs

• Maîtriser les trois canaux et choisir selon le contexte.
• Comprendre le modèle « sources inconnues » moderne (par app installatrice).
• Mettre à jour sans perdre les données (les règles signature + versionCode).
• Diffuser proprement à un petit cercle (famille/amis) sans store.

Canal 1 : adb — le canal du builder

adb install -r .\build-drill.apk      # -r : par-dessus l'existant (mise à jour)

Déjà pratiqué. Deux ajouts de confort pour la vie sans câble :

# adb par WiFi (Android 11+) : Options développeur → Débogage sans fil → Associer
adb pair 192.168.1.42:37123           # code affiché sur le téléphone
adb connect 192.168.1.42:40551
adb install -r .\build-drill.apk      # comme avant — sans câble

Et le combo du rituel : adb install -r + adb shell am start -n com.alex.drill/.MainActivity (installe ET lance — la boucle la plus courte).

Canal 2 : le lien EAS — le canal sans machine

Chaque build cloud (et --local avec upload) a sa page : eas build:list → l’URL → le QR. Sur n’importe quel téléphone : scanner → télécharger → installer. C’est le canal quand l’APK est sur les serveurs EAS de toute façon — et le plus simple pour installer sur le téléphone d’un proche à distance (envoyer le lien).

Durée de vie : ~30 jours (ch. 12.2) — pour du durable, canal 3.

Canal 3 : le fichier — le canal des copains

Un APK est un fichier : Drive, mail, clé USB, Syncthing… Le destinataire tape le fichier → Android l’installe (après l’autorisation ci-dessous). Deux règles d’hygiène de diffuseur :

1. Nommez informatif : drill-1.2.0.apk (pas build-7f3a.apk) — votre futur vous remerciera aussi.
2. Un canal stable : un dossier Drive « Apps d’Alex » partagé à la famille, toujours le même — les mises à jour s’y déposent, personne ne cherche.

« Sources inconnues » — démystifié

Le modèle moderne (Android 8+) : l’autorisation se donne à l’app qui installe, pas globalement. Premier APK depuis Chrome → « Autoriser Chrome à installer des applications ? » → une fois. Depuis Files ensuite → même question pour Files. C’est sain : le canal est identifié, révocable (Paramètres → Apps → accès spécial → Installer des apps inconnues).

À dire aux proches à qui vous diffusez (le pitch honnête) : « Android affichera un avertissement parce que l’app ne vient pas du Store — c’est normal pour une app perso ; l’autorisation ne vaut que pour l’app par laquelle tu l’installes. » Play Protect scannera l’APK de toute façon (il scanne aussi le sideload) — et peut afficher « app non reconnue » : « Installer quand même » est le chemin prévu pour ce cas.

La mise à jour : les deux conditions

Installer une nouvelle version PAR-DESSUS (données conservées : SQLite, réglages, tout) exige :

1. Même signature (ch. 12.3 — notre keystore unique y veille) ;
2. versionCode ≥ l’installé — l’entier monotone d’Android (≠ le version marketing).

// app.config.ts — les deux versions
version: '1.2.0',                    // humaine (semver, affichée)
android: { versionCode: 7 },         // machine (entier, TOUJOURS croissant)

Gestion recommandée : autoIncrement: true dans le profil EAS (le cloud/local EAS incrémente seul — un souci de moins), et le ch. 12.6 pose la stratégie complète. Erreur symptôme : INSTALL_FAILED_VERSION_DOWNGRADE = vous installez un versionCode plus vieux (le -d d’adb force le downgrade — DEV UNIQUEMENT).

⚠️ Piège — Le sideload a UN vrai manque par rapport au Store : personne ne pousse les mises à jour — vos proches garderont la v1.0 buguée jusqu’à ce que vous leur re-envoyiez un fichier… C’est exactement le trou que comble le chapitre suivant : avec EAS Update, l’APK sideloadé se met à jour TOUT SEUL (le JS du moins). Le sideload + OTA = 95 % du confort du Store, 0 % de sa bureaucratie.

💡 Pour un dev Next.js — Le sideload est le « self-hosting » du mobile : la liberté (aucune review, aucun délai, aucun compte) contre la logistique (distribution, mises à jour). La réponse du web au problème des mises à jour, c’est l’URL — celle du mobile, c’est l’OTA. Chapitre suivant.

✏️ Exercices

1. Configurez adb par WiFi et refaites le rituel complet (build —local → install -r → launch) sans toucher un câble. Chronométrez la boucle.

2. Diffusez Drill à UN proche par le canal fichier : préparez le message d’accompagnement (3 phrases : quoi, l’avertissement expliqué, comment les mises à jour arriveront).

3. Testez la persistance des données à travers une mise à jour : jouez 2 parties, bumpez versionCode, rebuild, install -r — l’historique est-il là ? Puis désinstallez/ réinstallez : que reste-t-il, et pourquoi ?

🧠 Quiz

1. Citez les trois canaux de sideload et leur contexte.

2. Comment fonctionne « sources inconnues » depuis Android 8 ?

3. Les deux conditions d’une mise à jour par-dessus ?

4. Que conserve une mise à jour, que détruit une désinstallation ?

5. Quel est le manque structurel du sideload, et sa réponse ?

👉 Chapitre suivant : 12.5 — EAS Update — le joyau : mettre à jour sans réinstaller.