Navigation Bar 修改问题（二）---- Launcher与应用之间切换

转载地址：http://blog.csdn.net/chenqian_lj/article/details/17956039

接 Navigation bar开机后显示和隐藏（一）

1） 对上面的方式进行总结

    从AMS--> WMS-->PMS --> StatusbarManagerService--> CommandQueue(callback) -->

    PhoneStatusBar

    也许有人会说，这样的调用很繁琐，为啥不用广播呢？

    原因很直接：广播显然是在不同的线程里面，这样做不能保证窗口同步刷新，layout以后的后果未知

2） 修改当然也会有问题，问题的发生在Launcher和应用切换间。Navigationbar的添加与否会影响Configuration的变化,这里的Configuration不单包括oritation的变化（其实这里没有oritation的变化），在实际中自写Launcher没有NV bar，android的原生应用有NV bar，发现一个问题，在从MMs返回自写Launcher时，会重新调用Launcher的onCreate函数，导致原本进入了GridView

的，结果停留在Home的壁纸界面；而其它的应用如计算器就会直接进如gridview页面。问题的原因就是由于应用的fullscreen和Launcher 的Configuration变化引起的。

   a. 解释下MMs和计算器的区别，实际上就是fullscreen的区别，通常来说和透明度相关

详细参见ActivityRecord()@ActivityRecord.java

MMs: fullscreen == false      

Caculator: fullscreen == true

   b. 解释下上面问题的原因，想象一下这样的情景，从GridView进入MMS中，

1）Launcher（fullscreen） Paused

2）launch MMs， Resumed

3）由于MMs不是fullscreen，所以在ensureActivitiesVisibleLocked中会去检查当前的top应用是否全屏

,如果不是全屏，则会把下边的Acitivity show出来，此刻，下面的Activity为Launcher，而且Launcher一直是启动的，所以这里调用relaunchActivityLocked,这会导致重新的onCreate

    : java.lang.Exceptioncom.android.server.am.ActivityStack.relaunchActivityLocked(ActivityStack.java:5374)

    :  at com.android.server.am.ActivityStack.ensureActivityConfigurationLocked(ActivityStack.java:5339)

    :  at com.android.server.am.ActivityStack.ensureActivitiesVisibleLocked(ActivityStack.java:1607)

    :  at com.android.server.am.ActivityStack.ensureActivitiesVisibleLocked(ActivityStack.java:1727)

    :  at com.android.server.am.ActivityStack.completeResumeLocked(ActivityStack.java:1538)

    :  at com.android.server.am.ActivityStack.realStartActivityLocked(ActivityStack.java:865)

    :  at com.android.server.am.ActivityManagerService.attachApplicationLocked(ActivityManagerService.java:4958)

    :  at com.android.server.am.ActivityManagerService.attachApplication(ActivityManagerService.java:5027)

    :  at android.app.ActivityManagerNative.onTransact(ActivityManagerNative.java:387)

    :  at com.android.server.am.ActivityManagerService.onTransact(ActivityManagerService.java:1908)

    :  at android.os.Binder.execTransact(Binder.java:351)

    :  at dalvik.system.NativeStart.run(Native Method)  

4) 正常情况下，就算对Launcher调用了ensureActivityConfigurationLocked

也不会刷新屏幕，从而进入launcher的onCeate流程，原因在下面就返回了：

        if (r.configuration == newConfig && !r.forceNewConfig) {   

            if (DEBUG_SWITCH || DEBUG_CONFIGURATION) Slog.v(TAG,

                    "Configuration unchanged in " + r);

            return true;

        }

但是这里Navigation bar的从有到无必然会导致前面所说的Configuration的变化，Configuration的变化如下：

[email protected]

01-0410:05:30.888 617 1306 V kkkk :

newConfig = {1.0 ?mcc?mnc en_USldltr sw360dp w360dp h567dp 320dpi nrml port finger -keyb/v/h -nav/hskin=/system/framework/framework-res.apk s.9}, 

r.configuration = {1.0?mcc?mnc en_US ldltr sw360dp w360dp h615dp 320dpi nrml long portfinger -keyb/v/h -nav/h skin=/system/framework/framework-res.apks.8}, r.forceNewConfig = false 

细心的读者可能发现屏幕的高度h567dp 和 h615dp 发生了变化，差别就是NavigationBar的高度，由于这样原因，这下真的就要调用relaunchActivityLocked来刷新后面的Activity了（Launcher）

问题的原因已经分析出来，修改也就简单了

final boolean ensureActivityConfigurationLocked(ActivityRecord r,

            int globalChanges) {

   if ((changes&(~r.info.getRealConfigChanged())) != 0 || r.forceNewConfig) {

        if ((r.packageName.contains("com.your.packagename")

                    && (changes == 0x500 || changes == 0x580))) {

            // cancel relauncher ifyour package

            r.configChangeFlags = 0;

            //r.stopFreezingScreenLocked(false);

            return true;

        }

        ....

    }

}