Saturday, February 8, 2014
Android root လုပ္တယ္ဆိုတာ မလြယ္ဘူး ဆိုေပမယ့္ သေဘာသဘာ၀နဲ႔ နည္းလမ္းကို သိသြားရင္ေတာ့ မခက္ခဲေတာ့ပါဘူး၊ ဒါေပမယ့္ Android Root လုပ္တဲ့ အခါ ျဖစ္ပ်က္သြားတဲ့ ေနာက္က Process ကေတာ့ အတိအက်သိဖို႔ ခက္ခဲသလို စိတ္၀င္စားစရာလဲ အလြန္ေကာင္း လွပါတယ္၊
Rooting အေၾကာင္းကို ေျပာမယ္ဆိုရင္ အာရံုကို ေနာက္ေစမယ့္ Flashing တို႔ Custom ROMs တို႔ WIFI ဖြင့္တာတို႔ Superuser.apk သြင္းတာတို႔ကို ခဏေမ့ထားၾကရေအာင္၊ ဖုန္းေတြကို ဘာေၾကာင့္ Root လုပ္တာလဲ၊ အဓီက အေၾကာင္းအရင္းက Android System ရဲ့ Hardware Layer အေပၚမွာရွိတဲ့ Linux Kernel ကို လိုသလို ထိန္းခ်ဳပ္လို႔ရႏိုင္မယ့္ အခြင့္အေရးရခ်င္လုိ႔ပါ၊ ဒီအခြင့္အေရးရယူႏိုင္ျခင္းကိုပဲ Root Access ရတယ္လို႔ေခၚပါတယ္၊ Root Access ရသြားရင္ Android File System ကို စိတ္ႀကိဳက္ ျပဳျပင္ႏိုင္ပါတယ္၊ Android File System ထဲမွာ အဓိက ပါ၀င္တဲ့ အလႊာ (Partitions) ၆ ခု ကိုလိုသလို အသံုးခ်ႏိုင္ရင္ Booting နဲ႔ ပက္သက္တဲ့ Process ေတြအားလံုးကိုထိန္းခ်ဳပ္ႏိုင္ သလို File System ထဲက တန္ဖိုးေတြနဲ႔ ထိန္းခ်ဳပ္မွူေတြကိုလဲ လိုသလို ျပဳျပင္ႏိုင္ပါပီ၊ ဒါတင္မကပါဘူး ကၽြန္ေတာ္တို႔ စိတ္ႀကိဳက္ SSH (Secure Share protocol) (သို႔) HTTP (Hyper Text Transfer Protocol) DHCP (Dynamic Host Configuration Protocol) (သို႔) DNS(Domain Name Server) နဲ႔ Proxy Servers ေတြကို လဲ အသံုးျပဳႏိုင္ပါပီ၊ Android System ရဲ့ လုပ္ေဆာင္မူေတြထဲက ရပ္ခ်င္သမွ်လုပ္ေဆာင္ခ်က္ေတြကိုလဲ ရပ္ထားႏိုင္တဲ့ အျပင္ Arbitrary commands ေတြလဲ အသံုးျပဳႏိုင္သြားပါတယ္၊ အျခားအျခား အျခား ေသာ အခ်က္ေတြအမ်ား အမ်ားႀကီးကိုလဲလုပ္ႏိုင္ပါေသးတယ္၊ ဒီအခ်က္ေတြက Root လုပ္ရျခင္းရဲ့ ရည္ရြယ္ခ်က္ပါ၊ ဒါကိုပဲ Rooting လုပ္တယ္လဲေခၚပါတယ္၊
ကုမၼဏီေတြက ထုတ္တဲ့ OEM Android Build ေတြက ပံုမွန္အားျဖင့္ ကၽြန္ေတာ္တို႔ကို root ေတြလို arbitary code ေတြကို သံုးခြင့္ျပဳမွာမဟုတ္ပါဘူး၊ ဆိုလိုတာကေတာ့ ကိုယ္၀ယ္ထားတဲ့ ဖုန္း ကို ကိုယ္က အကန္႔အသက္နဲ႔ ပဲသံုးခြင့္ရွိတယ္ေပါ့၊ ထုတ္လုပ္တဲ့ ကုမၼဏီေတြက မႏွစ္ၿမိဳ႕တဲ့ applications မ်ိဳး (Third party appi ေတြကိုဆိုလိုပါတယ္) ကိုေတာ့ Android ဖုန္းမွာ သံုးခြင့္ရွိမွာမဟုတ္ပါဘူး၊
ဥပမာ WiFi sharing ကိုၾကည့္ပါ၊ Cell Phone ထုတ္လုပ္သူေတြက ေငြပိုထပ္လိုခ်င္တဲ့ အတြက္ ဖုန္းေတြမွာ WiFi share လုပ္ခြင့္မေပးထားပါဘူး၊ လိုခ်င္ရင္ေတာ့ ေငြထပ္ေပးရပါတယ္၊ ဒါ့ေၾကာင့္ ဖုန္းေတြအမ်ားစုက proprietary WiFi pre-packaged ေတြနဲ႔လာတာပါ၊ လိုခ်င္ရင္ ေငြပိုေပး၀ယ္ရပီေပါ့၊ ဒီလိုေငြေပးရတဲ့ WiFi pre-packaged အစား အခမဲ့ရတဲ့ Wireless Tether ကိုသံုးလို႔ရပါတယ္၊ ဒါေပမယ့္ Root access ေတာ့ ရွိဖို႔လိုပါတယ္၊
Bootloader and Recovery
Android power စဖြင့္တာနဲ႔ အလုပ္လုပ္တဲ့ Bootloader ကုတ္က Android OS ကို RAM ထဲမွာ ၀န္တင္ပီး အလုပ္လုပ္ေစပါတယ္၊ ဒီ့ အျပင္ Bootloader ရဲ့ အျခား ထင္ရွားတဲ့ အလုပ္ႏွစ္ခုကေတာ့ Recovery System ကို RAM မွာ ၀င္တင္ပီး အလုပ္လုပ္ေစႏိုင္ျခင္းနဲ႔ ROM အသစ္ကို Flash လုပ္ႏိုင္ျခင္းပါပဲ၊ ROM အသစ္ကို Flash လုပ္တာကို Flashing လို႔ေခၚပါတယ္၊
Arbitrary ROMs ကို Flash လုပ္ ႏိုင္တဲ့ Bootloader ကို lock ပြင့္ သြားတဲ့ Bootloader လို႔ေခၚပါတယ္၊ ဒါေပမယ့္ Bootloader ေတြအားလံုးကေတာ့ lock ပြင့္ေနမွာ မဟုတ္ပါဘူး၊ ကုမၼဏီတိုင္းက သူတို႔စိတ္ႀကိဳက္ထိန္းခ်ဳပ္ထားတဲ့ software ထိန္းခ်ဳပ္မွဴေတြေအာက္မွာ ပဲ သူတို႔ ဖုန္း အသံုးျပဳသူေတြကိုရွိေစခ်င္ပါတယ္၊ ဒါ့ေၾကာင့္လဲ Software ထိန္းခ်ဳပ္မွဴေတြကို ကန္႔သက္မဲ့ ပယ္ဖ်က္ႏိုင္တဲ့ Root access ရမယ့္ လမ္းေၾကာင္းျဖစ္တဲ့ Booloader ကို Locked ခ်ပီး ဖုန္းေတြကို ေရာင္းၾကတယ္၊ Bootloader သာလွ်င္ Custom ROMs ကို Flash လုပ္ႏိုင္မွာ ျဖစ္တဲ့ အတြက္ Bootloader ကို ေလာ့ခ္(locked) ခ်ထားမွေတာ့ Custom ROMs ထည့္သြင္းလို႔မရဘူးေပါ့၊ ဒါ့ေၾကာင့္ပဲ အသံုးျပဳသူေတြက Stock ROMs အစား ထိန္းခ်ဳပ္မွဴကင္းမဲ့တဲ့ Custom ROMs ကို ထည့္သံုးဖို႔ နည္းမ်ိဳးစံုနဲ႔ Hack ဖို႔ႀကိဳးစားၾကပါတယ္၊
တစ္ခ်ိဳ႕ဖုန္းေတြၾကေတာ့လဲ လြယ္ပါ ကီးေလး ႏွစ္ခု (သို႔) သံုးခုေလာက္ေပါင္းႏွိပ္ပီး ဖုန္းကို ကြန္ျပဴတာနဲ႔ခ်ိတ္ ႀကိဳက္တဲ့ Custom ROMs ကို Flash လုပ္လိုက္ရံုပါပဲ၊ တစ္ခ်ဳိ႕ ဖုန္းမ်ားၾကေတာ့လဲ Bootloader က nvflash ရဲ့ က႑အထိ လိုက္ထိန္းခ်ဳပ္ထားတယ္ဗ်ာ SBK လို႔ေခၚတဲ့ Secure Boot Key ကိုသိမွ lock ဖြင့္လို႔ရတယ္တဲ့၊ SBK ဆိုတာ ဖုန္းတစ္လံုးနဲ႔ တစ္လံုး မတူတဲ့ AES key (Advanced Encryption Standard) ေတြကို သံုးပီး Bootloader ကို encrypt လုပ္ထားတဲ့ Command ေတြေပးပို႔တယ္၊ အဲ့ဒီ့ command ေတြကို Bootloader က decrypte လုပ္ပီးလက္ခံတယ္စစ္တယ္၊ စစ္တာမွန္မွ အလုပ္လုပ္တယ္
အခု System recovery အေၾကာင္းကိုေျပာရေအာင္၊ System recovery ဆိုတာကေတာ့ Bootloader နဲ႔ System တို႔ပီးရင္ Android File System ရဲ့ တတိယ ေနရာျဖစ္တဲ့ Recovery မွာတသီးပုဂၢလ အလႊာ (partition) မွာရွိမယ့္ low-level ကုတ္ေတြကို ညြန္းတာပါ၊ (ခုက စိတ္ကူးနဲ႔ ေျပာေနသလိုျဖစ္ေနလို႔ မိတ္ေဆြတို႔ နားလည္ရခက္မယ္ မပူနဲ႔ နက္ျဖန္ ကၽြန္ေတာ္ Android File System ကို ပံု နဲ႔ အေသးစိတ္ ရွင္းျပမယ္)၊ Volumn Key တို႔ Power Key တို႔ကို သက္ဆိုင္ရာ ဖုန္းအလိုက္ တြဲႏွိပ္ပီး System Recovery ကို ေခၚႏိုင္ပါတယ္၊ System Recovery က low-level ကုတ္ေတြျဖစ္ပီး Linux နဲ႔ Android Userland တို႔နဲ႔ လံု၀ ကင္းလြတ္စြာ ရပ္တည္ႏိုင္တဲ့ Primitive OS တစ္ခုျဖစ္ပါတယ္၊ root access ေတြဘာေတြမရွိဘူး၊ Stock System Recovery အလုပ္လုပ္တဲ့ အခါမွာ ထုတ္လုပ္တဲ့ ကုမၼဏီေပၚမူတည္ပီး ကြဲျပားမွဴေတြရွိပါတယ္၊ ပံုမွန္အားျဖင့္ေတာ့ File System ထဲက data အလႊာကို ကို Format ခ်မယ္၊ extrenal microSD Card ထဲက Zip ဖိုင္ကိုေျဖပီး ROM ကို Update လုပ္မယ္၊ ဒီမွာ Custom ROMs ထည့္သံုးဖို႔ လမ္းေၾကာင္း အသစ္ေတြ႔ပီဆိုပီး ေပ်ာ္မသြားပါနဲ႔ အံုး Upadate လုပ္တဲ့ ROM က ထုတ္လုပ္တဲ့ ကုမၼဏီရဲ့ အထူး သတ္မွတ္ခ်က္ပါတယ္ (signature ပါတာကို ဆိုလိုပါတယ္) ၊ ဒီေတာ့ System Recover လုပ္ပီဆိုတာနဲ႔ Stock ROM ကို Update လုပ္တယ္၊ အလႊာ ၆ ခုမွာပါတဲ့ system အလႊာ , Data အလႊာ , Cache အလႊာ , Misc (miscellaneous system) အလႊာေတြကို ျပန္ပီးသိုေလွာင္ပါတယ္၊ ျပန္ျဖည့္တဲ့သေဘာပါ ClockworkMod Recovery ကေတာ့ third-party recovery image ကိုသံုးပီး Arbitary ROMs ကို Flash ျခင္း backup လုပ္ျခင္း partitions (အလႊာ) ျပန္တည္ေဆက္ျခင္း ေတြလုပ္ရာမွာ နာမည္ႀကီးပါတယ္၊ (ClockworkMod Recovery အေၾကာင္းေနာက္ပိုင္းမွ အေသးစိတ္လာမယ္)၊
ADB ကို Android နဲ႔ ကြန္ျပဴတာခ်ိတ္ဆက္ပီး အခ်ိဳ႕ အလုပ္ေတြအတြက္ အသံုးျပဳပါတယ္၊ ဒီအလုပ္အခ်ိဳ႕ထဲက အသံုးမ်ားတဲ့တစ္ခုကေတာ့ ADB Shell Command ကိုသံုးပီး Android Phone ေပၚမွာ Shell ကို ေပၚေစတာပါပဲ၊
Shell process အလုပ္လုပ္ေအာင္ ဘယ္လို commands ကို user ကအသံုးျပဳလဲ၊ ဒီေနရာမွာ ro.secure လို႔ေခၚတဲ့ Android System property တန္ဖိုးက အေရးႀကီးလာပါတယ္၊ (Android System property တန္ဖိုး ကို ADB shell က တဆင့္ getprop ro.secure လို႔ ရိုက္ထည့္ပီးျဖစ္ေစ၊ ဖုန္းရဲ့ terminal emuloator မွာ ရိုက္ထည့္ပီးျဖစ္ေစရွာႏိုင္ပါတယ္၊ အကယ္၍ ro.secure=0 ဆိုတဲ့ တန္ဖိုးရရင္ေတာ့ ADB shell က ေရးတဲ့ commands ေတြကို root user အေနနဲ႔ ဖုန္းမွာ Run ေပးပါလိမ့္မယ္၊ ဒါမွမဟုတ္ပဲ ro.secure=1 ဆိုရင္ေတာ့ ADB shell က ေရးတဲ့ commands ေတြကို unprivileged user အေနနဲ႔ ဖုန္းမွာ Run ေပးပါလိမ့္မယ္၊ အကယ္၍ ro.secure=0 ေတြပဲ အျမဲ ေတြ႔ေနရရင္ေတာ့ အိုေက ပီေပါ့ဗ်ာ ဒါေပမယ့္ ဒီေလာက္ေတာ့ ဘယ္လြယ္ပါ့မလဲ stock OEM ေတြမွာ ro.secure=1 ပဲ ေတြ႔ရမွာပါ၊ ကိုယ့္ဘာကိုေျပာင္းဖို႔ေတာ့ မေတြးပါနဲ႔ဗ်ာ ဒီေလာက္လဲ မလြယ္ဘူးေလ၊ ဒီတန္ဖိုးကို boot time စမွတ္ကတည္းက root directory ထဲ႕ default.prop ဖိုင္ထဲမွာ သတ္မွတ္ထားတာ၊ ဒီ root directory ဆိုတာကလဲ internal storage ရဲ့ boot ထဲက ေကာင္ပီကူးယူထားတာဗ်ာ၊ ဒါေပမ.့္ partition ထဲမွာေတာ့ root မလုပ္ရေသးဘူးဆိုရင္ ၀င္ေရးႏိုင္တယ္၊ ေျပာခ်င္တာက ADB ကေန တန္ဖိုးေျပာင္းတာကို လက္မခံရင္ Boot မစတင္ကတည္းက Root access ျဖစ္ေအာင္ လုပ္ထားဖို႔လိုတာေပါ့၊ ဒါေပမယ့္ ဒီ့ အတြက္လံုးျခံဳေရးကလဲ ရွယ္ေက်ာ္ျဖတ္ဖို႔လိုပါတယ္၊
Android UI
privileged user ဆိုတာက Root access နဲ႔ Run ေနတဲ့ program မွန္သမွ်ကိုေခၚတယ္၊ Unprivileged_user ကေတာ့ Root access နဲ႔ Run တာမဟုတ္တဲ့ program ေတြကိုေခၚတယ္၊
Android System မွာ ကၽြန္ေတာ္တို႔ Run သမွ် အလုပ္လုပ္ေနတာ ျမင္ရသမွ် ေရး ထိ အသံုးျပဳႏိုင္သမွ် Applications ေတြအားလံုးက un_privileged user အေနနဲ႔ Sandboxes ထဲမွာ Run ေနတာပါ၊ ေျပာခ်င္တာက ကၽြန္ေတာ္တို႔ Run ေနတဲ့ Unprivileged Program ေတြက privileged Program ေတြကို အလုပ္မခိုင္းႏိုင္ဘူး စတင္အလုပ္လုပ္ေအာင္ မေခၚႏိုင္ဘူးေပါ့ (ဥပမာ privileged function တစ္ခုကို un_privileged app ထဲက function တစ္ခု က စတင္ေစလို႔မရဘူးေပါ့၊ ဒီလို un_privileged app ထဲက function က privileged function တစ္ခုကို ေခၚႏိုင္ရင္ျဖင့္ လိုခ်င္တာ အားလံုးျဖစ္ပီေပါ့ဗ်ာ၊ ေနာက္တစ္ခ်က္က root access န႔ဲ run ေနတဲ့ privileged function တစ္ခုက အျခား program တစ္ခုကို root access အေနနဲ႔ေကာ unprivileged user အေနနဲ႔ ပါလွမ္းေခၚသံုးႏိုင္တယ္၊ Linux မွာေတာ့ privilege escalation ေတြကို su နဲ႔ sudo program ေတြကတစ္ဆင့္ ေခၚတယ္၊ su နဲ႔ sudo တို႔က setuid(0) လို႔ေခၚတဲ့ system ကို Run ေစႏိုင္တဲ့ programs ေတြပါ၊ setuid(0) System က အလုပ္လုပ္ေနတဲ့ program တစ္ခုကို unprivileged user အဆင့္ကေန root access နဲ႔ ေျပာင္းပီး Run ခိုင္းႏိုင္ပါတယ္၊ ကၽြန္ေတာ္တို႔ ျမင္ေတြ႔ေနရတဲ့ root access လိုတယ္ဆိုတဲ့ Applications ေတြက တကယ္ေတာ့ အျခား binaries package ပါ၀င္တဲ့ program ေတြကို su က တဆင့္ ေခၚပီး သံုးဖို႔လိုလို႔ပါ၊ Stock OEM ROMs ေတြက ဘယ္ေတာ့မွ su မပါလာပါဘူး၊ su က ေဒါင္းလုပ္လုပ္လို႔လဲမရဘူး ေကာ္ပီကူးယူလဲ မရဘူးေလ၊ su ကိုသံုးဖို႔ အတြက္ SUID bit set ရွိဖို႔လိုတယ္၊ SUID bit set က privilege root access နဲ႔ Run ခြင့္ရွိတဲ့ Program ေတြကိုညြန္ျပတယ္၊ root access မရွိရင္ SUID bit ကို လဲ program တစ္ခုကို root access နဲ႔ Run ေစဖို႔ ညြန္ျပႏိုင္ေအာင္မလုပ္ႏိုင္ပါဘူး၊
ဒီေတာ့ Android ထိေတြ႔ အသံုးျပဳလို႔ရသမွ် unprivilege user application ေတြက privileged access ကို မရႏိုင္ဘူး (သို႔) privileged mode နဲ႔ အလုပ္မလုပ္ႏိုင္ဘူး၊ privileged mode နဲ႔ Run ေနတဲ့ အျခား Program တစ္ခုကိုလဲ စတင္ေအာင္ေခၚလို႔မရဘူး၊ Android System (lift circle) တစ္ခုလံုးေတာင္မွာ တကယ္ေတာ့ privilege escalation attempts နဲ႔ အလုပ္လုပ္ေနတာမဟုတ္ပါဘူး၊
Hacking the system
ဒါဆို Android ဖုန္းကို ဘယ္လို Root လုပ္မလဲ၊ အထက္က လံုျခံဳေရး အတြက္သံုးတဲ့ ဗ်ဴဟာေတြကိုသေဘာေပါက္သြားပီဆိုရင္ျဖင့္ လံုျခံဳေရးဗ်ဴဟာမွာ အသက္သြင္းထားတဲ့ Component တစ္ခုစီကို တန္ျပန္တိုက္ခိုက္ႏိုင္ပါပီ၊ ဥပမာ Samsung Phone က Blootloader ကို Flash လုပ္ခြင့္ျပဳတယ္ဆိုတယ္ဆိုပါေတာ့ ဒါဆိုရင္ လိုအပ္တဲ့ တစ္ေယာက္က Stock ROM ကို ဖုန္းရဲ့ disk drive ကေနပီး ကူး sudo ထည့္ Modified လုပ္မယ့္ ROM ထဲကို package အျဖစ္ ျပန္တည္ေဆာက္ ဖုန္းကို ့Hardware keys ေပါင္းႏွိပ္ပီး Flash Mode ကေန ၀င္ ပီး Modified ROM ကို flash လုပ္လိုက္၊ အကယ္၍ ro.secure ကို 1 မေပးထားရင္ျဖင့္ root လုပ္ရတာ ပိုေတာင္လြယ္တယ္၊ ဖုန္းကို Computer နဲ႔ ခ်ိတ္ ADB ကို run ဒါဆိုရင္ ဘယ္ program ကိုမဆို Root access လို႔ run ေပးႏိုင္တဲ့ shell ရပီ၊ ဒီေတာ့ /system ကို readwrite access ျဖစ္ေအာင္ ေျပာင္း su ကို install လုပ္ ပီးပီ၊
ဒါေပမသည့္ Android သံုး Devices ေတြအားလံုက အထက္က ေျပာသေလာက္ေတာ့မလြယ္ဘူး၊ bootloader ကို locked ခ်ထားတယ္ ro.secure ကိုလဲ set ထားတယ္၊ ဒါ့ေၾကာင့္ unprivileged program ေတြနဲ႔သာလွ်င္ ဆက္သြယ္ အသံုးျပဳႏိုင္တယ္၊ privileged ျဖစ္မယ့္ ကုတ္ေတြေတာ့ Run လို႔မရဘူး၊ ဒါဆို ဘယ္လိုလုပ္မလဲ၊
အေရးႀကီးတဲ့ program မွန္သမွ်က Hardware ေတြနဲ႔ တိုက္ရိုက္ ခ်ိတ္ဆက္ပီး ခိုင္းေစဖို႔ အတြက္ root access အေနနဲ႔ Run ရပါတယ္၊ ဒီေတာ့ Hardware ေတြနဲ႔ တိုက္ရိုက္ဆက္သြယ္ႏိုင္တဲ့ low-level System service ေတြကိုေတာ့ Root Access အျမဲ ဖြင့္ေပးထားရတယ္၊ ဒါက ဘယ္ ဖုန္း ဘယ္ ကြန္ျပဴတာမဆုိ ပါ၊
မေန႔က ေဆာင္းပါးမွာ Linux Tag က linux kernel image ကို RAM ေပၚမွာ ၀င္တင္ပီးေတာ့ Kernel စတင္အလုပ္လုပ္တာနဲ႔ System File ထဲက 'init' ဖိုင္ကိုရွာပီး System စတင္ဖို႔အတြက္ root process ကိုစတင္တယ္၊ ဒီမွာ Root Process ဆိုတာကိုမိတ္ေဆြတို႔ေတြ႔ရမယ္၊ init က သူ႔ထဲက functions ေတြကို စတင္အလုပ္လုပ္ေစမယ္၊ Kernel ရဲ့ init ဖိုင္ကို Run တဲ့ အခါ privileged process ျဖစ္ဖို႔အတြက္ Root Access နဲ႔ Run ရတယ္၊ ဒီအခ်က္ကို အေျခခံပီးေတာ့ one-clickroot တို႔ z4root တို႔ ကို လုပ္ထားတာပါ၊ System process က root access အေနနဲ႔ Arbitary code ကို Run ေနတဲ့ အခါမွာ ထိုးေဖာက္၀င္ေရာက္ႏိုင္တဲ့ လမ္းစေပၚလာပါတယ္၊ အေၾကာင္းက Arbitary code က system စတင္ဖို႔ အတြက္ read-write mode နဲ႔ su ကို install လုပ္ထားတဲ့ ကုတ္ျဖစ္လို႔ပါ၊ Android က Linux လို Open Source ျဖစ္တဲ့ အတြက္ မ်ားစု က System Services ေတြအားလံုးထဲက လံုးျခံဳေရးကို ၀င္ပီး ျဖတ္ႏိုင္မယ့္ ထိုးေဖာက္ႏိုင္မယ့္ လမ္းကို ရွာၾကပါတယ္၊ လမ္းေၾကာင္းရွာေတြ႔သြားလဲ မလြယ္ပါဘူး Google နဲ႔ သက္ဆိုင္ရာ အဖြဲ႔ေတြက မနည္းရွာထားရတဲ့ လမ္းေၾကာင္းကို ေပါက္ပီလို႔ၾကားတာနဲ႔ လိုက္လိုက္ပိတ္ပစ္တာေလ၊ ဒီေတာ့ Version အသစ္ထြက္တိုင္း လံုျခံဳေရးေတြပိုေကာင္းလာတာေပါ့၊ အရင္ရထားတဲ့ လမ္းေၾကာင္းေလးေတြပိတ္ပိတ္သြားတာေပါ့၊ ဒါေပသည့္ OTA Update ကိုေတာ့ ပိတ္လိုက္ရေအာင္ Google အပါအ၀င္ အျခား Android ထုတ္လုပ္သူေတြက မေၾကာင္ၾကေသးပါဘူး သူတို႔လဲ အဲ့ဒီ့ေလာက္ေတာ့ ေငြမေပါဘူးေလ၊ ဒီေတာ့ကာ အသစ္ထြက္လာတိုင္းလံုျခံဳေရး အဆင့္ပိုျမင့္လာမယ္၊ ထိုးေဖာက္ထဲ သူေတြကလဲ rooting လုပ္ဖို႔ ရရာ နည္းလမ္ကို အစြမ္းကုန္ရွာၾကမယ္ေပါ့၊
low-level Programming ေလ့လာဖူးသူေတြအေနနဲ႔ Kernel ရဲ့ init ဖိုင္ကို ေသခ်ာ ေမႊေနာက္ၾကည့္ရင္ေကာ..............................
Android ဖုန္းလို႔ေျပာေပးမယ့္ Android သံုးသမွ် အျခား Devices (ပစၥည္းေတြ) အားလံုးကို ညြန္းပါတယ္၊
ေၾကာ္ျငာမ်ား ၀င္ေရာက္ၾကည္႔ရႈေပးျခင္းျဖင့္ ကူညီပါ။
