AOD相关机制

AOD的概念：

                   AOD,即A（lways） O（n） D（isplay）是android一种低功耗的显示模式的一种应用，他能保证屏幕某块区域一直亮，该应用开启时绘制的频率会低于正常的频率。由于AOD现实的不是和正常的亮屏之后显示的一样，只                   会显示非黑色的部分，而且频率低于正常的频率 ，所以即使一直在显示功耗也比较低。

       AOD进程的流程： 

           AOD是一个应用，主要是通过DreamManagerService来切换DOZE、DOZE_SUSPEND实现AOD的进入、退出和显示。 如图一 transitionTo开始进入到setDozeScreenState结束，而DreamService也就是DreamServiceManager的               代理，后面就开始到了DreamServiceManager里面来做了。

     DreamManager和DreamManagerService

         在DreamManager里面是通过updateDoze 从而调用到PowerManagerService里面的mSandman.startDozing方法来和DreamManagerService通讯的，此处调用逻辑简单看下源码就知道。

         在DreamManagerService中，我们以进入DOZE状态为例，分析下调用流程。在进入DOZE的时候最重要的方法是

            

private void startDozingInternal(IBinder token, int screenState,
            int screenBrightness) {
        if (DEBUG) {
            Slog.d(TAG, "Dream requested to start dozing: " + token
                    + ", screenState=" + screenState
                    + ", screenBrightness=" + screenBrightness);
        }

        synchronized (mLock) {
            if (mCurrentDreamToken == token && mCurrentDreamCanDoze) {
                mCurrentDreamDozeScreenState = screenState;
                mCurrentDreamDozeScreenBrightness = screenBrightness;
                mPowerManagerInternal.setDozeOverrideFromDreamManager(
                        screenState, screenBrightness);//设置亮度
                if (!mCurrentDreamIsDozing) {
                    mCurrentDreamIsDozing = true;
                    mDozeWakeLock.acquire();//申请一个DozeWakeLock的锁
                }
            }
        }
    }

这个方法中其实最重要的就是设置一个亮度，申请一个锁。
    先说亮度：这个亮度screenBrightness最终将通过PowerManagerService的mDozeScreenBrightnessOverrideFromDreamManager封装成一个request，给PowerManagerService和DisplayManagerServices交互的类DisplayPowerController
然后在recordBrightnessChange方法中通过binder直接给surface底层，从而把这个亮度给设置进去。
    前面说过状态的切换最重要的是申请一个DozeWakeLock锁，这个锁定义如下：

   mDozeWakeLock = mPowerManager.newWakeLock(PowerManager.DOZE_WAKE_LOCK, TAG);
    这个锁对应的类型未   public static final int DOZE_WAKE_LOCK = OsProtoEnums.DOZE_WAKE_LOCK; // 0x00000040
   也就是说申请了0x00000040的锁，熟悉PowerManagerServices的同学都知道，这个锁最终会和用户行为一起合成一个drity，在getDesiredScreenPolicyLocked方法里计算出一个最终的policy给DisplayPowerController，
