有機會去碰到ICS的Build system, 老大丟了兩個shell檔，看的有點霧煞煞，想說找些東西來看，順便記起來。
Android 需要sign過的application，才能夠給予適當的權限來進行管控的動作（user mode），像之前開發ota的一些東西，就必須要先sign過release key才可以得到system的權限。
Anyway，Android 主要是透過四組key來維護整個security system，分別介紹如下（下面翻譯有些也是怪怪的，有機會碰到更了解後會回頭補充）：
platform : 核心系統的key
shared:用來分享home跟contract 的process專用的key
media:如果package 需要用到media/download system(?)
releasekey:如果沒有shared 跟media的需求，這個key就是預設用來sign的key
目前上面這四個來說，我也只用過platform( for update.zip)跟releasekey(OTA apk)。
這些key就是拿來sign application，那我們一般沒有特別去指定key，build完系統後，android都是預設使用testkey來做sign的動作（path: source code root/build/target/product/security/）。一般在engineer /userdebug 階段都可以用testkey，但是testkey是不能拿來出release 成產品的，這樣是不被允許的。
2012年2月22日
2011年12月30日
Recovery console test tool in Android
在Android source code中，make的時候最後會吐出幾個img檔案，這次就是要挑recovery.img下手。
客戶提出了一個需求，那就是如果user送修的時候，如果不能進入Android OS的時候，要能夠讓service center的人能夠基本對component進行檢測的動作。所以提出了在recovery console下進行除錯的動作。
對我來說，沒有一種語言算熟的，所以我也不挑剔，反正以前到現在案子都是邊做邊學。
環境是，fastboot起來之後，可以根據HW 組合鍵來進入recovery console mode，再來就是讓服務人員進行基本的檢測。這時候Kernel已經起來了，所以基本上driver也都已經起來了，接下來就是看怎樣在console mode中去跟kernel進行溝通的動作。
使用者需求主要要滿足以下幾點：
1.Display test -這部分只要確認是否panel在顯示時有缺失（如色偏或是亮點等）
2.Pointing device (touch, mouse and pen ）-這部分比較麻煩，touch還好，因為kernel driver有實做絕對位置來跟framework溝通。但是mouse 在driver僅使用相對移動量來與上層溝通。這部分的測試項可能會將getevent的實做方式參考。
3.HW Key -這沒太大問題，kernel input已經醒來了。
4.Battery Status -這部分當初與EC溝通時，大多專案都有建立Kobject來進行溝通，所以已經有已知的attribute來使用。
5.Memory test-據老闆說，這部分只要malloc一個區塊，然後進行5(0101) A(1010)的讀寫，就算驗證？？我想眼下可能只能這樣做....
6.SD solt -SD卡插拔，可以去驗證/sdcard2是不是有被mount起來即可。
目前來說，大致上都已經確定可以做的，但是觸控以及mouse的部分必須要想辦法一些東西過來，有關係到inotify，就必須要再看一下了。
客戶提出了一個需求，那就是如果user送修的時候，如果不能進入Android OS的時候，要能夠讓service center的人能夠基本對component進行檢測的動作。所以提出了在recovery console下進行除錯的動作。
對我來說，沒有一種語言算熟的，所以我也不挑剔，反正以前到現在案子都是邊做邊學。
環境是，fastboot起來之後，可以根據HW 組合鍵來進入recovery console mode，再來就是讓服務人員進行基本的檢測。這時候Kernel已經起來了，所以基本上driver也都已經起來了，接下來就是看怎樣在console mode中去跟kernel進行溝通的動作。
使用者需求主要要滿足以下幾點：
1.Display test -這部分只要確認是否panel在顯示時有缺失（如色偏或是亮點等）
2.Pointing device (touch, mouse and pen ）-這部分比較麻煩，touch還好，因為kernel driver有實做絕對位置來跟framework溝通。但是mouse 在driver僅使用相對移動量來與上層溝通。這部分的測試項可能會將getevent的實做方式參考。
3.HW Key -這沒太大問題，kernel input已經醒來了。
4.Battery Status -這部分當初與EC溝通時，大多專案都有建立Kobject來進行溝通，所以已經有已知的attribute來使用。
5.Memory test-據老闆說，這部分只要malloc一個區塊，然後進行5(0101) A(1010)的讀寫，就算驗證？？我想眼下可能只能這樣做....
6.SD solt -SD卡插拔，可以去驗證/sdcard2是不是有被mount起來即可。
目前來說，大致上都已經確定可以做的，但是觸控以及mouse的部分必須要想辦法一些東西過來，有關係到inotify，就必須要再看一下了。
2011年12月13日
ANR issue for broadcast timeout BOOT_COMPLETED
最近有個issue已經看很多天了，目前沒有解法，還在進行實驗中。
最大問題在於大概兩三百次才會出現一次錯誤（有時候要跑六七百次），所以下一些solution不見得可以立刻得到結果，所以必須要等待結果的出現。
系統在開機的時候，會有1/300左右的機率會發生ANR，比較了正常與不正常開機之後的Log，會發現系統在發broadcast BOOT_COMPLETED 的時候，package = android應該要收到卻沒有收到。
另外，device必須要在有連上網路的狀況下才會掛掉，如果不連網路打死也不掛給你看。
timeout訊息如下：
com.android.server.BootReceiver註冊於frameworks/base/core/res/AndroidManifest.xml，而該package設定為android。
經過驗證之後，非常確定根本就沒有進到BootReceiver.onReceive()裡面，根據下面Log來看，必須要先往發送那一端來trace=>frameworks/base/service/com/android/server/am/PackageManagerService.java
比較過正常與不正常的Log之後，發現package android 的執行一定是跟在com.android.phone以後，但有發現com.android.phone有被執行完，這表示Broadcast有被發出，但是可能因為某部分而被Queue住了，最後造成timeout。
所以再往下看，根據以下Log，可以確定ActivityManagerService已經有執行到該執行的地方。
所以就要另外指向他們之間所拋出的方法，app.thread.scheduleReceiver()。其實也跟前面的Log呼應了，指向了android.app.ActivityThread。在ActivityThread中的scheduleReceiver中，將訊息導到queueOrSendMessage()，最後則是導到了Handler.sendMessage()，所以必須回到HandlerMessage()去找。
目前懷疑到這裡，正在做實驗，要看是否丟進來的MessageQueue有被delay或是lost。
這次比較久，實驗來到794次。
--12/15--
做了超多次（上千次），但可能因為Log被加入太多，所以Matt認為可能這樣已經把時序問題給往後推，所以反而問題複現不出來了。
所以Matt建議我把不需要的Log拿掉，這樣應該可以復現問題。Log下在ActivityThread.java裡的HandleMessage，而且只會看uid=1000的訊息，想看看是不是某個事件還沒被處理完，結果就過期了。
但最後實驗的結果，所有uid=1000的事件都有被done。
到目前我會認為Queue裡面有事情沒做完，所以就timeout了。code可以有多個Thread，但只會有一個Queue，所以Queue中可能在其他Thread有事情正在處理，所以被弄到time out了。
目前是這樣推斷，但我沒辦法把Queue所有的Message List出來，所以先看Log，看哪裡可以下手。目前是看到有些Handler就是在處理service，所以可能會在這些Handler下Log看是不是等太久了。
最大問題在於大概兩三百次才會出現一次錯誤（有時候要跑六七百次），所以下一些solution不見得可以立刻得到結果，所以必須要等待結果的出現。
系統在開機的時候，會有1/300左右的機率會發生ANR，比較了正常與不正常開機之後的Log，會發現系統在發broadcast BOOT_COMPLETED 的時候，package = android應該要收到卻沒有收到。
另外，device必須要在有連上網路的狀況下才會掛掉，如果不連網路打死也不掛給你看。
timeout訊息如下：
12-12 13:21:39.690 W/ActivityManager( 141): Timeout of broadcast BroadcastRecord{40b4d570 android.intent.action.BOOT_COMPLETED} - receiver=android.app.ActivityThread$ApplicationThread@40462d00, started 10000ms ago
12-12 13:21:39.690 W/ActivityManager( 141): Receiver during timeout: ResolveInfo{40af9ba8 com.android.server.BootReceiver p=0 o=0 m=0x108000}
com.android.server.BootReceiver註冊於frameworks/base/core/res/AndroidManifest.xml，而該package設定為android。
經過驗證之後，非常確定根本就沒有進到BootReceiver.onReceive()裡面，根據下面Log來看，必須要先往發送那一端來trace=>frameworks/base/service/com/android/server/am/PackageManagerService.java
12-12 13:21:29.680 V/ActivityManager( 141): Processing ordered broadcast BroadcastRecord{40b4d570 android.intent.action.BOOT_COMPLETED}
比較過正常與不正常的Log之後，發現package android 的執行一定是跟在com.android.phone以後，但有發現com.android.phone有被執行完，這表示Broadcast有被發出，但是可能因為某部分而被Queue住了，最後造成timeout。
所以再往下看，根據以下Log，可以確定ActivityManagerService已經有執行到該執行的地方。
12-12 13:21:29.690 V/ActivityManager( 141): Delivering to component ComponentInfo{android/com.android.server.BootReceiver}: BroadcastRecord{40b4d570 android.intent.action.BOOT_COMPLETED}
12-12 13:21:29.690 V/ActivityManager( 141): Process cur broadcast BroadcastRecord{40b4d570 android.intent.action.BOOT_COMPLETED} DELIVERED for app ProcessRecord{406473a0 141:system/1000}
所以就要另外指向他們之間所拋出的方法，app.thread.scheduleReceiver()。其實也跟前面的Log呼應了，指向了android.app.ActivityThread。在ActivityThread中的scheduleReceiver中，將訊息導到queueOrSendMessage()，最後則是導到了Handler.sendMessage()，所以必須回到HandlerMessage()去找。
目前懷疑到這裡，正在做實驗，要看是否丟進來的MessageQueue有被delay或是lost。
這次比較久，實驗來到794次。
--12/15--
做了超多次（上千次），但可能因為Log被加入太多，所以Matt認為可能這樣已經把時序問題給往後推，所以反而問題複現不出來了。
所以Matt建議我把不需要的Log拿掉，這樣應該可以復現問題。Log下在ActivityThread.java裡的HandleMessage，而且只會看uid=1000的訊息，想看看是不是某個事件還沒被處理完，結果就過期了。
但最後實驗的結果，所有uid=1000的事件都有被done。
到目前我會認為Queue裡面有事情沒做完，所以就timeout了。code可以有多個Thread，但只會有一個Queue，所以Queue中可能在其他Thread有事情正在處理，所以被弄到time out了。
目前是這樣推斷，但我沒辦法把Queue所有的Message List出來，所以先看Log，看哪裡可以下手。目前是看到有些Handler就是在處理service，所以可能會在這些Handler下Log看是不是等太久了。
好像該寫點東西來紀錄了
以前總很懶惰，最多就是用google bookmark來把自己看過的東西mark下來。
不過隨著時間經過，除了會忘記以前看過了什麼以外，還會忘記自己曾經做過的實驗或是下過的solution。
還有個問題就是沒人可以討論，有時候搞不好下的方法根本就有問題，最後又在鑽牛角尖。
還是把東西紀錄一下好了.....
不過隨著時間經過，除了會忘記以前看過了什麼以外，還會忘記自己曾經做過的實驗或是下過的solution。
還有個問題就是沒人可以討論，有時候搞不好下的方法根本就有問題，最後又在鑽牛角尖。
還是把東西紀錄一下好了.....
訂閱：
文章 (Atom)