2026 — sprint Flutter/Android à court cycle : Gradle sur Mac cloud à la journée (appareil réel) face aux agents Linux auto-hébergés — limites des émulateurs, clés de cache NDK et matrice de décision location à la semaine (FAQ)

Lorsqu'une équipe Flutter pousse Android tous les deux ou trois jours, la CI n'est plus seulement « vert sur main » : c'est un agenda — découpe ABI, règles Play, plugins natifs, transformations Gradle se disputent la même après-midi. Un émulateur ARM rapide sur Apple Silicon manque encore de toute une famille de défauts visibles seulement sur stockage réel, pilotes GPU constructeur et politique d'énergie OEM. D'où le duo fréquent : un agent Linux auto-hébergé peu coûteux pour l'analyse Dart et les tests unitaires, plus une voie Mac cloud à la journée pour bundleRelease digne d'une release, tests d'intégration et fumée sur appareil avant étiquetage store.

Vitesse d'émulateur ≠ vérité matériel

Les émulateurs récents excellent pour tests de widgets, captures golden et itération rapide. Ils peinent quand le sujet est le timing JNI, les bizarreries HAL caméra, le report des tâches en arrière-plan ou les codecs médias spécifiques au fabricant. Dans une fenêtre à court cycle, on a rarement le temps de bissecter des flakiness « émulateur seulement » : nous traitons la suite émulateur comme un signal et exigeons au moins un appareil physique ou un slot lab avant de taguer un candidat store. Sans lab quotidien, un Mac cloud loué avec redirection USB ou un téléphone appairé coûte souvent moins cher qu'un mauvais binaire et un rollback Play.

Gradle Mac cloud à la journée face aux agents Linux

Les agents Linux brillent sur flutter test, l'analyse statique et les services dockerisés : la RAM est abordable et les images démarrent vite. Ils coincent sur les suites instrumentées Android Studio, les tests d'intégration gourmands GPU ou les scripts de signature qui supposent des chemins macOS. Une voie Mac cloud offre Studio, le JDK épinglé et des daemons Gradle prévisibles sans contorsions conteneur glibc pour dépendances natives exotiques. Si vous hésitez déjà entre ajouter un second pipeline macOS et pousser plus de jobs sur Linux, les mêmes compromis files d'attente et secrets s'appliquent — voir 2026 — sprint à court cycle : second pipeline macOS CI ou jobs sur agents Linux ? File d'attente, secrets, matrice et FAQ pour un cadrage parallèle utile aux dépôts Flutter multi-cibles.

Clés de cache Gradle conscientes NDK (où le poison silencieux se cache)

Les caches distants ne sont sûrs que si les entrées sont hachées honnêtement. Pour les modules Android Flutter qui tirent CMake ou des artefacts prefab, monter le NDK sans renommer l'espace de cache est un classique : CI verte, nightly cassée. Figez au minimum la version AGP, la version Gradle, la révision NDK et le couple ABI + STL. Si vous symlinkez les SDK dans l'image, normalisez le chemin avant hachage pour éviter deux empreintes différentes pour le même compilateur.

# Exemples — adapter à votre fournisseur de cache distant
android.ndkVersion=26.3.11579264
android.defaults.buildfeatures.buildconfig=true   # si d'anciens plugins émettent encore BuildConfig
flutter.version=3.24.x                 via FVM / fichier de version
cmake.arguments=-DANDROID_STL=c++_shared        doit matcher sur toute la matrice

Couplez ces clés à un job hebdomadaire froid (./gradlew clean + miss de cache) : si la médiane explose seulement sur Mac, vous êtes probablement limités par les I/O des logs daemon ou le miroir Maven, pas par la compilation Kotlin.

Location à la semaine vs paiement à la journée (matrice)

En stand-up, une colonne par signal suffit : la location évite l'immobilisation d'un Mac inactif quand la roadmap Flutter est en rafales.

Une fois le runner Mac provisionné, enchaînez avec l'enregistrement réseau et des jetons minimalistes : la checklist détaillée se trouve dans 2026, pics CI à cycle court : après activation du Mac cloud — enregistrer le runner, auto-contrôle réseau et jetons minimalistes (checklist 30–60 min + FAQ).