Aller au contenu principal

Multi-Flavors et architectures CPU (ABI)

Les applications Flutter d'entreprise ciblent fréquemment plusieurs environnements d'exécution (Flavors Gradle et Schémas Xcode) ainsi qu'une diversité d'architectures matérielles (terminaux Android 32-bits et 64-bits).

La CLI tk-ota-push gère nativement le cycle de vie complet multi-flavors et multi-architectures (lib/src/cli/publisher.dart et test/flavor_build_args_test.dart), évitant les erreurs de compilation croisée et les incompatibilités binaires.

1. Gestion avancée des Flavors Flutter​

Lorsqu'un projet utilise des variantes de build (ex: dev, staging, prod), la CLI relaye automatiquement les arguments requis au moteur Flutter tout en résolvant l'app_id correspondant.

Options de build relayées (commonFlutterBuildArgs)​

Option CLIArgument Flutter généréDescription
--flavor <nom>--flavor <nom>Variante Gradle (Android productFlavors) ou Xcode Scheme / Configuration
-t, --target <fichier>-t <fichier>Point d'entrée Dart spécifique (ex: lib/main_prod.dart)
--dart-define CLE=VALEUR--dart-define CLE=VALEURVariable d'environnement Dart (répétable à volonté)
--dart-define-from-file <chemin>--dart-define-from-file=<chemin>Fichier de configuration .json ou .env (répétable)
--build-name <version>--build-name <version>Surcharge le nom de version sans modifier pubspec.yaml
--build-number <numéro>--build-number <numéro>Surcharge le numéro de build sans modifier pubspec.yaml
-- <arguments><arguments>Relaye des arguments bruts directement à Flutter (ex: --no-tree-shake-icons)

Exemples concrets par variante​

# 1. Release Android Staging au format Android App Bundle (AAB)
tk-ota-push release 2.4.0+10 \
  -p android \
  --flavor staging \
  -t lib/main_staging.dart \
  --artifact aab \
  --dart-define-from-file=env/staging.json

# 2. Patch OTA Android Production ciblant un flavor spécifique
tk-ota-push patch 2.4.0+10 \
  -p android \
  --flavor prod \
  -t lib/main_prod.dart \
  --dart-define API_URL="https://api.banque.com" \
  -m "Correctif de validation OTP"

# 3. Release iOS Ad-Hoc avec méthode d'exportation
tk-ota-push release 2.4.0+10 \
  -p ios \
  --flavor dev \
  -t lib/main_dev.dart \
  --artifact ipa \
  --export-method ad-hoc

2. Architectures CPU Android (ABI)​

Sous Android, le code Dart compilé en AOT (binaire d'application) est du code machine spécifique à l'architecture du processeur de l'appareil. tk-ota-push prend en charge les deux ABIs majeures du marché :

Identifiant CLI (--arch)Dossier ABI AndroidArchitecture processeurAppareils concernés
aarch64arm64-v8aARM 64-bitsLa quasi-totalité des smartphones modernes depuis Android 9
armarmeabi-v7aARM 32-bitsSmartphones d'entrée de gamme, terminaux POS et anciens appareils
all (défaut)Les deuxMulti-ABIGénère et publie automatiquement pour aarch64 ET arm

Fonctionnement du mode --arch all​

Par défaut, la CLI compile une seule archive contenant toutes les cibles avec le flag Flutter --target-platform android-arm,android-arm64.

Lors de l'extraction, la CLI analyse l'archive compilée (.apk ou .aab) :

  1. Elle extrait lib/arm64-v8a/binaire d'application et calcule son empreinte SHA-256.
  2. Elle extrait lib/armeabi-v7a/binaire d'application et calcule son empreinte SHA-256.
  3. Elle soumet deux publications distinctes auprès du serveur OTA (arch=aarch64 et arch=arm).
Compilation Android terminée.
[aarch64] binaire d'application extrait : 14.8 Mo (SHA-256: 4a2b9f...)
[arm]     binaire d'application extrait : 11.2 Mo (SHA-256: 9e8c1d...)
Enregistrement Release Android 2.4.0+10 (aarch64)... ✅
Enregistrement Release Android 2.4.0+10 (arm)...     ✅
Pourquoi les patchs sont-ils séparés par architecture ?

Un binaire binaire d'application compilé pour arm64-v8a ne peut pas s'exécuter sur un processeur 32-bits armeabi-v7a (et réciproquement). En publiant deux patchs distincts, tk-ota-push garantit :

  • Que chaque téléphone télécharge uniquement le différentiel correspondant à son processeur.
  • Un gain de bande passante de plus de 50 % par rapport à un patch universel lourd.
  • L'absence absolue de plantages natifs SIGSEGV / SIGILL à l'exécution.

3. Formats d'artefacts Android : APK vs AAB​

La CLI s'adapte automatiquement à votre format de packaging via l'option --artifact :

Format APK (--artifact apk, défaut)​

  • Commande Flutter sous-jacente : flutter build apk --release
  • Emplacement binaire dans le ZIP : lib/<abi>/binaire d'application
  • Idéal pour la distribution interne, le sideloading et les tests en entreprise.

Format Android App Bundle (--artifact aab)​

  • Commande Flutter sous-jacente : flutter build appbundle --release
  • Emplacement binaire dans le ZIP : base/lib/<abi>/binaire d'application
  • Obligatoire pour la publication sur le Google Play Store.

Grâce à ZipDecoder de la bibliothèque archive, tk-ota-push inspecte les chemins lib/ et base/lib/ de façon transparente :

# Publication d'une Release AAB prête pour Google Play
tk-ota-push release 1.0.0+1 -p android --artifact aab --flavor prod

4. Architecture iOS : Arm64 et Runner.app​

Sous iOS, l'écosystème matériel 64-bits est unifié :

  • L'architecture cible est systématiquement aarch64 (arm64).
  • Lors d'une release, la CLI inspecte le bundle d'application Runner.app (situé dans build/ios/iphoneos/Runner.app ou extrait de l'IPA).
  • Elle extrait le binaire App du framework Frameworks/App.framework/App, calcule son SHA-256 et génère le fichier diff_base nécessaire pour les futurs patchs différentiels.
  • Lors d'un patch, tk-ota-push compile app.dill, appelle gen_snapshot_arm64 pour produire out.aot, puis invoque aot-tools.dill link pour générer le binaire patché artefact de patch.