在PowerManager的API文檔中，給出了一個關(guān)機(jī)/重啟接口：
成都創(chuàng)新互聯(lián)是一家集網(wǎng)站建設(shè),山陰企業(yè)網(wǎng)站建設(shè),山陰品牌網(wǎng)站建設(shè),網(wǎng)站定制,山陰網(wǎng)站建設(shè)報價,網(wǎng)絡(luò)營銷,網(wǎng)絡(luò)優(yōu)化,山陰網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競爭力?？沙浞譂M足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時我們時刻保持專業(yè)、時尚、前沿，時刻以成就客戶成長自我，堅持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實用型網(wǎng)站。
public void reboot (String reason)
對于這個接口的描述很簡單，就是幾句話。
接口的作用就是重啟設(shè)備，而且，就算重啟成功了也沒有返回值。
需要包含REBOOT權(quán)限，也就是android.permission.REBOOT
唯一參數(shù)reason代表需要的特定重啟模式，比如recovery，當(dāng)然也可以為null。
1.frameworks/base/core/java/android/os/PowerManager.java
2.frameworks/base/core/java/android/os/IPowerManager.aidl
3.frameworks/base/services/java/com/android/server/PowerManagerService.java
4.frameworks/base/services/java/com/android/server/pm/ShutdownThread.java
5.frameworks/base/services/jni/com_android_server_PowerManagerService.cpp
---------------------》
6.system/core/libcutils/android_reboot.c
7.bionic/libc/unistd/reboot.c
8.__reboot通過syscall來到內(nèi)核
9.kernel/sys.c
frameworks/base/core/java/android/os/PowerManager.java
mService為IPowerManager Binder接口服務(wù)。
frameworks/base/core/java/android/os/IPowerManager.aidl
frameworks/base/services/java/com/android/server/PowerManagerService.java
frameworks/base/services/java/com/android/server/pm/ShutdownThread.java
這里說明是需要重啟，且不是安全模式，重啟參數(shù)為傳遞下來的reason，shutdownInner的confirm參數(shù)是用來設(shè)置是否有確認(rèn)提示框的，通過reboot接口調(diào)用重啟是沒有的，為false。
重啟的實現(xiàn)在run()中，因為ShutdownThread是Thread的擴(kuò)展，所以run會自動運(yùn)行。
frameworks/base/services/java/com/android/server/pm/ShutdownThread.java
在重啟前會將重啟原因?qū)懭雜ys.shutdown.requested，如果沒有則為空，如果是安全模式還會將persist.sys.safemode置1，之后會進(jìn)行一些關(guān)機(jī)前的預(yù)處理，關(guān)閉ActivityManager以及MountService，最終調(diào)用rebootOrShutdown進(jìn)行關(guān)機(jī)操作。
如果確認(rèn)重啟，則調(diào)用PowerManagerService的lowLevelReboot函數(shù)，參數(shù)就是傳遞下來的reason，稍后分析。如果不是重啟，即mReboot=false,那就是需要關(guān)機(jī)了，在shutdown函數(shù)中就能夠知道。
frameworks/base/services/java/com/android/server/PowerManagerService.java
frameworks/base/services/jni/com_android_server_PowerManagerService.cpp
可以看到無論是關(guān)機(jī)還是重啟，都是調(diào)用android_reboot來實現(xiàn)的，只是參數(shù)不一樣而已。
system/core/libcutils/android_reboot.c
以reboot recovery為例，arg即為recovery,所在在第五步的時候會傳入ANDROID_RB_RESTART2。到了android_reboot函數(shù)中，會看到這樣的定義#ifdef RECOVERY_PRE_COMMAND，即屬于重啟前會執(zhí)行的命令，如果定義了就會執(zhí)行。
下面也是做了一些關(guān)機(jī)重啟前的預(yù)處理工作，sync()作用是將緩存中的信息寫入磁盤，以免程序異常結(jié)束導(dǎo)致文件被損壞，linux系統(tǒng)關(guān)機(jī)前會做幾次這樣的動作；而remount_ro()作用是通過調(diào)用emergency_remount()強(qiáng)制將文件系統(tǒng)掛載為只讀，不再允許任何寫入操作，同時會通過檢查/proc/mounts的設(shè)備狀態(tài)來確認(rèn)是否當(dāng)前的所有寫入工作已經(jīng)完成，這個檢查過程是阻塞操作。
接下來才是對參數(shù)的解析處理：
1）普通重啟 ANDROID_RB_RESTART， reason = RB_AUTOBOOT；
2）關(guān)機(jī) ANDROID_RB_POWEROFF， 無需reason，直接調(diào)用reboot進(jìn)行關(guān)機(jī)；
3）帶參數(shù)的特殊重啟 ANDROID_RB_RESTART2， reason 將為默認(rèn)值 -1
這里又出現(xiàn)一個#ifdef RECOVERY_PRE_COMMAND_CLEAR_REASON，如果定義了它，則無論上層傳下來的參數(shù)是什么樣的，最終都只是普通重啟而已。定義它的方式是在BoardConfig.mk中加入TARGET_RECOVERY_PRE_COMMAND_CLEAR_REASON := true，應(yīng)該有廠商會喜歡這么做的，畢竟除了普通重啟，都可能帶給用戶一定的風(fēng)險。
最后會對reason進(jìn)行一個檢測，那么通過上邊的分析，其實只有帶參數(shù)的特殊重啟才會為-1,而不等于-1的情況中有普通重啟和關(guān)機(jī)，而關(guān)機(jī)已經(jīng)自行解決了……所以，不等于-1的情況到了這里也只有普通重啟了。最終這里就是區(qū)分普通重啟與特殊重啟的地方了。這里再插入一個問題，其他的幾個cmd都是什么值呢？答案在bionic/libc/include/sys/reboot.h中：
reboot(reason) - reboot(RB_AUTOBOOT) - __reboot( LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, LINUX_REBOOT_CMD_RESTART, NULL )
__reboot通過syscall來到內(nèi)核bionic/libc/arch-arm/syscalls/__reboot.S
其被指定了一個固定的偏移量，在被調(diào)用的時候就是通過這個偏移量去內(nèi)核中尋找對應(yīng)的入口的，由此可見，內(nèi)核中一定有著相同的定義，否則將不能成功調(diào)用。內(nèi)核中對syscall偏移量的定義在內(nèi)核源碼中的arch/arm/include/asm/unistd.h，相關(guān)信息完全一致。
已經(jīng)找到了內(nèi)核中的對應(yīng)映射，那么下一步就要去找尋真正的實現(xiàn)函數(shù)了，在include/asm-generic/unistd.h中可以找到內(nèi)核對__NR_reboot的syscall函數(shù)映射，即
同時，能夠發(fā)現(xiàn)如此溫馨的一幕，內(nèi)核已經(jīng)指引我們下一步該去哪里尋找sys_reboot，即kernel/sys.c。
include/linux/syscalls.h
與__reboot的調(diào)用參數(shù)一致。
進(jìn)入sys.c文件后，并沒有找到名為sys_reboot的函數(shù)，而通過仔細(xì)查找，發(fā)現(xiàn)一個很有趣的函數(shù)，其定義為SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd, void __user *, arg)，對比__reboot的參數(shù)，能夠符合。究竟是不是這個函數(shù)？
同樣在include/linux/syscalls.h文件中，能夠找到這樣幾個定義：
而pm_power_off為空的話，就把用戶的關(guān)機(jī)命令轉(zhuǎn)換為掛起：
arch/arm/kernel/process.c
pm_power_off = msm_pm_power_off;
SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd, void __user *, arg)
這個過程是用reboot_mutex互斥鎖來進(jìn)行保護(hù)的，以保證同一時間只可能有一個解析過程，避免沖突。
bionic/libc/include/sys/reboot.h 中可以看到android定義的啟動方式
RESTART
POWER_OFF
RESTART2
對框架進(jìn)行賦值，qcom 平臺 845上已經(jīng)不是這函數(shù)，自己查找
arm_pm_restart = msm_pm_restart;
下面是qcom 實現(xiàn)，每個平臺不同
可以在跟蹤這個流程的過程中會發(fā)現(xiàn)，確實是有存在關(guān)機(jī)的相關(guān)接口的。那么關(guān)機(jī)該怎么用呢？
frameworks/base/services/java/com/android/serverBatteryService.java
重啟方式： 最后就是設(shè)定寄存器，Uboot 解析不同寄存器的值進(jìn)入不同的啟動模式
recovery 如果傳下來的字符串是recovery那么，就在RTC寄存器里設(shè)置某個特定值，當(dāng)uboot里讀取RTC寄存器的時候如果獲取了這個特定值，那就可以起recovery這個動作了。
Ref:
上面主要講到流程，在實際開發(fā)中， 主動調(diào)用系統(tǒng)開機(jī)關(guān)機(jī)如何做
(Ref: )
一. 發(fā)送系統(tǒng)廣播方式
二. 通過init.rc啟動系統(tǒng)服務(wù)來運(yùn)行sh文件
三. Runtime調(diào)用Linux-shell
四 . PowerManager reboot以及反射調(diào)用PowerManagerService shutdown
五．使用ShutdownThread （嘗試不成功，但想法覺得可行）
Intent.java位于源碼/frameworks/base/core/java/android/content/Intent.java下面
腳本方式，實際都是基于指令的
使用PowerManager 或ShutdownThread 都是基于關(guān)機(jī)流程
1、手機(jī)重啟的主要原因是系統(tǒng)問題，而內(nèi)存卡導(dǎo)致系統(tǒng)出現(xiàn)問題的概率較大。
2、除了購買品牌內(nèi)存卡之外，安裝軟件或者游戲到內(nèi)存卡上也需要注意，這里建議使用link2sd工具，該工具可以將軟件產(chǎn)生的數(shù)據(jù)文件掛載到內(nèi)存卡上，一方面可以盡量避免占用手機(jī)自帶內(nèi)存，另一方面可以避免系統(tǒng)數(shù)據(jù)錯誤而導(dǎo)致安卓系統(tǒng)問題。
3、對于已經(jīng)出現(xiàn)了手機(jī)自動重啟的問題，可以進(jìn)入手機(jī)的recovery模式，清除系統(tǒng)緩存和系統(tǒng)數(shù)據(jù)，再次重啟手機(jī)，一般的問題都可以解決。
4、進(jìn)入recovery模式之后，選擇：wipe data/factory reset 和 wipe cache partition，按下電源鍵確認(rèn)選擇。
5、等待清除系統(tǒng)數(shù)據(jù)和系統(tǒng)緩存之后，回到主菜單，選擇第一項重啟手機(jī)。
6、此時手機(jī)會有一個較長的進(jìn)入系統(tǒng)的時間，需要耐心等待，等手機(jī)進(jìn)入系統(tǒng)之后，再試試，看是否非常流暢呢
Android 系統(tǒng)重啟原因分析
重啟原因分類
1.上層造成重啟
system_server被殺
watchdog重啟
重要線程阻塞
2.kernel造成重啟
空指針
非法地址
3.kernel watchdog 造成重啟，原因不確定
內(nèi)存原因
nand驅(qū)動
重慶分公司
重慶分公司
