samsung - El servicio en segundo plano de Android se reinicia cuando se mata la aplicación
porque se apaga mi celular de repente (7)
Estoy desarrollando una aplicación en la que se crea un servicio en segundo plano para recopilar datos del sensor. Estoy comenzando el servicio de mi actividad:
startService(new Intent(this, MyService.class));
Creé el servicio así que si la aplicación se destruye, el servicio en segundo plano aún continúa recopilando datos. Intenté esto, y funcionó hasta cierto punto. Mi problema es que cuando onCreate() la aplicación, el servicio parece reiniciarse porque se onCreate() servicio onCreate() y los métodos onStart() . ¿Hay alguna forma de que el servicio no se reinicie por favor?
ACTUALIZAR:
Como se sugiere en la respuesta a continuación, agregué el siguiente método en el servicio, pero no tuve suerte.
@Override
public int onStartCommand(Intent intent, int flags, int startId) {
return START_NOT_STICKY;
}
Cuando la memoria es baja, un servicio que se ejecuta en segundo plano se destruye automáticamente. En lugar de utilizar startService () para iniciar un servicio, intente utilizar StartForeground () en su lugar. El servicio se ejecuta en primer plano y nunca se eliminará, incluso si la memoria es baja.
Depende del valor devuelto en onStartCommand.
Debes devolver START_NOT_STICKY
De acuerdo con la documentation :
Para los servicios iniciados, hay dos modos principales de operación adicionales en los que pueden decidir ejecutarse, según el valor que devuelven desde onStartCommand (): START_STICKY se usa para servicios que se inician y detienen explícitamente según sea necesario, mientras se usan START_NOT_STICKY o START_REDELIVER_INTENT para servicios que solo deberían seguir ejecutándose mientras se procesan los comandos enviados a ellos
En resumen: si devuelve START_STICKY, el servicio se vuelve a crear siempre que los recursos estén disponibles. Si devuelve START_NOT_STICKY, debe reactivar el servicio enviando un nuevo intento.
Como todo esto despertó mi curiosidad, hice una aplicación de muestra para probar esto. Puede encontrar el zip con todas las fuentes aquí. Hay un botón startService y un botón stopService que hacen lo que esperaría de ellos. El servicio devuelve START_NOT_STICKY en onStartCommand. Puse tostadas en onCreate, onStartCommand y onDestroy.
Aquí lo que sucede:
- Si presiono inicio, se llaman onCreate y onStart
- Si presiono detener, se activa onDestroy
- Si presiono inicio dos veces, onCreate se llama una vez y onStartCommand dos veces
Entonces se comporta como uno esperaría.
Si inicio el servicio y elimino la aplicación como describió, no se llama a onDestroy pero ni onCreate ni onStart.
Si vuelvo a la aplicación y presiono comenzar de nuevo, se llama a onCreate , lo que significa que, como escribí antes, START_NOT_STICKY impide que el servicio se reinicie automáticamente.
Supongo que tienes algo más en tu aplicación que inicia el servicio nuevamente (tal vez un intento pendiente).
La aplicación y el servicio viven en el mismo proceso, lo que significa que cuando se mata la aplicación también lo hace su servicio. Cambiar el valor de retorno de onStartCommand no afecta este proceso. Simplemente le dice al Servicio que comience o pare cuando lo diga o cuando termine de hacer lo que necesita. Como mencioné en su comentario a su publicación original, establecerlo como un proceso en primer plano funcionó, pero eso solo está forzando al servicio a tener una alta prioridad, no a resolver el problema.
Para cambiar el Servicio para que se cancele por separado y suponiendo que se trata de un servicio iniciado en lugar de un servicio vinculado debido al uso de onStartCommand, especifique un nombre de proceso en el manifiesto para ese Servicio.
De la Guía del desarrollador de procesos e hilos :
La entrada de manifiesto para cada tipo de elemento de componente -
<activity>, <service>, <receiver>, and <provider>- admite un atributo android: process que puede especificar un proceso en el que se debe ejecutar ese componente. Puede establecer este atributo para que cada componente se ejecute en su propio proceso o para que algunos componentes compartan un proceso mientras que otros no. También puede establecer android: process para que los componentes de diferentes aplicaciones se ejecuten en el mismo proceso, siempre que las aplicaciones compartan el mismo ID de usuario de Linux y estén firmadas con los mismos certificados.Android podría decidir cerrar un proceso en algún momento, cuando la memoria es baja y es requerida por otros procesos que están sirviendo al usuario más inmediatamente. Por lo tanto, se destruyen los componentes de la aplicación que se ejecutan en el proceso anulado. Se inicia nuevamente un proceso para esos componentes cuando nuevamente hay trabajo para ellos.
De <service> en archivo de manifiesto :
android: proceso
El nombre del proceso donde se ejecutará el servicio. Normalmente, todos los componentes de una aplicación se ejecutan en el proceso predeterminado creado para la aplicación. Tiene el mismo nombre que el paquete de la aplicación. El atributo de proceso del elemento puede establecer un valor predeterminado diferente para todos los componentes. Pero el componente puede anular el valor predeterminado con su propio atributo de proceso, lo que le permite distribuir su aplicación en múltiples procesos.
Si el nombre asignado a este atributo comienza con dos puntos ('':''), se crea un nuevo proceso, privado para la aplicación, cuando es necesario y el servicio se ejecuta en ese proceso. Si el nombre del proceso comienza con un carácter en minúscula, el servicio se ejecutará en un proceso global de ese nombre, siempre que tenga permiso para hacerlo. Esto permite que los componentes en diferentes aplicaciones compartan un proceso, reduciendo el uso de recursos.
No estoy seguro de por qué votó la otra respuesta que mencionó esto. He utilizado este método en el pasado y, hoy, creé una aplicación de actividad simple con un servicio en un proceso diferente solo para asegurarme de que no estaba loco. Usé el Android Device Monitor para matar el proceso de la aplicación. Puede ver ambos procesos por separado en ADM y puede ver que cuando el proceso de la aplicación se cancela, el Servicio no lo hace.
Me encontré con el mismo problema y pude resolverlo haciendo que el servicio se ejecutara en un proceso global. Para ello, agregue lo siguiente a la etiqueta de manifiesto:
process = "com.myapp.ProcessName"
(Inventar cualquier nombre)
Cuando hice esto, descubrí que mi servicio no se eliminó (y se reinició) cuando la aplicación se borró de la lista. Presumiblemente, esto se debe a que el proceso de la aplicación se cancela cuando lo desliza, pero los procesos de servicio global no lo hacen.
La desventaja de esto es que la comunicación entre su aplicación y el servicio ahora tiene que ser a través de la interfaz de IBinder; no puede llamar directamente a funciones en la aplicación o servicio desde el otro, porque se están ejecutando en procesos diferentes.
Sé que es muy tarde para responder a esta pregunta, pero puede ser útil para otros. Esto realmente me ayudó para mi aplicación de reproductor de música.
Si hay servicios que pueden ser perjudiciales o pueden afectar la experiencia del usuario, como la música, etc., entonces en ese caso debe usar la Notificación y cuando el servicio se inicia correctamente, luego cree la Notificación y use la función.
startForeground(int Notification_id,Notification);
Esto ejecutará su servicio en segundo plano sin reiniciar y reiniciar sus métodos
Si está utilizando un IntentService, tiene un
onHandleIntent()
método donde debe colocar el código que debe ejecutarse. Se ejecuta en un hilo separado (no en un hilo de interfaz de usuario donde se ejecuta la aplicación), por lo tanto, su aplicación no debería afectarlo. Cuando el código ha terminado de ejecutarse, el hilo finaliza y el servicio se detiene automáticamente.
Start not sticky no funciona arriba de kitkat, y el otro onTaskRemoved no funciona arriba de Marshmellow. onTaskRemoved se puede usar manejando algunas excepciones. No funcionó en eso. Pero intenta eso.