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

[Nivek]

Sur une idée née sur ce forum, je vous présente ACRA : Application Crash Report for Android, librairie pour les développeurs d'applis permettant d'envoyer automatiquement des rapports de crash quand l'application plante.

La philosophie de cette librairie est simple :

- il existe des solutions plus ou moins efficaces, plus ou moins détaillées sur divers blogs, qu'il faut généralement réimplémenter soi-même... tâche pas toujours aisée pour tout le monde

- la plupart de ces solutions impliquent d'avoir un serveur disponible sur lequel héberger un script chargé de réceptionner et stocker les rapports de crash... ceci n'est pas forcément donné à tout le monde non plus

=> il devient nécessaire d'avoir une librairie permettant d'intégrer cette fonctionnalité avec peu d'effort dans le code des applications et permettant de récupérer les rapports le plus simplement du monde

Alocaly avait publié sur son blog une solution qui réalisait l'envoi des rapports via mail... ce qui est intrusif pour l'utilisateur et nécessite sa validation pour l'envoi => peu efficace.

ACRA reprend le code proposé par Alocaly (avec notamment une grosse quantité d'infos système permettant de connaitre le contexte) et envoie les rapports non pas par mail mais sur un formulaire Google Docs.

Avantages:

- pas de problématique d'hébergement... c'est chez Google

- pas de besoin de validation par l'utilisateur => tous les crash sont envoyés

- si le terminal android n'est pas online au moment du crash, le rapport d'erreur est stocké pour être envoyé plus tard lors d'un prochain lancement de l'appli

- simplicité de mise en oeuvre, il faut simplement :

* importer un fichier excel dans GoogleDocs, le transformer en formulaire

* ajouter la libraire ACRA dans son projet

* implémenter une classe Application héritant d'une classe fournie par ACRA et imposant l'implémentation d'une unique méthode dont le seul rôle est de retourner l'identifiant du formulaire GoogleDocs

* modifier le manifest de l'appli pour préciser le nom de la classe Application qui vient d'être créée et éventuellement ajouter la permission INTERNET si elle n'était pas déjà utilisée.

- les données des crash sont donc rassemblées dans un tableau Google Docs, ce qui permet d'envisager tous les avantages de ce service :

* partage du document avec toute une équipe de développeurs

* mise en place de notifications à l'arrivée de rapports d'erreur (à l'unité ou résumé quotidien)

* ... certainement encore beaucoup d'autres choses auxquelles nous n'avons pas encore pensé

Je vous invite donc à tester cette librairie, elle est dans un état que je considère maintenant suffisamment stable pour que vous n'ayez pas à subir de désagréments en l'utilisant (et vos utilisateurs non plus).

La librairie est opensource, sous licence Apache donc peut être utilisée dans toute application : libre ou non, payante, gratuite...

Plus d'infos sur ce billet que je viens de publier sur un blog que je viens d'ouvrir :

http://android-dev-fr.blogspot.com/2010/04/mon-application-plante.html

Le site du projet :

http://acra.googlecode.com/

N'hésitez pas à nous remonter d'éventuels soucis ou propositions d'évolution sur http://code.google.com/p/acra/issues/list

Et le détail de la mise en oeuvre (en anglais pour le moment) :

http://code.google.com/p/acra/wiki/ACRAHowTo

Le projet est maintenu par Alocaly et moi-même.

A vous de jouer !

Modifié 29 avril 2010 par Nivek

[Tama Chan]

Alors là je dis bravo! C'est une excellente initiative et je vais m'y interesser vivement et en faire la publicité si ça marche comme promis!

C'est le genre de truc qui va m'aider grandement car recuperer les logs des utilisateurs c'est assez difficile! Si j'ai un moment je teste aujourd'hui

[Fluckysan]

Merchi Nivke et Alocaly pour ce projet !

Je vais l'utiliser et je vous ferais un retour

[Igosuki]

C'est vrai que côté libs de log chez Android c'est pas encore ça, mais ça va pas durer grâce à vous !

[Profete162]

C'est parti, mais je dois d'abord me battre avec Google Docs ( que j'ai jamais utilisé)

Click for full size - Uploaded with plasq's Skitch

[Nivek]

Argh, je vais vérifier le fichier que j'ai mis dans le package alors :(

[Profete162]

Alors? je suis le seul à pas savoir uploader ce fichier sur Google Docs?

J'aurais voulu l'intégrer à mes applis asap, ca semble vraiment puissant!

[Nivek]

J'ai eu la même erreur que toi. Je vérifie cette nuit.

[rafffel]

au moment d'uploader juste avant il faut sélectionner un dossier et la ça marche ;)

J'ai reussi a l'integré dans l'une de mes applications quelqu'un aurait un exemple simple d'un bug qui donne lieu a un crash?

Edit:

j'ai trouvé un exemple simple de crash

Class test extends Activity{

Public TextView tv;

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.main);

tv.setText("testcrash");

}

et ça devrai suffire

Modifié 29 avril 2010 par rafffel

[popolbx]

superbe j'ai joué avec hier, surtout avec l'option pour l utiliser avec un webservice dédié...

la seule chose qui me gène c'estque l'user n'est pas au courant.

et que les applsi n utilisant pas internet se retrouvent avec une permission internet qui prete à confusion.

Par contre en regardant le code j'ai une proposition.

Au moment ou l'on relance l'appli (ou au moment ou ça crash):

on affiche une dialog disant : "blabla a planté, envoyer le rapport d'erreur ?" © microsoft

.

et là le rapport est envoyé sur l'intent "envoyer vers" : du coup le mec n'a

plus qu'à choisir gmail/mail et on vire la permùission internet.

En plus mle gars est super rassuré il voit que son crash va servir et qu'on s'en occupe :)

voilà. Je pense que je mettrait en place cette solution.

Mais bravo pour ce boulot car la méthode de l'appli hérité est super interessante.

[Nivek]

Je suis assez d'accord avec toi sur le principe et j'ai en tête 2 évolutions (une fois qu'on sera sûrs de la façon la plus simple pour initialiser le google doc :P ) :

- ajout d'une question à l'utilisateur avant envoi de rapports (quelle que soit la destination)

- réintroduction de l'envoi par mail (c'était le mode d'envoi d'origine sur le code d'Alocaly), activable par le développeur en retournant un "mailto:dev@appli.com?subject=Crash" dans le getFormUri() de l'Application.

Je ne suis en revanche pas convaincu par la méthode de l'envoi par mail, très intrusive pour l'utilisateur... mais si certains dev préfèrent ça pourquoi pas.

Je pense qu'à terme un simple dialog "à la windows" puis envoi sur script serveur (google doc ou serveur perso) sera le plus efficace et le plus "correcte" pour l'utilisateur. Par contre je ne pense pas qu'il soit utile de l'imposer dans la lib, le développeur devrait avoir le choix de poser ou non la question et de choisir la destination de ses rapports.

[Alocaly]

et là le rapport est envoyé sur l'intent "envoyer vers" : du coup le mec n'a

plus qu'à choisir gmail/mail et on vire la permùission internet.

En plus mle gars est super rassuré il voit que son crash va servir et qu'on s'en occupe :)

En fait, c'est la solution initiale que j'avais sur mon blog que tu veux utiliser :)

Mon expérience, pour avoir utilisé d'abord ( depuis pas mal de temps ) la solution 100% mail, et depuis 15 jours la solution google Docs, c'est que le mail, la plupart des gens refusent de l'envoyer. Je ne connais pas leur raison, mais j'imagine que c'est ou par flemme, ou par peur de diffuser leur adresse email, et de recevoir plein de spam.

Je dirais à la louche que je recevais 10% des crashs par mail.

J'en discute sur mon blog, mais ma conclusion, c'est que je pense que ca suffit pour traiter les bugs. Meme avec une appli beaucoup moins utilisée que la tienne, Popolbx, si un bug revient de facon signiifcative, j'aurais un mail.

Par contre, à présent, je me pose des questions sur l'interet de l'utilisateur : effectivement, voir qu'un mail est envoyé est rassurant et fait sérieux. Maintenant, vu que pour 9 personnes sur 10, le mail n'est pas envoyé, je dirais que pour ces personnes là, c'est plus un handicap. De la même facon, si l'un des utilisateurs qui acceptent d'envoyer les mails a le bug 4 fois dans la journée, ca va commencer à le pénaliser, à détériorer son expérience, et à le pousser vers d'autres horizons.

Ma conclusion, c'est que je suis super content de ce qu'a fait Nivek à partir de mon crash reporter, et j'aime beaucoup la solution google docs.