最终在DisplayPowerState里面将状态设置成为对应的状态（在这里要注意的是brightness原生流程中也是在DisplayPowerState里面去设置的，但是因为我们将传统的亮度和doze的亮度两个节点在底层分开了，所以doze的亮度是通过
recordBrightnessChange，利用binder直接和底层通信，将亮度设置进去的，具体的J1/J2 AOD节点移植方案）。
    我们看可以看下getDesiredScreenPolicyLocked里面DOZE在是如何影响影响policy的

    int getDesiredScreenPolicyLocked() {
       。。。。。。
        if (mWakefulness == WAKEFULNESS_DOZING) {
            if ((mWakeLockSummary & WAKE_LOCK_DOZE) != 0) {
                return DisplayPowerRequest.POLICY_DOZE;//policy的状态为doze
            }
           。。。。

        return DisplayPowerRequest.POLICY_DIM;
    }

  如果当前状态为WAKEFULNESS_DOZING且mWakeLockSummary里面有WAKE_LOCK_DOZE时当前policy就是DOZE

private static final int WAKE_LOCK_DOZE = 1 << 6;
前面DOZE_WAKE_LOCK是十进制的64，WAKE_LOCK_DOZE换成10进制也是64，换句话说进入DOZE状态的途径之一就是申请DOZE_WAKE_LOCK锁。
既然是途径之一还有什么方法可以进入DOZE状态能，通过源码我们发现，如果当前是本来就是POLICY_DOZE且有WAKE_LOCK_DRAW锁，这个时候回将dozeScreenState变成DOZE状态

private boolean updateDisplayPowerStateLocked(int dirty) {
       。。。。。。
            if (mDisplayPowerRequest.policy == DisplayPowerRequest.POLICY_DOZE) {
                mDisplayPowerRequest.dozeScreenState = mDozeScreenStateOverrideFromDreamManager;
                if ((mWakeLockSummary & WAKE_LOCK_DRAW) != 0
                        && !mDrawWakeLockOverrideFromSidekick) {
                    if (mDisplayPowerRequest.dozeScreenState == Display.STATE_DOZE_SUSPEND) {
                        mDisplayPowerRequest.dozeScreenState = Display.STATE_DOZE;//display为doze状态
                    }
                    if (mDisplayPowerRequest.dozeScreenState == Display.STATE_ON_SUSPEND) {
                        mDisplayPowerRequest.dozeScreenState = Display.STATE_ON;
                    }
                }
        。。。。。。。。。。。。
        return mDisplayReady && !oldDisplayReady;
    }

要通过dozeScreenState来进入DOZE,在源码中还有一种情况就是dozeScreenState为STATE_UNKNOWN状态，这个时候会用dozeScreenState的状态，但这种情况进入DOZE的会比较少。

 private void updatePowerState() {
        。。。。。
            case DisplayPowerRequest.POLICY_DOZE:
                if (mPowerRequest.dozeScreenState != Display.STATE_UNKNOWN) {
                    state = mPowerRequest.dozeScreenState;
                } else {
                    state = Display.STATE_DOZE;
                }
                if (!mAllowAutoBrightnessWhileDozingConfig) {
                    brightness = mPowerRequest.dozeScreenBrightness;
                    mBrightnessReasonTemp.setReason(BrightnessReason.REASON_DOZE);
                }
                break;
               。。。。。。
         }

    那如何切成DOZE_SUSPEND的呢，对应用（如指纹）会使用AOD暴露给他们的接口fireAodState，调到AOD的流程里，而AOD那边也是通过setDozeScreenState方法切成DOZE_SUSPEND同时应用（如指纹）释放DOZE_WAKE_LOCK锁的时候，CPU会
挂起，再通过DreamManagerService将mDozeScreenBrightnessOverrideFromDreamManager然后进入DOZE_SUSPEND状态,这里就不贴代码了，对应的log如下，

01-17 21:47:17.348 29499 29514 D PowerManagerService: acquireWakeLockInternal: lock=158204803, flags=0x80, tag="gxzw", ws=null, uid=1000, pid=29873  // 申请
01-17 21:47:17.356 29499 29809 I LocalDisplayAdapter: setDisplayState(id=0, state=DOZE)  // DOZE_SUSPEND -> DOZE
01-17 21:47:17.665 29499 30650 D PowerManagerService: releaseWakeLockInternal: lock=158204803 [gxzw], flags=0x10000  // 释放
01-17 21:47:17.672 29499 29809 I LocalDisplayAdapter: setDisplayState(id=0, state=DOZE_SUSPEND)  // DOZE -> DOZE_SUSPEND
01-17 21:47:18.882 29499 29514 D PowerManagerService: acquireWakeLockInternal: lock=206718903, flags=0x80, tag="Window:AOD", ws=WorkSource{1000 com.miui.aod}, uid=1000, pid=29499
01-17 21:47:18.899 29499 29809 I LocalDisplayAdapter: setDisplayState(id=0, state=DOZE)
01-17 21:47:19.019 29499 29499 D PowerManagerService: releaseWakeLockInternal: lock=206718903 [Window:AOD], flags=0x10000
01-17 21:47:19.023 29499 29809 I LocalDisplayAdapter: setDisplayState(id=0, state=DOZE_SUSPEND)
01-17 21:47:22.412 29499 30650 D PowerManagerService: acquireWakeLockInternal: lock=258767652, flags=0x80, tag="Window:gxzw_anim", ws=WorkSource{1000 com.android.systemui}, uid=1000, pid=29499
01-17 21:47:22.416 29499 29809 I LocalDisplayAdapter: setDisplayState(id=0, state=DOZE)
01-17 21:47:22.423 29499 30103 D PowerManagerService: acquireWakeLockInternal: lock=158204803, flags=0x80, tag="gxzw", ws=null, uid=1000, pid=29873
01-17 21:47:22.749 29499 29809 I LocalDisplayAdapter: setDisplayState(id=0, state=DOZE_SUSPEND)

 

      关于DOZE，DOZE_SUSPEND的切换还有另外一种情况就是在LocalDisplayAdapter.java中，如果两次发下来的都是DOZE_SUSPEND，这个时候会在requestDisplayStateLocked方法里面切成DOZE,这也是很多时候把指纹等一些应用关掉之后，没有任何进程在上层切换，也会来回切的原因，这是Google原生的逻辑，最好还是别在这里动刀，这样设计的目的估计也是因为下两次联系的DOZE_SUSPEND的可能性非常小，下了两次就肯定是要做其他的事情（如修改亮度），这个时候就不能在DOZE_SUSPEND下修改了。

分析方法

在AOD的分析过程中，更多的是底层发现问题，fw层定位问题，给出解决方案，上层修改问题。
总的来说就是找到根本原因，上层能改就尽量上层改。
对于问题首先要确定上层的状态指令已经下到fw层，也就是先确定有类似的08-15 23:54:38.412 3482 3482 W DozeScreenState: applyScreenState: setDozeScreenState 4，如果没有则可以先让AOD排查下逻辑是否正常；
如果有指令下发，则需要排查是否底层和上层应用的一些状态没有对上。
还有一种情况就是有一些机制Google和底层并没有打成一致的协议，如底层要求DOZE_SUSPEND下不去绘制，但Google并没有任何机制去保证，对于某些屏也没有做限制.
当然更多的还是具体问题具体分析，这里也只能按照往常分析fw问题的方式，先确定下到底是哪里的问题（即有没有对应的log），不同的问题还要根据不同团队的能力给出不同的解决方案。