Android Service d'arrière-plan est de redémarrer lorsque l'application est tué

Je développe une application dans laquelle un service d'arrière-plan est créé pour recueillir des données de capteur. Je suis en train de créer le service de mon activité:

startService(new Intent(this, MyService.class));

J'ai créé le service, de sorte que si la demande est détruit, le service d'arrière-plan continue à recueillir des données. J'ai essayé cela, et cela a fonctionné dans une certaine mesure. Mon problème est que quand je vais tuer l'application, le service semble redémarrer car le onCreate() service et la onStart() méthodes sont invoquées. Est-il de toute façon avec laquelle le service n'est pas redémarré s'il vous plaît?

Mise à JOUR:

Comme suggéré dans la réponse ci-dessous, j'ai ajouté la méthode suivante dans le service, mais pas de chance.

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
    return START_NOT_STICKY;
}

ce qui se passe pour moi aussi. Et je ne fais pas tout se lie, soit
Vous ne le mentionnez pas, donc: avez-vous essayé de spécifier de séparer les processus global de votre service dans le AndroidManifest?
trouvez-vous une solution? merci de me guider si tout
J'ai fini à l'aide d'un premier plan de service. Ce type de service est considérée comme un processus que l'utilisateur est activement à la connaissance et, par conséquent, le système ne peut pas le considérer comme un candidat processus à tuer lorsqu'il est faible sur la mémoire. Afin de s'assurer que l'utilisateur est conscient de le processus en cours d'exécution, il doit fournir une notification qui ne peut être rejetée lorsque le service est arrêté.

InformationsquelleAutor duncanportelli | 2013-03-16

20

Il dépend de la valeur retournée dans onStartCommand.

Vous devez retourner START_NOT_STICKY

Selon la la documentation:

Pour les services démarrés, il existe deux grands modes de fonctionnement, ils peuvent décider d'exécution, en fonction de la valeur de retour de onStartCommand(): START_STICKY est utilisé pour les services qui sont explicitement démarré et arrêté, tout START_NOT_STICKY ou START_REDELIVER_INTENT sont utilisées pour des services qui ne devraient continuer à fonctionner pendant le traitement de toutes les commandes envoyées à eux

En bref:
Si vous retournez START_STICKY le service soit recréé à chaque fois que les ressources sont disponibles. Si vous retournez START_NOT_STICKY vous devez réactiver le service d'envoi d'une nouvelle intention.

Depuis tous ce qui a provoqué ma curiosité, j'ai fait un exemple d'application pour tester cela. Vous pouvez trouver le zip avec tous les les sources ici
Il y a un startService bouton et un stopService bouton que de faire ce que vous attendez d'eux.
Le service renvoie START_NOT_STICKY dans onStartCommand.
J'ai placé les tartines dans onCreate, onStartCommand et onDestroy.

Ici ce qui se passe:
- Si j'appuie sur démarrer, onCreate et onStart sont appelés
- Si j'appuie sur stop, onDestroy est déclenchée
- Si j'appuyez deux fois sur start, onCreate est appelé une fois et onStartCommand deux fois
De sorte qu'il se comporte comme l'on pourrait s'attendre.

Si je démarre le service et tuer l'application que vous l'avez décrit, onDestroy n'est pas appelé mais ni onCreate ou en démarrage.

Si je revenir à l'application et j'appuyez de nouveau sur start, onCreate est appelée ce qui signifie que, comme je l'ai écrit avant, START_NOT_STICKY empêche le service pour obtenir automatiquement redémarré.