Si on veut chouchouter encore plus l'utilisateur, et avoir les avantages du mail, peut-etre qu'on pourrait :

* afficher un toast lors de l'envoi du rapport d'erreur. Comme ca l'utilisateur voit que le bug est rapporté

* Mettre une option dans son appli pour déactiver le bug reporting.

* Prévenir l'utilisateur.

En meme temps, dans mon expérience, les gens qui veulent savoir ce genre de choses sont ultra minoritaires, et très 'vocal' ( c'est comme ca qu'on dit à mon boulot ). C'est à dire qu'ils sont très actifs sur les forums, parlent beaucoup pour dénoncer ce genre de pratiques, mais restent une petite minorité. Ca ne veut pas dire qu'ils ne faut pas les prendre en considération, juste qu'à mon avis, il ne faut pas détériorer l'expérience de la majorité à cause d'eux...

Bon, voila pour ce matin, je retourne à mon vrai job...

Emmanuel / Alocaly

Ps : Rafffel => C'est la premiere fois que je vois quelqu'un demander sur un forum de dev comment on fait un crash :)

[Nivek]

J'ai remplacé le .xls par un .csv, je pense que ça a plus de chances de s'intégrer correctement.

Pro-fête, si tu veux bien tester avec ce serait cool, j'ai préparé un ACRA-1.2.1 avec juste ce remplacement (+ mise à jour du How-To).

http://acra.googlecode.com/files/ACRA-1.2.1.zip

Dès que c'est bon pour toi je la passe en 'featured' et je mets la 1.2.0 en 'deprecated'.

A part ça, j'ai mis en place ACRA dans EmailAlbum depuis hier et je dois dire que c'est VRAIMENT indispensable d'avoir ce genre d'outil dans son appli...

- J'ai pu détecter très rapidement que une modif de dernière minute "mineure" dans un .xml me faisait planter mon écran de préférences sur les android 1.5 (et donc republier un correctif dans la foulée)

- J'ai déjà 2 ou 3 bugs à étudier

Modifié 30 avril 2010 par Nivek

[Profete162]

Désolé Nivek, mais Google t'as piqué ton idée...

Je suppose que tu as vu la nouveauté sur ta page de dev:

Click for full size - Uploaded with plasq's Skitch

Ca va faire du bien ca!

[Nivek]

Terrible !

Bah c'est tant mieux :)

