關於失敗

「失敗的人是最沒有資格痛哭的」如果哭只是要博取同情，就省省吧

只有在苦盡甘來，走過失敗，回首過去那段辛苦的日子，才允許那些許的辛酸感

走過之後哭才是有意義的

從無到有到負到零，最辛苦的是沒人可以去宣洩那個壓力，生活一切正常

正常吃、正常睡、正常笑、正常工作、正常玩，只為了維持正常

我相信，雨過終會天晴，只要自己不放棄自己

Ext3 support for Froyo in recovery

某個案子把 nand flash 改成 eMMC，同時檔案系統也改採用 ext3 取代原本的 ext2

本來一切都很美好，直到發現在 Recovery mode 裡選用 --wipe_data 清空 /data 和 /cache 後

系統無法正常開機，或者應該說無法順利的 mount /data 及 /cache

奇怪的是，Froyo 的 recovery 本就支援 ext3，畢竟 ext3 只比 ext2 多了 journaling

但是，問題就是存在，花了一些時間去追，發現如果手動將 /cache 以 ext2 掛上是沒問題的

所以，問題應該是出在建 journal 時發生錯誤，為了證明這個想法，把 e2fsprogs 移植到系統上

接著利用 dumpe2fs 檢查被 recovery 過後的 device，結果跟猜想的一樣，現在比較麻煩的是

Recovery 在格式化的過程中完全沒有錯誤訊息，也找不到建 journal 的文件

最後，直接從 e2fsprogs 裡面去挖 code，把相關的程式碼弄成函式庫，再讓 Recovery 去連結

Done

android - cts

cts - compatibility test suite

簡單說就是一堆 test cases 的集合，Android 為了確保出貨的產品可以提供使用者一致性

如果要和 Google 簽合約拿到 GMS，那麼勢必 cts 的測試結果必須是 100%

cts 你可以從網路上抓 google release 的，你也可以自己從 source 去編譯產生

這是我前陣子在弄的，結果還不錯，扣除兩個因為硬體 GPS 拉賽所造成的 failed，其他都過了

幾個重點:

首先遇到錯誤時，請先 google 該錯誤的 test item，android 的每個發行版是一直持續再更新的

包含 cts，這些更新有時候是為了解決系統上的安全漏洞，當然，cts 一定會有對應的測項

檢測你目前的 source code 是否已經更新了某些 critical issue [1]，這種狀況，你可以很快的解決

再來，每個 Failed 都有錯誤訊息，也會告訴我們是 test case 的哪一行程式碼產生的

有時候，光是錯誤訊息你就可以直接知道問題點，另外，請善用 test case

test case 不只是拿來讓我們 monkey try 的，我們還可以去嘗試修改它，讓它可以提供更多的資訊

個人經驗，只是去追 test case 的程式碼，就知道失敗的 root cause 了

最後的最後，真的就只能很深入的追下去，很幸運的，常常解了一個問題後，連帶會一起解決其他的問題