logandroid

㈠ 如何在android手机上查看log

使用cmd命令查看logcat 使用adb logcat命令可查看android系统和应用的log adb logca

㈡ android中的几个log的功能及作用

android.util.Log常用的方法有以下5个：Log.v() Log.d() Log.i() Log.w() 以及 Log.e()
Log.v 的调试颜色为黑色的，任何消息都会输出，这里的v代表verbose啰嗦的意思，平时使用就是Log.v("","");
Log.d的输出颜色是蓝色的，仅输出debug调试的意思，但他会输出上层的信息，过滤起来可以通过DDMS的Logcat标签来选择.
Log.i的输出为绿色，一般提示性的消息information，它不会输出Log.v和Log.d的信息，但会显示i、w和e的信息
Log.w的意思为橙色，可以看作为warning警告，一般需要我们注意优化Android代码，同时选择它后还会输出Log.e的信息。
Log.e为红色，可以想到error错误，这里仅显示红色的错误信息，这些错误就需要我们认真的分析，查看栈的信息了。
以下是使用方法：
Log.v(LogDemo.ACTIVITY_TAG, "This is Verbose.");
Log.d(LogDemo.ACTIVITY_TAG, "This is Debug.");
Log.i(LogDemo.ACTIVITY_TAG, "This is Information");
Log.w(LogDemo.ACTIVITY_TAG, "This is Warnning.");
Log.e(LogDemo.ACTIVITY_TAG, "This is Error.");

㈢ Android 各种log 的介绍

包含设备日志，堆栈跟踪和其他诊断信息，可帮助您查找和修复应用中的错误。

安卓bugreport主要用于分析手机的状态。其包含： main log ， kernel log ，cpuinfo等信息。bugreport是一个可执行文件，编译后的路径为system/bin/bugreport，源码位于framework/native/cmds/bugreport。其核心在于启动mpsys服务。bugreport同mpstate服务建立socket通信（建立连接20次，超时3min无数据等容错）。连接之后，将接收到的数据定向到文件中。

  因此我们看到的bugreport数据均来自mpstate。

bugreport通过socket与mpstate服务建立通信，在mpstate.cpp中的mpstate()方法完成核心功能。分别输出： current log、 last log、 vm trace、 mpsys、 system info

 其详细内容主要有： 系统build及运行时长等信息、 内存和CPU进程的信息、 kernel log、 system log、 radio log、 event log 等等。实际来说，bugreport中显示的大部分为信息，都有对应的命令方式可以获取。bugreport只是作为一个在不打扰用户的前提下执行的一套命令集合。

    1). main_log    记录手机android上层app以及framework相关活动的log，比如你写的app打印的log，就在这里面

    2). events_log    主要是ActivityManager、powerManager等相关的log

    3). kernel Log    驱动相关的log

Logcat是内置在Android系统中的一个可执行工具，用于转储系统消息日志，其中包括设备引发错误时的堆栈追踪以及从您的应用当使用 Log 类编写的消息。可以在主机上通过adb logcat命令来查看模拟机上日志信息。

Android tcpmp是命令行数据包捕获实用程序。它可以捕获来自您的Wi-Fi连接，蜂窝连接以及您在android设备上可能具有的任何其他网络连接的数据包

modem 是手机里负责搜网和sim卡数据操作底层模块，每个手机都有，md log 用于分析掉网、掉话、无信号等问题

系统崩溃时留下的遗言，怎么死的，死哪了，死的多惨。

当一个动态库（native 程序）开始执行时，系统会注册一些连接到 debuggerd 的 signal handlers，当系统 crash（崩溃） 的时候，会保存一个 tombstone 文件到/data/tombstones目录下（Logcat中也会有相应的信息），文件的确就像墓碑一样记录了死亡了的进程的基本信息（例如进程的进程号，线程号），死亡的地址（在哪个地址上发生了 Crash），死亡时的现场是什么样的（记录了一系列的堆栈调用信息）等等。

6. netlog    网络相关

看网络链接情况，抓取网络包等等

7. QXDM（the Qualcomm eXtensible Diagnostic Monitor）高通可扩展诊断监视器

该工具适用于拥有使用Qualcomm ASIC和试用硬件的设备的人，并允许他们测试，评估和潜在诊断其移动设备的RF性能问题。通常使用它来促进这些设备的产品开发。

