El servicio Android se bloquea después de que la aplicación se borre de la lista de aplicaciones recientes

Tengo un servicio que se inicia (no limitado) por una actividad. Si la actividad se destruye (por ejemplo, presionando el botón de retroceso), el servicio continúa ejecutándose, esto es, por supuesto, la intención. Sin embargo, si deslizo la actividad de la lista de "aplicaciones recientes", el servicio se reinicia inmediatamente. Esto es reproducible, cada vez que se borra la actividad / aplicación de la lista, hay una nueva llamada al método onCreate del servicio. ¡Ninguna llamada a onDestroy en el medio!

Primero pensé que el servicio era asesinado por android, aunque no veía ninguna razón para matar (ni la actividad ni el servicio consumen recursos, de hecho son minimalistas y no hacen nada). Pero entonces me di cuenta de que el servicio realmente se bloquea.

V/MainActivity(856): onDestroy // swipe out of the list I/ActivityManager(287): Killing 856:com.example.myapp/u0a10050: remove task W/ActivityManager(287): Scheduling restart of crashed service com.example.myapp/.TestService in 5000ms 

El código no es digno de mención, pero aquí está

Actividad:

 public class MainActivity extends Activity { private static final String TAG = "MainActivity"; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); Log.v(TAG, "onCreate, starting service..."); startService(new Intent(this, TestService.class)); } @Override protected void onStart() { super.onStart(); Log.v(TAG, "onStart"); } @Override protected void onDestroy() { super.onDestroy(); Log.v(TAG, "onDestroy"); } //[...] } 

Servicio:

 public class TestService extends Service { private static final String TAG = "Service"; // onBind omitted @Override public int onStartCommand(Intent intent, int flags, int startId) { Log.v(TAG, "onStartCommand"); return super.onStartCommand(intent, flags, startId); } @Override public void onDestroy() { super.onDestroy(); Log.v(TAG, "onDestroy"); } } 

En pocas palabras: Mi servicio es independiente del ciclo de vida de la actividad, pero solo mientras no elimine la aplicación de la lista de aplicaciones recientes. En ese caso, el servicio se reinicia pero sin una llamada a onDestroy.

Cada vez que esto sucede, se pierde no sólo el estado del servicio, sino también el trabajo que el servicio está haciendo. Sólo quiero saber por qué el golpe es la razón de esto.

4 Solutions collect form web for “El servicio Android se bloquea después de que la aplicación se borre de la lista de aplicaciones recientes”

Cambiar la aplicación de la lista de tareas recientes realmente elimina el proceso del sistema operativo que aloja la aplicación. Dado que su servicio se ejecuta en el mismo proceso que sus actividades, esto efectivamente mata el servicio. No llama a onDestroy() en el servicio. Sólo mata el proceso. Auge. Muerto. Ido. Su servicio no se bloquea .

Dado que su servicio devolvió START_STICKY desde la llamada a onStartCommand() , Android reconoce que su servicio debe reiniciarse y programa un reinicio del servicio fallecido. Sin embargo, cuando su servicio se reinicie será en un proceso recién creado (puede ver onCreate() llamado en el servicio), por lo que tendrá que iniciar el trabajo de nuevo.

Regla # 1: Nunca deslizar las aplicaciones de la lista de tareas recientes 😉

Al pasar, no harás que el proceso de la aplicación sea asesinado. No. Sólo se elimina la tarea de aplicación (o pila trasera). La tarea de aplicación NO es igual al proceso de aplicación.

Así que si usted tiene algún trabajo de fondo (hilo, servicio, etc) atado a su pila trasera y tiene una política de cancelación buena, a continuación, los servicios relacionados se recuperarán también.

Si elimina los procesos de aplicación del Administrador de tareas, significa que el proceso (asumiendo que su aplicación está vinculada a un proceso que es el caso habitual) se eliminará y, por lo tanto, su jvm / sandbox se eliminará junto con Todos los recursos pertenecen a ese proceso agresivamente por el sistema.

Tal vez puede ser un problema con los receptores de difusión definidos en el manifiesto.

¿Tiene algún receptor / filtro de intenciones definido en su manifiesto en el nivel de aplicación? Solía ​​tener el mismo tipo de problema y se debía al receptor declarado en el manifiesto en el nivel de aplicación

Utilizar * START_NOT_STICKY * como onStartCommand return

 @Override public int onStartCommand(Intent intent, int flags, int startId) { Log.v(TAG, "onStartCommand"); return START_NOT_STICKY; } 
  • Android startActivity de la intención en el servicio
  • Espera en startService antes de bindService
  • ¿Cómo detener / cancelar el administrador de alarmas en otra actividad?
  • OnStart () y onStartCommand () siguen llamados en 2.0 y superiores
  • Java.lang.IllegalAccessError ref de clase en la clase preverified resuelto a la implementación inesperada
  • ¿Cómo puedo llamar a startIntentSenderForResult en el servicio correctamente?
  • Firebase + Android - Notificaciones ChildAdded - ¿Cómo obtener sólo New Childs?
  • Varias TextViews se actualizan muy lentamente
  • StopService () detendrá un servicio de primer plano?
  • No se puede iniciar el servicio con null
  • Nombre de la Actividad o Receptor que llama al Servicio
  • FlipAndroid es un fan de Google para Android, Todo sobre Android Phones, Android Wear, Android Dev y Aplicaciones para Android Aplicaciones.