ACRA - comment récupérer simplement les infos de crash d'appli

[Fluckysan]

Ca fonctionne bien :)

Bravo à Nivek et Alocaly, c'est très pratique

[Topper Harley]

Salut,

Juste pour dire bravo et merci. C'est impressionnant ! Très propre, très pratique à utiliser !

Je l'utilise dans mon appli de suivi conso NRJ Mobile

http://consonrj.googlecode.com

[naholyr]

Merci pour cet excellent travail :) Intégré dans la prochaine version d'Horaires TER SNCF !

[Nivek]

Super ! :)

Si vous avez des retours à nous faire sur des enrichissements (ou correctifs) à apporter à la librairie ou sur des astuces pour l'exploitation du google doc ensuite, n'hésitez pas à nous en faire part !

[naholyr]

J'ai une question digne d'une FAQ : J'aimerais pouvoir parfois lancer des rapports sans pour autant laisser échapper l'exception. Comment faire ? J'utilise ErrorReporter.getInstance().uncaughtException(t, e) ? Mais je ne sais pas avec quoi remplir l'objet Thread (quand je suis dans le onCreate par exemple, sans avoir démarré une classe Thread interne) :) Si je lui passe "null" il fera pas la gu***** ?

Modifié 11 mai 2010 par naholyr

[Nivek]

Exact, je m'étais fait la même réflexion en constatant par moi-même un bug dans mon appli qui ne pouvait pas être remonté par ACRA puisque intercepté par un try catch.

En l'état je ne pense pas qu'il soit possible de fournir null pour le paramètre de type thread car celui-ci, même s'il n'est pas utilisé par ACRA, est retransmis ensuite au UncaughtExceptionHandler par défaut du système qui lui réalise les opérations nécessaires à l'arrêt de l'activité qui a pausé problème.

Tu peux toujours tester... au pire on pourra rajouter un test sur le contenu de ce paramètre et n'appeler le handler par défaut que si celui-ci n'est pas null (mais je pense plutôt implémenter une méthode spécifique).

[naholyr]

Et dans les taches que je crée dans mes activity, ça peut marcher ? Par exemple :

public void onCreate() {
 new Thread() {
   public void run() {
     try {
       ...
     } catch (Exception e) {
       ErrorReporter.getInstance().uncaughtException(this, e);
     }
   }
 }.start();
}

ça marchera dans ce cas ? en fait j'ai du mal à comprendre exactement le contexte d'utilisation de cette méthode ^^ ça me permettrait sans doute de compléter moi-même la lib au besoin ;)

[Nivek]

Essaie avec cette version :

http://www.gaudin.tv/storage/android/CrashReport/acra-1.3.0.jar

ErrorReporter.getInstance().handleException(tonException);

;-)

[naholyr]

Tu rosk :D

Je vais l'intégrer dans ma prochaine version d'ici dimanche, super ;)

Edit : Tiens je vois que la v1.3 correspondant au Jar que tu viens de passer n'est pas sur Google Code, tu attends des retours de test avant de la publier ?

Modifié 12 mai 2010 par naholyr

[Nivek]

Oui, j'ai fait un refactoring rapide pour extraire cette méthode du uncaughtException(Thread, Throwable) d'origine sans avoir le temps de tester ni faire le complément de doc. Si tu me confirmes que cela fonctionne correctement je publierai dans les jours qui viennent.

[Nivek]

En plus de cette fonction, j'aimerais ajouter la possibilité d'afficher un Dialog demandant à l'utilisateur son autorisation pour envoyer un rapport dans la prochaine version... je me suis beaucoup bagarré avec le système des dialogs hier et aboutis à la conclusion que ca ne va pas être si simple... Impossible d'ouvrir un AlertDialog en dehors d'une Activity alors que l'objet d'envoi des rapports ne dispose que du context de l'application (l'AlertDialog du "Force Close" est générée dans un context système dont les méthodes d'accès ne sont pas disponibles via le sdk).

Du coup je suis en train de réfléchir à la méthode la plus simple possible pour packager une activity spécifique dans la lib et la façon la plus simple pour le développeur final d'intégrer le tout dans son appli... en espérant que l'état de l'appli au moment d'un crash permette de lancer cette nouvelle Activity.

Au final je pense que je vais certainement rejoindre la solution proposée par Emmanuel :

- affichage d'un avertissement par Toast

- nécessité pour le développeur d'ajouter une Przference spécifique désactivable par l'utilisateur

[naholyr]

- affichage d'un avertissement par Toast

- nécessité pour le développeur d'ajouter une Przference spécifique désactivable par l'utilisateur

