What is android logcat

Отладка приложения, Logcat

Для отладки приложений могут быть использованы всплывающие сообщения Toast. Однако это не эффективно. Android SDK включает средство просмотра отладочных сообщений Logcat. Оно не представляет сложности в освоении, поэтому широко используется программистами. Logcat позволяет просматривать отладочные сообщения не только разрабатываемого приложения, но и протоколируемые системой сообщения. Так, например, Garbage Collection периодически протоколирует свои сообщения о выполнении определенных действий («сборке мусора»), которые можно просматривать с помощью Logcat.

Для протоколирования сообщений необходимо использовать класс android.util.Log, позволяющий объединять сообщения по категориям. В следующем списке приведены методы класса Log, отсортированные по приоритету (важности) от высшего к низшему :

• Log.e(String, String) — ошибка (error)
• Log.w(String, String) — предупреждение (warning)
• Log.i(String, String) — информация (info)
• Log.d(String, String) — отладка (debug)
• Log.v(String, String) — подробно (verbose)

Пример протоколирования

В качестве первого параметра методов Log используется текстовый тег (в примере переменная TAG). Если имеется необходимость в качестве тега сообщения определить наименование класса, то можно использовать следующее определение :

Панель Logcat в Studio

Logcat в среде разработки Android Studio располагается на отдельной вкладке, интерфейс которой представлен на следующем скриншоте. Слева вертикально располагаются кнопки управления сообщениями : очистка, перемещение по списку и т.д. Интерес представляет расположенный сверху справа компонент с выпадающим списком/меню. Если выбрать представленный на скриншоте пункт «Edit Filter Configuration», то можно определить фильтр сообщений, окно которого изображено на следующем скриншоте.

Фильтр сообщений

Logcat позволяет создать набор из нескольких фильтров. Достаточно только для каждого фильтра определить его наименование «Filter Name» и тег сообщений «Log Tag». Значение тега сообщения регистрируется классом android.util.Log.

Создадим простой пример протоколирования сообщений. В примере переопределим методы активности; в каждом методе будем протоколировать соответствующее сообщение.

Листинг активности

После старта приложения переходим на вкладку Locat и просматриваем список регистрируемых сообщений. Чтобы исключить сообщений системы установим фильтр State (справа, сверху). После этого можно менять ориентацию устройства (portrait => landscape => portrait) и контролировать список сообщений.

Протоколируемые сообщения можно просматривать не только с помощью Logcat. Они также попадают и на вкладку Run (см. следующий скриншот), но только с ме́ньшей функциональностью (отсутствует время регистрации, нельзя фильтровать и т.д.).

Формат сообщения

Logcat представляет сообщения в определенном формате : «date time PID-TID/package priority/tag: message». Поле даты (date) имеет формат MM-DD (месяц–день). Формат времени (time) HH24:MI:SS.SSS (часы:минуты:секунды.мс) включает милисекунды. Значения идентификаторов процесса PID и потока TID могут совпадать, если существует только один поток. Пример сообщения : 02-08 08:43:51.557 11608-43308/com.android.test.p08activity D/ACTIVITY_STATE: onStop.

Английский вариант полного описания Logcat.

Контроль протоколирования, BuildConfig

На этапе разработки приложения вывод отладочных сообщений, конечно же, полезен и необходим. Но что делать с этими сообщеними в готовом релизе? Если проект включает несколько модулей с различными тегами отладочных сообщений, то подготовка очередного релиза потребует определенных усилий с ручным удалением отладочных сообщений и комментариев. Иногда программисты используют условные выражения для вывода сообщений/комментариев. Например :

В этом примере сообщения будут протоколироваться в отдельной процедуре WriteLog только если IS_RELEASE=false. Одним движением (IS_RELEASE=true) можно блокировать протоколирование сообщений перед созданием готового apk-файла.

Начиная с 17-ой версии Android Build Tools в приложении автоматически формируется класс BuildConfig, содержащий статическое поле DEBUG с признаком отладочной сборки. При использовании данного класса перед протоколированием необходимо выполнить следующую проверку :

Объект BuildConfig можно расширить и включить в него свой «тег». Для этого необходимо внести соответствующие изменения в секцию buildType сборочного build.gradle файла проекта. Вот как может выглядеть секция buildType для тега ACTIVITY_STATE :

