Debug Android: различия между версиями

Материал из Toshiba AC100 wiki
Перейти к навигации Перейти к поиску
м (udev перечитываем правила)
м (logging perf note)
 
(не показаны 3 промежуточные версии этого же участника)
Строка 10: Строка 10:
Также нужно будет добавить следующую переменную в ''cmdline'' запуска ядра:
Также нужно будет добавить следующую переменную в ''cmdline'' запуска ядра:
<pre>
<pre>
console=tty0
console=tty
</pre>
</pre>
после этих процедур при запуске устройства ядро будет направлять свой вывод
после этих процедур при запуске устройства ядро будет направлять свой вывод
Строка 22: Строка 22:
</pre>
</pre>
которая является в Андроиде частью busybox или toolbox.
которая является в Андроиде частью busybox или toolbox.
===Увеличение детализации сообщений от ядра===
Можно поменять специальной переменной в настройках ядра: <br />
<pre>
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=7
</pre>
по умолчанию оно стоит в значении 4. <br />
Или черех ''cmdline'': <br />
<pre>
loglevel=7
</pre>
Список возможных значений: <br />
<pre>
loglevel= All Kernel Messages with a loglevel smaller than the
console loglevel will be printed to the console. It can
also be changed with klogd or other programs. The
loglevels are defined as follows:
0 (KERN_EMERG) system is unusable
1 (KERN_ALERT) action must be taken immediately
2 (KERN_CRIT) critical conditions
3 (KERN_ERR) error conditions
4 (KERN_WARNING) warning conditions
5 (KERN_NOTICE) normal but significant condition
6 (KERN_INFO) informational
7 (KERN_DEBUG) debug-level messages
</pre>
первоисточник https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt <br />
Также через ''cmdline'' можно форсировать значение переменной '''loglevel''' другой переменной
'''ignore_loglevel''', это удобно для дебага когда надо видеть все сообщения ядра.
Если даже так нет вразумительной информации в каком месте затыкается ядро, такое возможно если в
этом месте нет обработки ошибок, можно добавить в ''cmdline'' переменную: <br />
<pre>
initcall_debug
</pre>
тогда в логах будет видно какие ядро вызывает функции и будет понятно в какой происходит ошибка. <br />
Увеличение логирования влияет на производительность ядра, особенно initcall_debug, в производстве <br />
их лучше не использовать. <br />


==Аналог /var/log/messages==  
==Аналог /var/log/messages==  
Строка 103: Строка 143:
$ dumpsys |less
$ dumpsys |less
</pre>
</pre>
----
----
[[user:zombah|1337638167]]


----
==ddms==  
==ddms==  
Разобрался, наконец, с ним.
Разобрался, наконец, с ним.
Строка 154: Строка 191:
Toshiba  0930
Toshiba  0930
</pre>
</pre>
то тошка сможет подхватываться автоматом без конфигурирования udev, как это делают всякие брендовые самсунги и т.п.
то тошка сможет подхватываться автоматом без конфигурирования udev, как это делают всякие брендовые самсунги и т.п. <br />
[[user:Sash0k]]
[[user:Sash0k]]

Текущая версия от 22:15, 29 октября 2017

Средства и приемы для сбора отладочной информации в системе Андройд

Вывод информации от ядра на экран

По умолчанию система Андроид скрывает вывод ядра, но его можно включить в самом ядре с помощью переменной:

CONFIG_FRAMEBUFFER_CONSOLE=y

в .config файле настройки ядра и пересобрав ядро после этого. Также нужно будет добавить следующую переменную в cmdline запуска ядра:

console=tty

после этих процедур при запуске устройства ядро будет направлять свой вывод на экран.

dmesg

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

dmesg

которая является в Андроиде частью busybox или toolbox.

Увеличение детализации сообщений от ядра

Можно поменять специальной переменной в настройках ядра:

CONFIG_DEFAULT_MESSAGE_LOGLEVEL=7

по умолчанию оно стоит в значении 4.
Или черех cmdline:

loglevel=7

Список возможных значений:

	loglevel=	All Kernel Messages with a loglevel smaller than the
			console loglevel will be printed to the console. It can
			also be changed with klogd or other programs. The
			loglevels are defined as follows:

			0 (KERN_EMERG)		system is unusable
			1 (KERN_ALERT)		action must be taken immediately
			2 (KERN_CRIT)		critical conditions
			3 (KERN_ERR)		error conditions
			4 (KERN_WARNING)	warning conditions
			5 (KERN_NOTICE)		normal but significant condition
			6 (KERN_INFO)		informational
			7 (KERN_DEBUG)		debug-level messages

