ForegroundServiceDidNotStartInTimeException bedeutet, dass Android einen Vordergrunddienst über Context.startForegroundService() oder ContextCompat.startForegroundService() gestartet hat, der neue Dienst sich aber nicht innerhalb weniger Sekunden mit ServiceCompat.startForeground() oder Service.startForeground() in den Vordergrund versetzt hat. Dies betrifft API 26 und höher. Unter Android 12 und höher wird die Ausnahme direkt benannt, während Android 8.0 bis Android 11 möglicherweise eine RemoteServiceException mit derselben Meldung ausgeben. Als sicherste erste Maßnahme sollten Sie die genaue Logcat-Signatur bestätigen und feststellen, ob der Absturzpfad einen nativen Dienst oder einen WorkManager-Vordergrund-Worker betrifft.

Genaue Ausnahme und Android-Version bestätigen

Suchen Sie nach der Meldung Context.startForegroundService() did not then call Service.startForeground(). Laut der Android-Dokumentation zur Fehlerbehebung bei Vordergrunddiensten löst Android diese Ausnahmefamilie aus, wenn ein mit startForegroundService() gestarteter Dienst nicht innerhalb des zulässigen Startzeitraums startForeground() aufruft.

Plattform oder Pfad Erwartete Signatur Nächster Diagnosezweig
Android 12 und höher ForegroundServiceDidNotStartInTimeException mit der passenden Meldung Ermitteln, ob die App einen nativen Dienst oder einen WorkManager-Vordergrund-Worker verwendet
Android 8.0–11 RemoteServiceException mit derselben Meldung zu startForegroundService()/startForeground() Dieselbe Zeitablaufdiagnose für native Dienste verwenden, sofern nicht auch der WorkManager-Marker vorhanden ist
WorkManager-Vordergrund-Worker Die Ausnahmefamilie und beim dokumentierten Wettlauf zusätzlich Re-initializing SystemForegroundService after a request to shut-down Das WorkManager-spezifische Verfahren nur verwenden, wenn dieser zusätzliche Marker erscheint

Die Referenz zu Context.startForegroundService erläutert den Kontext der auslösenden API. Ordnen Sie nicht jede RemoteServiceException diesem Fehler zu; die entsprechende Meldung muss vorhanden sein.

Ähnliche Fehler bei Vordergrunddiensten ausschließen

  • ForegroundServiceStartNotAllowedException betrifft die Frage, ob Android den Start des Dienstes aus dem Hintergrund zulässt. Dies ist ein separater Fehler unter Android 12 und höher, der in den Android-Einschränkungen für den Start aus dem Hintergrund behandelt wird.
  • Abstürze aufgrund von Laufzeitüberschreitungen bei Vordergrunddiensten und ANRs kurz laufender Dienste treten nach anderen Laufzeitgrenzen auf. Sie sind keine Varianten dieses Fehlers bei der Aktivierung während des Starts.
  • Eine SecurityException im Zusammenhang mit dem Typ oder den Berechtigungen eines Vordergrunddienstes gehört ebenfalls zu einer anderen Fehlerfamilie, selbst wenn sie in der Nähe des Aktivierungsaufrufs auftritt.

Wenn die genaue Meldung fehlt, wenden Sie diese Anleitung nicht so an, als seien die Fehler gleichwertig.

Nativen Dienst korrigieren, der nicht rechtzeitig in den Vordergrund wechselt

Wann dieses Verfahren gilt: Verwenden Sie diesen bestätigten Pfad, wenn der App-Code einen nativen Dienst mit startForegroundService() oder ContextCompat.startForegroundService() startet und Logcat die genaue Meldung zur fehlenden Vordergrundaktivierung enthält. Verwenden Sie dieses Verfahren nicht als Ersatz für die Diagnose einer Einschränkung beim Start aus dem Hintergrund oder eines WorkManager-Wettlaufs.
Voraussetzungen:

  • Ein gültiger Benachrichtigungskanal unter Android 8.0 und höher.
  • Die Vordergrundbenachrichtigung wurde vor der Aktivierung erstellt.
  • ServiceCompat ist im App-Code verfügbar, wenn ServiceCompat.startForeground() verwendet wird.