Конфигурация releaseWithLog будет релизной сборкой с протоколированием. Соответственно в коде приложения необходимо будет выполнять следующую проверку :

Источник

Logcat

В Android SDK входит набор инструментов, предназначенных для отладки. Самый важный инструмент при отладке — это LogCat (очень красивое название, которое можно перевести как Логичный Кот). Он отображает сообщения логов (журнал логов), рассылаемые при помощи различных методов.

Рассмотрим на примере. Очень часто программисту нужно вывести куда-то промежуточные результаты, чтобы понять, почему программа не работает. Особо хитрые временно размещают на экране текстовую метку и выводят туда сообщение при помощи метода textView.setText(«Здесь был Васька»). Но есть способ лучше. В Android есть специальный класс android.util.Log для подобных случаев.

Класс android.util.Log позволяет разбивать сообщения по категориям в зависимости от важности. Для разбивки по категориям используются специальные методы, которые легко запомнить по первым буквам, указывающие на категорию:

• Log.e() — ошибки (error)
• Log.w() — предупреждения (warning)
• Log.i() — информация (info)
• Log.d() — отладка (degub)
• Log.v() — подробности (verbose)
• Log.wtf() — очень серьёзная ошибка! (What a Terrible Failure!, работает начиная с Android 2.2)
• Log.meow() — когда жрать дадут? (MEOW!) Недокументированный метод, используйте на свой страх и риск. Работает не на всех устройствах

В первом параметре метода используется строка, называемая тегом. Обычно принято объявлять глобальную статическую строковую переменную TAG в начале кода:

Некоторые в сложных проектах используют следующий вариант, чтобы понимать, в каком классе происходит вызов:

Далее уже в любом месте вашей программы вы вызываете нужный метод журналирования с этим тегом:

Также используется в исключениях:

Пользователи не видят этот журнал. Но, вы, как разработчик, можете увидеть его через программу LogCat, доступный в Android Studio.

Полный вид сообщения выглядит следующим образом.

03-09 20:44:14.460 3851-3879 / ru.alexanderklimov.cat I/OpenGLRenderer : Initialized EGL, version 1.4

• 03-09 20:44:14.460 Date/Time
• 3851-3879 Process & Thread IDs
• ru.alexanderklimov.cat Package name
• I/OpenGLRenderer Tag
• Initialized EGL, version 1.4 Message

Подобные длинные сообщения не всегда удобны для чтения. Вы можете убрать ненужные элементы. Для этого выберите значок LogCat Header в виде шестерёнки и уберите флажки у опций.

В LogCat вы можете отфильтровать сообщение по заданному типу, чтобы видеть на экране только свои сообщения. Для этого выберите нужный тип тега из выпадающего списка Verbose.

Типы сообщений можно раскрасить разными цветами через настройки File | Settings | Editor | Colors Scheme | Android Logcat.

Для отслеживания сообщений с заданным текстом введите в поле поиска нужную строку и нажмите Enter.

Также активно используйте варианты из других выпадающих списков. Например, выбирайте свой пакет из второй колонки, а в последней выбирайте Show only selected application. Для более точной настройки используйте Edit Fiter Configuration.

По умолчанию, окно LogCat выводится в нижней части студии. При желании, можно выбрать другие варианты через значок настроек окна.

LogCat также можно запустить из командной строки:

Параметры командной строки смотрите в документации.

Быстрое отключение журналирования

Настоятельно рекомендуется удалять все вызовы LogCat в готовых приложениях. Если проект очень большой и вызовы журналирования разбросаны по всем местам кода, то ручное удаление (или комментирование) становится утомительным занятием. Многие разработчики используют следующую хитрость — создают обёртку вокруг вызова методов LogCat.

Теперь остаётся только присвоить нужное значение переменной isDebug перед созданием готового apk-файла для распространения.

Способ устарел. В 17-й версии Android Build Tools появился класс BuildConfig, содержащий статическое поле DEBUG. Можно проверить следующим образом:

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

В этом случае конфигурация releaseWithLog будет являться релизной сборкой с ведением логов. Естественно, в коде слегка поменяется проверка:

LogCat на устройстве