使用该软件，用户可以查看他们的移动设备发出的所有信令消息，因为该软件会生成它们的日志。这些日志也可以通过软件进行注释。可以将网络和电话参数的任何混合添加到屏幕，并且允许用户在使用其参数时使用复杂的公式。该程序还实时生成大量统计数据，以便用户可以更好地识别潜在的性能问题。用户可以访问Markov统计信息，Mux统计信息，RLP统计信息，块错误率，移动性管理数据，寻呼和访问统计信息，前向和反向链路统计信息等等。该程序还为用户提供了便携式设备信号的图形显示。该程序与Windows操作系统兼容。

8. init Log（init进程log）

9. Crashlog（崩溃日志）

㈣ 如何分析android log日志

1 log文件分类简介

实时打印 的主要有： logcat main ， logcat radio ， logcat events ，tcpmp ，还有高通平台的还会有 QXDM 日志

状态信息 的有： adb shell cat /proc/kmsg ， adb shell dmesg ， adb shell mpstate ， adb shell mpsys ， 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 打印系统事件的日志，比如触屏事件。。。

tcpmp 是很有用的，对于 TCP/IP 协议相关的都可以使用这个来抓， adb shell tcpmp -s 10000 -w /sdcard/capture.pcap ，比如抓 mms 下载的时候的 UA profile， browser 上网的时候，使用 proxy 的 APN 下载， streaming 的相关内容包括 UA profile 等。

㈤ 如何分析Android的Log

首先，让我们看一看AndroidLog的格式。下面这段log是以所谓的long格式打印出来的。从前面Logcat的介绍中可以知道，long格式会把时间，标签等作为单独的一行显示。

[ 12-09 21:39:35.510 396: 416 I/ActivityManager ]

Start procnet.coollet.infzmreader:umengService_v1 for service
net.coollet.infzmreader/com.umeng.message.

UmengService:pid=21745 uid=10039 gids={50039, 3003, 1015,1028}

[ 12-09 21:39:35.518 21745:21745I/dalvikvm ]

Turning on JNI app bug workarounds fortarget SDK version 8...

[ 12-09 21:39:35.611 21745:21745D/AgooService ]

onCreate()

我们以第一行为例：12-09 是日期，21:39:35.510是时间396是进程号，416是线程号；I代表log优先级，ActivityManager是log标签。

在应用开发中，这些信息的作用可能不是很大。但是在系统开发中，这些都是很重要的辅助信息。开发工程师分析的log很多都是由测试工程师抓取的，所以可能有些log根本就不是当时出错的log。如果出现这种情况，无论你怎么分析都不太可能得出正确的结论。如何能最大限度的避免这种情况呢？笔者就要求测试工程师报bug时必须填上bug发生的时间。这样结合log里的时间戳信息就能大致判断是否是发生错误时的log。而且根据测试工程师提供的bug发生时间点，开发工程师可以在长长的log信息中快速的定位错误的位置，缩小分析的范围。

同时我们也要注意，时间信息在log分析中可能被错误的使用。例如：在分析多线程相关的问题时，我们有时需要根据两段不同线程中log语句执行的先后顺序来判断错误发生的原因，但是我们不能以两段log在log文件中出现的先后做为判断的条件，这是因为在小段时间内两个线程输出log的先后是随机的，log打印的先后顺序并不完全等同于执行的顺序。那么我们是否能以log的时间戳来判断呢？同样是不可以，因为这个时间戳实际上是系统打印输出log时的时间，并不是调用log函数时的时间。遇到这种情况唯一的办法是在输出log前，调用系统时间函数获取当时时间，然后再通过log信息打印输出。这样虽然麻烦一点，但是只有这样取得的时间才是可靠的，才能做为我们判断的依据。

另外一种误用log中时间戳的情况是用它来分析程序的性能。一个有多年工作经验的工程师拿着他的性能分析结果给笔者看，但是笔者对这份和实际情况相差很远的报告表示怀疑，于是询问这位工程师是如何得出结论的。他的回答让笔者很惊讶，他计算所采用的数据就是log信息前面的时间戳。前面我们已经讲过，log前面时间戳和调用log函数的时间并不相同，这是由于系统缓冲log信息引起的，而且这两个时间的时间差并不固定。所以用log信息前附带的时间戳来计算两段log间代码的性能会有比较大的误差。正确的方法还是上面提到的：在程序中获取系统时间然后打印输出，利用我们打印的时间来计算所花费的时间。

