ForegroundServiceDidNotStartInTimeException means Android started a foreground service through Context.startForegroundService() or ContextCompat.startForegroundService(), but the new service did not promote itself with ServiceCompat.startForeground() or Service.startForeground() within a few seconds. This affects API 26 and later. Android 12 and later name the exception directly, while Android 8.0 through Android 11 may report RemoteServiceException with the same message. The safest first action is to confirm the exact Logcat signature and determine whether the crashing path is a native service or a WorkManager foreground worker.

Confirm the exact exception and Android version

Look for the message Context.startForegroundService() did not then call Service.startForeground(). According to the Android foreground-service troubleshooting documentation, Android raises this exception family when a service started with startForegroundService() does not call startForeground() within the permitted startup interval.

Platform or path Expected signature Next branch
Android 12 and later ForegroundServiceDidNotStartInTimeException with the matching message Determine whether the app uses a native service or WorkManager foreground worker
Android 8.0-11 RemoteServiceException with the same startForegroundService()/startForeground() message Use the same native-service timing diagnosis unless the WorkManager marker is also present
WorkManager foreground worker The exception family plus, for the documented race, Re-initializing SystemForegroundService after a request to shut-down Use the WorkManager-specific procedure only when that secondary marker appears

The Context.startForegroundService reference provides the trigger API context. Do not classify every RemoteServiceException as this failure; the corresponding message must be present.

Exclude adjacent foreground-service failures

  • ForegroundServiceStartNotAllowedException concerns whether Android permits the service to start from the background. It is a separate Android 12+ failure covered by Android background-start restrictions.
  • Foreground-service duration timeout crashes and short-service ANRs occur after different runtime limits; they are not variants of this startup-promotion failure.
  • A foreground-service-type or permission-related SecurityException is also a separate failure family, even if it occurs near the promotion call.

If the exact message is absent, do not apply this guide as though the failures were equivalent.

Fix a native service that misses foreground promotion

When this applies: Use this confirmed path when app code starts a native service with startForegroundService() or ContextCompat.startForegroundService(), and Logcat contains the exact startup-promotion message. Do not use this procedure as a substitute for diagnosing a background-start restriction or a WorkManager race.

Prerequisites:

  • A valid notification channel on Android 8.0 and later.
  • The foreground notification built before promotion.
  • ServiceCompat available in the app code when using ServiceCompat.startForeground().

Notification, manifest and foreground-service-type requirements can vary with the service type and Android version. Verify the app-specific requirements before assuming the promotion call is valid; this guide does not invent declarations that are not confirmed for the app.

  1. Create the notification channel before promotion. The channel must already be available when the foreground notification is used.
  2. Build the foreground notification immediately. Do not place notification creation after network access, disk operations or other lengthy initialization.
  3. Call ServiceCompat.startForeground() within a few seconds of service start. Service.startForeground() serves the same promotion purpose when used directly. Do not invent or rely on a longer exact deadline.
  4. Move substantive work after promotion. Network, disk and other long initialization work must not block the required promotion.
  5. Audit every conditional and lifecycle path. Confirm that every newly created service instance reaches foreground promotion, including branches that return early or handle different start actions.

Expected result: Each newly created service enters the foreground before substantive work begins, and the exact exception should not recur when the original start scenario is retested. This result must be verified rather than assumed.

Risk: Low. Moving promotion earlier can change when the user-visible notification appears and can expose app-specific notification or manifest problems that previously occurred later.

Rollback: If the lifecycle change causes a regression, restore the previous service flow while investigating. Keep the original crash visible in controlled testing rather than suppressing it.

Do not add an arbitrary sleep, move promotion into a later callback, or replace startForegroundService() with startService() as a blanket workaround. Those actions are not supported corrections for this exception and may worsen or conceal the timing failure.

If the intended promotion sequence is not reached consistently, inspect the app’s lifecycle branches manually. Community reports mention interactions with stopSelf(), stopService() and delayed notification posting, but the supplied official evidence does not confirm a universal repair for those patterns. Treat them as app-specific diagnostics, not as additional confirmed fixes.

Use the WorkManager fix only when the shutdown marker appears

When this applies: Use this branch only when the crashing path is a WorkManager foreground worker using setForeground() or setForegroundAsync() and Logcat includes the exact secondary marker Re-initializing SystemForegroundService after a request to shut-down. Without that marker, do not assume the documented WorkManager race caused the crash.

Prerequisites:

  • The affected path must use a WorkManager foreground worker.
  • The exact shutdown/reinitialization marker must be present in Logcat.
  1. Confirm the marker in Logcat. Preserve the surrounding exception and worker context so the race is not confused with a native-service timing failure.
  2. Update to the most recent maintained WorkManager version available to the project. WorkManager 2.10.5 introduced the documented fix for this shutdown-overlap crash. It should not be described as the current release without a publication-time version check.
  3. Retest the overlapping foreground-worker scenario. Use the same worker timing and trigger that previously produced the crash.
  4. Report a remaining issue to the WorkManager issue tracker. Include the exact exception, shutdown marker and reproduction details if the documented update path does not resolve the tested scenario.

Expected result: WorkManager should no longer reproduce the documented SystemForegroundService shutdown/reinitialization crash during the same overlapping-worker test. This does not establish that unrelated worker failures are fixed.

Risk: Low, but a dependency update can introduce unrelated behavior changes. Regression-test relevant foreground-worker and background-work behavior.

Rollback: Pin back only if the WorkManager update introduces an unrelated regression. Otherwise, retain the maintained version containing the documented fix.

Verify that every service instance is promoted in time

Verification must reproduce the original trigger without suppressing the exception or adding timing changes solely to make the test pass.

  1. Repeat the original scenario. Start the same native service or reproduce the same overlapping foreground-worker sequence that previously crashed.
  2. Keep the failure observable. Do not catch, hide or delay the exception as proof of repair.
  3. For a native service, inspect every path. Confirm that each newly created instance builds the valid notification and reaches foreground promotion before network, disk or other substantive work.
  4. For WorkManager, repeat the overlap after updating. Confirm that the test follows the same foreground-worker path and that the maintained WorkManager version is actually in use.
  5. Review Logcat. Check for recurrence of Context.startForegroundService() did not then call Service.startForeground(). In the WorkManager branch, also check for Re-initializing SystemForegroundService after a request to shut-down.
  6. Regression-test behavior. Verify the user-visible notification timing and relevant background execution behavior on the Android versions the app supports.

The correction is supported only after the original trigger no longer reproduces the exact exception across the relevant service paths. A single unrelated app launch is not sufficient verification, and no procedure should be treated as guaranteed.

Related reading

For a separate Android network-security error, see this related Android troubleshooting guide. Cleartext HTTP policy does not cause this foreground-service startup exception.