Попался в сети пример для просмотра сообщений LogCat на устройстве. С примером не разбирался, оставлю здесь на память.

Источник

logcat

The Android logging system provides a mechanism for collecting and viewing system debug output. Logs from various applications and portions of the system are collected in a series of circular buffers, which then can be viewed and filtered by the logcat command. You can use logcat from an ADB shell to view the log messages.

For complete information about logcat options and filtering specifications, see Reading and Writing Logs.

For more information on accessing logcat from DDMS, instead of the command line, see Using DDMS.

Syntax

You can run logcat as an adb command or directly in a shell prompt of your emulator or connected device. To view log output using adb, navigate to your SDK platform-tools/ directory and execute:

You can create a shell connection to a device and execute:

Options

The following table describes the command line options of logcat .

Option	Description
-b	Loads an alternate log buffer for viewing, such as events or radio . The main buffer is used by default. See Viewing Alternative Log Buffers.
-c	Clears (flushes) the entire log and exits.
-d	Dumps the log to the screen and exits.
-f	Writes log message output to . The default is stdout .
-g	Prints the size of the specified log buffer and exits.
-n	Sets the maximum number of rotated logs to . The default value is 4. Requires the -r option.
-r	Rotates the log file every of output. The default value is 16. Requires the -f option.
-s	Sets the default filter spec to silent.
-v You have successfully signed up for the latest Android developer news and tips. Источник XDA Basics: How to take logs on Android Logs are very useful when a developer is diagnosing an error with a piece of software. So, as a user, when you complain to a developer about a problem with their Android app or an aftermarket firmware (custom ROM), they’ll ask you to submit a log to help them troubleshoot the issue. Android includes a number of logs that deal with different parts of the firmware, and there are a number of ways to collect those logs. In this guide, we’ll talk about the various common logs and how you can collect them on Android for bug reports. Before we start, you should set up Android Debug Bridge on your computer as you might need ADB access for some of these logs. We have a great guide on how to set up ADB on any computer. Kernel panic logs Kernel panic logs are useful to figure out what happened during an unsuccessful boot. If you’re trying to run a custom ROM but your phone is stuck at the boot loop, you can collect kernel panic logs to help the ROM developer find out what went wrong. A majority of Android manufacturers use upstream ‘pstore’ and ‘ramoops’ drivers to store kernel logs after a panic. Ramoops writes its logs to the RAM before the system crashes. With root access, these logs can be retrieved from: The file name could be slightly different but it’ll be in the pstore directory. You can get it using ADB pull or any other way you want. For example: adb pull /sys/fs/pstore/console-ramoops C:\Users\Gaurav\Desktop\filename Driver messages The log from the driver messages buffer can be used to diagnose issues with system drivers and why something isn’t working. On Android, you can use the ‘dmesg’ output to get these logs. You’ll need root access to get these logs though. Use the following ADB command to export the complete log. System logs System logs are useful when something in the system throws an error. Android allows collecting system logs using Logcat. Log messages can be viewed in a Logcat window in Android Studio, or you can use the command line tool to pull them. Several Android apps are also available in the Google Play store that allow easy access to these tools. We’ll talk about these apps later in this article. Moreover, several custom ROMs come with options in the Developers settings to collect the system logs. To collect logs using ADB, use the following command. This command will export a continuous log, so use Ctrl + C to stop it. You can use the -d parameter to export the complete log in one go. If you want, you can also view or save the radio buffer using the following command. If your device is rooted, you can use the Terminal app on the device itself to collect logs. To save a log using Terminal on your phone, type the following command so the log will be saved on your phone. Android apps for collecting logs Logcat Extreme Logcat Extreme can help you read the logcat and dmesg outputs as well as record logs. It requires root access to show logs properly. Источник Читайте также:  Все самое новое для андроида Оцените статью Вам также может понравиться Как деактивировать режим наушников на смартфоне с Android? Когда к мобильному устройству присоединены наушники Обзор игры Джелли-Джу для Android В последние годы популярность мобильных игр резко возросла Лучшие шахматные приложения для iOS и Android Нынешний читерский скандал в шахматном мире сейчас Что хотят увидеть пользователи от Android 5.0 Key Lime Pie ОС Google Android развивается, и по всему видимому Правообладателям Политика конфиденциальности Контакты