CatchLog Xiaomi — что это за программа и нужна ли она? (com.bsp.catchlog)
Приветствую. Операционка Андроид содержит много компонентов, функций, системных программ. Некоторые отключать нельзя — иначе могут быть серьезные последствия (например bootloop). Другие — вполне можно, так как носят служебный характер, не влияют на стабильность работы.
CatchLog Xiaomi — что это такое?
Приложение, позволяющее узнать износ батареи, а также другую служебную информацию. Удалять не рекомендуется. Можно заморозить.
На форуме 4PDA пишут — отвечает за вызов меню *#*#6485#*#*.
Полное название — Charging and Battery Information, переводится как информация о зарядке и аккумуляторе.
Присутствует в стоковой прошивке Андроид, вывод — системное приложение.
Один пользователь заморозил — проблем не замечено. Морозить лучше используя Titanium Backup (нужны root-права).
Если запустить активити приложения, то там тесты/датчики какие-то, возможно связанные с батареей. Но явно не логи, как может показаться по названию.
Оказывается CatchLog в кастомных прошивках вырезают — видимо не особо важно.
Морозить можно, но CatchLog позволит узнать износ батареи — набираем комбинацию *#*#6485#*#* и смотрим пункты MF_05 и MF_06:
Проверять износ лучше когда телефон только снят был с зарядки. Проверена работа на MiUi 11.0.4.0 (Android 10), на 11.0.5.0 (Android 9) — не работает.
Logcat
Рассмотрим на примере. Очень часто программисту нужно вывести куда-то промежуточные результаты, чтобы понять, почему программа не работает. Особо хитрые временно размещают на экране текстовую метку и выводят туда сообщение при помощи метода textView.setText(«Здесь был Васька»). Но есть способ лучше. В Android есть специальный класс android.util.Log для подобных случаев.
Класс android.util.Log позволяет разбивать сообщения по категориям в зависимости от важности. Для разбивки по категориям используются специальные методы, которые легко запомнить по первым буквам, указывающие на категорию:
В первом параметре метода используется строка, называемая тегом. Обычно принято объявлять глобальную статическую строковую переменную TAG в начале кода:
Некоторые в сложных проектах используют следующий вариант, чтобы понимать, в каком классе происходит вызов:
Далее уже в любом месте вашей программы вы вызываете нужный метод журналирования с этим тегом:
Также используется в исключениях:
Пользователи не видят этот журнал. Но, вы, как разработчик, можете увидеть его через программу LogCat, доступный в Android Studio.
Полный вид сообщения выглядит следующим образом.
03-09 20:44:14.460 3851-3879 / ru.alexanderklimov.cat I/OpenGLRenderer : Initialized EGL, version 1.4
Подобные длинные сообщения не всегда удобны для чтения. Вы можете убрать ненужные элементы. Для этого выберите значок LogCat Header в виде шестерёнки и уберите флажки у опций.
В LogCat вы можете отфильтровать сообщение по заданному типу, чтобы видеть на экране только свои сообщения. Для этого выберите нужный тип тега из выпадающего списка Verbose.
Типы сообщений можно раскрасить разными цветами через настройки File | Settings | Editor | Colors Scheme | Android Logcat.
Для отслеживания сообщений с заданным текстом введите в поле поиска нужную строку и нажмите Enter.
Также активно используйте варианты из других выпадающих списков. Например, выбирайте свой пакет из второй колонки, а в последней выбирайте Show only selected application. Для более точной настройки используйте Edit Fiter Configuration.
По умолчанию, окно LogCat выводится в нижней части студии. При желании, можно выбрать другие варианты через значок настроек окна.
LogCat также можно запустить из командной строки:
Параметры командной строки смотрите в документации.
Быстрое отключение журналирования
Теперь остаётся только присвоить нужное значение переменной isDebug перед созданием готового apk-файла для распространения.
Способ устарел. В 17-й версии Android Build Tools появился класс BuildConfig, содержащий статическое поле DEBUG. Можно проверить следующим образом:
В этом случае конфигурация releaseWithLog будет являться релизной сборкой с ведением логов. Естественно, в коде слегка поменяется проверка:
LogCat на устройстве
Попался в сети пример для просмотра сообщений LogCat на устройстве. С примером не разбирался, оставлю здесь на память.
[MIUI Питання та відповіді] catch log что за приложение
Xiaomi Comm APP
Stay updated on Mi Products and MIUI
Featured
* Recommended to upload a 720*312 image as the cover image
* Changes are irreversible after submitting
Cookies Preference Center
We use cookies on this website. To learn in detail about how we use cookies, please read our full Cookies Notice. To reject all non-essential cookies simply click «Save and Close» below. To accept or reject cookies by category please simply click on the tabs to the left. You can revisit and change your settings at any time. read more
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services such as setting your privacy preferences, logging in or filling in formsYou can set your browser to block or alert you about these cookies, but some parts of thesite will not then work. These cookies do not store any personally identifiable information.
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services such as setting your privacy preferences, logging in or filling in formsYou can set your browser to block or alert you about these cookies, but some parts of thesite will not then work. These cookies do not store any personally identifiable information.
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services such as setting your privacy preferences, logging in or filling in formsYou can set your browser to block or alert you about these cookies, but some parts of thesite will not then work. These cookies do not store any personally identifiable information.
Android: логгирование и отправка результатов на почту
Хочу начать небольшой разговор о том, как можно получать данные о работе приложения и некоторых его компонентов от пользователей.
Одно дело — разработка, LogCat в Android Studio (если вы из любителей пожестче — можно распечатку в консоли смотреть с помощью adb), и совсем другое — ломать голову над вопросом почему у вас все работает на всем парке тестовых устройств, а пользователь жалуется на абсолютно обратную ситуацию. Коммуникация между разработчиком и конечным пользователем — это хорошо, но совсем другое — видеть своими глазами картинку происходящего (помните, как в матрице — для кого-то это зеленые иероглифы, а для кого-то — женщина в красном?)
Предлагаю разбить задачу на несколько частей, а именно — сбор и хранение логов, способ их передачи из одного приложения в другие с помощью FileProvider, ну и небольшой helper класс для создания писем с аттачами. Итак, поехали.
Сбор и хранение логов.
Кто-то использует System.out.println, кто-то — статические методы класса Log. Я с некоторых пор пришел к написанию своего класса для распечатки логов. Давайте вкратце расскажу почему.
Во-первых, это проще. Как правило, для отслеживания изменений в процессе выполнения приложения я использую одну и ту же метку. И вот однажды я подумал — зачем ты пишешь постоянно Log.i(MY_TAG, «info») если можно сократить немного и убрать из этой формулы одну постоянную?
Во-вторых, расширение логгирования. Это конкретно упирается в нашу задачу — хранение логов в файлах. Можно написать отдельный класс, в который будем передавать какие-то данные, как то: данные и имя файла, но данные мы уже передаем в метод Log.i / Log.e / проч., создавать лишний раз переменную что ли для этого? Некрасиво все это как-то.
Ладно, довольно лирики, давайте лучше взглянем на класс Diagnostics.
Для того, чтобы вывести информацию в LogCat с дефолтной меткой, достаточно написать следующее:
Иногда мне хочется видеть какие методы вызываются и в каких объектах. И с какими параметрами или значениями переменных. В общем, тут важно для меня — где именно производится вызов. Тогда я использую следующую конструкцию
Diagnostics.i(this, “onCreate w/param1 = “ + param1);
где this — это экземпляр класса Caller. Например, для MainActivity вы увидите следующее:
03–29 12:31:53.203 16072–16072/com.isidroid.platform I/Diagnostics: MainActivity.onCreate w/param1 = 200
И все сразу становится понятно — кто вызывает и где вызывает.
А теперь о хранении этой информации.
Как вы уже могли видеть, в классе Diagnostics есть методы для работы с файлами — createLog и appendLog. Объяснять, я думаю, не стоит — первый создает файл, второй — добавляет в него строку. Для новичков или тех, кто ленится читать код, уточню — appendLog создает файл, если его не существует, а createLog всегда создает новый. Чтобы лишней информации там не хранилось.
Файлы хранятся в cache директории, которая, к слову, недоступна для других приложений (ну, если у вас телефон не рутован, конечно).
В общем, теперь процедура распечатки лога и хранения его в файле выглядит следующим образом.
Надеюсь, это выглядит просто в использовании.
Передача файлов в другие приложения
Как я уже говорил выше, наши файлы для лога хранятся в некоторой защищенной от чужих глаз папке. Она настолько защищена, что если вы попробуете передать файлы в другое приложение с использованием относительного пути File.getAbsolutePath(), то вы потерпите неудачу.
На помощь к нам мчится FileProvider, друзья!
Вообще, в документации есть отличная статья (она же — пошаговая инструкция) на эту тему — Setting Up File Sharing, но для тех, кто предпочитает читать StackOverFlow и isidroid.com, я приведу выжимку из статьи с кодом реализации.
2. Указываем директории, доступные для шаринга. Для этого создаем файл res/xml/cache_file_paths и для нашего конкретного примера заполняем его.
Конец.
Нет, правда, это все.
На самом деле это довольно мощный инструмент для работы с файлами в вашем приложении, но в рамках поставленной задачи это все, что нам нужно сделать. Подробности — в официальной документации.
Отправка писем с логами.
Мы с вами почти добрались до конца, осталось дело за малым. Вообще, создание намерения (intent) для отправки писем — это довольно тривиальная задача, чтобы под нее писать отдельный хелпер. Но с другой стороны, если можно причесать код в вашей Activity / Fragment, то почему бы и нет, верно?
Гораздо симпатичнее будет выглядеть какой-нибудь строитель (builder) в коде нежели условия, проверки и лишние циклы. Я за то, чтоб это выносить в отдельный класс (кстати, не только я ратую за разделение представления от бизнес-логики).
Давайте перейдем сразу к сути. Сначала я покажу класс (который вы можете скопировать и использовать не глядя, конечно), а потом пример его использования. Поехали!
Где this — это Activity.
Вы можете самостоятельно указать «рыбу» для текста письма, но я рекомендую использовать те данные, которые указаны в методе buildContent, расширяя их при необходимости. Можно конечно извернуться и применить паттерн «декоратор» для расширения этих данных без модификации класса FeedbackHelper, но лично для меня необходимости в этом не было… Что до вас, то дерзайте!
Расставляем сообщения Android Logcat на шкале времени VTune Amplifier
Известная пословица гласит: «Один ум хорошо, а два лучше». Она справедлива не только для житейских ситуаций, но и в делах отладки приложений. Объединяя «умы» различных программных средств, можно получить не только количественные, но и качественные преимущества. Например, союз Android Logcat и VTune Amplifier – это как раз такой случай.
Android Logcat – это мощный отладочный инструмент. С его помощью можно получить массу полезной информации о системе или о приложениях с привязкой к временным меткам. Android предоставляет разработчикам стандартные API для логирования данных. Этими API удобно пользоваться при разработке и отладке приложений: достаточно добавить вызовы соответствующих команд в нужные места программного кода. Команды выводят сообщения в Logcat, где их можно просмотреть.
VTune Amplifier для специализированных систем – это программный комплекс для профилирования. С его помощью можно анализировать и оптимизировать производительность операционных систем и приложений. VTune Amplifier имеет весьма полезное средство – панель шкалы времени. Оно позволяет разработчику просматривать сведения о производительности, привязанные ко времени.
Как сопоставить сообщения из Logcat с временной шкалой VTune Amplifier? Это даст разработчикам возможность видеть сообщения из Logcat совместно со сведениями о производительности из временной шкалы VTune Amplifier. Как результат – можно будет узнать, что именно произошло в конкретное время и тут же понять, какую нагрузку на систему оказало то или иное событие, как оно повлияло на производительность.
Intel VTune Amplifier способен обрабатывать и интегрировать в собственные наборы данных, полученные с помощью его встроенных инструментов, дополнительные сведения о производительности. Они могут быть получены с помощью внешних сборщиков данных или средствами тестируемого приложения. Для того чтобы добавить в VTune Amplifier внешние данные, нужен CSV-файл, обладающий определенной структурой, в котором находятся собранные сведения. Этот файл, для дальнейшей работы с ним, надо загрузить в VTune Amplifier.
Подробности о создании собственных CSV-файлов с данными можно найти в руководстве пользователя VTune Amplifier. В частности, в разделе VTune Amplifier > User’s Guide > External Data Import есть сведения о том, как создавать такие файлы. Имеются там и примеры их внутренней структуры. Для того чтобы сообщения из Logcat оказались на временной шкале VTune, нужно, следуя руководству, преобразовать их в CSV-файл и загрузить полученный файл в VTune Amplifier.
Пример
Рассмотрим пример. Имеется приложение «com.example.Thread1». В нём есть функция, в которой выполняются тяжёлые вычисления. Вот как она, в общих чертах, выглядит:
Обратите внимание на то, что перед профилированием Android-приложения с помощью VTune Amplifier, приложение нужно подготовить. А именно, в его файле AndroidManifest.xml, в разделе , должна быть включена возможность отладки:
Установить debug-версию приложения на Android-устройство можно, например, с помощью стандартных средств Android Studio. А после установки приложения Android Studio нужно будет закрыть, иначе VTune Amplifier не сможет собрать данные. Для того чтобы совместить сбор Logcat-сообщений и профилирование в VTune Amplifier, Logcat понадобится запустить из командной строки. Универсальное средство, подходящее и тем, кто работает в Windows, и тем – кто пользуется Linux – это оболочка bash.
В Linux-системах bash присутствует по умолчанию. А вот если ваша хост-система – Windows, вам потребуется дополнительное ПО. Мы рекомендуем Cygwin. Это приложение позволяет пользоваться bash-окружением в Windows. Подробности о работе с Logcat из командной строки можно узнать здесь.
Мы перенаправляем вывод от Logcat в файл log.txt, который будет помещен в текущей директории.
Начинать сбор Logcat-данных нужно до запуска профилирования в VTune Amplifier, а останавливать (Ctrl + C в командной строке) – после.
Вернемся к нашему примеру. Судя по временной шкале VTune Amplifier, которая показана ниже, функция была выполнена 6 раз. ID главного потока приложения – 12271. Коричневые столбцы – это сведения о производительности (процессорное время), которые были собраны в ходе профилирования с помощью VTune Amplifier.
Просмотр результатов анализа приложения на шкале времени VTune Amplifier
Получив эти данные, мы можем конвертировать их в CSV-файл подходящего формата, который подходит для загрузки в VTune Amplifier. В соответствии с документацией к VTune Amplifier, нужный нам CSV-файл может выглядеть так:
Здесь, в качестве столбца данных «name», используется тег, который применялся при логировании, и строка сообщения. Время сообщения попадает в столбцы start_tsc.UTC и end_tsc. ID процесса и ID потока представлены в CSV-файле, соответственно, как pid и tid. Поля разделены запятыми.
Теперь нужно перейти в VTune Amplifier и выполнить команду Analysis Type > Import from CSV, выбрав для импорта только что созданный файл с данными. Приложение загрузит данные и отобразит сообщения из Logcat на временной шкале со сведениями о производительности. На рисунке ниже показано, как перемещение мыши к маленькому жёлтому треугольнику, который указывает на точку расположения сообщения, выводит всплывающее окно с данными из Logcat, которые были сгенерированы нашим приложением.
Просмотр сообщений из Logcat на шкале времени VTune Amplifier
Вот несколько советов, которые касаются создания CSV-файлов.
Вспомогательный скрипт
Мы создали экспериментальный bash-скрипт (logcat2vtune.sh), который позволяет упростить вышеописанные действия. Вы можете воспользоваться им для того, чтобы автоматизировать сбор Logcat-данных и создание CSV-файла. Скрипт может собирать сообщения, которые выводят в Logcat приложения, а так же – сообщения от ядра системы. Кроме того, он считывает сведения о целевой системе, разбирает результаты логирования и автоматически генерирует CSV-файлы.
Для того чтобы воспользоваться этим скриптом, вам понадобится bash-окружение. Как было сказано выше, в Linux-системах это стандартная рабочая среда, а в Windows можно воспользоваться, например, Cygwin.
Для того чтобы получить CSV-файл с данными в ходе профилирования с помощью VTune Amplifier, нужно сделать следующее:
Эта команда позволяет собрать данные Logcat, отобрать сообщения со строкой «MYTEST» и сгенерировать CSV-файл. Данные Logcat скрипт собирает с помощью следующей команды:
«MYTEST» – это строка, по которой осуществляется фильтрация сообщений из Logcat. Мы настоятельно рекомендуем пользоваться фильтрами, так как Logcat может выводить весьма длинные списки сообщений, в то время как разработчиков обычно интересуют лишь сообщения от их процесса. В качестве фильтра можно использовать имя тега Logcat-сообщений, ID процесса, ID потока или любую другую строку. Здесь можно использовать запятые, можно указывать несколько строк. Сообщения, в которых найдено совпадение с любой строкой, указанной при запуске скрипта с ключом «-g», будут отобраны и организованы в виде CSV-файла.
С помощью такой команды можно собрать сообщения от «dmesg», отфильтровать их по строке «MYDRIVER» и создать CSV-файл.
Эта команда позволяет собрать и обычные сообщения из Logcat, и сообщения от ядра, отфильтровать их по строкам «MYTEST» или «MYDRIVER» и создать CSV-файл. В результате на временной шкале VTune Amplifier можно будет просмотреть сообщения от обычных приложений пользовательского уровня и сообщения ядра от «dmesg». Эти данные скрипт собирает с помощью следующей команды:
В данном случае на шкале времени можно будет видеть сообщения от vmlinux с TID 0 и логи пользовательского уровня из Logcat с TID 1922.
Просмотр Logcat-сообщений, полученных из различных потоков, на шкале времени VTune Amplifier
Для того чтобы узнать подробности о работе со скриптом, воспользуйтесь следующей командой: «logcat2vtune.sh –h».
При желании, вы можете настроить скрипт под собственные нужды. Пожалуйста, учитывайте, что «logcat2vtune.sh» – это экспериментальный проект, он не прошёл всеобъемлющего тестирования. Если при работе с ним обнаружатся какие-либо проблемы – вы можете сообщить нам об этом.
Выводы
То, о чём мы здесь рассказали, применимо к продуктам Intel System Studio 2015 и Intel System Studio 2016. В материале освещена работа с хост-системами Windows (IA-32, Intel 64) и Linux (IA32, Intel 64). В качестве целевой системы рассмотрена ОС Android.
Воспользовавшись инструментами и приёмами работы, описанными выше, вы можете вывести профилирование и отладку Android-приложений на более высокий уровень, совместив информацию из Android Logcat с данными о производительности из VTune Amplifier. Надеемся, это поможет вашим приложениям покорить новые вершины производительности и экономичности.
