Поймать журнал, что это за программа для Android

Обновлено: 30.09.2022

Сбои на Android могут очень расстраивать пользователей, настолько, что после двух сбоев обычный пользователь удалит ваше приложение. К счастью, Android Framework предоставляет несколько отличных инструментов для отладки сбоев и предоставляет несколько полезных журналов сбоев, которые разработчики могут прочитать, чтобы определить, что вызвало эту критическую проблему. В этой записи блога мы рассмотрим три наиболее важных журнала сбоев, используемых системой: трассировки стека исключений, трассировки ANR и захоронения NDK.

Трассировка стека исключений

Трассировка стека JVM — это наиболее распространенный тип сбоя, с которым сталкиваются типичные приложения Android, поскольку большинство приложений написано либо на Kotlin, либо на Java. В языках JVM исключение создается в исключительных обстоятельствах и содержит отладочную информацию о возникшей ошибке, например трассировку стека с информацией о номере файла/строки и сообщение об ошибке.

Если в приложении не установлен пакет SDK для создания отчетов о сбоях, следующий лучший способ получить журналы сбоев — использовать adb для просмотра logcat. Это удобный метод, если возможен физический доступ к устройству, потому что UncaughtExceptionHandler по умолчанию в приложениях для Android распечатывает всю трассировку стека в Logcat перед завершением процесса, что означает, что аварийный выход фактически выполняется в доступном месте для разработчиков.< /p>

Отслеживание ANR

ANR (приложение не отвечает) возникает, когда приложение не отвечает на действия пользователя в течение заметного периода времени. Видимый эффект этого заключается в том, что приложение «зависает» с точки зрения пользователя, что может быть очень неприятно. Распространенные причины включают чтение/запись диска в основном потоке и другие длительные задачи, которые препятствуют обновлению пользовательского интерфейса в ответ на вводимые пользователем данные.

Если приложение находится на переднем плане, примерно через 5 секунд появится диалоговое окно, позволяющее пользователю закрыть приложение. В этот момент на диск будет записана трассировка, включающая детали ANR, из которой можно извлечь ценную информацию для отладки. Опять же, для этого требуется физический доступ к устройству, если у вас не установлен SDK для создания отчетов о сбоях, который поддерживает обнаружение ANR.

Надгробие

Журналы сбоев Tombstone записываются, когда в приложении Android происходит собственный сбой в коде C/C++. Платформа Android записывает трассировку всех запущенных потоков на момент сбоя в /data/tombstones вместе с дополнительной информацией для отладки, такой как информация о памяти и открытых файлах. Надгробия ближе всего к металлу с точки зрения информации, поскольку они будут записывать такие детали, как необработанные адреса памяти, и поэтому их может быть немного сложнее понять, если вы не знакомы с отладкой собственного кода. Опять же, для чтения надгробий требуется физический доступ к корневому устройству.

Как получить журналы сбоев с устройства Android

В качестве предварительного условия для всех этих шагов вы должны установить Android Studio и добавить инструменты командной строки в свой путь. Эти локальные методы используют инструмент adb. У вас также должно быть подключено устройство или эмулятор, на котором включены параметры разработчика.

Примечание. Если вам удобно использовать Проводник файлов устройства непосредственно в Android Studio, вы можете открывать файлы устройств непосредственно оттуда, а не с помощью adb pull.

Трассировка стека исключений

По умолчанию трассировки стека исключений распечатываются в инструменте Logcat на устройствах Android. Журналы сбоев можно получить, выполнив следующие действия:

  1. Вызвать сбой на устройстве. Трассировка стека будет отображаться в терминале как новый текст.
  2. Сохраните вывод терминала в файл по вашему выбору для последующего просмотра.

Если на устройстве недавно произошел сбой, вы можете пропустить шаг 2. Это связано с тем, что Logcat сохраняет буфер последних журналов, который должен включать исключение. Однако это зависит от времени, поэтому, если вы ищете сбой, произошедший день назад, эта информация может быть потеряна навсегда, если вы не воспользуетесь инструментом для создания отчетов о сбоях, например Bugsnag.

