что значит уровень журнала на андроид
Как включить/отключить уровни журналов в Android?
У меня есть множество операторов регистрации для отладки, например.
при развертывании этого приложения на телефоне устройства я хочу отключить подробный журнал, откуда я могу включить/отключить протоколирование.
ОТВЕТЫ
Ответ 1
Общим способом является создание имени именованного логического уровня и определение его уровня отладки на основе loglevel.
Позже вы можете просто изменить LOGLEVEL для всех уровней вывода отладки.
Ответ 2
Verbose никогда не следует компилировать в приложение, кроме как во время разработки. Журналы отладки компилируются, но удаляются во время выполнения. Журналы ошибок, предупреждений и информации всегда сохраняются.
Таким образом, вы можете захотеть удалить дескрипторы журнала Verbose, возможно, используя ProGuard, как это предлагается в другом ответе.
В качестве альтернативы вы можете указать их в файле ‘/data/local.prop’ следующим образом:
В более поздних версиях Android требуется, чтобы /data/local.prop был доступен только для чтения. Этот файл читается во время загрузки, поэтому вам необходимо перезапустить его после его обновления. Если /data/local.prop доступен для записи в мире, он, вероятно, будет проигнорирован.
Ответ 3
Это будет — кроме всех других оптимизаций ProGuard — удалите любые подробные записи журнала непосредственно из байт-кода.
Ответ 4
Ответ 5
Лучше всего использовать API SLF4J + часть его реализации.
Для приложений Android вы можете использовать следующее:
Ответ 6
Вы должны использовать
Ответ 7
Удаление журнала с помощью proguard (см. ответ от @Christopher) было простым и быстрым, но оно вызвало трассировку стека из производства, чтобы не соответствовать источнику, если в файле было зарегистрировано отладочное ведение журнала.
В этом методе используется запись в сообществах.
Ответ 8
Log4j или slf4j также могут использоваться в качестве фреймворков регистрации в Android вместе с logcat. См. Проект android-logging-log4j или поддержка log4j в android
Ответ 9
Ответ 10
Это позволяет вам иметь прекрасный контроль над журналами. Вы можете, например, отключить все журналы или только журналы некоторых пакетов или классов.
Кроме того, он добавляет некоторые полезные функции (например, вам не нужно передавать тег для каждого журнала).
Ответ 11
Вот более сложное решение. Вы получите полную трассировку стека, и метод toString() будет вызываться только при необходимости (Performance). Атрибут BuildConfig.DEBUG будет ложным в рабочем режиме, поэтому все журналы трассировки и отладки будут удалены. Компилятор горячей точки имеет возможность удалить вызовы из-за окончательных статических свойств.
Ответ 12
Я создал утилиту /Wrapper, которая решает эту проблему + другие общие проблемы, связанные с журналом.
Утилита отладки со следующими функциями:
Я попытался сделать документацию самодостаточной.
Предложения по улучшению этой утилиты приветствуются.
Ответ 13
В очень простом сценарии ведения журнала, где вы буквально просто пытаетесь писать на консоль во время разработки для целей отладки, проще всего просто выполнить поиск и заменить перед вашей производственной сборкой и прокомментировать все вызовы в журнал или System.out.println.
Например, если вы не используете «Журнал». где-либо вне вызова Log.d или Log.e и т.д., вы можете просто найти и заменить все решение для замены «Log». с «//Log». прокомментировать все ваши вызовы регистрации, или, в моем случае, я просто использую System.out.println всюду, поэтому, прежде чем приступать к производству, я просто сделаю полный поиск и замените для «System.out.println» и заменим на «//System.out.println».
Я знаю, что это не идеально, и было бы неплохо, если бы способность находить и прокомментировать вызовы Log и System.out.println были встроены в Eclipse, но до тех пор, пока это не будет самым простым и быстрым и лучшим способом сделайте это, чтобы прокомментировать поиск и заменить. Если вы это сделаете, вам не нужно беспокоиться о несоответствии номеров строк трассировки стека, потому что вы редактируете исходный код, и вы не добавляете никаких накладных расходов, проверяя конфигурацию уровня журнала и т.д.
Ответ 14
Ответ 15
Мы можем использовать класс Log в нашем локальном компоненте и определить методы как v/i/e/d. Основываясь на необходимости, мы можем позвонить дальше.
пример показан ниже.
Ответ 16
Для меня часто бывает полезно установить разные уровни журналов для каждой TAG.
Я использую этот очень простой класс-оболочку:
Теперь просто установите уровень журнала на TAG в начале каждого класса:
Ответ 17
Ответ 18
Однако System.setProperty() хранит совершенно другой набор свойств по сравнению со свойствами, доступ к которым может получить команда getprop которая может быть выдана в оболочке ADB. Следовательно, даже если вы попытаетесь использовать System.setProperty() для хранения уровня журнала для тега, он не будет работать.
Как уже упоминалось, вы можете использовать adb shell setprop
Уровни ведения журнала для Android
у меня возникли некоторые трудности с настройкой ведения журнала Android. Вот как выглядит мой код:
довольно просто, не так ли?
, у меня совсем немного труда получить Log.isLoggable(«MY_TAG», Log.VERBOSE) возвращает true.
Per http://developer.android.com/reference/android/util/Log.html, я попытался Добавить локальный.файл prop в каталог /data/, который выглядит следующим образом:
но не повезло. Я тоже попробовал:
но это не сработало.
любые идеи о том, что я делаю неправильно здесь? Я запускаю Android 2.1-update1 на Nexus 1, если это имеет значение.
3 ответов
кажется, что более поздние версии Андроид /data/local.prop для записи только root. The adb push команда, по-видимому, изначально создает файлы с предоставлением каждому доступа для чтения/записи (потому что маска файла по умолчанию 777 ). Андроид, мудро, игнорирует /data/local.prop так как это может быть угрозой безопасности.
я экспериментировал только с Android 2.3.3, и 4.1.2. У первого нет проблем с чтением a local.prop это мир, доступный для записи, в то время как последний, кажется, молча игнорировать содержимое файла.
создание local.prop файл, как описано в исходном вопросе:
а затем, нажав его на устройство следующим образом, кажется, делает трюк:
вы можете дважды проверьте, чтобы убедиться, что значения в local.prop читали исполнитель:
используя adb shell setprop log.tag.MyAppTag VERBOSE также работать. Проблема в том, что значения свойств теряются после перезагрузки.
важная цель-не отправлять производственное приложение с тонной вызовов журнала, оставшихся в нем, увеличивая его размер и даже, возможно, даже влияя на его производительность.
для этого я рекомендую поместить эти константы в начало каждого класса, который будет иметь вызовы журнала:
теперь, где вы входите, сделайте это:
включите журналы, изменив DEBUG постоянное значение true. (Если вы хотите, вы могли бы иметь один класс с этими статика для всего кода вашего приложения. Это имеет смысл для небольшого приложения, но по мере того, как все становится большим, приятно решить, какие части включить вход в систему.)
это подход, который принимает много рамок Android. Например,ManagerService Активность.
это имеет эти константы вверху, и различные строки журнала, разбросанные по всему на их основе. (И куча других констант суб-отладки для различных аспектов этого, так как этот файл смехотворно глупо велик.)
Уровни журнала Android
Android поддерживает различные уровни журналов, Verbose, Debug, Info, Warn и Error. Я понимаю, как работают уровни ведения журнала; Меня больше интересует типичный результат, ожидаемый для заданного уровня.
Например, при разработке приложения мне может быть любопытно, когда какой-то метод что-то делает (это часто бывает для целей отладки). Я просмотрю журналы, чтобы убедиться, что методы вызываются в ожидаемом порядке, если сетевой ответ – это то, что, как я думаю, должно быть, если парсеры найдут нужную информацию и т. Д.
Почему кто-то использует Verbose vs Debug vs Info?
С точки зрения разработчика, для первого, второго или стороннего приложения не все журналы для целей отладки? (Предполагая, что разработчики не смотрят журналы для удовольствия … Я не такой садистский)
С точки зрения потребителя, когда s *** попадает в вентилятор, и им необходимо обратиться в службу поддержки клиентов, потому что их супер важное / деловое приложение не работает, разработчик использует журнал для целей отладки.
Единственная причина, по которой я мог видеть использование подробностей или информации, – это, вероятно, операции сбора данных / хранилища данных. Если да, зачем использовать verbose vs info.
Не уверен. Если я злоупотребляю этим или если инфраструктура андроида …
Я в основном следую тому, что должен сказать Томаш Нуркевич при рассмотрении уровня ведения журнала:
ОШИБКА – случилось что-то ужасное, что нужно немедленно расследовать. Никакая система не может переносить элементы, зарегистрированные на этом уровне. Пример: NPE, недоступная база данных, критически важный случай использования не может быть продолжен.
WARN – процесс может быть продолжен, но проявляйте особую осторожность. Пример: «Приложение, запущенное в режиме разработки» или «Консоль администрирования не защищена паролем». Приложение может переносить предупреждающие сообщения, но они всегда должны быть оправданы и проверены.
INFO – Важный бизнес-процесс завершен. В идеальном мире администратор или продвинутый пользователь должен понимать сообщения INFO и быстро узнать, что делает приложение. Например, если заявка касается бронирования авиабилетов, в каждом билете должно быть только одно заявление INFO, в котором говорится: «[Кто] забронировал билет с [Где] до [Где]». Другое определение сообщения INFO: каждое действие значительно изменяет состояние приложения (обновление базы данных, внешний системный запрос).
VERBOSE – очень подробная информация, предназначенная только для разработки. Вы можете сохранять сообщения трассировки в течение короткого периода времени после развертывания в рабочей среде, но относить эти операторы журнала как временные, которые должны или могут быть отключены в конечном итоге. Различие между DEBUG и VERBOSE является наиболее сложным, но если вы поместите инструкцию регистрации и удалите ее после того, как функция была разработана и протестирована, она, вероятно, должна быть на уровне VERBOSE.
Мой самый любимый уровень – WTF (2.2+), который, как предполагается, будет означать «Какая ужасная неудача», для ситуаций, которые никогда не должны происходить.
Обычно я использую «информацию» для простых сообщений.
Инструменты для снятия логов с Android / iOS-устройств. Чтение и разбор
Привет! Сегодня стартует наш четвертый митап для тестировщиков, QAчественное общение. До 18:00 МСК на него все еще можно зарегистрироваться. А пока мы начинаем выкладывать доклады с предыдущего митапа, и начинаем с Ольги, старшего QA-инженера в компании red_mad_robot. Поговорим про мобильные устройства и про снятие логов с этих мобильных устройств, почитаем их и разберем, как вообще с ними работать.
Что вообще такое логи мобильного устройства? Логи – это записи либо сообщения в виде текста. У нас в этом тексте записываются все действия пользователя или как отвечает система на действия пользователя, соответственно, вся та информация, что вы делаете, куда нажимаете на самом устройстве, в приложении – всё это пишется в логи.
Какие логи в принципе бывают? Разделим их на две группы. Первая – это Crash logs, они подразумевают под собой отдельный файл, куда сыпется только информация об экстренном завершении программы. И второй вариант – это просто логи, файл, который является журналом событий, в нём хранятся все системные записи и ответы устройства на действия пользователя.
Уровни логирования
Хочу заметить, что эти уровни логирования больше под Android-логи, потому что именно разделение на Error, Warn, Info, Debug и Verbose в основном вы можете увидеть именно на логах с Android. Плюс, такая же информация чаще всего будет в ваших серверных логах, в принципе, будет довольно полезно изучить их. Что примечательно, каждый уровень включает в себя предыдущий. Если мы возьмем Verbose, фильтрацию по нему, например, то мы будем получать логи со всех предыдущих уровней, то есть абсолютно все логи. Разберем каждый подробно.
Первый – это Error. Ошибки уровня Error – ошибки, которые говорят о работе системы, на них надо очень быстро реагировать и всегда сообщать о них разработчикам.
Например, SpannableStringBuilder – это ошибка приложения, которая говорит нам о том, что текстовое поле, то есть Span, наш элемент, он не может быть нулевым либо пустым. Второй вариант – это системная ошибка ZeroHung. Данная ошибка говорит о том, что у нас происходит утечка памяти, она может быть как от какого-то действия с приложением, так и от самого приложения.
Следующий вариант – Warning. Это тоже ошибки, которые говорят о каком-то неожиданном поведении, которые требуют внимания, но они не такие важные, как error. Например, ошибка из приложения: мы пытаемся декодировать видео в нужное нам качество, в нужный формат, и у нас на этом происходит ошибка. Второй вариант, например, BroadcastQueue. Это ошибка системная, ошибка работы какого-то виджета на вашем устройстве. У меня это был Android Huawei, мне от системы сыпятся такие ошибки.
Следующий уровень – Info. Это уровень логов, на котором нам приходят записи чисто информационного характера о работе системы. Например, в этот уровень будут приходить ваши запросы, которые отправляют приложения на сервер. То есть он будет выглядеть так: http start, здесь вы увидите, какие header’ы отправляются, какое тело отправляется, если оно есть, и так же будете получать ответ от сервера в таком формате: json, key, value, ключ, значение и так далее. Заканчиваться он будет как http end. Далее, системный вариант ошибки или системный вариант лога о том, что сейчас мы намереваемся выключить экран. То есть, эта запись появляется, когда мы просто блокируем экран телефона, и он гаснет. Это у нас падает в информацию.
Далее, уровень Debug. Это тот уровень сообщений, в котором передается информация о процессах отладки или шаги каких-то крупных процессов, то, на что разработчики хотели обратить пристальное внимание. Например, мы просто нажали на качель громкости. Здесь будет, конечно, более подробно внутри этого лога – если вы его поймаете, то увидите конкретно что произошло: мы увеличили звук, уменьшили звук и на какое количество. И второй вариант, например, у вас приложение работает по WebSocket, и вам надо понять, подключились вы вообще или нет. Соответственно, вот это сообщение о том, что коннект произошел (на экране «b$b: WebSocket connected»).
Следующий уровень Verbose. Это уровень самого низкого приоритета, там сыпятся вообще все логи, там будет какая-то дополнительная информация, которая не вошла в Info, например. К примеру, у нас всплывает окно, мы его закрываем, у нас WindowManager, и мы здесь видим, что-либо добавилось, либо все удалилось. Далее, вся информация о геолокации. Например, у нас есть LocationProvider. В более расширенном варианте там будет полностью писаться ваша геолокация вплоть до долготы и широты. И третий пример, тоже связанный со звуком, то есть какой у нас звук и насколько он громкий. То есть, например, volume 10 это у нас максимальный звук, и мы его увеличили до такого варианта (на экране «AudioManager: getStreamVolume streamType: 3 volume: 10»). Очень похож на Info, но, я бы сказала, что более подробная информация на него передается.
Чем снимать логи?
Android
Первый инструмент – это Android Studio, в частности, его утилита Logcat. Что надо для того, чтобы начать снимать логи через Android Studio? Первое, конечно же, необходимо перевести устройство в режим разработчика. В настройках вы ищете номер вашего билда или операционной системы, в зависимости от того, на каком устройстве вы собираетесь смотреть, оно меняется от производителей. Нажимаете около 10 раз на эту информацию, и у вас появляется сообщение «Не желаете ли вы перевести ваше устройство в режим разработчика?». Нажимаете «Ок», и ваш телефон уже не такой обычный. Далее, вам надо подключить это устройство по USB к вашему компьютеру, конечно же, установить на сам компьютер Android Studio, он устанавливается как на Windows, так и на MacOS, тут проблем никаких нет.
Открывая Android Studio, выбираем вкладку Logcat. Под цифрой 1 то, где найти это сокровенное слово. Нажимая на него, переходим в сообщения в реальном времени. Под цифрой 2 окно, где мы выбираем телефон, с которого будем снимать логи. Соответственно, если ничего не подключено либо ваш телефон не виден, здесь вы ничего не сможете выбрать. Под цифрой 3 интересный момент: если вы хотите полностью снимать все логи (системные и со всех приложений, которые у вас сыпятся), не выбирайте здесь ничего. Если вы выберете какое-то конкретное приложение, которое debug’ное, у вас будут показываться логи исключительно по нему. Рядом с цифрой 3 вы видите слово Verbose – это уровень того лога, который вы хотите видеть. То есть, если вы выберете Error, будут только Error’ы. И под цифрой 4 у вас поле поиска. Это то поле, где вы сможете фильтровать выдачу по приложению, по уровню, по какой-то утилите, которая вам нужна, соответственно, это у нас regular выражение, и там все довольно просто ищется по совпадению. Вариант второго скриншота – это я уже выбрала конкретную сборку, и мы видим, что у нас по этой сборке сыпятся логи.
Дальше у вас в терминале, примерно так же, как и в Android Studio, будут в режиме реального времени сыпаться логи. Разберем, как их читать. Под цифрой 1 будет дата и время, когда пришла запись. Под цифрой 2 – маленький столбец, где вы видите буквы V, D, E, I и так далее. Это как раз те самые уровни нашего логирования Debug, Verbose, Warning или Info. В графе 3 – названия – инструменты, утилиты или части ОС, откуда идет сообщение, и, соответственно, его расшифровка – что конкретно у нас происходит. Конечно, выглядит это так, что в Android’е это все намного удобнее и приятнее, легко можно фильтровать. В Terminal’е фильтровать будет уже посложнее, надо будет менять саму команду, добавлять ключи, которые бы фильтровали выдачу по уровню либо по отдельному приложению.
Открываем его, как мы видим, информация похожа на ту, что в Terminal, единственное, как вы прекратили команду, этот файл больше не обновляется до тех пор, пока вы снова не повторите эту команду. Опять же, в таблице 1 мы видим дату и время прихода сообщения, таблица 2 – уровень наших логов, в таблице 3 мы видим, от какой части системы у нас сыпятся данные, лог и его расшифровка.
Конечно же, первое, о чем я хотела бы рассказать, это xCode и встроенный для него симулятор. К сожалению, xCode – программа только для MacOS. Чтобы снять с симулятора логи, нужно установить xCode, зайти в меню, открыть Developer Tools и симулятор. Симулятор – дополнительная программа, которая позволяет воспроизводить работу системы, если у вас нет физического девайса.
В этот симулятор мы устанавливаем нужное нам приложение, выбираем, какой конкретно IPhone, его размеры, разрешение и операционную систему. И уже в симуляторе выбираем пункт «Debug» и «Open System Log». Это выглядит так: я выбираю в самом симуляторе папку Debug и подвкладку Open System Log. Он точно так же идет в режиме реального времени, но они (логи) выведены по-другому, не так, как на Android.
Мы видим, что тут уже нет уровня логирования, есть дата и время. Цифра 2 – сообщение, что мы вообще видим. Мы видим, с какого устройства была снята информация.
В моем случае это имя моего Mac. Видим дополнительную запись, с какого элемента системы это сообщение пришло и его расшифровка. Например, в логах IOS придётся поковыряться чуть поподробнее, чем в Android.
Второй инструмент тоже связан с xCode, но он идет по другой «дорожке». Это Devices and Simulator. Устанавливаем xCode, подключаем устройство по USB, тут уже важно, чтобы было реальное устройство. В самом xCode открываем вкладку Window, там выбираем подвкладку Devices and Simulator. Нажимаем у устройства «Open Console». На панели видим название нашего устройства, какая у него операционная система, модель, и правее этой кнопки нам интересно «Open Console».
Под цифрой 1 мы видим все приложения, которые дополнительно установлены на наши устройства, в колонке под цифрой 2 – версия этого устройства, которую разработчик указывает. Третье пишется URL нашего устройства. То есть, например, у вашего разработчика, у вашей компании, у вашего приложения есть свой URL, по которому он ходит. Соответственно, здесь он отражен.
Как это все выглядит: здесь довольно удобно отслеживать, как сыпятся логи. Они тоже сыпятся в реальном времени, и, если их никак не фильтровать, они будут постоянно падать, но здесь все удобно смотреть. У нас есть время этого сообщения, процесс – это с какой части системы, приложения пришло сообщение. В колонке «Сообщение» мы видим подробное описание того, что происходит, что не так, вся сервисная системная информация. Что интересно, именно в Devices and Simulator есть поиск, который позволяет фильтровать выдачу. То есть, справа сверху мы можем написать название нашего приложения, и у нас все отфильтруется по процессу. Также мы можем приостановить выдачу по кнопке, и тогда логи перестануть хаотично и беспорядочно сыпаться (чтобы удобнее искать то, что вы хотите найти на устройстве).
Как снимать логи с IOS на Windows
Есть приложение iMazing, которое ставится на Windows и MacOS. Подключаете устройство по USB и в меню выбираете «показать консоль устройства». В целом, это приложение платное, однако, снять логи с устройства можно на триальной версии, она никак не ограничивается. У нас открывается следующее окно: мы видим, какое устройство у нас подключено, мы видим аккаунт, и в меню мы видим как раз «показать консоль устройства».
Если мы на нее нажмем, увидим следующее. Первый квадрат – это дата и время, когда мы получили это сообщение, второй пункт – от кого, с какого устройства, так как это уже реальный девайс, он называется у нас «IP-040». Далее, пишется, с какой части системы прилетело сообщение и его описание. Под цифрой 3 мы видим поле поиска. Мы можем фильтровать эту выдачу, можем остановить поток входящих логов по кнопке «пауза» и отфильтровать ее в поле поиска. Это поможет вам сконцентрироваться на конкретном запущенном приложении. Также у iMazing можно эти логи сохранять по соответствующей кнопке.