Android 5.0原生bug及修复方法
分类：android系统层
Android 5.0已经来了，这个版本改动非常大，也意味着会有更多的bug隐藏在其中，我会在这篇文章中一直更新自己遇到的原生bug及修复方法。
1、bug1
现象：
5.0中ActivityManagerService.keyguardWaitingForActivityDrawn()接口替换了4.4中ActivityManagerService.dismissKeyguardOnNextActivity()接口,但是带来了一个显示bug，现象是keyguard隐藏后activity窗口还没显示出来，先看到的是launcher界面，，接着才会显示目标activity窗口。
原因分析：
5.0上触发调用ActivityStackSupervisor.notifyActivityDrawnForKeyguard()时机提前导致。
解决方法：
注释掉ActivityStack.completeResumeLocked()函数中对notifyActivityDrawnForKeyguard()函数的调用。
frameworks\base\services\java\com\android\server\am\ActivityStack.java
private void completeResumeLocked(ActivityRecord next) {next.idle = false;next.results = null;next.newIntents = null;if (next.isHomeActivity() && next.isNotResolverActivity()) {ProcessRecord app = next.task.mActivities.get(0).app;if (app != null && app != mService.mHomeProcess) {mService.mHomeProcess = app;}}if (next.nowVisible) {// We won't get a call to reportActivityVisibleLocked() so dismiss lockscreen now.//mStackSupervisor.notifyActivityDrawnForKeyguard();//注释掉}
2、bug2
现象：
一个父窗口拥有两个子窗口，且子窗口的type类型一致，两个子窗口有前后添加顺序，当两个子窗口同时显示时然后按下home键进入后台，再从桌面启动这个应用，会发现两个子窗口相对上下位置发生对调。
原因分析：
有两个原因，一是子窗口type类型不该一致，二是WindowManagerService针对两个子窗口type类型一致时逻辑不健全。
解决办法：
方法一：将两个子窗口type类型进行更改；
方法二：在WindowState的构造函数修改子窗口添加逻辑；
frameworks\base\services\java\com\android\server\am\WindowState.java
WindowState(WindowManagerService service, Session s, IWindow c, WindowToken token,WindowState attachedWindow, int appOp, int seq, WindowManager.LayoutParams a,int viewVisibility, final DisplayContent displayContent) {…………..if (children_size == 0) {mAttachedWindow.mChildWindows.add(this);} else {for (int i = 0; i < children_size; i++) {WindowState child = (WindowState)mAttachedWindow.mChildWindows.get(i);if (this.mSubLayer < child.mSubLayer) {mAttachedWindow.mChildWindows.add(i, this);break;} else if (this.mSubLayer > child.mSubLayer) {continue;}if (this.mBaseLayer <= child.mBaseLayer) {mAttachedWindow.mChildWindows.add(i, this);break;} else {continue;}}if (children_size == mAttachedWindow.mChildWindows.size()) {mAttachedWindow.mChildWindows.add(this);}}……….}
3、bug3
现象：
两个activity之间跳转时都加上Intent.FLAG_ACTIVITY_REORDER_TO_FRONT这个flag，按照A–>B–>A跳转后，按下back键，此时必会引起launcher ANR。
原因分析：
加上Intent.FLAG_ACTIVITY_REORDER_TO_FRONT进行A–>B–>A跳转后，由于focused activity没有更新为A，导致WMS中寻找focused window为null，key事件上报找不到focused window以致无法分发key事件，最终导致launcher ANR。
解决办法：
在ActivityStackSupervisor.startActivityUncheckedLocked()函数中加上mService.setFocusedActivityLocked(targetStack.topRunningActivityLocked(null));语句。frameworks/base/services/java/com/android/server/am/ActivityStackSupervisor.java
final int startActivityUncheckedLocked(ActivityRecord r,ActivityRecord sourceRecord, int startFlags, boolean doResume,Bundle options) {………….else if (!addingToTask &&(launchFlags&Intent.FLAG_ACTIVITY_REORDER_TO_FRONT) != 0) {// In this case, we are launching an activity in our own task// that may already be running somewhere in the history, and// we want to shuffle it to the front of the stack if so.final ActivityRecord top = sourceTask.findActivityInHistoryLocked(r);if (top != null) {final TaskRecord task = top.task;task.moveActivityToFrontLocked(top);ActivityStack.logStartActivity(EventLogTags.AM_NEW_INTENT, r, task);top.updateOptionsLocked(options);top.deliverNewIntentLocked(callingUid, r.intent);targetStack.mLastPausedActivity = null;if (doResume) {targetStack.resumeTopActivityLocked(null);mService.setFocusedActivityLocked(targetStack.topRunningActivityLocked(null)); //添加该语句；}return ActivityManager.START_DELIVERED_TO_TOP;}}……….}
待续。
上一篇NotificationManagerService笔记下一篇Location服务框架笔记
顶0踩0
即使没有收获的希望也心平气和的继续。
