Android Logging System
Android Logging System
http://elinux.org/Android_Logging_System
This article describes the Android logging system
Contents[hide]
|
Overview
The Android system has a logging facility that allows systemwide logging of information, from applications and system components. This is separate from the Linux kernel's own logging system, which is accessed using 'dmesg' or '/proc/kmsg'. However, the logging system does store messages in kernel buffers.
image by Tetsuyuki Kobabayshi, of Kyoto Microcomputer Co. The logging system consists of:
- a kernel driver and kernel buffers for storing log messages
- C, C++ and Java classes for making log entries and for accessing the log messages
- a standalone program for viewing log messages (logcat)
- ability to view and filter the log messages from the host machine (via eclipse or ddms)
There are four different log buffers in the Linux kernel, which provide logging for different parts of the system. Access to the different buffers is via device nodes in the file system, in /dev/log.
The four log buffers are:
- main - the main application log
- events - for system event information
- radio - for radio and phone-related informatio
- system - a log for low-level system messages and debugging
Up until 2010, only the first three logs existed. The system log was created to keep system messages in a separate buffer (outside of '/dev/log/main') so that a single verbose application couldn't overrun system messages and cause them to be lost.
Each message in the log consists of a tag indicating the part of the system or application that the message came from, a timestamp, the message log level (or priority of the event represented by the message) and the log message itself.
All of the log buffers except for 'event' use free-form text messages. The 'event' buffer is a 'binary' buffer, where the event messages (and event parameters) are stored in binary form. This form is more compact, but requires extra processing when the event is read from the buffer, as well as a message lookup database, to decode the event strings.
The logging system automatically routes messages with specific tags into the radio buffer. Other messages are placed into their respective buffers when the the log class or library for that buffer is used.
Kernel driver
The kernel driver for logging is called the 'logger'. See Android logger
System and Application logging
Application log
An Android application includes the android.util.Log class, and uses methods of this class to write messages of different priority into the log.
Java classes declare their tag statically as a string, which they pass to the log method. The log method used indicates the message "severity" (or log level). Messages can be filtered by tag or priority when the logs are processed by retrieval tools (logcat).
Event log
Event logs messages are created using android.util.EventLog class, which create binary-formatted log messages. Log entries consist of binary tag codes, followed by binary parameters. The message tag codes are stored on the system at: /system/etc/event-log-tags. Each message has the string for the log message, as well as codes indicating the values associated with (stored with) that entry.
System log
Many classes in the Android framework utilize the system log to keep their messages separate from (possibly noisy) application log messages. These programs use the android.util.Slog class, with its associated messages.
In all cases, eventually a formatted message is delivered through the C/C++ library down to the kernel driver, which stores the message in the appropriate buffer.
'log' command line tool
There is a 'log' command line tool that can be used to create log entries from any program. This is built into the 'toolbox' multi-function program.
The usage for this is:
USAGE: log [-p priorityChar] [-t tag] message priorityChar should be one of: v,d,i,w,e
Capturing stdout with logwrapper
It is sometimes useful to capture stdout from native applications into the log. There is a utility called 'logwrapper' which can be used to run a program, and redirect it's stdout into log messages.
The logwrapper usage is:
Usage: logwrapper [-x] BINARY [ARGS ...]Forks and executes BINARY ARGS, redirecting stdout and stderr tothe Android logging system. Tag is set to BINARY, priority isalways LOG_INFO.-x: Causes logwrapper to SIGSEGV when BINARY terminates fault address is set to the status of wait()
Source for logwrapper is at: system/core/logwrapper/logwrapper.c
Logcat command
You can use the 'logcat' command to read the log. This command is located in /system/bin in the local filesystem, or you can access the functionality using the 'adb logcat' command.
Documentation on the use of this command is at: http://developer.android.com/guide/developing/tools/adb.html
Some quick notes:
- Log messages each have a tag and priority.
- You can filter the messages by tag and log level, with a different level per tag.
- You can specify (using a system property) that various programs emit their stdout or stderr to the log.
Trick to couple Android logging to Linux kernel logging
Note that the android logging system is completely separate from the Linux kernel log system (which uses printk inside the kernel to save messages and dmesg to extract them). You can write to the kernel log from user space by writing to /dev/kmsg.
I've seen a reference to couple the two together, to redirect android messages into the kernel log buffer, using the 'logcat' program launched from init, like below:
service logcat /system/bin/logcat -f /dev/kmsg oneshot
(See http://groups.google.com/group/android-kernel/browse_thread/thread/87d929863ce7c29e/f8b0da9ed6376b2f?pli=1)
I'm not sure why you'd want to do this (maybe to put all messages into a single stream? With the same timestamp, if kernel message timestamping is on?)
Resources
- Android Debug Bridge reference page - has 'adb logcat' usage information
- Logging System Of Android Presentation by Tetsuyuki Kobayashi, September, 2010 at CELF's Japan Technical Jamboree 34
How to debug with Android Logging
http://log4think.com/debug-android-logging/
AP Logger Architecture
The above image shows the architecture of Android logging system.It provides a java class for logging named android.util.Log. It also provides log macros for native C applications in liblog.
There are four log devices in the kernel.Three for user space log: /dev/log/main, /dev/log/radio, /dev/log/events. One for kernel space log: /dev/log/kernel.
For user space applications, those binary log messages will be written to /dev/log/events. Those log messages with tht tag "HTC_RIL" "RILJ" "RILC" "RILD" "RIL" "AT" "GSM" "STK" will be written to /dev/log/radio. Other log messages will be written to /dev/log/main.
The log devices named /dev/log/kernel is for kernel log message collection. A console is registerred in /dev/log/kernel and collect all the printk output to the device.It will output kernel log messages with the same log format as other log devices.
Logcat is a tool provided by Android.It could read log messages from log devices and output to the console or to a file.You can find the detail usage later.
an aplog daemon is added for offling log.A filter is added to do some security checking.
Logging interface For Java applications
Logging class Introduction
Class Name: android.util.Log
General method:
Log.v() Log.d() Log.i() Log.w()
The order in terms of verbosity, from least to most is ERROR, WARN, INFO, DEBUG, VERBOSE. Verbose should never be compiled into an application except during development. Debug logs are compiled in but stripped at runtime. Error, warning and info logs are always kept. Tip: A good convention is to declare a TAG constant in your class:
private static final String TAG = "TAG_MyActivity";
and use that in subsequent calls to the log methods.
When you're building the string to pass into Log.d, Java uses a StringBuilder? and at least three allocations occur: the StringBuilder? itself, the buffer, and the String object. Realistically, there is also another buffer allocation and copy, and even more pressure on the gc. That means that if your log message is filtered out, you might be doing significant work and incurring significant overhead.
For more details, please visit http://developer.android.com/reference/android/util/Log.html Android log reference
Program Example
package com.android.hello;import android.app.Activity;import android.os.Bundle;import android.widget.TextView;import android.util.Log; /*import log class*/private static final String TAG = "MOT_MyActivity"; /* define log tag*/public class !HelloAndroid extends Activity { /** Called when the activity is first created. */ @Override public void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); /* setContentView(R.layout.main); */ Log.i(TAG, "this is a log.i message"); Log.v(TAG, "test is a log.v message"); Log.d(TAG, "test is a log.d message"); Log.w(TAG, "test is a log.w message"); Log.e(TAG, "test is a log.e message"); !TextView tv = new !TextView(this); tv.setText("Hello, Android"); setContentView(tv); }} Logging interface For Native applications
Header File
#include <cutils/log.h>Logging Macros
Common Logging Macros
LOGV LOGD LOGI LOGW LOGE
The order in terms of verbosity, from least to most is ERROR, WARN, INFO, DEBUG, VERBOSE. Verbose should never be compiled into an application except during development. Debug logs are compiled in but stripped at runtime. Error, warning and info logs are always kept.
Condition Logging Macros
LOGV_IF LOGD_IF LOGI_IF LOGW_IF LOGE_IF
The order in terms of verbosity, from least to most is ERROR, WARN, INFO, DEBUG, VERBOSE. Verbose should never be compiled into an application except during development. Debug logs are compiled in but stripped at runtime. Error, warning and info logs are always kept. The definition is as below:
#define LOGV_IF(cond, ...) ( (CONDITION(cond)) ?((void)LOG(LOG_VERBOSE, LOG_TAG, VA_ARGS)) : (void)0 )
Logging Macros overview
API for sending log output.
Note:
1: You should define LOG_TAG in your C source code firstly.
2: To build out C/C++ applications outside android, you should add "LOCAL_SHARED_LIBRARIES := liblog libcutils" in your Android.mk file
Program Example
#include#include /* log header file*/#include/* define log tag */#ifdef LOG_TAG#undef LOG_TAG#define LOG_TAG "app"#endifint main(){ LOGV( "Verbose: _app"); LOGD( "Debug: _app"); LOGI( "Info: _app"); LOGW( "Warn: _app"); LOGE( "Error: _app"); printf("Hello Android.n"); return 0;} Log command on Android
Command location
/system/bin/logCommand usage
log [-p priorityChar] [-t tag] messagepriorityChar should be one of : v,d,i,w,e
Log format on Android
The format of a log messages is
tv_sec tv_nsec priority pid tid tag messageLen Message
tag log tag
tv_sec&tv_nsec the timestamp of the log messages
pid the process id of where log messages come from
tid the thread id
Priority value is one of the following character values, ordered from lowest to highest priority
:
* V — Verbose (lowest priority)*
* D — Debug*
* I — Info*
* W — Warning*
* E — Error*
* F — Fatal*
* S — Silent (highest priority, on which nothing is ever printed)*
Android 软件测试日志文件抓取
1 log文件分类简介
实时打印的主要有：logcat main，logcat radio，logcat events，tcpdump，还有高通平台的还会有QXDM日志
状态信息的有：adb shell cat /proc/kmsg ，adb shell dmesg，adb shell dumpstate，adb shell dumpsys，adb bugreport，工程模式等
2 LOG抓取详解
l 实时打印
adb logcat -b main -v time>app.log 打印应用程序的log
adb logcat -b radio -v time> radio.log 打印射频相关的log，SIM STK也会在里面，modem相关的ATcommand等，当然跟QXDM差的很远了。
adb logcat -b events -v time 打印系统事件的日志，比如触屏事件。。。
tcpdump 是很有用的，对于TCP/IP协议相关的都可以使用这个来抓，adb shell tcpdump -s 10000 -w /sdcard/capture.pcap，比如抓mms下载的时候的UA profile，browser上网的时候，使用proxy的APN下载，streaming的相关内容包括UA profile等。
最后是高通平台的QXDM，不管是不是Android，只要使用高通芯片，都会对它很熟悉，当然了，不是高通的芯片就不用提它了。这个不多讲，内容丰富，射频，电话，上网，...凡是高通提供的解决方案，这个都可以抓。(QXDM 的LOG抓取方法请参考QPST、QXDM的基本使用说明及作用)
l 状态信息
o bugreport（命令adb bugreport>bugreport.log)。里面包含有dmesg，dumpstate和dumpsys。
o dumpstate是系统状态信息，里面比较全，包括手机当前的内存信息、cpu信息、logcat缓存，kernel缓存等等。
o adb shell dumpsys这个是关于系统service的内容都在这个里面，这个命令还有更详尽的用法，比如adb shell dumpsys meminfo system是查看system这个process的内存信息。
o kmsg抓取
adb shell cat /proc/kmsg > kmsg.txt
说明：用于检索用printk生成的内核消息。任何时刻只能有一个具有超级用户权限的进程可以读取这个文件。也可以用系统调用syslog检索这些消息。通常使用工具dmesg或守护进程klogd检索这些消息。proc是一个内存文件系统, 每次读文件kmsg实际是内核内部的循环缓冲区,每读过后,循环缓冲区的东西就被认为已经处理过了(也就是变成无效内容),所以你再次读为空是很正常的 为什么会这样处理呢,循环缓冲区大小有限,内核又随时可能往里面写东西,所以这样处理很正常. 你去查一下/proc/kmsg的信息有没有跟系统日志关联,如果有的话,你就可以读日志文件
o dmsg抓取
adb shell dmesg > dmesg.txt
说明：dmesg用来显示开机信息，kernel会将开机信息存储在ring buffer中。您若是开机时来不及查看信息，可利用dmesg来查看。dmesg是kernel的log，凡是跟kernel相关的，比如driver出了问题（相机，蓝牙，usb，启动，等等）开机信息亦保存在/var/log目录中，名称为dmesg的文件里。more /var/log/dmesg
o 工程模式下log的抓取
对于Apollo手机请拨打*#*#8888#*#* ,然后勾选相应的LOG。待测试结束后，通过SD卡导出LOG到PC.
3.Log分析：
Get Log from Android System
adb bugreport > bugreport.txt
copy bugreport to the current directory.
bugreport里面包含了各种log信息,大部分log也可以通过直接运行相关的程序来直接获得.
步骤如下:
1.adb shell
2.进入相关工具程式的目录
3.执行相关程式
4.得到相关信息
下面以输出进程信息为例
1.adb shell
2.输入ps -P
3.可以看到相关进程信息
Log Archive Analysis
1.bugreport
bugreport记录android启动过程的log,以及启动后的系统状态,包括进程列表，内存信息，VM信息等等到.
2.bugreport结构分析
(1)dumpstate
MEMORY INFO
获取该log:读取文件/proc/meminfo
系统内存使用状态
CPU INFO
获取该log:执行/system/bin/top -n 1 -d 1 -m 30 -t
系统CPU使用状态
PROCRANK
获取该log:执行/system/bin/procrank
执行/system/xbin/procrank后输出的结果,查看一些内存使用状态
VIRTUAL MEMORY STATS
获取该log:读取文件/proc/vmstat
虚拟内存分配情况
vmalloc申请的内存则位于vmalloc_start～vmalloc_end之间，与物理地址没有简单的转换关系，虽然在逻辑上它们也是连续的，但是在物理上它们不要求连续。
VMALLOC INFO
获取该log:读取文件/proc/vmallocinfo
虚拟内存分配情况
SLAB INFO
获取该log:读取文件/proc/slabinfo
SLAB是一种内存分配器.这里输出该分配器的一些信息
ZONEINFO
获取该log:读取文件/proc/zoneinfo
zone info
SYSTEM LOG(需要着重分析)
获取该log:执行/system/bin/logcat -v time -d *:v
会输出在程序中输出的Log,用于分析系统的当前状态
VM TRACES
获取该log:读取文件/data/anr/traces.txt
因为每个程序都是在各自的VM中运行的,这个Log是现实各自VM的一些traces
EVENT LOG TAGS
获取该log:读取文件/etc/event-log-tags
EVENT LOG
获取该log:执行/system/bin/logcat -b events -v time -d *:v
输出一些Event的log
RADIO LOG
获取该log:执行/system/bin/logcat -b radio -v time -d *:v
显示一些无线设备的链接状态,如GSM，PHONE,STK(Satellite Tool Kit)…
NETWORK STATE
获取该log:执行/system/bin/netcfg (得到网络链接状态)
获取该log:读取文件/proc/net/route (得到路由状态)
显示网络链接和路由
SYSTEM PROPERTIES
获取该log:参考代码实现
显示一些系统属性,如Version,Services,network…
KERNEL LOG
获取该log:执行/system/bin/dmesg
显示Android内核输出的Log
KERNEL WAKELOCKS
获取该log:读取文件/proc/wakelocks
内核对一些程式和服务唤醒和休眠的一些记录
KERNEL CPUFREQ
(Linux kernel CPUfreq subsystem) Clock scaling allows you to change the clock speed of the CPUs on the fly.
This is a nice method to save battery power, because the lower the clock speed is, the less power the CPU consumes.
PROCESSES
获取该log:执行ps -P
显示当前进程
PROCESSES AND THREADS
获取该log:执行ps -t -p -P
显示当前进程和线程
LIBRANK
获取该log:执行/system/xbin/librank
剔除不必要的library
BINDER FAILED TRANSACTION LOG
获取该log:读取文件/proc/binder/failed_transaction_log
BINDER TRANSACTION LOG
获取该log:读取文件/proc/binder/transaction_log
BINDER TRANSACTIONS
获取该log:读取文件/proc/binder/transactions
BINDER STATS
获取该log:读取文件/proc/binder/stats
BINDER PROCESS STATE
获取该log:读取文件/proc/binder/proc/*
bind相关的一些状态
FILESYSTEMS
获取该log:执行/system/bin/df
主要文件的一些容量使用状态(cache,sqlite,dev…)
PACKAGE SETTINGS
获取该log:读取文件/data/system/packages.xml
系统中package的一些状态(访问权限,路径…)，类似Windows里面的一些lnk文件吧.
PACKAGE UID ERRORS
获取该log:读取文件/data/system/uiderrors.txt
错误信息
KERNEL LAST KMSG LOG
最新kernel message log
LAST RADIO LOG
最新radio log
KERNEL PANIC CONSOLE LOG
KERNEL PANIC THREADS LOG
控制台/线程的一些错误信息log
BACKLIGHTS
获取该log:获取LCD brightness读/sys/class/leds/lcd-backlight/brightness
获取该log:获取Button brightness读/sys/class/leds/button-backlight/brightness
获取该log:获取Keyboard brightness读/sys/class/leds/keyboard-backlight/brightness
获取该log:获取ALS mode读/sys/class/leds/lcd-backlight/als
获取该log:获取LCD driver registers读/sys/class/leds/lcd-backlight/registers
获取相关亮度的一些信息
(2)build.prop
VERSION INFO输出下列信息
当前时间
当前内核版本:可以读取文件(/proc/version)获得
显示当前命令:可以读取文件夹(/proc/cmdline)获得
显示系统build的一些属性:可以读取文件(/system/build.prop)获得
输出系统一些属性
gsm.version.ril-impl
gsm.version.baseband
gsm.imei
gsm.sim.operator.numeric
gsm.operator.alpha
(3)dumpsys
执行/system/bin/dumpsys后可以获得这个log.
经常会发现该log输出不完整,因为代码里面要求该工具最多只执行60ms,可能会导致log无法完全输出来.
可以通过修改时间参数来保证log完全输出.
信息:
Currently running services
DUMP OF SERVICE services-name(running)
Log Code Analysis
Site: .\frameworks\base\cmds\dumpstate\
相关Log程序的代码可以从上面目录获取
Log Analysis Experience
分析步骤
1.查看一些版本信息
确认问题的系统环境
2.查看CPU/MEMORY的使用状况
看是否有内存耗尽,CPU繁忙这样的背景情况出现.
3.分析traces
因为traces是系统出错以后输出的一些线程堆栈信息,可以很快定位到问题出在哪里.
4.分析SYSTEM LOG
系统Log详细输出各种log,可以找出相关log进行逐一分析
实例分析
下面分析我写的一个测试例子,在OnCreate做一个死循环,这样主线程会被锁住，在按下硬件的Back之后会出现ANR的错误.
在traces中发现该程序的堆栈信息如下:
—– pid 20597 at 2010-03-15 01:29:53 —–
Cmd line: com.android.test
DALVIK THREADS:
"main" prio=5 tid=3 TIMED_WAIT
| group="main" sCount=1 dsCount=0 s=N obj=0x2aac6240 self=0xbda8
| sysTid=20597 nice=0 sched=0/0 cgrp=default handle=1877232296
at java.lang.VMThread.sleep(Native Method)
at java.lang.Thread.sleep(Thread.java:1306)
at java.lang.Thread.sleep(Thread.java:1286)
at android.os.SystemClock.sleep(SystemClock.java:114)
at com.android.test.main.onCreate(main.java:20)
at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2459)
at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:2512)
at android.app.ActivityThread.access$2200(ActivityThread.java:119)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1863)
at android.os.Handler.dispatchMessage(Handler.java:99)
at android.os.Looper.loop(Looper.java:123)
at android.app.ActivityThread.main(ActivityThread.java:4363)
at java.lang.reflect.Method.invokeNative(Native Method)
at java.lang.reflect.Method.invoke(Method.java:521)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:868)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:626)
at dalvik.system.NativeStart.main(Native Method)
"Binder Thread #2" prio=5 tid=11 NATIVE
| group="main" sCount=1 dsCount=0 s=N obj=0x2fb7c260 self=0×143860
| sysTid=20601 nice=0 sched=0/0 cgrp=default handle=1211376
at dalvik.system.NativeStart.run(Native Method)
"Binder Thread #1" prio=5 tid=9 NATIVE
| group="main" sCount=1 dsCount=0 s=N obj=0x2fb7c1a0 self=0x14c980
| sysTid=20600 nice=0 sched=0/0 cgrp=default handle=1207920
at dalvik.system.NativeStart.run(Native Method)
"Signal Catcher" daemon prio=5 tid=7 RUNNABLE
| group="system" sCount=0 dsCount=0 s=N obj=0x2fb7a1e8 self=0x126cc0
| sysTid=20599 nice=0 sched=0/0 cgrp=default handle=1269048
at dalvik.system.NativeStart.run(Native Method)
"HeapWorker" daemon prio=5 tid=5 VMWAIT
| group="system" sCount=1 dsCount=0 s=N obj=0x2e31daf0 self=0x135c08
| sysTid=20598 nice=0 sched=0/0 cgrp=default handle=1268528
at dalvik.system.NativeStart.run(Native Method)
—– end 20597 —–
该文件的堆栈结构从下往上进行分析
(1)栈底at dalvik.system.NativeStart.run(Native Method)
系统为当前的task(应用程式)启动一个专用的虚拟机
(2) at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:2459)
Activity Services是在后台负责管理Activity,它此时将测试例子的Activity启动起来了
(3)at com.android.test.main.onCreate(main.java:20)
启动测试程序
(4)栈顶at java.lang.VMThread.sleep(Native Method)
线程被sleep掉了,所以无法响应用户,出现ANR错误.
上面是对一个非常简单的问题的分析.
如果遇到比较复杂的问题还需要详细分析SYSTEM LOG.
1.比如网络异常,要通过SYSTEM LOG里面输出的网络链接信息来判断网络状态
2.数据传输,网络链接等耗时的操作需要分析SYSTEM LOG里面ActivityManager的响应时间
3…
让adb logcat打印内核调试信息
http://blog.csdn.net/ryfjx6/article/details/7096018
在默认情况下，adb logcat只能显示应用程序的调试信息，我把logcat.cpp修改了一下，让它同时可以打印内核调试信息：
修改的文件：system/core/logcat/logcat.cpp
1、首先先加入头文件
#include <sys/klog.h> //add by
2、定义所使用的TAG
#define KERNEL_TAG "Kernel"
3、替换readLogLines函数
01.static void readLogLines(log_device_t* devices) 02.{ 03. log_device_t* dev; 04. int max = 0; 05. int ret; 06. int queued_lines = 0; 07. bool sleep = true; 08. char buffer[256] = {0}; //add by zhaofei 09. 10. 11. int result; 12. fd_set readset; 13. 14. 15. for (dev=devices; dev; dev = dev->next) { 16. if (dev->fd > max) { 17. max = dev->fd; 18. } 19. } 20. 21. 22. while (1) { 23. do { 24. timeval timeout = { 0, 5000 /* 5ms */ }; // If we oversleep it's ok, i.e. ignore EINTR. 25. FD_ZERO(&readset); 26. for (dev=devices; dev; dev = dev->next) { 27. FD_SET(dev->fd, &readset); 28. } 29. result = select(max + 1, &readset, NULL, NULL, sleep ? NULL : &timeout); 30. } while (result == -1 && errno == EINTR); 31. 32. 33. if (result >= 0) { 34. for (dev=devices; dev; dev = dev->next) { 35. if (FD_ISSET(dev->fd, &readset)) { 36. queued_entry_t* entry = new queued_entry_t(); 37. /* NOTE: driver guarantees we read exactly one full entry */ 38. ret = read(dev->fd, entry->buf, LOGGER_ENTRY_MAX_LEN); 39. if (ret < 0) { 40. if (errno == EINTR) { 41. delete entry; 42. goto next; 43. } 44. if (errno == EAGAIN) { 45. delete entry; 46. break; 47. } 48. perror("logcat read"); 49. exit(EXIT_FAILURE); 50. } 51. else if (!ret) { 52. fprintf(stderr, "read: Unexpected EOF!\n"); 53. exit(EXIT_FAILURE); 54. } 55. 56. 57. entry->entry.msg[entry->entry.len] = '\0'; 58. 59. 60. dev->enqueue(entry); 61. ++queued_lines; 62. 63. 64.#if 1 //read kernel log 65. if((ret = klogctl(9, buffer, sizeof(buffer))) > 0) { 66. if((ret = klogctl(2, buffer, sizeof(buffer))) > 0) { 67. entry->entry.tid = 0; 68. entry->entry.pid = getpid(); 69. /*priority*/ 70. entry->entry.msg[0] = ANDROID_LOG_INFO; 71. /*tag*/ 72. strcpy(entry->entry.msg+1, KERNEL_TAG); 73. /*message*/ 74. strncpy(entry->entry.msg+1+sizeof(KERNEL_TAG), buffer, ret); 75. entry->entry.len = 1 + sizeof(KERNEL_TAG) + ret + 1; 76. entry->entry.msg[entry->entry.len] = '/0'; 77. /* 78. if (g_printBinary) { 79. printBinary(dev, entry->entry); 80. } else { 81. (void) processBuffer(dev, entry->entry); 82. } 83. */ 84. printNextEntry(dev); 85. } 86. } 87.#endif 88. } 89. } 90. 91. 92. if (result == 0) { 93. // we did our short timeout trick and there's nothing new 94. // print everything we have and wait for more data 95. sleep = true; 96. while (true) { 97. chooseFirst(devices, &dev); 98. if (dev == NULL) { 99. break; 100. } 101. if (g_tail_lines == 0 || queued_lines <= g_tail_lines) { 102. printNextEntry(dev); 103. } else { 104. skipNextEntry(dev); 105. } 106. --queued_lines; 107. } 108. 109. 110. // the caller requested to just dump the log and exit 111. if (g_nonblock) { 112. exit(0); 113. } 114. } else { 115. // print all that aren't the last in their list 116. sleep = false; 117. while (g_tail_lines == 0 || queued_lines > g_tail_lines) { 118. chooseFirst(devices, &dev); 119. if (dev == NULL || dev->queue->next == NULL) { 120. break; 121. } 122. if (g_tail_lines == 0) { 123. printNextEntry(dev); 124. } else { 125. skipNextEntry(dev); 126. } 127. --queued_lines; 128. } 129. } 130. } 131.next: 132. ; 133. } 134.}
这里没有把内核调试信息的级别转换成Androind的LOG级别，entry->entry.msg[0] = Android_LOG_INFO;使用了ANDROID_LOG_INFO级别，进程ID用了当前的进程ID。
然后就可以使用logcat来抓取kernel的log了！
更多相关文章
- 小编程（三）：用户登录注册界面开发及用户信息管理案例代码详解
- Android沉浸式状态栏下，如何代码实现android:fitsSystemWindows="
- Android之地理信息服务·Android的定位服务
- android studio 使用adb 命令传递文件到android 设备的方法
- Android NDK开发使用以及so文件生成和注意事项
- 【原创】Android 耗电信息统计服务——BatteryStats源码分析（一）
- 关于获取Android中文件内容有感
- iOS开发－Android 录制的mp4视频文件在IOS中无法播放问题
- Android通过HttpURLConnection上传多个文件至服务器 - 流传输