Отслеживание ANR

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

Кроме того, вы можете просмотреть сводную информацию ANR, выполнив следующую команду

Надгробие

    или эмулятор, чтобы вы могли получить доступ к каталогу захоронения. (Будьте осторожны при рутировании устройств, так как этот шаг потенциально может привести к поломке вашего телефона)
  1. Вызвать встроенный сбой на устройстве.
  2. Выполните следующую команду, чтобы определить, какие журналы сбоев-захоронений присутствуют на устройстве.
  1. Выполните следующую команду, заменив место назначения файлом по вашему выбору.tombstone_01 показан здесь в качестве примера имени файла, которое было бы получено на предыдущем шаге
  1. Проверьте информацию в журнале сбоев Tombstone, открыв сохраненный файл.

Понимание данных журнала сбоев Android

Трассировка стека исключений

Чтение трассировки стека JVM поначалу может показаться пугающим, но если разбить ее на составные части, задача станет довольно простой. Давайте рассмотрим это шаг за шагом со следующим исключением RuntimeException, которое было сгенерировано в примере приложения:

Начнем с верхней части журнала сбоев. Здесь мы видим идентификатор процесса, который система присвоила исполняющемуся приложению, а также имя пакета, что может быть полезно при сопоставлении с другой информацией, полученной с помощью logcat. В нашем примере приложения имя пакета — «com.bugsnag.android.example»:

Следующая полезная информация — это класс исключений. В Java/Kotlin все исключения и ошибки являются классами, которые расширяют Throwable или один из подклассов Throwable, и каждый класс исключений может иметь разное семантическое значение. Например, разработчик может захотеть сгенерировать исключение IllegalStateException, если программа вошла в неожиданное состояние, или исключение IllegalArgumentException, если пользователь попытался сохранить значение null в качестве своего имени. В нашем случае мы сгенерировали исключение RuntimeException, полное имя класса которого показано ниже:

Сообщение об ошибке также печатается в журнале сбоев, что может быть очень полезно для предоставления дополнительной отладочной информации. В нашем случае мы только что предоставили текст «Фатальный сбой», но мы могли бы также передать значения наших переменных во время сбоя, если нам нужна дополнительная информация для отладки.

Следующее, что есть в нашем журнале сбоев, — это пикантная часть информации — трассировка стека потока, в котором произошло исключение. Глядя на верхний кадр стека, мы обычно можем точно определить, откуда была выдана ошибка, а кадры под ним позволяют наблюдать, в каком состоянии была программа во время сбоя. Верхний кадр стека выглядит следующим образом:

Мы сразу видим, что это содержит очень полезную информацию. Нам дан класс «com.example.foo.CrashyClass», так что мы можем открыть исходный файл и поискать там ошибку. Нам также дается имя метода «sendMessage» и номер строки сбоя, 10, поэтому мы можем точно указать в нашем источнике, откуда было выдано исключение.

Понимание журнала сбоев с этого момента зависит от чтения приведенных ниже кадров стека, которые расположены в том порядке, в котором методы были первоначально вызваны. Рассмотрим пример ниже:

-- CODE language-shell --
at com.example.foo.CrashyClass.sendMessage(CrashyClass.java:10)
at com.example.foo.CrashyClass.crash( CrashyClass.java:6)
в com.bugsnag.android.example.ExampleActivity.crashUnhandled(ExampleActivity.kt:55)

Начиная сверху, мы можем сказать, что «sendMessage» был вызван «crash», который, в свою очередь, был вызван методом «crashUnhandled», который, по-видимому, и является источником нашего сбоя. Конечно, полная трассировка стека исключений была несколько сложнее и также включала вызовы методов в среде Android, но основной принцип остался прежним.

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

Отслеживание ANR

Трассы ANR содержат очень большой объем информации. Поскольку ANR потенциально может быть вызвано тем, что несколько приложений борются за ограниченное количество ресурсов, полный журнал сбоев содержит трассировки стека для нескольких разных процессов. Эта полная информация может быть очень полезна для отладки, когда ничего не помогает, но в большинстве случаев сводной информации ANR, напечатанной в Logcat, достаточно для отладки ошибки. Учтите следующее:

Во-первых, журнал сбоев содержит информацию о том, какой процесс в системе подвергся ошибке ANR, а также идентификатор процесса и имя пакета, которые пригодятся при поиске соответствующих трассировок стека в более подробной трассировке ANR:

-- CODE language-shell --
E/ActivityManager: ANR в com.bugsnag.android.example (com.bugsnag.android.example/.ExampleActivity)
PID: 10859

Среда Android дает нам причину для ANR. В этом случае пользователь коснулся экрана несколько раз, и очередь отправки ждала более 6 секунд, не показывая видимого ответа на эти события касания. Это представляет собой очень плохой пользовательский опыт, который будет заметен, поскольку все приложение будет зависать с точки зрения пользователя:

-- CODE language-shell --
Причина: истекло время ожидания диспетчеризации ввода (ожидание отправки неключевого события, поскольку затронутое окно не завершило обработку определенных событий ввода, которые были доставлены ему более 500,0 мс назад. Длина очереди ожидания: 33. Возраст заголовка очереди ожидания: 6178,1 мс.)

Наконец, мы получили некоторую информацию о загрузке процессора. Хотя некоторые ANR имеют простые причины, такие как выполнение ввода-вывода в основном потоке, это не всегда так. Иногда ANR может возникать на низкопроизводительном устройстве из-за того, что множество ресурсоемких приложений конкурируют за ЦП, поэтому определение того, есть ли другие приложения, использующие много ресурсов одновременно с нашим приложением, может быть очень полезным:

Надгробие

Как и трассировки ANR, надгробия также содержат очень большой объем информации, которую невозможно просмотреть полностью. Мы рассмотрим усеченный пример, в котором самая важная информация показана вверху:

Аннотация:
Эта статья будет полезна тестировщикам и разработчикам мобильных приложений для установки и сбора журналов в приложении Android. Я попытался объяснить, как тестер/разработчик может установить приложение для Android и вести журнал сбоев/ошибок для сбоя приложения. Журнал полезен разработчику для отладки и исправления ошибок.

Введение.
Во время тестирования/использования приложения для Android происходит сбой или прекращение работы приложения по непредвиденным причинам. Когда приложение дает сбой, процесс приложения завершается и отображается диалоговое окно с сообщением, например: «К сожалению, приложение остановлено». Инструмент захвата журнала фиксирует весь процесс и создает историю, известную как журнал, которая требуется разработчику для отладки кода и выяснения фактической причины сбоя/ошибки. Многие компании по разработке приложений для Android полагаются на использование интегрированной среды разработки для всех приложений Android, и Android Studio всегда возглавляет список предпочтительных инструментов для разработчиков.

Различные способы установки и вести журнал сбоев/ошибок на устройствах Android

Как установить файл .apk на устройства Android:

Установка в формате .apk для Android. Существует два распространенных способа установки файла .apk на устройство Android.

<р>1. Лучший способ установить приложение для Android — это установить его через приложение Diawi или Hockey или из Play Store (для альфа- и бета-версий). Много раз мы наблюдали, что сборка работает нормально, если мы устанавливаем ее локально с компьютера, но после публикации ее на каком-либо канале мы начинаем получать странные ошибки, например, функция, работающая в локальной сборке, не работает в выпущенной сборке. Чтобы избежать этих проблем, я бы посоветовал тестировщику загрузить сборку с промежуточных платформ, таких как приложение Diawi или Hockey, или из Play Store (для альфа- и бета-версий).

Различные способы установки и вести журнал сбоев/ошибок на устройствах Android

<р>2. Установите .apk на Android-устройство с помощью ADB:

Различные способы установки и вести журнал сбоев/ошибок на устройствах Android

Различные способы установки и вести журнал сбоев/ошибок на устройствах Android

Как записать журнал для приложения Android:

Во время тестирования приложения иногда происходит сбой приложения или появляются непредвиденные ошибки, и тестировщик/пользователь блокируется для тестирования/использования приложения. Итак, нам потребовалось записать журнал устройства, чтобы узнать точную проблему. Существует множество способов захвата журнала для Android. Мы можем записывать журнал с помощью ADB Command, Android SDK, Android Studio и инструментов aLogcat.

Захват журнала устройства Android с помощью команды ADB. Чтобы записать журнал устройства, нам нужно выполнить несколько шагов.
• Подключите устройство к ПК.
• Включите режим разработчика устройства (перейдите в «Настройки» > «О телефоне» > «Номер сборки» > нажмите на номер сборки 4–5 раз > включите отладку по USB в режиме разработчика)
• Откройте командную строку
• Напишите команду «adb devices» в командной строке
• После отображения подключенного устройства в командной строке напишите «Adb logcat», чтобы записать журнал
• Выполните действия на устройство для воспроизведения сбоя/ошибки
• После воспроизведения ошибки остановите процесс записи журнала, нажав «Ctrl+C»
• Напишите команду «adb logcat>log path/file name.txt», чтобы сохранить журнал файл.

Различные способы установки и вести журнал сбоев/ошибок на устройствах Android

Различные способы установки и сохранения журнала сбоев/ошибок на устройствах Android

Различные способы установки и вести журнал сбоев/ошибок на устройствах Android

Создание журнала устройства Android с помощью Android SDK (инструмент monitor.bat):

Чтобы вести журнал устройства с помощью Android SDK, на ПК должен быть установлен инструмент Android SDK. Нам необходимо выполнить указанные ниже шаги для записи журнала с помощью инструмента Android SDK.

• Подключите устройство к ПК.
• Перейдите в раздел Android SDK > Инструменты и дважды щелкните файл monitor.bat.
• После нажатия на файл monitor.bat открывается инструмент «Android Debug Monitor».
• Затем выберите устройство в разделе «Устройство».
• Нажмите на вкладку Logcat с консолью.
• Нажмите на значок «Очистить», чтобы очистить предыдущий журнал.
• Выполните шаги, чтобы воспроизвести ошибку на устройстве.
• После воспроизведения ошибки на устройстве нажмите кнопку «Сохранить» в «Android Debug Monitor».
• Выберите путь к папке и сохраните файл.

Различные способы установки и вести журнал сбоев/ошибок на устройствах Android

Запись журнала устройства Android с помощью Android Studio:

Чтобы записать журнал устройства, нам нужно выполнить несколько шагов.
• Включите режим разработчика устройства (перейдите в «Настройки» > «О телефоне» > «Номер сборки» > нажмите на номер сборки 4-5 раз >
Включите отладку по USB в режиме разработчика)
• Подключите устройство к ПК < br />• Запустите Android Studio.
• Нажмите кнопку «Выполнить».
• Выберите свое устройство.
• Нажмите кнопку «ОК».
• Нажмите «Android Monitor».
• Перейдите на вкладку Logcat
• Выполните действие в приложении на устройстве
• Выберите и скопируйте захваченный журнал на вкладке Logcat
• Откройте файл .txt, вставьте скопированный журнал и сохраните файл

Различные способы установки и вести журнал сбоев/ошибок на устройствах Android

Различные способы установки и вести журнал сбоев/ошибок на устройствах Android

Запись журнала с помощью инструмента aLogcat на устройстве Android:

Инструмент aLogcat разработан для устройств Android. Инструмент aLogcat — это приложение для Android, которое используется для записи журнала сбоев или ошибок. Итак, нам нужно установить на наше устройство инструмент Logcat из магазина Google Play. Чтобы записать журнал с помощью aLogcat, нам нужно выполнить несколько шагов.
• Запустите инструмент aLogcat на устройстве.
• Сверните инструмент aLogcat.
• Запустите приложение для тестирования.
• Выполните действие и воспроизведите ошибку сбоя/ошибки в приложении для тестирования.
• Разверните инструмент aLogcat и закройте его.
• Перейдите в память устройства > папка Logcat
• Сохраните файл Logcat.txt

