android - samsung - porque mi celular se bloquea solo a cada rato

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

Question

Tengo un servicio que se inicia (no está vinculado) por una actividad. Si la actividad se destruye (por ejemplo, al presionar el botón de retroceso), el servicio continúa ejecutándose, por supuesto, esto está destinado. Sin embargo, si saco la actividad de la lista de ''aplicaciones recientes'', el servicio se reinicia de inmediato. Esto es reproducible, cada vez que la actividad / aplicación se elimina de la lista, hay una nueva llamada al método onCreate del servicio. No hay llamada a onDestroy entre!

Primero, pensé que el servicio era asesinado por android, aunque no vi ninguna razón para el asesinato (ni la actividad ni el servicio hacen cosas que consumen recursos, de hecho son minimalistas y no hacen nada). Pero luego 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 resumen: 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, no solo se pierde el estado del servicio, sino también el trabajo que está haciendo el servicio. Solo quiero saber por qué el golpe es la razón de esto.

Answer 1

Al deslizar, su sistema NO garantiza que el sistema muera. No. Solo eliminas la tarea de aplicación (o la contraportada). La tarea de la aplicación NO es igual al proceso de la aplicación.

Entonces, si tiene trabajos de fondo (hilos, servicios, etc.) vinculados a su pila de respaldo y tiene una buena política de cancelación. El sistema puede intentar almacenar en caché el proceso si es adecuado para más adelante.

Sin embargo, si elimina los procesos de la aplicación desde el Administrador de tareas, eso significa que su proceso se eliminará y, por lo tanto, el sistema lo eliminará de forma agresiva de su JVM / sandbox.

Answer 2

Al pasar la aplicación de la lista de tareas recientes, se mata el proceso del sistema operativo que aloja la aplicación. Dado que su servicio se está ejecutando en el mismo proceso que sus actividades, esto mata efectivamente el servicio. NO llama onDestroy() en el servicio. Simplemente 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 cancelado. Sin embargo, cuando se reinicie el servicio, estará en un proceso recién creado (puede ver onCreate() llamado en el servicio), por lo que tendrá que comenzar el trabajo nuevamente.

Regla n. ° 1: no deslice nunca aplicaciones de la lista de tareas recientes ;-)

Answer 3

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

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

Answer 4

Utilice * START_NOT_STICKY * como retorno de onStartCommand

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
Log.v(TAG, "onStartCommand");
return START_NOT_STICKY;
}