START_STICKY et START_NOT_STICKY

Les deux codes ne sont pertinents que lorsque le téléphone est à court de mémoire et tue le service avant la fin de son exécution. START_STICKY indique au système d’exploitation de recréer le service après avoir suffisamment de mémoire et appelle à nouveau onStartCommand() avec une intention nulle. START_NOT_STICKY demande au système d’exploitation de ne pas recréer le service à nouveau. Il existe également un troisième code START_REDELIVER_INTENT qui indique au système d’exploitation de recréer le service et de redissortingbuer la même intention à onStartCommand() .

Cet article de Dianne Hackborn a bien mieux expliqué le contexte que la documentation officielle.

Source: http://android-developers.blogspot.com.au/2010/02/service-api-changes-starting-with.html

La partie clé ici est un nouveau code de résultat renvoyé par la fonction, indiquant au système ce qu’il doit faire avec le service si son processus est supprimé pendant son exécution:

START_STICKY est fondamentalement le même que le comportement précédent, où le service est laissé “démarré” et sera ensuite redémarré par le système. La seule différence avec les versions précédentes de la plate-forme est que si elle est redémarrée parce que son processus est supprimé, onStartCommand () sera appelée sur l’instance suivante du service avec une intention nulle au lieu de ne pas être appelée du tout. Les services qui utilisent ce mode doivent toujours vérifier ce cas et le traiter de manière appropriée.

START_NOT_STICKY dit qu’après le retour de onStartCreated (), si le processus est tué sans commandes de démarrage restantes à délivrer, le service sera arrêté au lieu d’être redémarré. Cela a beaucoup plus de sens pour les services destinés à être exécutés uniquement lors de l’exécution de commandes qui leur sont envoyées. Par exemple, un service peut être démarré toutes les 15 minutes à partir d’une alarme pour interroger un état du réseau. S’il est tué pendant ce travail, il serait préférable de le laisser s’arrêter et de démarrer la prochaine fois que l’alarme se déclenche.

START_REDELIVER_INTENT est similaire à START_NOT_STICKY, sauf si le processus du service est tué avant d’appeler stopSelf () pour une intention donnée, cette intention sera ré-livrée jusqu’à la fin (sauf après plusieurs tentatives, il ne peut toujours pas se terminer). à quel point le système abandonne). Ceci est utile pour les services qui reçoivent des commandes de travail et qui veulent s’assurer qu’ils terminent éventuellement le travail pour chaque commande envoyée.

Réponse KISS

Différence:

START_STICKY

le système va essayer de recréer votre service après sa mort

START_NOT_STICKY

le système n’essaiera pas de recréer votre service après qu’il soit tué

Exemple standard:

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

La documentation de START_STICKY et START_NOT_STICKY est assez simple.

START_STICKY:

Si le processus de ce service est onStartCommand(Intent, int, int)) démarrage (après le retour de onStartCommand(Intent, int, int)) , laissez-le dans l’état démarré, mais ne conservez pas cette intention. Plus tard, le système essaiera de recréer le service. Comme il est à l’état démarré, il garantit d’appeler onStartCommand(Intent, int, int) après la création de la nouvelle instance de service; S’il n’y a pas de commandes de démarrage en attente à livrer au service, il sera appelé avec un object d’intention nulle. Vous devez donc vérifier cela.

Ce mode a un sens pour les choses qui seront explicitement démarrées et arrêtées pour s’exécuter pendant des périodes de temps arbitraires, telles qu’un service effectuant une lecture de musique de fond.

Exemple: exemple de service local

START_NOT_STICKY:

Si le processus de ce service est onStartCommand(Intent, int, int)) démarrage (après le retour de onStartCommand(Intent, int, int)) et qu’il n’y a pas de nouvelles intentions de démarrage à fournir, onStartCommand(Intent, int, int)) le service de l’état démarré et ne pas recréer jusqu’à un futur appel explicite à Context.startService(Intent) . Le service ne recevra pas d’ onStartCommand(Intent, int, int) avec un Intent null car il ne sera pas redémarré s’il n’y a aucune intention en attente à livrer.

Ce mode a du sens pour les tâches qui nécessitent un certain travail suite à un démarrage, mais qui peut être interrompu sous la pression de la mémoire et qui s’affichera plus tard pour faire plus de travail. Un exemple d’un tel service serait celui qui interroge les données d’un serveur: il pourrait programmer une alarme pour interroger toutes les N minutes en faisant démarrer le service de l’alarme. Lorsque son onStartCommand(Intent, int, int) est appelé à partir de l’alarme, il programme une nouvelle alarme pour N minutes plus tard et lance un thread pour effectuer sa mise en réseau. Si son processus est interrompu lors de cette vérification, le service ne sera pas redémarré tant que l’alarme ne se sera pas déclenchée.

Exemple: ServiceStartArguments.java