.

Объедините свои веб-приложения и мобильные приложения с гибкими услугами и решениями по тестированию для обеспечения качества с помощью QSS Technosoft. Поддерживаемая квалифицированной командой тестировщиков, QSS является лидером в предоставлении надежных услуг по обеспечению качества и тестированию в Индии. Так что не ищите дальше и свяжитесь с нами, чтобы получить бесперебойную и беспроблемную работу с веб-приложениями и мобильными приложениями без сбоев!

Об авторе:
Рагендра Сингх — инженер по контролю качества, в настоящее время работает в QSS Technosoft Pvt Ltd. Он получил степень магистра информационных технологий.

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

Причина, по которой я пишу здесь, заключается в том, что в какой-то момент мое приложение дало сбой, но когда я беру журналы с помощью DDMS/Logcat, мои данные о сбое записываются новыми журналами.

Как мне получить журналы причин сбоев..

Особенно хочу зафиксировать сбой нативного кода.

т. е. I/DEBUG (21835): сигнал 11 (SIGSEGV), код 1 (SEGV_MAPERR), адрес ошибки 00000004.

Будет ли этот adb logcat > crash.txt гарантировать, что запись в файл будет происходить вечно?


6 ответов 6

Я попробовал это. Работает очень хорошо, но не уверен, сколько батареи он будет потреблять.. Если ваше приложение находится на стадии тестирования, вы можете использовать это.. Перед выпуском вы должны удалить этот код и опубликовать..


Журнал Android будет сохранен только в том случае, если в манифесте вашего приложения указано значение Debugging = true (т. е. когда вы находитесь в режиме отладки).

См. документацию по отключению ведения журнала и отладки

Это будет вызываться всегда, когда ваше приложение принудительно закрывается из-за исключения.

Вы сохраняете StackTrace в файле в режиме добавления.

Вы также можете использовать это в режиме отладки.

LogCat — это очередь, поэтому есть изменения, которые вы не заметите в своем журнале (старый журнал будет автоматически удален).

Я предлагаю вам реализовать setDefaultUncaughtExceptionHandler, чтобы вы никогда не пропускали ни одного журнала исключений. Также позаботьтесь об удалении файла после использования, иначе ваш файл со временем станет очень большим.


установите приложение aLogCat, а затем, если ваше приложение выйдет из строя, запустите его. Используйте фильтр (из меню), чтобы сузить данные до тех, которые относятся к вашему приложению, и в конечном итоге сохранить их или отправить вам с устройства по почте. Но это не совершит большого волшебства — если журналы физически исчезли с устройства, оно не отправит вам больше, чем вы можете получить с помощью DDMS. Однако это весьма полезно, если ваши пользователи сообщают о сбоях.

tanZ.. Я знаю о приложении alogcat.. Но недостатком является то, что оно не будет фиксировать какие-либо детали сбоя собственного кода, т.е. I/DEBUG (21835): сигнал 11 (SIGSEGV), код 1 (SEGV_MAPERR), адрес ошибки 00000004

Предположим, что у вас есть доступ к устройству:

  1. Подключите устройство к компьютеру.
  2. Запустите DDMS, выберите устройство и перейдите на вкладку проводника.
  3. Найдите файл, указанный в LogCat, и нажмите кнопку «Извлечь с устройства» вверху.

Вы должны использовать уникальные теги журнала для своих сообщений, чтобы вы могли фильтровать кота для этого. Например. getPackageName() — хороший кандидат, и он возвращает строку.

В Eclipse вы можете щелкнуть зеленый значок +, чтобы добавить еще один фильтр для представления LogCats. В окне повторяете свой тег в поле "по тегу журнала".

Также кажется, что когда я запускаю свое приложение из Eclipse, автоматически появляется новая вкладка под названием «Фильтр сеанса», предоставляющая соответствующие журналы, включая, но не только те, которые написаны программистом.

Вы также можете получить журнал непосредственно из консоли с помощью Android Developer Bridge. adb logcat — это команда, которую вы ищете, и, по словам человека, применимы те же настройки фильтра. Хотя я не мог понять синтаксис :)

