美文网首页
logcat日志抓取及分析

logcat日志抓取及分析

作者: 小时光_XSG | 来源:发表于2017-05-01 10:47 被阅读0次

    分析logcat日志,最好要有一定的编程基础。不会分析的可以找有经验的作者帮你看看。

    移植系统卡动画,日志会循环的输出一些特点信息,如果你发现系统日志一直都是循环输出一些一样的信息,那基本就可以判断系统是起不来的了。

    归结起来,常见日志里面有如下三种情况会导致系统卡动画(开不了机),当然还有更多情况,这里只举三种:

    (1) 某些系统关键服务启动失败,系统拒绝启动。常见输出日志如下

    I/ServiceManager( 1589): service 'media.audio_flinger' died

    I/ServiceManager( 1589): service 'media.player' died

    I/ServiceManager( 1589): service 'media.camera' died

    I/ServiceManager( 1589): service 'media.audio_policy' died

    这里出现的service XXX  died,那么系统基本就是起不来的了。这种问题多出在我们修复bug,替换文件时产生的。如果出现这种问题,找到你刚刚替换的文件,再换回去即可。 当然,有的文件需要配套使用,可能你再多换几个文件,这个问题就没了。根据自己的经验来找寻解决办法。

    (2) c语言文件执行是的段错误,大致日志如下:

    I/DEBUG   (  580): backtrace:

    I/DEBUG   (  580):     #00 pc 00011a50 /system/lib/libcamdrv.so(ImgSensorDrv::getCurrentSensorType(SENSOR_DEV_ENUM)+75)

    I/DEBUG   (  580):    #01  pc 0001302b  /system/lib/libcamdrv.so(ImgSensorDrv::impSearchSensor(int (*)())+422)

    I/DEBUG   (  580):    #02  pc 000133ed  /system/lib/libcamdrv.so(SensorDrv::searchSensor(int (*)())+14)

    I/DEBUG   (  580):    #03  pc 0001696f  /system/lib/libcamdrv.so(SensorHalImp::searchSensor()+226)

    I/DEBUG   (  580):    #04  pc 0000838d  /system/lib/hw/camera.default.so(android::CamDeviceManager::getNumberOfCameras()+120)

    I/DEBUG   (  580):    #05  pc 0001c317  /system/lib/libcameraservice.so(android::CameraService:: onFirstRef()+58)

    I/DEBUG   (  580):    #06  pc 0000ef2d  /system/lib/libutils.so(android::RefBase::incStrong(void const*) const+38)

    I/DEBUG   (  580):    #07  pc 00000bc9  /system/bin/mediaserver

    I/DEBUG   (  580):    #08  pc 00000c87  /system/bin/mediaserver

    I/DEBUG   (  580):    #09  pc 0001bd98  /system/lib/libc.so (__libc_init+64)

    I/DEBUG   (  580):    #10  pc 00000aa0  /system/bin/mediaserver

    这里是程序的调用的so库的堆栈,可以看到最后的段错误发生在libcamdrv.so,这个时候,你尝试着将libcamdrv.so进行替换。如果不行,再换下一个,即camera.default.so,依次类推。

    (3) java代码异常,这种异常比较常见,经常遇到的apk FC问题都是要看这个的。出现这种异常,把logcat日志导出来,然后搜索“FATAL”, 基本就可以定位出问题的日志位置了。常见日志如下:

    E/AndroidRuntime( 3305): *** FATAL EXCEPTION IN SYSTEM PROCESS: main

    E/AndroidRuntime( 3305): java.lang.NullPointerException

    E/AndroidRuntime( 3305):        at com.android.commands.pm.Pm.preInstall(Pm.java:785)

    E/AndroidRuntime( 3305):        at com.android.commands.pm.Pm.run(Pm.java:114)

    E/AndroidRuntime( 3305):        at com.android.commands.pm.Pm.main(Pm.java:77)

    E/AndroidRuntime( 3305):        at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)

    E/AndroidRuntime( 3305):        at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:235)

    E/AndroidRuntime( 3305):        at dalvik.system.NativeStart.main(Native Method)

    E/ServiceManager( 3305): error in getService

    E/ServiceManager( 3305): android.os.RemoteException: Unknown binder error code. 0xfffffff7

    E/ServiceManager( 3305):        at android.os.BinderProxy.transact(Native Method)

    E/ServiceManager( 3305):        at android.os.ServiceManagerProxy.getService(ServiceManagerNative.java:123)

    E/ServiceManager( 3305):        at android.os.ServiceManager.getService(ServiceManager.java:55)

    E/ServiceManager( 3305):        at android.app.ActivityManagerNative$1.create(ActivityManagerNative.java:1832)

    E/ServiceManager( 3305):        at android.app.ActivityManagerNative$1.create(ActivityManagerNative.java:1830)

    E/ServiceManager( 3305):        at android.util.Singleton.get(Singleton.java:34)

    E/ServiceManager( 3305):        at android.app.ActivityManagerNative.getDefault(ActivityManagerNative.java:74)

    E/ServiceManager( 3305):        at com.android.internal.os.RuntimeInit$UncaughtHandler.uncaughtException(RuntimeInit.java:76)

    E/ServiceManager( 3305):        at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:693)

    E/ServiceManager( 3305):        at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:690)

    E/ServiceManager( 3305):        at dalvik.system.NativeStart.main(Native Method)

    这个异常堆栈,从第二行就可以看到是一个空指针异常,出现异常的位置在com.android.commands.pm.Pm类的preInstall方法的第785行中。根据这个信息你就可以找到相应的apk或者jar文件,然后反编译分析下代码逻辑,看看缺少了什么标志位导致的系统异常。

    对于ROM移植,一般来说代码我们是不需要做太多修改的,代码中需要什么样的调节,我们设定满足就好。常见的就是修改build.prop中的某些值来解决这种问题。

    最典型的例子就是有些系统移植MIUI后,修改了build.prop的某些值系统就各种fc,这是因为这些值会改变程序的执行逻辑,所以导致了问题的产生。

    ROM移植bug非常难修,更多是时候是经验帮助我们解决了问题。同样的bug,不同机器解决办法可能就不一样了。一般来说看日志主要用于解决系统的各种fc问题,插桩则是必须要看日志来解决问题的。

    相关文章

      网友评论

          本文标题:logcat日志抓取及分析

          本文链接:https://www.haomeiwen.com/subject/mduftxtx.html