первоисточник https://www.kernel.org/doc/Documentation/admin-guide/kernel-parameters.txt
Также через cmdline можно форсировать значение переменной loglevel другой переменной ignore_loglevel, это удобно для дебага когда надо видеть все сообщения ядра.

Если даже так нет вразумительной информации в каком месте затыкается ядро, такое возможно если в этом месте нет обработки ошибок, можно добавить в cmdline переменную:

initcall_debug

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

Увеличение логирования влияет на производительность ядра, особенно initcall_debug, в производстве
их лучше не использовать.

Аналог /var/log/messages

Очень часто хочется смотреть на уже загруженной системе вывод ядра в текущем времени, по аналогии с /var/log/messages в линуксе, в андройде это можно сделать через файл /proc/kmsg, например так:

tail -f /proc/kmsg

logcat

Мощнейший иструмент для вывода отладочной информации системы Андроид, служит команда:

logcat

Ее можно вызывать из консоли, в терминальных приложениях и через adb консоль.

Чтобы вывести только ошибки:

logcat *:E

Чтобы увеличить кол-во информации которую показывает logcat нужно задать значение в файле init.rc системы Андроид переменной loglevel с 0 до 8, чем больше значение тем больше информации будет фигурировать в логах.

У logcat есть несколько разных буфферов логирования их список видно при вызове с ключем --help. Буфферы следующие 'main', 'system', 'radio' и 'events' Например вызвав

logcat -b radio

можно посмотреть отладучную информацию радио модуля.

С помощью комманды

logcat -b events

можно увидеть uevent'ы системы, например изменения заряда батареи.

strace

Для вывода более глубокой отладочной информации по запуску определенной службы системы Андроид используется утилита strace которая является часть системы и обычно располагается в папке /system/xbin Добавать в запуск службы вывод strace, можно отредактировав файл init.rc следующим образом:

service surfaceflinger /system/xbin/strace -tt -o/data/surfaceflinger.strace /system/bin/surfaceflinger

после такой операции отладочная информация запуска сервиса surfaceflinger будет помещаться в файл surfaceflinger.strace в корне папки /data/

или

service surfaceflinger /system/xbin/strace -ttf -o/data/surfaceflinger.strace /system/bin/surfaceflinger

если сервис будет создавать fork процессы

debugfs

Некоторые системы ядра позволяют получить дополнительную информацию о своей работе через виртуальную файловую систему debugfs, по умолчанию она не монтируется как файловые системы sysfs или procfs, подмонтировать debugfs можно следующим образом из консоли или терминала системы Андроид:

mkdir /data/debugfs
mount -t debugfs debugfs /data/debugfs

после этого в папке /data/debugfs появятся каталоги и файлы по структуре похожие на procfs

dumpsys

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

$ dumpsys window

Список доступных для dumpsys сервисов, можно увидеть на первом экране если запустить dumpsys без ключей

$ dumpsys |less

ddms

Разобрался, наконец, с ним. Инфа актуальна для разработки андроид-приложений, при использовании тошибы с андроидом в качестве устройства для тестирования. Но так же можно снимать logcat с андроида непосредственно на бб.

При использовании для разработки компа с линуксом, тошиба определяется как неизвестное устройство (unknown device)

$ ./android-sdk-linux/platform-tools/adb devices

List of devices attached
0000000000000000 unknown

Соответственно, тошибу нельзя выбрать как цель для запуска приложения. Для решения проблемы необходимо добавить правило в udev на ведущем компе (не на тошибе)

Для этого:

  • Создаём файл:
/etc/udev/rules.d/51-android.rules
  • Заполняем его:
SUBSYSTEM=="usb", ATTR{idVendor}=="18d1", MODE="0666", GROUP="plugdev"
  • Выставляем права:
 chmod a+r /etc/udev/rules.d/51-android.rules
  • Перечитываем правила udev
$ sudo udevadm control --reload-rules
  • Не забыть включить режим Отладка Android в настройках тошибы;

После этого тошиба начнёт определяться в DDMS, можно отлаживать приложения под андроид и logcat можно смотреть непосредственно в Eclipse, например;

ATTR{idVendor}=="18d1" - это VID тошибы с цианогеном, значение соответствует производителю "Google"; Чтобы просмотреть VID, при подключенной тошибе можно выполнить $lsusb на ведущем компе;

Эта же инфа на английском

По ссылке также находится таблица VID-ов, соответсвующая производителям. 2 zombah: подозреваю, что если сконфигурировать нужный VID

Toshiba  0930

то тошка сможет подхватываться автоматом без конфигурирования udev, как это делают всякие брендовые самсунги и т.п.
user:Sash0k