Quand le service en arrière-plan de FlutterFlow fait la sieste
Imaginez la scène : vous développez une super application de tracking pour que vos agents marketing sachent où ils ont rogné le bitume… et là, patatras. Dès que votre appli passe en arrière-plan sur Android, le service de localisation fait la grasse matinée. Vous aviez pourtant tout bien suivi : permissions, manifest, librairies, café — rien n’y fait. La communauté FlutterFlow se reconnaîtra dans cette galère !
Rassurez-vous, vous n’êtes pas seul à vouloir taper du poing sur le bureau. On va décortiquer ensemble ce qui sabote le service de fond, les subtilités Android qui coincent, et des astuces pour se sortir de ce pétrin. Allez, sortez les outils de dev, on fait le tour de la question… avec un p’tit sourire !
Les ambitions classiques… et la douche froide côté Android
Créer un suivi de géolocalisation pour tracer l’activité d’un collaborateur pendant ses heures de travail semble simple avec FlutterFlow… sur le papier ! L’idée : quand l’utilisateur « pointe », on démarre la collecte des données de localisation et on les stocke, en continu, même si l’appli est réduite ou fermée.
Après avoir potassé la documentation FlutterFlow, tout configuré comme un vrai chef, la mésaventure commence :
- Le service démarre bien à l’ouverture
- Mais dès qu’on met l’appli en arrière-plan ou qu’on la ferme, la magie opère… le service s’arrête !
- Votre base de données ne reçoit plus rien. Silence radio.
On connaît tous ce moment de solitude quand, sur Android, le background service préfère partir en week-end anticipé…
Les bonnes pratiques de configuration (mais qui parfois ne suffisent pas)
Côté développeur averti, voici ce qui a été tenté — histoire de prouver qu’on ne fait pas les choses à moitié :
- Permissions :
- ACCESSBACKGROUNDLOCATION
- FOREGROUND_SERVICE
- SCHEDULEEXACTALARM
- RECEIVEBOOTCOMPLETED
- Librairies : les bons vieux
flutter_background_service,flutter_local_notifications,geolocatoret cie sont bien installés à la bonne version - AndroidManifest.xml : le fameux
<service ...>est là, bien niché dans<application>, avectools:replace="android:exported" - Réglages du téléphone : permissions activées, pas d’économies d’énergie ou d’optimisation batterie qui tuerait le processus, « auto-launch »… tout est bon !
- Test minimaliste : même en forçant juste l’écriture d’un timestamp en base de temps en temps (sans géoloc, sans notifs), le service s’arrête quand l’app est fermée.
Si vous vous reconnaissez dans cette checklist, arrêtez de vous arracher les cheveux. C’est probablement Android qui vous joue des tours… et il peut être sacrément taquin.
Pourquoi Android aime mettre les bâtons dans les roues aux applis en arrière-plan ?
Android (surtout depuis les versions 8 à 13) joue la carte de l’optimisation à fond : protection de batterie, confidentialité des données, restriction des jobs en background pour éviter le gaspillage de ressources.
Les causes fréquentes des interruptions de service
- Gestion agressive des processus en arrière-plan : Les constructeurs (Samsung, Xiaomi, Huawei, Oppo… vous voyez le genre) dézinguent sans état d’âme les services de vos apps pour prolonger la batterie.
- Permissions « volatiles » : Certaines permissions peuvent passer à la trappe après une maj mineure Android ou selon la politique du fabricant.
- Service mal déclaré : Une virgule déplacée ou une balise mal placée dans le manifeste et, pouf, le service tombe aux oubliettes.
- Politique sur les tâches exactes : Les alarmes exactes (SCHEDULEEXACTALARM) sont désormais très surveillées — ce qui complexifie tout push en arrière-plan.
Des symptômes qui ne trompent pas
- Le service démarre mais s’arrête brutalement (souvent à la mise en arrière-plan ou lors d’une longue inactivité)
- Les notifications ne s’affichent plus, preuve que le process est tué
- Les logs le confirment… ou n’affichent rien (“mort subite” en bon dev).
Comment corriger, contourner ou (presque) forcer le service background Android
Pas de recette miracle, hélas. Pourtant, certains membres chevronnés de la communauté FlutterFlow ressortent régulièrement quelques joker spécialisés…
1. Passer en service premier plan… vraiment visible !
Le « Foreground Service » est votre meilleur allié, mais attention :
- Assurez-vous de générer une notification permanente pendant tout le suivi
- Sans notification, Android considère le process comme « inutile » et le coupe
Astuce : personnalisez la notification pour qu’elle explique à l’utilisateur qu’il est suivi (et évitez un face-à-face tendu avec la CNIL…).
2. Ajoutez une (vraie) exclusion de l’optimisation batterie
Même après avoir mis « non optimisé » dans les réglages, certains constructeurs ne respectent pas ce choix ! Rendez-vous aussi dans les options avancées (genre « Lancer au démarrage », « Autorisation d’arrière-plan » sur Huawei, etc…)
Sur les forums, Xiaomi est champion du « kill en force » : une appli pourrait nécessiter 3 menus différents pour vraiment lever toutes les restrictions.
3. Vérifiez l’ensemble du code custom et ouvrez les logs
Bien analyser :
- Si la logique du background service ne crashe pas silencieusement
- Si le
onStartdu service gère bien les exceptions - Si le process s’arrête après une certaine durée, ou après une exception invisible
Une trace dans la base de données, une écriture dans un fichier log local ou même un toast temporaire peuvent aider à pister d’où vient le souci exact.
4. Testez sur plusieurs appareils et plusieurs versions Android
Ce qui passe sans souci sur un Pixel ou un émulateur peut foirer lamentablement sur un OPPO ou un Galaxy avec surcouche custom. Testez sur plusieurs modèles : c’est parfois la seule façon de détecter un fabricant « surprotecteur ».
5. Utilisez des plugins maintenus et ouverts aux issues
Vérifiez :
- Les dernières versions de
flutter_background_serviceougeolocatoret l’état des issues sur GitHub - Les problèmes connus (batterie, permissions auto-supprimées, alarmes non déclenchées)
Parfois, une simple mise à jour ou rollback permet de retrouver la lumière !
6. Soyez transparent côté utilisateur
Prévenez franchement l’utilisateur :
- De la nécessité de laisser l’app tourner en arrière-plan
- D’accepter les autorisations demandées. Sinon, vous aurez des « ça marche pas » mais côté Google Play ou App Store Review…
Un utilisateur bien informé, c’est déjà la moitié des soucis en moins !
Quelques alternatives si ça coince (parce que la vie, c’est aussi l’art du plan B)
- Push via serveur : Déplacez la logique de géolocalisation au serveur (ex. via un job programmé ou notifications push régulières pour relancer la collecte)
- API d’activités spécifiques : Utilisez « Geofencing » ou les API de « Significant Changes » qui consomment moins et sont mieux tolérées par Android pour des usages non critiques en temps réel
- Expliquez au client final : Ce n’est pas vous, c’est… Android. Ok, ça fait pas avancer le schmilblick, mais parfois, il faut poser les limites techniques (et détourner l’attention avec une super UX !)
En résumé : patience, tests, et optimisation (et un peu d’humour)
Créer une application de tracking fiable avec service background via FlutterFlow sur Android, c’est un peu comme jouer à Jumanji : on ne sait jamais quel piège va surgir au prochain écran !
La recette : combiner tous les paramètres (permissions, manifest, notifications, exclusions de batterie), multiplier les essais, lire les docs des plugins, surveiller les issues sur GitHub — et boire un peu de café (ou du thé, on ne juge pas ici).
Restez curieux, échangez sur la communauté FlutterFlow, et n’oubliez pas : la persévérance finit toujours par payer… ou par inspirer une bonne blague à rapporter à la machine à café 😉
Et vous, quels sont vos pires (ou meilleurs !) bugs sur FlutterFlow ? Partagez vos épiphanies et vos galères dans les commentaires – ici, on aime vous lire autant que coder !