Как получить наибольшую выгоду от Crash Reports или упрощаем себе жизнь

    Привет хабродроидеры!
    Если ваше приложение падает в production и вам нужно быстро понять почему, на каком девайсе, с какой прошивкой и конфигурацией, то этот маленький топик расскажет об одном способе решения данной проблемы.
    Под катом описание возможностей ACRA.


    Стандартное сообщение о падении приложения мало чем помогает(банальный стектрейс), никакой полезной информации об устройстве или его конфигурации, но к нам на помощь приходит ACRA — code.google.com/p/acra

    Данная библиотека помогает сделать отчеты о падениях приложения информативным и более удобным способом.
    Доступны следующие способы из коробки:
    1. Запись отчета о падении в ваш Google Docs документ(способ по-умолчанию)
    2. Отправка отчета на почту
    3. Отправка данных на сервер, где его может обработать ваш скрипт произвольным образом
    Также можно довольно просто написать свой ReportSender реализовав метод send данного интерфейса.
    Присутствует несколько режимов уведомлений о репорте:
    1. Silent(по-умолчанию) — пишется отчет в ваш гугл-документ не сообщая об этом пользователю и вызывается стандартный диалог падения
    2. Toast — появляется toast-уведомление с вашем сообщением
    3. Notification — появится сообщение в статус-баре и далее диалог в котором можно ввести комментарий(опционально).
    Отмечу, что в отчет отправляется довольно много параметров, но их можно выбирать задавая в аннотации параметр customReportContent.
    Установка

    Скачиваем zip-архив по ссылке выше. Далее, кидаем jar библиотеки в папку проекта libs, добавляете ссылку в Build Path в Eclipse и либа готова к использованию.

    Пример работы

    После ознакомления со всеми способами отправки отчета я остановился на первом(отправка в Google Docs).
    Далее расскажу как это чудо заставить работать(также, это описано в wiki проекта).
    Прежде всего нам понадобится экземпляр класса Application для которого мы добавим аннотацию и пару строк кода, вот так:

    import org.acra.*;
    import org.acra.annotation.*;
    @ReportsCrashes( formKey = "ВАШ КЛЮЧ ФОРМЫ",	    
    	                       logcatArguments = { "-t", "50", Constants.DEBUG_TAG+":D"} )
    public class MyApp extends Application {
    	@Override
        public void onCreate() {
            ACRA.init(this); 
            ErrorReporter.getInstance().checkReportsOnApplicationStart();
            super.onCreate();
        }
    }
    

    И необходимо добавить описание имени объекта Application в ваш манифест:
    <application
    		android:name="MyApp"
                    ...
    

    В аннотации мы указываем ключ формы(как и где его получить опишу ниже) и параметры фильтрации вывода LogCat. в отчет В параметре фильтра мы ограничиваем количество записей лога в 50 штук и подсказываем библиотеке включить наш кастомный тег в отчет(честно говоря работает этот фильтр странновато, но все нужные теги добавляет).
    Кстати не забудьте добавить разрешение на чтение логов в манифест:
    <uses-permission 
    	    android:name="android.permission.READ_LOGS"/>
    </pre>
    

    Далее, в методе onCreate мы инициализируем библиотеку и говорим ей проверить ранние отчеты при запуске приложения. Это удобная опция позволяет подгрузить отчеты к вам в документ, которые были зафиксированы ранее, но не были отправлены(к примеру, не было интернета на девайсе).

    Подготовка Google Docs

    У вас наверняка есть аккаунт гугла. Входим в Google Docs и жмем кнопочку «Загрузить»(Load) и выбираем в архиве ACRA в папке doc файл CrashReports-Template.csv. После загрузки можем переименовать док, не суть важно. Заходим в документ в меню Tools выбираем Form->Create Form. Откроется новое окошко, в котором нужно убрать галочку «Require <ваш домен> sign-in to view this form». Внизу этого окна в ссылке будет нужный вам ключ — formKey, сохраните его. Жмете кнопку «save» вверху этого окна и ваш документ готов к получению баг репортов. Вставляете сохраненный ключ в код и все готово!

    В wiki библиотеки доступно много дополнительных примеров.
    code.google.com/p/acra/wiki/AdvancedUsage

    Кроме того, здесь можно почитать обсуждение рассмотренного вопроса и посмотреть альтернативные способы обработки падения:
    stackoverflow.com/questions/601503/how-do-i-obtain-crash-data-from-my-android-application

    Добавлю, что посланные отчеты мгновенно появляются в форме вашего документа.
    Все вопросы и замечания по топику, как обычно, в личку.
    Поделиться публикацией
    Похожие публикации
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 16
    • +1
      Очень полезная штука. Пользуюсь ей в режиме отправки отчётов в Google Docs.
      • +1
        Без такой штуки не обойтись. Пользователи как-то неохотно отправляют стэктрейси и уж тем более почти никогда не пишут, что же они делали в момент крэша.
        Думал Flurry с их системой событий (events) уж точно поможет в исправлении ошибок, а на деле там присылают только имя класса в котором возникло исключение и название метода откуда выбросили исключение (что естественно почти никак не помогает). Но с Acra можно и этого добиться, теперь каждый event я еще складываю в ErrorReporter.getInstance().putCustomData("eventId", eventParams); и тогда при репорте получаю последние события, которые совершил пользователь.
        • 0
          Да, система очень гибкая и впринципе расширяема
        • +1
          А ещё не нужно забывать, что для Android 2.2+ есть встроенный механизм для отправки ошибок (Android Application Error Reports)
          • 0
            в тех репортах крайне мало информации. Часто бывает так, что какой-то баг проявляется только на определенных девайсах и без этой информации те репорты будут почти к ничему.
          • 0
            Спасибо! Скажите, если ли какое-нибудь заметное влияние на производительность?
            • 0
              Производительность приложения? Когда оно работает без крэша?
              Если так, то разницы на девайсе никакой нет, ибо либа(я исходники не копал) просто ловит необработанные исключения в потоке, как в stackoverflow(ссылка в посте) написано.

              Единственно, что я зметил так это отправление отчетов от приложения когда их собирается много будет довольно длительная задержка при отправке(ну оно и понятно)
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                Вы можете написать свой ReportSender, так что это вопрос реализации.
                • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                Тоже пользуюсь, библиотека хорошая, но
                1) Это просто jar и хотелось бы иметь возможность использовать ACRA внутри опять же просто Java–проектов (весь код который напрямую не связан с андроидом удобнее выносить в такие проекты для тестирования) — но увы, так ACRA не работает, пришлось делать обертку
                2) Google Docs для изучения репортов мягко говоря не удобен, приходится выгружать в текстовый файл и смотреть просто в текстовом редакторе — так и то удобнее. Далее видимо надо либо собственное серверное приложение сделать для сбораа репортов вместо Google Docs (ничего подходящего готового не нашел), либо какой-нибудь скрипт написать для разбора CSV и преобразования во что-нибудь более адекватное.
                • 0
                  На счет второго я отчасти согласен, так как в меню документа можно легко получить любой удобный формат, а писать скрипт в данном случае на мой взгляд только тратить время на сомнительные улучшения.
                  С другой стороны не очень удобно, потому что по дефолту в репорт включается очень много полей, многие из которых ненужны, но для исправления ситуации можно поменять шаблон формы и настроить вывод нужных полей.

                  А вцелом, с Вами согласен.
                  А вообще библиотека на мой взгляд незаменимая, по крайней мере для быстрого и удобного решеняия проблемы информативности репорта.

                  Кстати недавно пришел репорт, довольно быстро разобрался в чем трабл и уже сделал фикс.
                  Спасибо, ACRA;)
                  • 0
                    Ну проблема в том что удобного формата как бы и нет — во чтобы ты эту таблицу не выгрузил — просматрвать неудобно. Хотелось бы каждый отдельный репорт видеть в виде отдельной страницы (между которыми можно было перемещаться) — поскольку только при таком виде можно просмотреть удобно stacktrace и собственные данные, и хотя бы иметь возможность отмечать старые-новые репорты.

                    В том же вопросе на stackoverflow предлагаются сервисы ориентированные на то что хотелось бы видеть — www.bugsense.com/ и www.apphance.com/ — надо будет попробовать.
                    • 0
                      Кстати первый сервис мне показался очень интересным, попробовать видимо стоит, по нему было пару вопросов, может быть будет интересно не только мне:

                      Thanks for stopping by! Can I help you with anything?
                      →Hi
                      BugSense-support: hello
                      →Are you service completely free?
                      BugSense-support: yeap
                      BugSense-support: Completely
                      BugSense-support: we plan to charge for some advanced features in the future
                      BugSense-support: but everything you see here now will be completely free
                      →Ok, that's incredible.
                      →Also — i found you have libs for Android, iOS and GAE
                      BugSense-support: yeap
                      →but what if I want to use you service for something else (like Mac desktop app for example)
                      →Do you have or plan public API?
                      BugSense-support: yeap
                      BugSense-support: we have a json api you can use
                      →Can't find docs on API
                      BugSense-support: and you can log whatever you like (we automatically display any extra info you send to us)
                      BugSense-support: yeap, it's not public yet
                      BugSense-support: but if you want I can send you our internal documentation
                      →Now I just investigate possibility, but thanks any way
                      →And thanks for your answers.
                      • 0
                        Так и что в итоге получилось?
                        Какие выводы можно сделать?

                        Впринципе и в гугл докс можно отделить баги по дате и версии, ведь багфиксы выпускаются — меняется версия приложения, появляются новые и легко понять где какие баги(старые или новые)
                • 0
                  Не рекомендую использовать google docs ввиду бажности данного продукта. Если хотя бы в одной ячейке много строк, то такой документ в google docs не отображается и его больше нельзя редактировать. По сути, после первой же загрузки данных через ACRA, документ становится нередактируемым. Плюс существует ограничение на количество записей — необходимо сразу интегрировать скрипт для очистки лишних записей.

                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.