Журналы устройств используются для устранения неполадок в приложениях. В этой статье базы знаний обсуждается, как устранять неполадки в защищенных приложениях Android с помощью ADB. Всякий раз, когда у вас возникают проблемы с приложением, его функциями или встроенным SDK, эти журналы могут помочь найти основную причину проблемы. В этой статье базы знаний содержатся пошаговые инструкции по сбору журналов устройств Android с помощью ADB при устранении неполадок в приложениях.

Мы надеемся, что вы найдете эту базу знаний полезной и получите удовольствие от использования Appdome!

Как устранять неполадки в защищенных приложениях Android с помощью ADB

ADB означает Android Debug Bridge. Устранение неполадок защищенных приложений Android с помощью ADB позволяет подключить устройство Android через USB-кабель к компьютеру. С помощью этого подключения вы можете удалять приложения, выполнять команды оболочки на своем устройстве, устанавливать приложения и выполнять другие административные функции, которые помогают при устранении неполадок. Для получения дополнительной информации об этом см. этот и просмотрите этот ресурс.

Appdome – это платформа безопасности мобильных приложений без кода, предназначенная для добавления функций безопасности в мобильные приложения.

Платформа Appdome для защиты мобильных приложений без кода предлагает мобильным разработчикам, DevSec и специалистам по безопасности удобный и надежный способ защиты приложений Android и iOS без написания кода. Когда пользователь нажимает «Создать мое приложение», Appdome использует микросервисную архитектуру, заполненную тысячами подключаемых модулей безопасности, и адаптивный механизм генерации кода, который сопоставляет правильные требуемые подключаемые модули со средой разработки, платформами и методами в каждом приложении.

При использовании Appdome не требуется предварительных условий разработки или написания кода для создания защищенных приложений. Нет ни SDK, ни библиотеки для ручного кодирования или реализации в приложении. Технология Appdome автоматически добавляет в приложение соответствующие стандарты, платформы, хранилища и логику, не требуя ручной разработки.

Необходимые условия для устранения неполадок в защищенных приложениях Android с помощью ADB

Чтобы использовать ADB, вам потребуется:

    . Убедитесь, что инструменты платформы включили ADB в этот пакет.
  • Драйвер USB для мобильного устройства
  • Приложение для Android, в котором включены журналы диагностики.

Чтобы упростить использование ADB, вам необходимо разрешить отладку по USB на вашем устройстве:

3 простых шага по устранению неполадок в защищенных приложениях Android с помощью ADB

Функции журналов диагностики Appdome также полезны при устранении неполадок в защищенных приложениях Android с помощью ADB.

  1. Обратитесь в службу поддержки Appdome, чтобы узнать, можно ли в вашем аккаунте включить журналы диагностики для сборок приложений.
  2. Во время слияния/сборки приложения вы можете включить журналы диагностики в нижней части страницы.
  3. В разделе «Устранение неполадок» включите журналы диагностики для сборки.
    • Вы можете включить возможность отправлять журналы по электронной почте или загружать их в службу поддержки Appdome одним касанием в приложении в разделе «Журналы диагностики».

Сбор журналов устройств Android с помощью ADB

Внимание! Если у вас версия ADB 1.0.40 и выше, а ваше устройство — LG:

  1. Имя устройства можно получить, введя «adb devices». Эта команда также сообщит вам, подключено ли устройство к компьютеру.
  2. Выполнить: adb -s shell -t «logcat»Вот ссылка на видео об извлечении журналов диагностики из приложений Android.

Как получить журналы устройств с помощью Android Studio

Как узнать больше?

Дополнительную информацию о получении журналов из Logcat с помощью Android Studio см. в этом блоге.

Спасибо!

Спасибо, что посетили Appdome! Наша миссия — упростить мобильную интеграцию. Мы надеемся, что мы выполняем миссию с вашим проектом. Если у вас еще нет учетной записи, вы можете зарегистрироваться бесплатно.

Читайте также: