ForegroundServiceDidNotStartInTimeException significa que Android inició un servicio en primer plano mediante Context.startForegroundService() o ContextCompat.startForegroundService(), pero el nuevo servicio no se promovió con ServiceCompat.startForeground() o Service.startForeground() en unos pocos segundos. Esto afecta a la API 26 y versiones posteriores. Android 12 y versiones posteriores identifican directamente la excepción, mientras que Android 8.0 a Android 11 pueden informar una RemoteServiceException con el mismo mensaje. La medida inicial más segura es confirmar la firma exacta en Logcat y determinar si la ruta que falla corresponde a un servicio nativo o a un trabajador en primer plano de WorkManager.

Confirma la excepción exacta y la versión de Android

Busca el mensaje Context.startForegroundService() did not then call Service.startForeground(). Según la documentación para solucionar problemas de servicios en primer plano de Android, Android genera esta familia de excepciones cuando un servicio iniciado con startForegroundService() no llama a startForeground() dentro del intervalo de inicio permitido.

Plataforma o ruta Firma esperada Siguiente rama
Android 12 y versiones posteriores ForegroundServiceDidNotStartInTimeException con el mensaje correspondiente Determinar si la aplicación usa un servicio nativo o un trabajador en primer plano de WorkManager
Android 8.0 a 11 RemoteServiceException con el mismo mensaje de startForegroundService()/startForeground() Usar el mismo diagnóstico de tiempo de promoción del servicio nativo, salvo que también esté presente el marcador de WorkManager
Trabajador en primer plano de WorkManager La familia de excepciones y, para la condición de carrera documentada, Re-initializing SystemForegroundService after a request to shut-down Usar el procedimiento específico de WorkManager solo cuando aparezca ese marcador secundario

La referencia de Context.startForegroundService proporciona el contexto de la API que desencadena el fallo. No clasifiques todas las excepciones RemoteServiceException como este fallo; debe estar presente el mensaje correspondiente.

Descarta otros fallos relacionados con servicios en primer plano

  • ForegroundServiceStartNotAllowedException se refiere a si Android permite iniciar el servicio desde segundo plano. Es un fallo independiente de Android 12 y versiones posteriores, descrito en las restricciones de Android para iniciar servicios desde segundo plano.
  • Los fallos por tiempo de espera de duración de un servicio en primer plano y los errores ANR de servicios de corta duración se producen después de límites de ejecución diferentes; no son variantes de este fallo de promoción durante el inicio.
  • Una SecurityException relacionada con el tipo de servicio en primer plano o con los permisos también pertenece a una familia de fallos distinta, aunque se produzca cerca de la llamada de promoción.

Si el mensaje exacto no aparece, no apliques esta guía como si los fallos fueran equivalentes.

Corrige un servicio nativo que no se promueve a tiempo

Cuándo corresponde: Usa esta ruta confirmada cuando el código de la aplicación inicie un servicio nativo mediante startForegroundService() o ContextCompat.startForegroundService() y Logcat contenga el mensaje exacto de promoción durante el inicio. No uses este procedimiento como sustituto del diagnóstico de una restricción de inicio desde segundo plano o de una condición de carrera de WorkManager.

Requisitos previos:

  • Un canal de notificaciones válido en Android 8.0 y versiones posteriores.
  • La notificación del servicio en primer plano creada antes de la promoción.
  • ServiceCompat disponible en el código de la aplicación cuando se use ServiceCompat.startForeground().

Los requisitos de notificaciones, manifiesto y tipos de servicios en primer plano pueden variar según el tipo de servicio y la versión de Android. Verifica los requisitos específicos de la aplicación antes de suponer que la llamada de promoción es válida; esta guía no propone declaraciones que no estén confirmadas para la aplicación.

  1. Crea el canal de notificaciones antes de la promoción. El canal ya debe estar disponible cuando se use la notificación del servicio en primer plano.
  2. Crea inmediatamente la notificación del servicio en primer plano. No dejes la creación de la notificación para después del acceso a la red, las operaciones de disco u otra inicialización prolongada.
  3. Llama a ServiceCompat.startForeground() en unos pocos segundos desde el inicio del servicio. Service.startForeground() cumple la misma función de promoción cuando se usa directamente. No inventes ni dependas de un plazo exacto más largo.
  4. Traslada el trabajo sustancial para después de la promoción. Las operaciones de red, disco y otras tareas de inicialización prolongadas no deben bloquear la promoción requerida.
  5. Revisa todas las condiciones y rutas del ciclo de vida. Confirma que cada instancia nueva del servicio llegue a la promoción al primer plano, incluidas las ramas que terminan antes o procesan distintas acciones de inicio.

Resultado esperado: Cada instancia nueva del servicio entra en primer plano antes de que comience el trabajo sustancial, y la excepción exacta no debería repetirse al volver a probar el escenario de inicio original. Este resultado debe verificarse, no darse por supuesto.

Riesgo: Bajo. Adelantar la promoción puede cambiar el momento en que aparece la notificación visible para el usuario y revelar problemas específicos de la aplicación relacionados con las notificaciones o el manifiesto que antes se producían más tarde.

Reversión: Si el cambio del ciclo de vida causa una regresión, restaura el flujo anterior del servicio mientras investigas. Mantén visible el fallo original durante las pruebas controladas en lugar de ocultarlo.

No añadas una espera arbitraria, no traslades la promoción a una devolución de llamada posterior ni sustituyas startForegroundService() por startService() como solución general. Esas acciones no son correcciones respaldadas para esta excepción y pueden empeorar u ocultar el fallo de temporización.

Si la secuencia de promoción prevista no se alcanza de forma consistente, inspecciona manualmente las ramas del ciclo de vida de la aplicación. Algunos informes de la comunidad mencionan interacciones con stopSelf(), stopService() y la publicación retrasada de notificaciones, pero la evidencia oficial proporcionada no confirma una solución universal para esos patrones. Trátalos como diagnósticos específicos de la aplicación, no como correcciones adicionales confirmadas.

Usa la corrección de WorkManager solo cuando aparezca el marcador de apagado

Cuándo corresponde: Usa esta rama únicamente cuando la ruta que falla sea un trabajador en primer plano de WorkManager que utilice setForeground() o setForegroundAsync() y Logcat incluya el marcador secundario exacto Re-initializing SystemForegroundService after a request to shut-down. Sin ese marcador, no supongas que la condición de carrera documentada de WorkManager causó el fallo.

Requisitos previos:

  • La ruta afectada debe usar un trabajador en primer plano de WorkManager.
  • El marcador exacto de apagado y reinicialización debe aparecer en Logcat.
  1. Confirma el marcador en Logcat. Conserva la excepción y el contexto del trabajador que aparecen alrededor para no confundir la condición de carrera con un fallo de temporización de un servicio nativo.
  2. Actualiza a la versión mantenida más reciente de WorkManager disponible para el proyecto. WorkManager 2.10.5 introdujo la corrección documentada para este fallo por solapamiento durante el apagado. No debe describirse como la versión actual sin comprobar las versiones disponibles en el momento de la publicación.
  3. Vuelve a probar el escenario de trabajadores en primer plano solapados. Usa los mismos tiempos y el mismo desencadenante del trabajador que anteriormente produjeron el fallo.
  4. Informa de cualquier problema restante en el sistema de seguimiento de incidencias de WorkManager. Incluye la excepción exacta, el marcador de apagado y los detalles de reproducción si la actualización documentada no resuelve el escenario probado.

Resultado esperado: WorkManager ya no debería reproducir el fallo documentado de apagado y reinicialización de SystemForegroundService durante la misma prueba con trabajadores solapados. Esto no demuestra que se hayan corregido otros fallos de trabajadores no relacionados.

Riesgo: Bajo, aunque una actualización de dependencias puede introducir cambios de comportamiento no relacionados. Realiza pruebas de regresión del comportamiento relevante de los trabajadores en primer plano y del trabajo en segundo plano.

Reversión: Vuelve a fijar la versión anterior solo si la actualización de WorkManager introduce una regresión no relacionada. En caso contrario, conserva la versión mantenida que contiene la corrección documentada.

Verifica que cada instancia del servicio se promueva a tiempo

La verificación debe reproducir el desencadenante original sin ocultar la excepción ni añadir cambios de temporización únicamente para que la prueba se complete correctamente.

  1. Repite el escenario original. Inicia el mismo servicio nativo o reproduce la misma secuencia de trabajadores en primer plano solapados que anteriormente causó el fallo.
  2. Mantén observable el fallo. No captures, ocultes ni retrases la excepción como prueba de que se corrigió.
  3. Para un servicio nativo, inspecciona todas las rutas. Confirma que cada instancia nueva cree la notificación válida y llegue a la promoción al primer plano antes de realizar operaciones de red, disco u otro trabajo sustancial.
  4. Para WorkManager, repite el solapamiento después de actualizar. Confirma que la prueba siga la misma ruta del trabajador en primer plano y que realmente se esté usando la versión mantenida de WorkManager.
  5. Revisa Logcat. Comprueba si vuelve a aparecer Context.startForegroundService() did not then call Service.startForeground(). En la rama de WorkManager, comprueba también si aparece Re-initializing SystemForegroundService after a request to shut-down.
  6. Realiza pruebas de regresión del comportamiento. Verifica el momento en que aparece la notificación visible para el usuario y el comportamiento relevante de ejecución en segundo plano en las versiones de Android compatibles con la aplicación.

La corrección solo se considera respaldada cuando el desencadenante original deja de reproducir la excepción exacta en las rutas de servicio relevantes. Iniciar una vez la aplicación en un escenario no relacionado no constituye una verificación suficiente, y ningún procedimiento debe considerarse garantizado.