ForegroundServiceDidNotStartInTimeException signifie qu’Android a démarré un service de premier plan avec Context.startForegroundService() ou ContextCompat.startForegroundService(), mais que le nouveau service ne s’est pas fait passer au premier plan avec ServiceCompat.startForeground() ou Service.startForeground() dans les quelques secondes imparties. Le problème concerne l’API 26 et les versions ultérieures. À partir d’Android 12, le nom de l’exception apparaît directement, tandis qu’Android 8.0 à Android 11 peuvent signaler une RemoteServiceException accompagnée du même message. La première mesure la plus sûre consiste à confirmer la signature exacte dans Logcat et à déterminer si le chemin qui plante correspond à un service natif ou à un worker WorkManager exécuté au premier plan.

Confirmer l’exception exacte et la version d’Android

Recherchez le message Context.startForegroundService() did not then call Service.startForeground(). Selon la documentation Android sur la résolution des problèmes liés aux services de premier plan, Android déclenche cette famille d’exceptions lorsqu’un service lancé avec startForegroundService() n’appelle pas startForeground() pendant l’intervalle de démarrage autorisé.

Plate-forme ou chemin d’exécution Signature attendue Étape suivante
Android 12 et versions ultérieures ForegroundServiceDidNotStartInTimeException avec le message correspondant Déterminer si l’application utilise un service natif ou un worker WorkManager exécuté au premier plan
Android 8.0 à 11 RemoteServiceException avec le même message contenant startForegroundService() et startForeground() Suivre le même diagnostic de délai pour un service natif, sauf si le marqueur WorkManager est également présent
Worker WorkManager exécuté au premier plan La famille d’exceptions et, pour la condition de concurrence documentée, Re-initializing SystemForegroundService after a request to shut-down Utiliser la procédure propre à WorkManager uniquement lorsque ce marqueur secondaire apparaît

La documentation de référence de Context fournit le contexte de l’API qui déclenche le service avec startForegroundService(). Ne classez pas toutes les RemoteServiceException dans cette catégorie : le message correspondant doit être présent.

Écarter les autres défaillances liées aux services de premier plan

  • ForegroundServiceStartNotAllowedException concerne l’autorisation de démarrer le service depuis l’arrière-plan. Il s’agit d’une défaillance distincte sous Android 12 et versions ultérieures, décrite dans les restrictions Android relatives au démarrage en arrière-plan.
  • Les plantages dus au dépassement de la durée autorisée d’un service de premier plan et les erreurs ANR des services de courte durée surviennent après d’autres limites d’exécution. Ce ne sont pas des variantes de cet échec de passage au premier plan au démarrage.
  • Une SecurityException liée au type de service de premier plan ou aux autorisations appartient également à une famille de défaillances distincte, même si elle se produit près de l’appel qui fait passer le service au premier plan.

Si le message exact est absent, n’appliquez pas ce guide comme si les défaillances étaient équivalentes.

Corriger un service natif qui ne passe pas à temps au premier plan

Quand cette procédure s’applique : utilisez ce chemin confirmé lorsque le code de l’application démarre un service natif avec startForegroundService() ou ContextCompat.startForegroundService() et que Logcat contient le message exact relatif au passage au premier plan au démarrage. N’utilisez pas cette procédure pour remplacer le diagnostic d’une restriction de démarrage en arrière-plan ou d’une condition de concurrence WorkManager.

Conditions préalables :

  • Un canal de notification valide sous Android 8.0 et versions ultérieures.
  • La notification du service de premier plan créée avant le passage au premier plan.
  • ServiceCompat disponible dans le code de l’application si ServiceCompat.startForeground() est utilisé.

Les exigences relatives aux notifications, au fichier manifeste et aux types de services de premier plan peuvent varier selon le type de service et la version d’Android. Vérifiez les exigences propres à l’application avant de supposer que l’appel de passage au premier plan est valide. Ce guide n’ajoute pas de déclarations qui n’ont pas été confirmées pour l’application.

  1. Créez le canal de notification avant le passage au premier plan. Le canal doit déjà être disponible au moment où la notification du service de premier plan est utilisée.
  2. Créez immédiatement la notification du service de premier plan. Ne placez pas sa création après un accès réseau, des opérations sur le disque ou une autre initialisation longue.
  3. Appelez ServiceCompat.startForeground() dans les quelques secondes qui suivent le démarrage du service. Service.startForeground() remplit le même rôle lorsqu’il est utilisé directement. N’inventez pas de délai exact plus long et ne vous appuyez pas sur un tel délai.
  4. Déplacez les tâches importantes après le passage au premier plan. Les opérations réseau, les accès au disque et les autres initialisations longues ne doivent pas bloquer le passage obligatoire au premier plan.
  5. Contrôlez chaque condition et chaque chemin du cycle de vie. Vérifiez que chaque nouvelle instance du service passe au premier plan, y compris dans les branches qui se terminent prématurément ou qui gèrent différentes actions de démarrage.

Résultat attendu : chaque nouvelle instance du service passe au premier plan avant le début des tâches importantes, et l’exception exacte ne doit plus se reproduire lorsque le scénario de démarrage initial est testé de nouveau. Ce résultat doit être vérifié et non supposé.