了解了时间，我们再谈谈进程Id和线程Id，它们也是分析log时很重要的依据。我们看到的log文件，不同进程的log信息实际上是混杂在一起输出的，这给我们分析log带来了很大的麻烦。有时即使是一个函数内的两条相邻的log，也会出现不同进程的log交替输出的情况，也就是A进程的第一条log后面跟着的是B进程的第二条log，对于这样的组合如果不细心分析，就很容易得出错误的结论。这时一定要仔细看log前面的进程Id，把相同Id的log放到一起看。

㈥ 如何分析Android的Log

首先，让我们看一看AndroidLog的格式。下面这段log是以所谓的long格式打印出来的。从前面Logcat的介绍中可以知道，long格式会把时间，标签等作为单独的一行显示。

这个log就不那么容易懂了，但是还是能从中看出很多信息，让我们一起来学习如何分析这种log。首先看下面这行：

pid: 2102, tid: 2102,name: testapp >>>./testapp <<<

从这一行我们可以知道crash进程的pid和tid，前文我们已经提到过，Android调用gettid函数得到的实际是进程Id号，所以这里的pid和tid相同。知道进程号后我们可以往前翻翻log，看看该进程最后一次打印的log是什么，这样能缩小一点范围。

接下来内容是进程名和启动参数。再接下来的一行比较重要了，它告诉了我们从系统角度看，出错的原因：

signal 11 (SIGSEGV), code 1(SEGV_MAPERR), fault addr 00000000

signal11是linux定义的信号之一，含义是Invalidmemory reference，无效的内存引用。加上后面的“faultaddr
00000000”我们基本可以判定这是一个空指针导致的crash。当然这是笔者为了讲解而特地制造的一个Crash的例子，比较容易判断，大部分实际的例子可能就没有那么容易了。

再接下来的log打印出了cpu的所有寄存器的信息和堆栈的信息，这里面最重要的是从堆栈中得到的backtrace信息：

I/DEBUG ( 127):backtrace:

I/DEBUG ( 127): #00 pc0000045e /system/bin/testapp

I/DEBUG ( 127): #01 pc0000046b /system/bin/testapp

I/DEBUG ( 127): #02 pc0001271f /system/lib/libc.so (__libc_init+38)

I/DEBUG ( 127): #03 pc00000400 /system/bin/testapp

因为实际的运行系统里没有符号信息，所以打印出的log里看不出文件名和行数。这就需要我们借助编译时留下的符号信息表来翻译了。Android提供了一个工具可以来做这种翻译工作：arm-eabi-addr2line，位于prebuilts/gcc/linux-x86/arm/arm-eabi-4.6/bin目录下。用法很简单：

#./arm-eabi-addr2line -f
-eout/target/proct/hammerhead/symbols/system/bin/testapp0x0000045e

参数-f表示打印函数名；参数-e表示带符号表的模块路径；最后是要转换的地址。这条命令在笔者的编译环境中得到的结果是：

memcpy
/home/rd/compile/android-4.4_r1.2/bionic/libc/include/string.h:108

剩余三个地址翻译如下：

main
/home/rd/compile/android-4.4_r1.2/packages/apps/testapp/app_main.cpp:38

out_vformat
/home/rd/compile/android-4.4_r1.2/bionic/libc/bionic/libc_logging.cpp:361

_start libgcc2.c:0

利用这些信息我们很快就能定位问题了。不过这样手动一条一条的翻译比较麻烦，笔者使用的是从网上找到的一个脚本，可以一次翻译所有的行，有需要的读者可以在网上找一找。

㈦ Android 手机中扩展名log是什么文件