Die Anforderungen an Benachrichtigungen, Manifest und Vordergrunddiensttyp können je nach Diensttyp und Android-Version variieren. Prüfen Sie die app-spezifischen Anforderungen, bevor Sie davon ausgehen, dass der Aktivierungsaufruf gültig ist. Diese Anleitung ergänzt keine Deklarationen, die für die App nicht bestätigt wurden.

  1. Erstellen Sie den Benachrichtigungskanal vor der Aktivierung. Der Kanal muss bereits verfügbar sein, wenn die Vordergrundbenachrichtigung verwendet wird.
  2. Erstellen Sie die Vordergrundbenachrichtigung sofort. Verschieben Sie die Erstellung der Benachrichtigung nicht hinter Netzwerkzugriffe, Datenträgeroperationen oder andere langwierige Initialisierungsschritte.
  3. Rufen Sie ServiceCompat.startForeground() innerhalb weniger Sekunden nach dem Dienststart auf. Service.startForeground() erfüllt bei direkter Verwendung denselben Zweck. Legen Sie keine längere exakte Frist fest und verlassen Sie sich nicht darauf.
  4. Verschieben Sie die eigentliche Arbeit hinter die Aktivierung. Netzwerk-, Datenträger- und andere langwierige Initialisierungsarbeiten dürfen die erforderliche Aktivierung nicht blockieren.
  5. Prüfen Sie jeden bedingten Ablauf und jeden Lebenszykluspfad. Stellen Sie sicher, dass jede neu erstellte Dienstinstanz in den Vordergrund wechselt. Dies gilt auch für Zweige, die frühzeitig beendet werden oder unterschiedliche Startaktionen verarbeiten.

Erwartetes Ergebnis: Jede neu erstellte Dienstinstanz wechselt vor Beginn der eigentlichen Arbeit in den Vordergrund. Die genaue Ausnahme sollte beim erneuten Testen des ursprünglichen Startszenarios nicht mehr auftreten. Dieses Ergebnis muss geprüft und darf nicht nur angenommen werden.
Risiko: Niedrig. Eine frühere Aktivierung kann den Zeitpunkt ändern, zu dem die sichtbare Benachrichtigung erscheint, und app-spezifische Probleme mit Benachrichtigungen oder dem Manifest offenlegen, die zuvor erst später aufgetreten sind.
Rollback: Falls die Änderung am Lebenszyklus eine Regression verursacht, stellen Sie den vorherigen Dienstablauf während der Untersuchung wieder her. Halten Sie den ursprünglichen Absturz in kontrollierten Tests weiterhin sichtbar, anstatt ihn zu unterdrücken.

Fügen Sie keine willkürliche Wartezeit ein, verschieben Sie die Aktivierung nicht in einen späteren Callback und ersetzen Sie startForegroundService() nicht pauschal durch startService(). Diese Maßnahmen sind keine belegten Korrekturen für diese Ausnahme und können den Zeitablauffehler verschlimmern oder verbergen.

Wenn die vorgesehene Aktivierungssequenz nicht zuverlässig erreicht wird, prüfen Sie die Lebenszykluszweige der App manuell. In Community-Berichten werden Wechselwirkungen mit stopSelf(), stopService() und einer verzögerten Anzeige der Benachrichtigung erwähnt. Die vorliegenden offiziellen Belege bestätigen für diese Muster jedoch keine allgemeingültige Reparatur. Behandeln Sie sie als app-spezifische Diagnosehinweise und nicht als zusätzliche bestätigte Lösungen.

WorkManager-Korrektur nur beim Marker für das Herunterfahren verwenden