Risque : faible. Un passage plus précoce au premier plan peut modifier le moment où la notification visible par l’utilisateur apparaît et révéler des problèmes propres à l’application concernant les notifications ou le fichier manifeste, qui se produisaient auparavant plus tard.

Retour en arrière : si la modification du cycle de vie entraîne une régression, rétablissez le déroulement précédent du service pendant l’analyse. Dans un environnement de test contrôlé, gardez le plantage initial observable au lieu de le masquer.

N’ajoutez pas de pause arbitraire, ne déplacez pas le passage au premier plan vers un rappel ultérieur et ne remplacez pas systématiquement startForegroundService() par startService(). Ces mesures ne constituent pas des corrections reconnues pour cette exception et peuvent aggraver ou masquer le problème de délai.

Si la séquence prévue pour le passage au premier plan n’est pas atteinte de manière systématique, examinez manuellement les différentes branches du cycle de vie de l’application. Des signalements de la communauté mentionnent des interactions avec stopSelf(), stopService() et la publication différée des notifications, mais les éléments officiels fournis ne confirment aucune correction universelle pour ces situations. Considérez-les comme des pistes de diagnostic propres à l’application, et non comme des correctifs confirmés supplémentaires.

Utiliser le correctif WorkManager uniquement lorsque le marqueur d’arrêt apparaît

Quand cette procédure s’applique : utilisez cette branche uniquement lorsque le chemin qui plante correspond à un worker WorkManager exécuté au premier plan avec setForeground() ou setForegroundAsync(), et que Logcat contient le marqueur secondaire exact Re-initializing SystemForegroundService after a request to shut-down. En l’absence de ce marqueur, ne supposez pas que la condition de concurrence WorkManager documentée est à l’origine du plantage.

Conditions préalables :

  • Le chemin concerné doit utiliser un worker WorkManager exécuté au premier plan.
  • Le marqueur exact d’arrêt et de réinitialisation doit être présent dans Logcat.
  1. Confirmez le marqueur dans Logcat. Conservez l’exception environnante et le contexte du worker afin de ne pas confondre cette condition de concurrence avec un problème de délai dans un service natif.
  2. Mettez à jour WorkManager vers la version maintenue la plus récente disponible pour le projet. WorkManager 2.10.5 a introduit le correctif documenté pour ce plantage causé par le chevauchement avec l’arrêt. Cette version ne doit pas être présentée comme la version actuelle sans vérifier les versions disponibles au moment de la publication.
  3. Testez de nouveau le scénario de chevauchement des workers exécutés au premier plan. Utilisez le même déclencheur et la même chronologie des workers que lors du plantage précédent.
  4. Signalez tout problème persistant dans l’outil de suivi des problèmes de WorkManager. Si la mise à jour documentée ne résout pas le scénario testé, joignez l’exception exacte, le marqueur d’arrêt et les étapes de reproduction.

Résultat attendu : WorkManager ne doit plus reproduire le plantage documenté de SystemForegroundService lié à l’arrêt et à la réinitialisation pendant le même test de chevauchement des workers. Cela ne démontre pas que les autres défaillances de workers sont corrigées.

Risque : faible, mais la mise à jour d’une dépendance peut entraîner d’autres changements de comportement. Effectuez des tests de régression sur les workers exécutés au premier plan et les tâches en arrière-plan concernés.

Retour en arrière : revenez à la version précédemment épinglée uniquement si la mise à jour de WorkManager entraîne une régression sans rapport avec ce problème. Sinon, conservez la version maintenue qui contient le correctif documenté.

Vérifier que chaque instance du service passe à temps au premier plan

La vérification doit reproduire le déclencheur initial sans masquer l’exception ni modifier artificiellement les délais dans le seul but de faire réussir le test.

  1. Répétez le scénario initial. Démarrez le même service natif ou reproduisez la même séquence de chevauchement des workers exécutés au premier plan qui provoquait auparavant le plantage.
  2. Gardez la défaillance observable. N’interceptez pas, ne masquez pas et ne retardez pas l’exception pour présenter cela comme une preuve de correction.
  3. Pour un service natif, examinez chaque chemin. Vérifiez que chaque nouvelle instance crée une notification valide et passe au premier plan avant tout accès réseau, toute opération sur le disque ou toute autre tâche importante.
  4. Pour WorkManager, répétez le chevauchement après la mise à jour. Vérifiez que le test suit le même chemin de worker exécuté au premier plan et que la version maintenue de WorkManager est réellement utilisée.
  5. Examinez Logcat. Vérifiez si Context.startForegroundService() did not then call Service.startForeground() réapparaît. Dans la branche WorkManager, recherchez également Re-initializing SystemForegroundService after a request to shut-down.
  6. Effectuez des tests de régression. Vérifiez le moment où la notification devient visible par l’utilisateur ainsi que le comportement d’exécution en arrière-plan concerné sur les versions d’Android prises en charge par l’application.

La correction n’est étayée qu’après confirmation que le déclencheur initial ne reproduit plus l’exception exacte dans les chemins de service concernés. Un simple démarrage de l’application sans rapport avec le problème ne constitue pas une vérification suffisante, et aucune procédure ne doit être considérée comme garantie.