Android框架杂谈

1.调用栈打印StackTraceElement st[] Thread.currentThread().getStackTrace();for (int i 0; i st.length; i) {System.out.println(showInput-Stack[i] st[i].toString());}2.setpowermode 中powermode对应关系surfaceflinger层面Off 0Doze 1On 2DozeSuspend 33.开发者选项触摸小圆点在InputReader阶段进行绘制具体绘制是在frameworks/base/libs/input/TouchSpotController.cpp中updateSprite函数中。void TouchSpotController::Spot::updateSprite(const SpriteIcon* icon, float x, float y,int32_t displayId) {sprite-setLayer(Sprite::BASE_LAYER_SPOT id);sprite-setAlpha(alpha);sprite-setTransformationMatrix(SpriteTransformationMatrix(scale, 0.0f, 0.0f, scale));sprite-setPosition(x, y);sprite-setDisplayId(displayId);...}4.Power键亮灭屏log关键字【1】kernel 上报power key[kernel log][53:pmic_thread]kpd: Power Key generate, pressed0【2】上层收到按键事件[eng版本上才有此logmain_log]WindowManager: interceptKeyTq keycode26 ...【3】PMS的wakeUp被调用[sys_log]PowerManagerService: Waking up from Dozing【4】准备绘制界面[sys_log]DisplayPowerController: Blocking screen on until initial contents have been drawn.【5】第一个wiating for drawn表示keyguard画完开始画window[sys_log]WindowManager: Waiting for drawn Window{6732b98 u0 com.android.settings/com.android.settings.SubSettings}:【6】底层resume时间L版本 setAutoSuspend/M版本 setPowerMode【main_log】注意这个log出现的时间点不是固定的要看底层resume的时间SurfaceControl: Excessive delay in setPowerMode(): 403ms【M 版本】PowerManagerService-JNI: Excessive delay in autosuspend_disable() while turning screen on: 424ms【L版本】【7】绘制界面完成及花费的时间[sys_log]DisplayPowerController: Unblocked screen on after 409 ms【8】上层设置背光[sys_log]DisplayPowerState: Requesting new screen state: stateON, backlight211【9】底层设置背光[sys_log,亮屏时间power key到此处的时间不一定每个版本都有此logkernel log]提示如果出现此log表示屏幕已经点亮PhotonicModulat][name:leds][LED]Set Backlight directly 211 at time 4294992661, mapping level is 211【10】亮屏操作完成[sys_log]DisplayPowerController: Finished business5.影响亮屏快慢的因素大致有三种1设置背光流程出问题了导致屏幕黑屏2window绘制时间过长导致屏幕block时间过长3底层surfacecontroller准备时间过长而根据遇到的亮屏慢的问题基本上都是由于window绘制时间过长导致屏幕亮屏慢最近处理的几个亮屏慢的问题其中关键log信息基本都是13-11 11:17:49.002 1313 1092 I DisplayPowerController: Blocking screen on until initial contents have been drawn.12-18 11:18:55.020 1313 1092 I DisplayPowerController: Unblocked screen on after 6018 ms6.关于触发拯救模式导致机器进入recovery。拯救模式又称救援模式是Android 8.0新增的一个功能。问题场景如下进入隐私空间长按控制中心的移动数据按钮此时com.android.phone进程报停还有一定的几率进入recovery。由于com.android.phone或者com.android.systemui是个常驻进程不断的重启又不断的died所以触发救援模式。救援模式在com.android.phone进程的不断started与died的过程中level等级被不断的提升一旦到达FACTORY_RESET等级系统就会自主进入recovery注最后一句log是自行添加的用来判断是哪个进程导致触发救援模式。W RescueParty: Attempting rescue level RESET_SETTINGS_UNTRUSTED_DEFAULTSW RescueParty: Attempting rescue level RESET_SETTINGS_UNTRUSTED_CHANGESW RescueParty: Attempting rescue level RESET_SETTINGS_TRUSTED_DEFAULTSW RescueParty: Attempting rescue level WARM_REBOOTW RescueParty: Attempting rescue level FACTORY_RESET所以处理进入recovery的问题首先就要判断是不是救援模式被触发了。7.冻屏问题总结首先按menu看是否有反应有反应说明不是死机冻屏冻屏出现过如下三种现象定屏1按虚拟键有背景色无法响应任何触摸事件音量键无作用power键有作用ADB能连定屏2按虚拟键无背景色power键有作用ADB能连定屏3power键都无作用ADB能连根据描述可见如上三个现象严重程度递增8.Input debug开关先执行enable_input_prop.bat脚本然后adb shell getprop persist.log.tag.InputTransportPublisher看下属性是否设置成功。成功了再抓下logenable_input_prop.batecho off:: 设置Android系统属性以启用InputTransportPublisher的调试日志adb shell setprop persist.log.tag.InputTransportPublisher DEBUGadb shell setprop persist.log.tag.InputDispatcherTouchMode DEBUGadb shell setprop persist.log.tag.InputDispatcherTouchOcclusion DEBUGadb shell setprop persist.log.tag.InputDispatcherInboundEvent DEBUGadb shell setprop persist.log.tag.InputDispatcherOutboundEvent DEBUGadb shell setprop persist.log.tag.InputDispatcherDispatchCycle DEBUGadb shell setprop persist.log.tag.InputDispatcherChannelCreation DEBUGadb shell setprop persist.log.tag.InputDispatcherFocus DEBUGadb shell setprop persist.log.tag.InputDispatcherAppSwitch DEBUGecho [SUCCESS] set property : persist.log.tag.InputTransportPublisherDEBUGpause