Wann dieses Verfahren gilt: Verwenden Sie diesen Zweig nur, wenn der Absturzpfad einen WorkManager-Vordergrund-Worker mit setForeground() oder setForegroundAsync() betrifft und Logcat den genauen zusätzlichen Marker Re-initializing SystemForegroundService after a request to shut-down enthält. Ohne diesen Marker dürfen Sie nicht davon ausgehen, dass der dokumentierte WorkManager-Wettlauf den Absturz verursacht hat.
Voraussetzungen:

  • Der betroffene Pfad muss einen WorkManager-Vordergrund-Worker verwenden.
  • Der genaue Marker für das Herunterfahren und die erneute Initialisierung muss in Logcat vorhanden sein.
  1. Bestätigen Sie den Marker in Logcat. Bewahren Sie die umgebende Ausnahme und den Worker-Kontext auf, damit der Wettlauf nicht mit einem Zeitablauffehler eines nativen Dienstes verwechselt wird.
  2. Aktualisieren Sie auf die neueste gepflegte WorkManager-Version, die für das Projekt verfügbar ist. WorkManager 2.10.5 führte die dokumentierte Korrektur für diesen Absturz bei einer Überschneidung mit dem Herunterfahren ein. Ohne eine Versionsprüfung zum Veröffentlichungszeitpunkt sollte diese Version nicht als aktuelle Version bezeichnet werden.
  3. Testen Sie das Szenario mit sich überschneidenden Vordergrund-Workern erneut. Verwenden Sie denselben Worker-Zeitablauf und denselben Auslöser, die zuvor den Absturz verursacht haben.
  4. Melden Sie ein verbleibendes Problem im WorkManager-Issue-Tracker. Geben Sie die genaue Ausnahme, den Marker für das Herunterfahren und die Reproduktionsschritte an, wenn der dokumentierte Aktualisierungspfad das getestete Szenario nicht behebt.

Erwartetes Ergebnis: WorkManager sollte den dokumentierten Absturz beim Herunterfahren und erneuten Initialisieren von SystemForegroundService im selben Test mit sich überschneidenden Workern nicht mehr reproduzieren. Dies belegt nicht, dass andere Worker-Fehler behoben wurden.
Risiko: Niedrig, allerdings kann eine Abhängigkeitsaktualisierung andere Verhaltensänderungen verursachen. Führen Sie Regressionstests für die relevanten Vordergrund-Worker und die Hintergrundarbeit durch.
Rollback: Setzen Sie die Version nur dann zurück, wenn die WorkManager-Aktualisierung eine nicht damit zusammenhängende Regression verursacht. Behalten Sie andernfalls die gepflegte Version mit der dokumentierten Korrektur bei.

Prüfen, ob jede Dienstinstanz rechtzeitig in den Vordergrund wechselt

Bei der Überprüfung muss der ursprüngliche Auslöser reproduziert werden, ohne die Ausnahme zu unterdrücken oder Zeitabläufe nur deshalb zu ändern, damit der Test erfolgreich ist.

  1. Wiederholen Sie das ursprüngliche Szenario. Starten Sie denselben nativen Dienst oder reproduzieren Sie dieselbe Abfolge sich überschneidender Vordergrund-Worker, die zuvor zum Absturz geführt hat.
  2. Halten Sie den Fehler sichtbar. Fangen Sie die Ausnahme nicht ab und verbergen oder verzögern Sie sie nicht als vermeintlichen Nachweis einer Reparatur.
  3. Prüfen Sie bei einem nativen Dienst jeden Pfad. Stellen Sie sicher, dass jede neu erstellte Instanz die gültige Benachrichtigung erstellt und vor Netzwerk-, Datenträger- oder anderen wesentlichen Arbeiten in den Vordergrund wechselt.
  4. Wiederholen Sie bei WorkManager die Überschneidung nach der Aktualisierung. Stellen Sie sicher, dass der Test denselben Vordergrund-Worker-Pfad verwendet und tatsächlich die gepflegte WorkManager-Version eingesetzt wird.
  5. Prüfen Sie Logcat. Kontrollieren Sie, ob Context.startForegroundService() did not then call Service.startForeground() erneut auftritt. Prüfen Sie im WorkManager-Zweig zusätzlich auf Re-initializing SystemForegroundService after a request to shut-down.
  6. Führen Sie Regressionstests durch. Prüfen Sie den Zeitpunkt der sichtbaren Benachrichtigung und das relevante Verhalten bei der Ausführung im Hintergrund auf den von der App unterstützten Android-Versionen.

Die Korrektur gilt erst dann als belegt, wenn der ursprüngliche Auslöser die genaue Ausnahme über die relevanten Dienstpfade hinweg nicht mehr reproduziert. Ein einzelner, nicht damit zusammenhängender App-Start reicht als Überprüfung nicht aus. Kein Verfahren sollte als garantiert betrachtet werden.