那有人會問了，既然這樣那高通為什麼不預設把這些值設為related呢？其實我也有相同的疑問，我老大說如果一遇到問題就讓子系統重啟那很多bug就測不出來了，這樣做是讓有些bug更好的浮出水面。
**中有這麼一段：
if [ $((subsys_mask & 4)) == 4 ]; then
echo "related" > /sys/bus/msm_subsys/devices/subsys1/restart_level
else
echo "system" > /sys/bus/msm_subsys/devices/subsys1/restart_level
fi判斷subsys_mask和4的位運算來給subsys1賦值， 要麼賦值related，要麼賦值system。subsys_mask的值是通過呼叫這個指令碼時傳進來的引數獲得的，再就是找到呼叫這個指令碼的地方，init.qcom.rc， 原始碼位置：device/qcom/common/rootdir/etc/init.qcom.rc，這裡要說明一下，*.rc的檔案中載入的都是系統的服務，裡面的值都是寫在系統檔案裡的，比如build.prop檔案，當這些值發生改變的時候(比如進入shell模式可以setprop *** yyy來更改系統服務)，這個服務就會重新執行一遍，以載入不同的檔案屬性。
裡面有這麼一段：
# ssr setting
on property:persist.sys.ssr.restart_level=*
exec /system/bin/sh /init.qcom.ssr.sh $
這裡就是呼叫那個指令碼的地方，也就是說當property:persist.sys.ssr.restart_level這個屬性發生改變的時候就執行init.qcom.ssr.sh這個指令碼，並且把自己當引數傳給ssr_str。再回到init.qcom.ssr.sh這個指令碼檔案，ssr_str是個陣列，也就是說property:persist.sys.ssr.restart_level這個屬性可以是有多個引數的(引數之間以逗號分隔)，不同的引數給subsys_mask賦不同的值，因為我們的問題是出在subsys1，所以要讓subsys_mask & 4 == 4，就需要將property:persist.sys.ssr.restart_level的引數設為modem，就會將/sys/bus/msm_subsys/devices/subsys1/restart_level的值設為related，讓subsys1子系統在遇到處理不了的問題的時候自行後台重啟。
剩下的問題就簡單了，在系統中預先給property:persist.sys.ssr.restart_level賦值乙個modem值，那系統屬性subsys1/restart_level的值就是related了，在buildspec.mk中加上這一句：additional_build_properties += persist.sys.ssr.restart_level=$(call add2prop,$(pwv_ssr_restart_level))，pwv_ssr_restart_level是自己定義的巨集，其值就是modem，編譯，公升級軟體，驗證ok。
覺得這些問題還是挺有價值的，就記錄下來，以便以後回味。
android 系統關機，重啟
android 系統關機，重啟 1.android系統的關機，重啟 位於frameworks base core jni android os power.cpp,裡面有 static void android os power shutdown jnienv env,jobject clazz s...
android 系統關機，重啟
android 系統關機，重啟 1.android系統的關機，重啟 位於frameworks base core jni android os power.cpp,裡面有 static void android os power shutdown jnienv env,jobject clazz s...
可能造成系統自動重啟原因
購置的機器，有時會自動重啟，雖不頻繁，但也惱人，於是從網上找了這篇文章，以作參考。一 軟體 1 病毒破壞 自從有了計算機以後不久，計算機病毒也應運而生。當網路成為當今社會的資訊大動脈後，病毒的傳播更加方便，所以也時不時的干擾和破壞我們的正常工作。比 較典型的就是前一段時間對全球計算機造成嚴重破壞的 ...