Le service Android se bloque après que l'application a été effacée de la liste des applications récentes

J'ai un service qui démarre (non lié) par une activité. Si l'activité est détruite (p. Ex. En appuyant sur le bouton Précédent), le service continue à fonctionner, ce qui est évidemment prévu. Cependant, si je glisse l'activité à partir de la liste des "applications récentes", le service est redémarré immédiatement. Ceci est reproductible, chaque fois que l'activité / l'application est effacée de la liste, il y a un nouvel appel à la méthode onCreate du service. Pas d'appel à onDestroy entre les deux!

D'abord, je pensais que le service est tué par Android, même si je n'ai vu aucune raison de tuer (ni l'activité ni le service ne consomment de ressources, en fait, ils sont minimalistes et ne font rien). Mais j'ai remarqué que le service s'effondrait réellement.

  • Modification de la couleur d'arrière-plan de la disposition linéaire tout en cliquant
  • Comment puis-je détecter l'entrée tactile sur Android
  • Problèmes fréquents liés à la vue Android, analyse des erreurs XML: préfixe non lié
  • Est-il possible de configurer System DateTime depuis mon application Android?
  • Android: comment puis-je parcourir le système de fichiers de périphériques à distance via bluetooth?
  • Ajout de fragments dynamiquement
  • 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 

    Le code n'est pas remarquable, mais ici il est

    Activité:

     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"); } //[...] } 

    Un service:

     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 bref: Mon service est indépendant du cycle de vie de l'activité, mais seulement tant que je ne glisse pas l'application de la liste des applications récentes. Dans ce cas, le service est redémarré mais sans appel à onDestroy.

    Chaque fois que cela se produit, non seulement l'état du service, mais aussi le travail que le service fait est perdu. Je veux juste savoir pourquoi le coup de glace est la raison pour cela.

  • Android: envoi de SMS par intention avec corps et retour.
  • Comment éviter le décapage des symboles de code natifs pour l'application Android
  • ActionBarSherlock entièrement transparent en utilisant le thème
  • Récepteur de diffusion dans un service
  • Les images de chargement par défaut sur Listview dans Android (niveau débutant)?
  • Implantation SMACK XEP-313
  • 4 Solutions collect form web for “Le service Android se bloque après que l'application a été effacée de la liste des applications récentes”

    Le fait de basculer l'application à partir de la liste des tâches récentes tue réellement le processus du système d'exploitation qui héberge l'application. Comme votre service fonctionne dans le même processus que vos activités, cela tue le service. Il onDestroy() PAS onDestroy() sur le service. Cela tue le processus. Boom. Mort. Disparu. Votre service ne se bloque pas .

    Étant donné que votre service a retourné START_STICKY depuis l'appel vers onStartCommand() , Android reconnaît que votre service devrait être redémarré et planifie un redémarrage du service onStartCommand() . Toutefois, lorsque votre service est redémarré, il sera dans un processus nouvellement créé (vous pouvez voir onCreate() appelé dans le service), donc il faudra recommencer le travail.

    Règle n ° 1: ne passez jamais les applications de la liste récente des tâches 😉

    En balayant, vous NE DEVEZ PAS faire tuer le processus de l'application. Non. Vous ne supprimez que la tâche d'application (ou pile arrière). La tâche d'application n'est PAS égale au processus de demande.

    Donc, si vous avez des travaux d'arrière-plan (thread, service, etc.) liés à votre pile de retour et vous avez une bonne politique d'annulation, les services seront également récupérés.

    Si vous tuez le (s) processus (s) de l'application du Gestionnaire des tâches, cela signifie que votre processus (en supposant que votre application est liée à un processus qui est le cas habituel) sera supprimé et que votre jvm / sandbox sera également supprimé avec Toutes les ressources appartiennent à ce processus de manière agressive par le système.

    Peut-être que cela peut être un problème avec les récepteurs de diffusion définis dans le manifeste.

    Avez-vous un récepteur / intention-filtre défini dans votre manifeste au niveau de l'application? J'avais l'habitude d'avoir le même type de problème et c'était dû au récepteur déclaré dans le manifeste au niveau de l'application

    Utilisez * START_NOT_STICKY * comme retour sur StartStore

     @Override public int onStartCommand(Intent intent, int flags, int startId) { Log.v(TAG, "onStartCommand"); return START_NOT_STICKY; } 
    coAndroid est un fan Android de Google, tout sur les téléphones Android, Android Wear, Android Dev et Android Games Apps.