Par contre j'ai l'impression que ça ne remonte des rapports que pour les android 2.x (pour le moment je n'ai que des "Droid" dans les plateformes qui ont renvoyé des rapports).

Y a eu une annonce quelque part ? je ne vois rien à ce sujet...

(et puis là je me tape plein de "server error" sur l'interface de dev mais bon, c'est tout frais :p )

Modifié 30 avril 2010 par Nivek

[Nivek]

Visiblement les rapports seraient transmis à l'initiative de l'utilisateur et pour le moment une petite partie des terminaux android disposerait de cette fonctionnalité :

http://stackoverflow.com/questions/2567197

Ca manque tout de même de communication pour le moment...

[Alocaly]

Je viens de voir ca !

Ca donne les rapports d'erreurs avec les callstacks ? On peut cliquer dessus pour voir ce qui se passe ?

C'est bien ca !!!

( parce que pour l'instant, j'ai 0 freeze, 0 crashes )

Sinon, je pense que ACRA a encore de beaux jours devant lui, car il offre des options en plus qui sont vraiment interessantes :

* La possibilité de rajouter des informations customs pour aider à debugger. J'ai trouvé ca vraiment super utile: à un moment, j'avais des crash que je ne comprenais pas lors de la validation des mots rentrés par le joueur. J'ai rajouté le dernier mot entré par le joueur en parametre custom, et en quelques temps le bug était reproduit !!

* Toutes les infos supplémentaires : en particulier le numéro de version de l'appli ( histoire de ne pas s'embeter avec des bugs déjà corrigés ), la place mémoire, la version d'OS / de tél

* La possibilité de voir ca dans une interface à la Excel, donc avec la possibilité de grouper par version / plate forme / callstack, voire de se faire des statistiques ( c'est un des points qu'on voudrait pousser ).

Mais il faut quand meme saluer ce dev de google !!

Emmanuel / Alocaly

[Nivek]

Le détail d'un crash :

Il manque en effet pas mal de détails.

Ce qu'il y a de plus que ne peut détecter ACRA ce sont les rapports sur freeze (ANR)

Modifié 1 mai 2010 par Nivek

[Profete162]

Et j'utiliserai de toutes facons ACRA quand j'aurai réussi à uploader le fichier excel sur Google docs.

Je trouve cela vraiment sympa pour l'utilisateur que son dev s'intéresse à lui plutot que le vilain message de plantage habituel.

Ca doit en effet lui faire super plaisir de voir un message de son dev qui lui dit "envoie moi un fichier et des infos" plutot que le sale message de crash dont il sait qu'il ne sert à rien!

Modifié 1 mai 2010 par Profete162

[Nivek]

Pour le fichier à uploader sur Google Docs, as-tu vu mon message un peu plus haut sur ce fil disant que je l'avais remplacé par un CSV et que j'aimerais que tu testes ?

[Nivek]

Ah tiens, je n'ai plus la section "feedback" sur ma home dev.

[Alocaly]

Yep, envolé...

J'ai aussi essayé de trouver l'URL sur mon application directement depuis mon historique... Mais je pense que Google ne manque pas d'expérience en ce qui concerne le Web, et ca n'a évidemment pas marché !

Bon, ca reviendra de toutes facons !!

Au fait, si vous voulez voir ce que ca donne pour les utilisateurs, j'ai trouvé ca sur le net :

http://bentobin.com/crashReportImages/

On peut voir que plus d'informations sont envoyées que ce qu'on croyait hier !

Emmanuel / Alocaly

[CedricGatay]

Bonjour à vous, merci pour cet outil bien pratique pour obtenir des traces de logs sur les crash, chose quasi impossible à obtenir facilement vu l'aspect grand public de la plateforme.

Grace à vous j'ai pu trouver quelques NPE qui impactaient mes utilisateurs !

Cedric

[Profete162]

Pour le fichier à uploader sur Google Docs, as-tu vu mon message un peu plus haut sur ce fil disant que je l'avais remplacé par un CSV et que j'aimerais que tu testes ?

Sorry, j'avais un peu zappé les autres messages!

Super simple d'installation en suivant le tuto, tout a fonctionné du premier coup.

Je pensais que l'utilisateur allait être prévenu par un petit message, mais aparemment non, ca se fait de maniere transparente pour lui si je comprends bien.

Je m'empresse donc de mettre tout cela dans mes applis!

Modifié 3 mai 2010 par Profete162

[Nivek]

Oui, pour le moment c'est fait "discrètement" mais je pense qu'on ajoutera dans une version ultérieure une boîte de dialogue demandant confirmation à l'utilisateur avant envoi.