Je suppose que vous avez quelque chose d'autre dans votre application qui démarre le service de nouveau (peut-être en attente d'un but).
- J'ai déjà essayé, mais le problème a persisté.
- Comment avez-vous "tuer" l'application? Et comment savez-vous que onCreate() et onStart() sont appelées de plus et plus?
- J'ai tuer l'application, effectuez un balayage à l'écart de l'application dans les Applications Récentes bac (j'ai un Galaxy Nexus en cours d'exécution sur Android 4.1.1). Je sais que le onCreate() et onStart() sont appelés encore une fois parce que je afficher une notification toast au début des 2 méthodes
- Je suis de tuer l'application comme indiqué ici: youtube.com/watch?v=XVyXCrM-3zw
- Ne vous liez l'activité du service?
- Non, Monsieur. Je n'ai pas
- J'ai arrêter le service lorsque l'utilisateur appuie sur un bouton de l'activité. Ma question est: comment puis-je garder le service en cours d'exécution en douceur, sans redémarrer, même si l'application est tué?
- Faut y aller maintenant. Je vais creuser en elle quand je serai de retour.
- Ok. Merci s'accoupler. Amusez-vous 🙂
- Merci pour votre demande. Quand j'ai tuer l'application que vous m'avez envoyé, bien que la onDestroy() n'est pas appelée, le service n'a pas de continuer à courir, et il se termine. Je peux vérifier cela à partir de mon gestionnaire des tâches. Quand j'ai changé le service de START_STICKY, et tué l'application, le service est redémarré. Je pense que je dois vivre avec elle.
- START_NOT_STICKY est de courte durée des services (où vous n'avez pas l'esprit si elle se ferme immédiatement), comme décrit par la cité de la documentation ci-dessus. Même si elle permet d'éviter le problème d'une certaine manière, il ne semble pas une solution à privilégier pour une longue durée de vie service d'arrière-plan. (J'aurais pensé qu'il pourrait arrêter Android de redémarrer le service, mais pas l'arrêter de le tuer en premier lieu.)
InformationsquelleAutor fedepaol
4

L'application et le service en direct sur le même processus, ce qui signifie que lorsque l'application est tué, donc, est à votre service. La modification de la valeur de retour de onStartCommand n'a pas d'incidence sur ce processus. Il indique simplement que le Service soit start/stop lorsque vous le dire ou quand elle a fini de faire ce qu'il doit. Comme mentionné dans votre commentaire votre post original, de le définir comme un processus d'arrière-plan a fonctionné, mais c'est vraiment juste de forcer le service une priorité haute, non à la résolution du problème.

Pour changer de Service, de sorte qu'il est tué séparément et en supposant que c'est un service démarré plutôt que d'une borne de service en raison de l'utilisation de onStartCommand, spécifiez un nom de processus dans le manifeste pour ce Service.

De la Les processus et Threads Guide du Développeur:

Le manifeste entrée pour chaque type de composant de l'élément de <activity>, <service>, <receiver>, and <provider>—
prend en charge android:processus d'attribut qui peut indiquer un
processus dans lequel le composant doit être exécuté. Vous pouvez définir
cette
attribut de sorte que chaque composant s'exécute dans son propre processus ou si
que certains composants de partager un processus tandis que
d'autres ne le font pas. Vous pouvez également définir android:processus, de sorte que
composants de différentes applications s'exécutent dans le même
processus—à condition que les applications partagent le même
Linux ID utilisateur et sont signés avec les mêmes certificats.

Android peut décider d'arrêter un processus
point, lorsque la mémoire est faible et est requis par d'autres
les processus qui sont plus immédiatement servir l'utilisateur.
Les composants de l'Application s'exécutant dans le processus de
tués sont donc détruites. Un processus est lancé
de nouveau pour ces composants quand il y a encore du travail à faire pour eux.

De <de service> dans le Fichier de Manifeste:

android:processus

Le nom du processus où le service est exécuté.
Normalement, tous les composants d'une application par défaut dans le processus de
créé pour l'application. Il a le même nom que l'application
package. L'élément du processus d'attribut peut définir un
par défaut différente pour tous les composants. Mais composant peut remplacer la
par défaut avec son propre processus d'attribut, vous permettant de diffuser votre
application à travers de multiples processus.

Si le nom attribué à ce
attribut commence par un signe deux-points (':'), un nouveau processus, privé de la
application, est créé lorsque c'est nécessaire, et le service s'exécute dans ce
processus. Si le nom du processus commence avec un caractère en minuscule, le
le service sera exécuté dans un processus global de ce nom, à condition qu'il
a la permission de le faire. Cela permet de composants dans les différents
des applications à partager un processus de réduction de l'utilisation des ressources.