文件扩展名: .log
log意即日志，通常是系统或者某些软件对已完成的某种处理的记录，以便将来做为参考，它并没有固定的格式，通常是文本文件，可以用记事本打开以查看内容，当然很可能是其它格式，直接打开就是乱码。大部分的log可以从文件名看出它的作用，比如uninstall.log或是error.log，当然前者通常是软件安装过程中生成的记录，以便将来卸载的时候可以提供给卸载程序使用，后者通常是用来记录一些软件运行中的错误信息等等。
首先,会发现数量最多的是"i tall.log"文件,而且都在各个应用软件的文件夹中，打开它，可以发现它详细地记录了安装信息：软件的源路径、安装时间、安装的整个过程，安装软件时的每一个操作，都会在这儿留下记录，包括向文件夹中拷贝".dll"，对注册表进行修改，如果有足够耐心，完全可以通过它自己安装软件。其实它的重要作用是为删除软件作准备的。如果删除或把这个文件从原来的文件夹中移开，在控制面板-添加/删除程序中不能卸载这个软件。它可由unwise.exe或它所在文件中的unwise.exe调用，假如执行unwise.exe文件，将会弹出对话框，要求提供"*.log",这类软件有：netants,acdsee,ultraedit,jetcar以及很多游戏。例如在注册表中关于NETANTS（网络蚂蚁，一个国产的下载加速软件）的卸载是这样记录的：
[HKEY_LOCAL_MACHINE\Software \Microsoft \Windows \CurrentVersion \Uni tall \NetAnts]
"Di layName"=" etAnt quot;
"Uni tallString"="D:\\NETANTS\\UNWISE.EXE D:\\NETANTS\\I TALL.LOG"，这里是不是看得很明显。
当然安装软件的记录文件也并不一定都是用这个文件名I TALL.LOG，象vopt99中产生一个vopt.log 的文件，它也是由安卓下的unwise.exe调用来删除软件。

㈧ 如何分析android的log

1、如何在程序中打出Log 以及Log的分类区别 ？
verbose、debug、info、warning、error

2、给你一个Log文件，如何定位到问题所在？
1）如果是ANR问题 ， 则搜索“ANR”关键词 。 快速定位到关键事件信息 。
2）如果是ForceClosed 和其它异常退出信息，则搜索"Fatal" 关键词， 快速定
位到关键事件信息 。

3）定位到关键事件信息后 ， 如果信息不够明确的，再去搜索应用程序包的虚拟
机信息 ，查看具体的进程和线程跟踪的日志，来定位到代码 。
用这种方法，出现问题，根本不需要断点调试 ， 直接定位到问题，屡试不爽 。
下面，我们就开始来分析这个例子的log 。
(打开log文件 ， 由于是ANR错误，因此搜索"ANR " ， 为何要加空格呢，你加上
和去掉比较一下就知道了 。 可以屏蔽掉不少保存到anr.log文件的无效信息 。)

3、何时会产生ANR ？
1）界面操作（点击按钮）：系统响应时间超过5秒
2）HandleMessage：处理时间超过10秒

4、log文件存在的目录？
一般在data/log目录下（真机才有）

5、一般哪几种情况会产生log文件 ？
1）程序异常退出 ， uncaused exception
2）程序强制关闭 ，Force Closed (简称FC)
3）程序无响应 ， Application No Response （简称ANR)

㈨ Android Log等级的介绍

android.util.Log常用的方法有以下5个：Log.v() ,Log.d() ,Log.i() ,Log.w() ,Log.e() 。按照日志级别从高到低为ERROR, WARN, INFO, DEBUG, VERBOSE.至于日志级别本身的含义.

1.下面是对各种日志级别的输出介绍:

1、Log.v 的输出颜色为黑色的，输出大于或等于VERBOSE日志级别的信息

2、Log.d的输出颜色是蓝色的，输出大于或等于DEBUG日志级别的信息

3、Log.i的输出为绿色，输出大于或等于INFO日志级别的信息

4、Log.w的输出为橙色, 输出大于或等于WARN日志级别的信息

5、Log.e的输出为红色，仅输出ERROR日志级别的信息.

Android的Log等级通常有五类，按照日志级别由低到高分别是Verbose、Debug、Info、Warning、Error，其对应的log定义在system层。

1.V

Verbose就是冗长啰嗦的。通常表达开发调试过程中的一些详细信息，用Log.v()输出，不过滤地输出所有调试信息。是最低级的Log可以不用管。

2.D

Debug来表达调试信息。用Log.d()输出，能输出Debug、Info、Warning、Error级别的Log信息。

3.I

Info来表达一些信息。用Log.i()输出，能输出Info、Warning、Error级别的Log信息。

4.W

Warning表示警告，但不一定会马上出现错误，开发时有时用来表示特别注意的地方。用Log.w()输出，能输出Warning、Error级别的Log信息。

5.E

Error表示出现错误，是最需要关注解决的。用Log.e()输出，能输出Error级别的Log信息。

注：Info、Warnning、Error等级的Log在普通调试中不随意滥用，存在发布版本中。在开发调试版本中，才会显示全部等级。