2012-09-21 4 views
0

Je suis en train de développer une application et je veux mettre une fonctionnalité de récupération d'urgence, en redémarrant mon application. Je n'ai pas écrit de code lié à ceci. Mon idée pour cela est de démarrer un service qui surveille l'état. Basé sur cette approche, le problème est que le service commence à partir de mon application, il va mourir si l'application meurt. Est-il possible de démarrer un service depuis mon application et de l'exécuter de manière autonome pour surveiller mon application et la redémarrer?Crash Recovery application android

Répondre

1

Il existe plusieurs façons d'aborder le problème que vous décrivez. Le plus simple est peut-être de fournir une classe Application personnalisée pour votre projet, et dans sa méthode onCreate(), appelez le Thread.setDefaultUncaughtExceptionHandler(this); pour affecter votre classe en tant que gestionnaire d'exceptions par défaut. Cela vous demandera de surcharger public void uncaughtException(Thread t, Throwable e) qui sera appelée au moment de la panne, et vous pourrez planifier un redémarrage.

Si vous voulez vraiment quelque chose en dehors de vos processus de surveillance, une approche est un service dans votre application qui est défini pour avoir son propre processus; ceci est fait avec un attribut AndroidManifest.

Une autre option consiste à utiliser l'AlarmManager Android, car il est géré par le système et peut redémarrer votre application.

+0

AlarmManager je crois pourrait être une solution si mon application a été programmée. Utilisation de Thread.setDefaultUncaughtExceptionHandler Je peux utiliser si je centre en un seul endroit la gestion des exceptions. Utiliser un service pour moi est une bonne idée: j'ai trouvé ça [link] (http://stackoverflow.com/questions/7254720/how-to-restart-an-activity-automatically-after-it-crashes?rq=1) utile. Mais j'aime vraiment entendre d'autres approches. – learner

+0

L'utilisation de AlarmManager dans votre cas d'utilisation serait quelque chose comme: lorsque votre application démarre, vous planifiez une alarme avec un certain retard. Lorsque cette alarme se déclenche, vous vérifiez que l'application est en cours d'exécution (ou redémarrez-la si nécessaire) et réorganisez également l'alarme suivante. Lorsque votre application se termine normalement, vous supprimez l'alarme actuelle. Ce cas d'utilisation correspond à votre modèle non planifié en commençant uniquement lorsque l'application démarre et en l'arrêtant (car vous l'arrêtez) dès que l'application est terminée. – mah

-3

Vous pouvez démarrer votre service lorsque le téléphone démarre en enregistrant le filtre d'intention avec l'action android.intent.action.BOOT_COMPLETED. Plus d'informations peuvent être trouvées here ou dans un similaire question

+0

-1: Cette réponse n'est pas liée au blocage/redémarrage de l'application. – mah

+0

Il est lié au service en cours d'exécution qui vérifiera l'état de l'application. Pourquoi AlarmManager est meilleur que le service? Et il pourrait y avoir plus d'un thread dans l'application – marwinXXII

+0

Je n'ai pas dit que AlarmManager était meilleur qu'un service, j'ai dit que c'était une autre option - cependant, puisqu'une application peut planter sans casser l'alarme en attente, c'est mieux. Plus important encore, la question posée n'était pas comment démarrer un tel service (auquel BOOT_COMPLETED est une réponse), mais plutôt sur les possibilités. Votre réponse suppose qu'il veut que quelque chose démarre au démarrage du périphérique, ce qu'il n'a jamais déclaré. Il a seulement déclaré qu'il voulait récupération d'un accident d'application; BOOT_COMPLETED suggère quelque chose qui vit beaucoup plus longtemps qu'il ne devrait, gaspille des ressources et ralentit les téléphones des gens. – mah