J'y avais refléchi aussi, et je crois que vu le contexte d'exécution de l'application aucune boite de dialogue ne pourra être affichée sans risque de plantage. Il y aurait bien une autre solution :

- Affichage d'une notification dans la barre d'état, et le rapport n'est envoyé qu'au clic sur cette notification.

L'idéal serait de mettre une option dans la classe Application pour choisir le comportement ;)

[Nivek]

Effectivement la notification ça a l'air d'être une bonne idée. J'ai commencé à creuser dans cette direction, je continue ;-)

[Nivek]

Bon bah j'ai quasi implémenté les trois modes :

- silencieux (envoi discret des rapports)

- toast (on indique qu'on envoie un rapport mais sans donner de choix autrement que par preferences)

- notification: quand on clique sur la notif, affichage de l'equivalent d'un dialog présentant à l'utilisateur le choix d'envoyer ou non un rapport et je pense ajouter un texte libre pour commentaire utilisateur.

Le tout ne devrait à priori pas trop complexifier la mise en place de la lib dans les applis...

Je fignole tout ca ce soir, normalement...

[Alocaly]

Waaa super tout ca Nivek !

Quelques commentaires :

* Pour la fonction qui permet d'envoyer un rapport, meme quand il n'y a pas de crash : Effectivement, c'est une super bonne idée. Avoir un moyen de détecter des comportements anormaux, meme si notre code applicatif propose un palliatif au probleme.

Par contre, moi j'aurais trouvé encore mieux de pouvoir avoir un moyen de déclencher ca sans donner d'exception ( ou peut-etre d'avoir les deux fonctions : une avec et l'autre sans exception en parametre ). En effet, y'a des cas ou tu te retrouve dans une situation que tu voudrais remoter, mais sans exception à la clé.

Et j'imagine que ce n'est pas tres compliqué à implémenter : il suffit que cette fonction lance elle meme une exception bidon pour que ce soit bon, non ? ( il me semble qu'il faut forcément une exception pour avoir la call stack )

* Sinon les modes d'envoi et de signalisation à l'utilisateur, c'est super, tout ca... Moi, je reste sur mes positions : je pense qu'un truc le moins intrusif possible, c'est ce qu'il y a de mieux pour l'utilisateur ( donc toast ). Une dialog box, ou le systeme de notification, je pense que ca gene en fait les utilisateurs ( et qu'en plus ils vont moins l'utiliser !! )

Voila, sinon, j'ai eu quelques rapports de bug avec des lignes toutes vides ( juste l'horodatage ). Je me demande dans quel cas ca peut etre possible d'avoir ca !!

Et encore bravo à Nivek !

Emmanuel / Alocaly

[Profete162]

Pour ma part, je suis vraiment pour le système de dialog box ( mais alors, pour ne pas avoir de double notification, il ne faudrait pas afficher celui par défaut, ce qui est je pense impossible..)

Et pouvoir en plus y joindre un texte personnalisé, c'est le pied!

Cela rassure l'utilisateur et lui montre que le dev est vraiment motivé!

Pour le reste, je suis certain qu'une fois implémenté sur quelques applis, ton système va vite devenir indispensable pour tous!

Je vais attendre que tout soit fini avant de mettre à jour mes applis. Et encore bravo!

[Nivek]

* cas des rapports "lignes vides" : j'en ai eu un aussi, effectivement... ne sais pas trop d'où cela peut venir.

* Toasts : et bien après les implémentations de cet après-midi, les tests de ce soir sont décevants : incapable d'afficher un Toast depuis ErrorReporter... il apparait pourtant bien une trace dans LogCat, mais rien à l'écran :

05-13 23:17:38.299: INFO/NotificationService(53): enqueueToast pkg=org.acra.sampleapp callback=android.app.ITransientNotification$Stub$Proxy@43daa3e8 duration=1

Finalement (je code en même temps que j'écris ce post :-P) en créant un Thread séparé faisant appel à Looper.prepare(), Toast.makeText().show() puis Looper.loop() ça fonctionne... mais impose de faire une temporisation de 3s dans le Thread qui a planté avant de laisser le UncaughtExceptionHandler par défaut faire son boulot (celui qui affiche le dialog Force Close).

Au final, je vais sûrement finir par ne pas faire appel à celui-ci (sisi, je pense que c'est possible Profete ;-)) dans les cas Toast ou Notif, je suis allé voir dans les sources android et le peu qu'il fait devrait pouvoir être réalisé également dans notre ErrorReporter. Je creuserai ça demain et laisse la tempo pour le moment dans le cas du Toast.

* Fonction d'envoi de rapport sur comportement anormal sans exception : je vais voir ça, au pire on peut simplement transmettre un new Exception("pouet") ;-)

Pour ce qui est du mode d'avertissement de l'utilisateur, ma position est que chaque développeur aura son propre avis et que si on peut avoir le choix c'est pas plus mal. L'avis de chacun peut aussi varier en fonction de l'état d'avancement de l'appli. Pour une appli qui démare, un dev préfèrera faire du reporting silencieux ou par Toast pour ne pas trop déranger l'utilisateur. Pour une appli qui a déjà été bien déverminée, on pourra ensuite opter pour le système par notification + dialog qui permettra de donner une sensation de sérieux pour peu qu'on n'en ait pas toutes les 5 minutes ;-)

Modifié 13 mai 2010 par Nivek

[Nivek]

* Pour les rapports "lignes vides" : j'ai corrigé un ou deux trucs qui pouvaient provoquer ça... notamment l'envoi de rapports au redémarrage avec plus de 5 rapports à envoyer... la fonction d'envoi était appelée au-delà des 5 rapports mais sans charger les données.

* Le système par notification commence à avoir l'air stable. L'impact pour le développeur :

- 1 ligne à ajouter dans son manifest pour déclarer l'activity (fournie dans ACRA) qui demande l'envoi de rapport à l'utilisateur,

- 1 méthode supplémentaire à ajouter pour fournir un Bundle contenant les resId des différents textes / icônes nécessaires

* Pour les modes Toast et Notif, je ne fais plus appel au UncaughtExceptionHandler par défaut du système. Cela évite d'avoir à la fois notifications custom et la vilaine boîte force close. J'ai ajouté dans notre handler les actions réalisées par celui du système, à savoir : un Process.kill(Process.myPid()) suivi d'un System.exit(10). Cela devrait permettre également d'éviter d'afficher la future dialog d'envoi de rapports qui devrait arriver dans FroYo

Reste à faire :

- tester

- tester

- documenter

- tester...

- et tester.

Modifié 16 mai 2010 par Nivek

[naholyr]

Super :)

Pour info, la version 2.2.2 de Horaires TER SNCF inclut la version 1.3 d'ACRA, et c'est un succès pour l'instant je reçois plein de rapports custom de mes exceptions perso :) ça me permettra notamment de savoir combien de fois le web-service n'a pas pu répondre par exemple, vraiment bon boulot !

[Invité]

Salut !

Perso, j'arrive pas à le faire marcher...

J'ai le JAR 1.2.1, celui trouvé sur GoogleCode.

J'ai suivi le HowTo (simple !), ajouté le JAR dans le BuildPath, surcharger le code du getFormId, etc...

J'ai introduit une erreur volontairement dans mon code, et mon appli plante (facile), mais rien n'est écrit dans mon doc...

Est-ce que quelqu'un peut m'aider ? J'ai des soucis avec une de mes applis, et j'aimerai pouvoir les tracker... :-(

MERCI !!!

Nekloth

[naholyr]

Tu as quoi dans le LogCat lorsque ton exception est levée ? Tu as bien déclaré ton application dans le manifest ? Tu as bien ajouté la permission INTERNET ?

[Invité]

J'ai

WARN/dalvikvm(476): threadid=3: thread exiting with uncaught exception (group=0x4001aa28)

ERROR/AndroidRuntime(476): Uncaught handler: thread main exiting due to uncaught exception

et tout ce qui va avec...

Oui, j'ai mis la permission internet:

Le reste du manifest doit être bon, puisque tout le reste fonctionne ! ;)

D'autres idées ?

(en tout cas, merci pour ta réponse)

Nekloth

[Fluckysan]

As-tu suivi le tuto : http://code.google.com/p/acra/wiki/ACRAHowTo

Il faut changer un name dans le manifest :)

[Invité]

Salut !

Un tuto si simple, avec si peu d'étape... et je suis pourtant passé à travers celle-ci !

Donc, non, je ne l'avais pas fait, c'est maintenant corrigé, mais ... ça ne marche toujours pas... :-( mon document Google reste désespérément vide :-(

HELP !!

Nekloth

[Invité]

AU TEMPS POUR MOI !!!

Ca ne marchait pas, parce que l'erreur que j'avais introduite se trouvait dans un try/catch !!!

Je l'ai sorti du try/catch, j'ai un force close et un ligne dans mon doc !!!

MERCI A TOUS POUR VOTRE AIDE !!!

Nekloth