Ne sais pas pourquoi l'autre réponse, qui a mentionné que c'était vers le bas voté. J'ai utilisé cette méthode dans le passé et, aujourd'hui, a créé une simple Activité d'application avec un Service sur un processus différent juste pour s'assurer que je n'étais pas folle. J'ai utilisé un Appareil Android Moniteur de tuer l'application du processus. Vous pouvez voir à la fois, des processus distincts dans le SMA et peut voir que lorsque l'application du processus est tué, le Service ne l'est pas.

InformationsquelleAutor Plumbus
1

Commencer pas collant ne fonctionne pas au-dessus de kitkat, et de l'autre onTaskRemoved ne fonctionne pas au-dessus de Marshmellow.
onTaskRemoved pourrait être utilisé par les traités de certaines exceptions. N'a pas travaillé sur le sujet. Mais essayez celui-là.

InformationsquelleAutor Minkoo
0

Si vous utilisez un IntentService, il a un
```
onHandleIntent() 
```
méthode où vous devez placer le code qui doit être exécuté. Il est exécuté dans un thread séparé (pas un thread d'INTERFACE utilisateur où votre application s'exécute) donc votre application ne devrait pas l'affecter. Lorsque le code a fini de s'exécuter, le thread est terminé et que le service est arrêté automatiquement.
- Je pense que sa ne se réfère pas à un IntentService (qui a le onHandleINtent méthode), mais à une plaine (Service).
- Il n'a pas préciser, mais sans doute vous avez raison.
- Désolé, je suis un newbie. Oui, je fais référence à une 'simple'
InformationsquelleAutor Marcin S.
0

Je sais que je suis beaucoup en retard pour répondre à cette question, mais peut-être il peut être utile à d'autres. Cela m'a vraiment aidé pour mon Application Lecteur de Musique.

Si il y a des services qui peuvent être perturbateurs ou peuvent affecter l'expérience de l'utilisateur comme de la musique, etc , alors dans ce cas, vous devez utiliser la Notification et lorsque le service est démarré, puis créer la Notification et l'utilisation de la fonction
```
startForeground(int Notification_id,Notification);
```
Cela permettra de exécuter votre service en arrière-plan sans redémarrer et reinvoking ses méthodes

https://developer.android.com/reference/android/app/Service.html

InformationsquelleAutor abissa
-2

Lorsque la mémoire est faible, un service qui s'exécute en arrière-plan est automatiquement tué. Au lieu d'utiliser startService() pour démarrer un service, essayez d'utiliser StartForeground() à la place. Le service s'exécute en premier plan et ne sera jamais tué, même si la mémoire est faible.
- Vous n'avez pas lu la question (correctement).
- pas strictement vrai à propos de la "jamais être tué," il peut être tué dans l'extrême circs, peu probable mais possible
InformationsquelleAutor Ankush Wadhwa
-2

J'ai rencontré le même problème et a pu le résoudre en faisant le service exécuté dans un processus global. Pour ce faire, ajoutez les lignes suivantes à la manifester tag:

processus="com.myapp.ProcessName"

(Faire jusqu'à ce que le nom.)

Quand j'ai fait ce que j'ai trouvé que mon service n'a pas été tué (et redémarré) lorsque l'application est glissée hors de la liste. Sans doute c'est parce que l'application est tué lorsque vous glissez le tout, mais le processus de service ne sont pas.

L'inconvénient de cette est que la communication entre votre application et le service doit être maintenant via le IBinder de l'interface; vous ne pouvez pas appeler directement les fonctions dans l'application ou le service de l'autre, car ils sont en cours d'exécution dans les différents processus.
- Cela ne semble pas fonctionner pour moi, du moins pas dans Android 5.1.1
- Il ne fonctionne pas.
InformationsquelleAutor sam

Vous devez vous connecter pour publier un commentaire.