Android的电源办理

总体上来说Android的电源办理还是比较大抵的, 紧张便是通过锁和定时器来切换体系的状态,使体系的功耗降至最低,整个别系的电源办理架构图如下: (注该图来自Steve Guo)

接下来我们从Java应用层面, Android framework层面, Linux内核层面分别举行过细的讨论:

应用层的利用:

Android提供了现成android.os.PowerManager类,该类用于控制配置的电源状态的切换.

该类对外有三个接口函数:

         void goToSleep(long time); //陵暴配置进入Sleep状态

         Note:

实行在应用层调用该函数,却不克不及告成,出现的错误好象是权限不敷, 但在Framework下面的Service里调用是可以的.

         newWakeLock(int flags, String tag);//获取相应层次的锁

flags参数阐发:

PARTIAL_WAKE_LOCK: Screen off, keyboard light off

SCREEN_DIM_WAKE_LOCK: screen dim, keyboard light off

SCREEN_BRIGHT_WAKE_LOCK: screen bright, keyboard light off

FULL_WAKE_LOCK: screen bright, keyboard bright

ACQUIRE_CAUSES_WAKEUP: 一旦有恳求锁时陵暴打开Screen和keyboard light

ON_AFTER_RELEASE: 在开释锁时reset activity timer

Note:

要是申请了partial wakelock,那么纵然按Power键,体系也不会进Sleep,如Music播放时

要是申请了别的的wakelocks,按Power键,体系还是会进Sleep

         void userActivity(long when, boolean noChangeLights);//User activity变乱孕育产生,配置会被切换到Full on的状态,同时Reset Screen off timer.

Sample code:

         PowerManager pm = (PowerManager)getSystemService(Context.POWER_SERVICE);

PowerManager.WakeLock wl = pm.newWakeLock (PowerManager.SCREEN_DIM_WAKE_LOCK, “My Tag”);

         wl.acquire();

         …….

         wl.release();

Note:

1. 在利用以上函数的应用步调中,必须在其Manifest.xml文件中参加下面的权限:

    <uses-permission android:name="android.permission.WAKE_LOCK" />

<uses-permission android:name="android.permission.DEVICE_POWER" />

2. 全部的锁必须成对的利用,要是申请了而没有及时开释会导致体系妨碍.如申请了partial wakelock,而没有及时开释,那体系就永世进不了Sleep模式.

Android Framework层面:

其紧张代码文件如下:

frameworks\base\core\java\android\os\PowerManager.java

frameworks\base\services\java\com\android\server\PowerManagerService.java

frameworks\base\core\java\android\os\Power.java

frameworks\base\core\jni\android_os_power.cpp

hardware\libhardware\power\power.c

此中PowerManagerService.java是内核, Power.java提供底层的函数接口,与JNI层举行交互, JNI层的代码紧张在文件android_os_Power.cpp中,与Linux kernel交互是通过Power.c来实现的, Andriod跟Kernel的交互紧张是通过sys文件的要领来实现的,细致请参考Kernel层的先容.

这一层的结果相相比较巨大,比如体系状态的切换,背光的调理及开关,Wake Lock的申请和开释等等,但这一层跟硬件平台无关,并且由Google认真维护,标题相对会少一些,有兴趣的朋侪可以本身查察干系的代码.

Kernel层:

其紧张代码在下各位置:

drivers/android/power.c

其对Kernel提供的接口函数有

EXPORT_SYMBOL(android_init_suspend_lock); //初始化Suspend lock,在利用前必须做初始化

EXPORT_SYMBOL(android_uninit_suspend_lock); //开释suspend lock干系的资源

EXPORT_SYMBOL(android_lock_suspend); //申请lock,必须调用相应的unlock来开释它

EXPORT_SYMBOL(android_lock_suspend_auto_expire);//申请partial wakelock, 定时时间到后会主动开释

EXPORT_SYMBOL(android_unlock_suspend); //开释lock

EXPORT_SYMBOL(android_power_wakeup); //唤醒体系到on

EXPORT_SYMBOL(android_register_early_suspend); //注册early suspend的驱动

EXPORT_SYMBOL(android_unregister_early_suspend); //取消已经注册的early suspend的驱动

提提供Android Framework层的proc文件如下:

"/sys/android_power/acquire_partial_wake_lock" //申请partial wake lock

"/sys/android_power/acquire_full_wake_lock" //申请full wake lock

"/sys/android_power/release_wake_lock" //开释相应的wake lock

"/sys/android_power/request_state" //恳求变革体系状态,进standby和回到wakeup两种状态

"/sys/android_power/state" //指示如今体系的状态

Android的电源办理紧张是通过Wake lock来实现的,在最底层紧张是通过如下三个行列步队来实现其办理:

static LIST_HEAD(g_inactive_locks);

static LIST_HEAD(g_active_partial_wake_locks);

static LIST_HEAD(g_active_full_wake_locks);

全部初始化后的lock都市被插入到g_inactive_locks的行列步队中,而如今活动的partial wake lock都市被插入到g_active_partial_wake_locks行列步队中, 活动的full wake lock被插入到g_active_full_wake_locks行列步队中, 全部的partial wake lock 和full wake lock在逾期后或unlock后都市被移到inactive的行列步队,等待下次的调用.

在Kernel层利用wake lock步调如下:

1.        调用函数android_init_suspend_lock初始化一个wake lock

2.        调用干系申请lock的函数android_lock_suspend 或 android_lock_suspend_auto_expire恳求lock,这里只能申请partial wake lock, 要是要申请Full wake lock,则须要调用函数android_lock_partial_suspend_auto_expire(该函数没有EXPORT出来),这个定名有点稀罕,不要跟前面的android_lock_suspend_auto_expire搞混了.

3.        要是是auto expire的wake lock则可以敷衍,不但是必须及时的把干系的wake lock开释失,不然会导致体系长期运行在高功耗的状态.

4.        在驱动卸载或不再利用Wake lock时请记取及时的调用android_uninit_suspend_lock开释资源.

体系的状态:

         USER_AWAKE, //Full on status

         USER_NOTIFICATION, //Early suspended driver but CPU keep on

         USER_SLEEP // CPU enter sleep mode

其状态切换表现图如下:

体系正常开机失队入到AWAKE状态, Backlight会从最亮垂垂调理到利用者设置的亮度,体系screen off timer(settings->sound & display-> Display settings -> Screen timeout)开始计时,在计时时间到之前,要是有恣意的activity变乱孕育产生,如Touch click, keyboard pressed等变乱, 则将Reset screen off timer, 体系保持在AWAKE状态. 要是有应用步调在这段时间内申请了Full wake lock,那么体系也将保持在AWAKE状态, 除非利用者按下power key. 在AWAKE状态下要是电池电量低大概是用AC供电screen off timer时间到并且选中Keep screen on while pluged in选项,backlight会被陵暴调理到DIM的状态.

要是Screen off timer时间到并且没有Full wake lock大概利用者按了power key,那么体系状态将被切换到NOTIFICATION,并且调用全部已经注册的g_early_suspend_handlers函数, 通常会把LCD和Backlight驱动注册成early suspend典范,如有须要也可以把别的驱动注册成early suspend,如许就会在第一阶段被封闭. 接下来体系会刚强是否有partial wake lock acquired, 要是有则等待其开释, 在等待的进程中要是有user activity变乱孕育产生,体系则顿时回到AWAKE状态;要是没有partial wake lock acquired, 则体系会顿时调用函数pm_suspend封闭别的干系的驱动, 让CPU进入休眠状态.

体系在Sleep状态时要是检测到恣意一个Wakeup source, 则CPU会从Sleep状态被唤醒,并且调用干系的驱动的resume函数,接下来顿时调用前期注册的early suspend驱动的resume函数,着末体系状态回到AWAKE状态.这里有个标题便是全部注册过early suspend的函数在进Suspend的第一阶段被调用可以明白,但是在resume的时间, Linux会先调用全部驱动的resume函数,而此时再调用前期注册的early suspend驱动的resume函数有什么意义呢?个人私家私家以为android的这个early suspend和late resume函数应该连合Linux下面的suspend和resume一起利用,而不是单独的利用一个行列步队来举行办理.

由于本人对Android研究的时间还不长,大概此中有些地方明白非法, 以致是错误的, 请大家体贴. 要是大家发明有疑问的地方,有兴趣也可以一起来讨论.