一、 總結
1. tombstones log的分析2012-06-04
附件是一個tombstones log的分析工具，具體使用方法如下：
1．將panic1.py拷貝到編譯服務器上的driod目錄下；
2．運行soucebuild/envsetup.sh設置好環境變量；
3．將tongstone log中的如下部分單獨拷貝到一個文件中，例如lll.txt
#00 pc 001a280c /system/lib/libwebcore.so
#01 pc 001a185c /system/lib/libwebcore.so
#02 pc 001a2e46 /system/lib/libwebcore.so
#03 pc 001a727a /system/lib/libwebcore.so
#04 pc 001a72f6 /system/lib/libwebcore.so
#05 pc 00011ef4 /system/lib/libdvm.so
4．運行腳本panic1.py lll.txt，即可看到相應的call stack；
需要注意的是：你必須編譯debug版本的system.img。
lirayi@localhost:~/m8665mo/trunk/droid$sourcebuild/envsetup.sh
includingdevice/htc/passion/vendorsetup.sh
includingdevice/qcom/common/vendorsetup.sh
includingdevice/samsung/crespo/vendorsetup.sh
lirayi@localhost:~/m8665mo/trunk/droid$./panic1.pylll.txt
read file ok
CachedNode.h:114 android::CachedNode::clearCursor(android::CachedFrame*)
CachedFrame.cpp:138 android::CachedFrame::clearCursor()
CachedRoot.cpp:1386 android::CachedRoot::setCursor(android::CachedFrame*, android::CachedNode*)
WebView.cpp:885 android::WebView::motionUp(int, int, int)
WebView.cpp:1678 android::nativeMotionUp(_JNIEnv*, _jobject*, int, int, int)
CallEABI.S:243 dvmPlatformInvoke
2. media縮略圖問題 2012-06-06
有些設備的ROM,mediastore的數據庫可能沒有提供thumbnails，這樣會造成其他設備訪問時，ArcSoftDMS在解圖CPU佔用率過高
經測試，當前ArgonSpins的mediastore的沒有photo thumbnails，但是TinBoost的mediastore是好的，請幫忙調查（argonspin測試設備使用的rom爲ARGONS_4_07.15.11RDS）
Tinboost以及argonspin的thumbnail文件夾的路徑是如下
/mnt/sdcard/DCIM/.thumbnails
argonspin在以下兩個版本查看，發現沒有生成thumbnail文件夾。
ARGONS_4_07.15.11RDS_flex_LATAM_CLALA_v5_0423.sbf
ARGONS_4_07.19.16RDS_flex_LATAM_Claro_LATAM_v12_0525_CELLONAPR.sbf
這個早期的版本也是沒有的。ARGONS_4_02.0D.11RDD_flex_PRC_Retail_v5_0217.sbf
Tinboost在以下版本查看，發現有生成thumbnail文件夾。這是一個比較舊的版本。
TNBST_4.02.19.0brps
Tinboost在以下版本查看，發現並沒有生成thumbnail文件夾。這是個比較新的版本。
TNBST_4_0A.1F.3DRPS
需要幫忙調查下爲什麼mediastore沒有生成thumbnail。
Photo以及video會生成thumbail，但是audio不會生成thumnail。
需要再去看看audio不會生成thumnail的原因，查清我們代碼有沒實現。若沒實現，簡單評估下實現該功能的思路以及工作量。
在tinboost上面，發現會在/mnt/sdcard/Android/data/com.android.providers.media/albumthumbs/下生成文件名是數字的文件，文件大小非0，且是概率性出現的。該文件打開就是亂碼，其實這是否就是audio專輯圖片縮略圖的數據，類似編碼後的圖片數據嗎？
在argon spin上，也曾試過在/mnt/sdcard/Android/data/com.android.providers.media/albumthumbs/下生成文件名是數字的文件，文件大小卻是0。
在argon spin上，暫未發現生成audio的thumbnail的代碼，下一步可以對比下tinboost相關代碼。
在可以正常拿到audiothumbnail的設備上測試，在這個目錄下生成的文件如圖所示，爲非0的文件，以數字命名
而在將此文件加後綴名jpg後，是可以用看圖工具打開的，但是這個應該只是一般規則，具體要根據實際設備上的代碼實現來確定
確認結果：
經過確認，在ARGONS_4_07.19.16RDS_flex_LATAM_Claro_LATAM_v12_0525_CELLONAPR.rar進行測試，photo和video會生成thumbnail。
測試描述：
在ARGONS_4_07.19.16RDS_flex_LATAM_Claro_LATAM_v12_0525_CELLONAPR.rar進行測試，拍照增加圖片、視頻，filemanager中對圖片視頻進行刪除操作，通過adb放入手機圖片視頻，格式化SD卡再增加圖片視頻等操作，次數爲30+次，photo以及video均會生成thumbnail。只是在filemanager中刪除圖片或是視頻文件時，會概率性存在該圖片或視頻刪除了，縮略圖仍未刪除的情況。
mediastore的thumbnail數據庫，含有thumbnails,videothumbnails和album_art三個表用來存放thumbnail的信息，實際的thumbnail文件保存在SDcard上面（/mnt/sdcard/DCIM/.thumbnails/目錄下放photo和video的，/mnt/sdcard/Android/data/com.android.providers.media/albumthumbs/下面放audio的album）
6090改出的問題，一個判斷條件弄錯。
3. APR問題_20120605_gallery 2012-06-07
atcom.cooliris.media.MediaFeed.shutdown(MediaFeed.java:~107)
- waiting to lock<0x407b3600> (a java.util.ArrayList) held by threadid=18 (MediaSets)
atcom.cooliris.media.GridLayer.shutdown(GridLayer.java:229)
atcom.cooliris.media.Gallery.onDestroy(Gallery.java:295)
atandroid.app.ActivityThread.performDestroyActivity(ActivityThread.java:2665)
atandroid.app.ActivityThread.handleDestroyActivity(ActivityThread.java:2696)
atandroid.app.ActivityThread.access$2100(ActivityThread.java:117)
atandroid.app.ActivityThread$H.handleMessage(ActivityThread.java:964)
atandroid.os.Handler.dispatchMessage(Handler.java:99)
atandroid.os.Looper.loop(Looper.java:179)
atandroid.app.ActivityThread.main(ActivityThread.java:3689)
atjava.lang.reflect.Method.invokeNative(Native Method)
atjava.lang.reflect.Method.invoke(Method.java:507)
atcom.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:875)
atcom.android.internal.os.ZygoteInit.main(ZygoteInit.java:633)
atdalvik.system.NativeStart.main(Native Method)
初步分析，認爲是某個對mMediaSets的同步塊出現sleep或是無終止執行，導致死鎖問題。可以在有mMediaSets的地方打印，看哪裏調用的比較耗時。
在mediafeed這個文件中，每個同步mMediaSets的地方都打印出執行這個塊的時間。如下：
然後讓測試去反覆操作使得可以走過那些有這些同步塊的地方。最後看看執行哪個塊佔用時間長。
自己的測試結果：
Rom：ARGONS_4_07.1A.13RDS_flex_LATAM_Claro_LATAM_v13_0530_CELLONAPR.sbf
次數：30+
其他預置環境：SD卡內有200+張圖片，10+個視頻文件。
出現lock的shutdown的同步塊最長試過1046ms的等待時間，然後每個同步塊（包括該shutdown同步塊）執行時間一般小於1ms,等待時間也是如此，可以說總體需時很短。
測試方法，發佈如下：
1） 將附件apk安裝在機器上，保證測試時不重啓手機，重啓的話需要重新安裝。
安裝命令： adb install -r[gallery3D.apk存放路徑]
2） 保證SD卡內有1000+個圖片文件，100+個視頻文件。
3） 用adb命令打印log。
adb logcat>gallery_lock.log
4） 進行如下操作
1>進入gallery。
2>多次操作，多選刪除圖片，或者可以多選刪除多個相冊，或者可以進入某個相冊然後多選相片進行刪除。
3>退出gallery。
4>重複。儘量重複多次，100+次。
此爲一組測試。Rom使用最新的三個不同版本測試，各測試一組，共三組。
5） 退出adblogcat命令。Log文件保存下來。
測試結束後，麻煩測試人員提供以下信息：
1） 每組的log文件。
2） 每組的rom信息。
3） 測試中碰到的異常，有的話就截圖。
結果如下：
在mediafeed.shutdown出現waiting for lock問題，推測現象是凍屏現象。
壓力測試結果如下：
ARGONS_4_07.1A.13RDS_flex_LATAM_Claro_LATAM_v13_0530_CELLONAPR.sbf
在mediafeed.shutdown的同步塊中，最長測得1046ms的等待時間。
ARGONS_4_07.1A.11RDS_flex_LATAM_Retail_AR_v11_0529_CELLONAPR.sbf
在mediafeed.Refresh的同步塊中，最長測得2472ms的等待時間。
ARGONS_4_07.1A.11RDS_flex_LATAM_Movistar_AR_v11_0529_CELLONAPR.sbf
在mediafeed.Refresh的同步塊中，最長測得2295ms的等待時間。
每個同步塊（包括該shutdown同步塊）執行時間一般小於1ms，等待時間也是如此，可以說總體需時很短，只是在有時會等待時間過長，但是不會出現waiting forlock問題，因爲未能出現凍屏現象，因此現象不能復現。同時無exception。另外不能知道等待時間長時是哪一塊線程訪問該臨界區變量。
Monkeytest結果如下：
用以下三個版本測，
ARGONS_4_07.1B.11RDS_flex_LATAM_Claro_LATAM_v16_0606_CELLONAPR.sbf
ARGONS_4_07.19.16RDS_flex_LATAM_Claro_LATAM_v12_0525_CELLONAPR.sbf
ARGONS_4_07.1A.13RDS_flex_LATAM_Claro_LATAM_v13_0530_CELLONAPR.sbf
跑了三個晚上，未出現凍屏現象，同時無exception，未能復現。
綜上，未能復現。
4. Monkeytest_20120704問題2012-07-04
private void showToast(final String string, final int duration, finalboolean centered) {
if (mContext != null && !App.get(mContext).isPaused()) {
App.get(mContext).getHandler().post(new Runnable() {
分析結果：
在App.get返回的app對象是null。進一步跟進得出根據context查詢hashmap，查詢不到該context記錄。尚未了解不能成功查詢到該記錄的原因。
Mediafeed.showToast在gallery3D中用於顯示toast信息，本人尚未碰到該現象，估計復現概率較低，有待進一步跟進。
5. [Gallery] The deletedpictures/video still lists in gallery . SMPCQ00009711 Level B 2012-07-03
描述：
在filemanager中刪除圖片後，保證gallery不是掛起後臺的情況下進入，就一切正常。否則，不正常，需要重新進入gallery才正常。
分析：
1）現在需要嘗試能否完全解決該問題。
2）理清cacheservice中相關流程。
updateNumExpectedItems中mNumExpectedItems取值，關係到最終顯示在界面的相冊照片張數值。需要確認該值獲取的正確流程。
3）
MediaFeed.run分析，數據庫已經更新了，懷疑與更新mediaset有關係。需要繼續分析MediaFeed.run。
4）對比DLNA應用。
同樣操作，DLNA會表現正常，不管是否有掛起DLNA應用。
5）
Mediaset中保存的mediaitem數組mItem中，被刪除文件的mFlagForDelete沒有被設置爲true，導致在mediaset中沒有被刪除，這樣就導致在更新相冊的標籤時出錯。（相片張數不對）可以從這裏入手尋找roorcause。
6）
對mFlagForDelete的操作有兩個函數，如下。
Mediaset.refresh
Mediaset.additem
對於第二種情況。發現Mediaset.additem會對傳入的mediaitem的mFlagForDelete設置爲false，也即是不要刪除。Cacheservice.loadMediaItemsIntoMediaFeed中，
byte[] albumData = sAlbumCache.get(set.mId, 0);
獲取存在問題，看看是否存在異步操作以及看看該獲取的函數調用流程。
6.1）
獲取數字值正確，但是在顯示出現問題。
6.2）
需要跟蹤每次對應mediaset的操作，看看cache文件的變化。
Cacheservice. loadMediaItemsIntoMediaFeed中，
在syncCache中會對所有的mediaset進行更新，包括mediaset裏面的mediaitem。然後AlbumData是根據傳入的mediaset獲取對應的mediaset數據。AlbumData是否爲null與該問題無關。
boolean setLookupContainsItem = set.lookupContainsItem(item);
這句執行的取值存在問題，正常情況下與非正常情況下存在問題，可以進一步分析。
addItem存在異步調用問題，導致Mediaitem的mFlagForDelete賦值存在問題。需要繼續查看。與set.lookupContainsItem也存在問題。
populateMediaItemsForSets內addItem存在問題，rootcause仍在查找。
已經跟老大說，週三可以解決問題。
7）
概率性復現。
8）
掛起gallery與沒掛起所走路徑不一樣。
Cacheservice.refresh
會將數據庫查詢到的image以及video記錄寫入mediaset中。對於mediaset，存在兩個形式，一個是標準的mediaset，使用arraylist存放。還有一個是LongSparseArray，這個當做是個快表，可以快速查詢，效率比hashmap高。
然後將mediaset寫入cache文件中。
很大可能是additem問題。查看調用地方。
1>
從以下三方面入手。
Mediaset.generateTitle中生成相冊名稱，與相冊張數正確與否。mNumExpectedItemsCountAccurate變量的研究。
Mediaset. Additem。
Localdatasource.refresh中流程。
9）
在刪除文件後，Mediaset的mediaitem更新，從arraylist頭開始更新覆蓋，但是被刪除的元素尚未被移出mediaset。
1） 嘗試過假定只刪除一個元素，然後把mediaset的mediaitem的list刪除最後一個元素，正常，等待修改爲刪除多個元素驗證。
2） 需要確認additem覆蓋的是從頭開始覆蓋。
是。
3） 需要考慮把相冊內圖片全部刪除的情況。
4） 當出現多個相冊時，使用本方法會出現問題。
mItems即使改變正確了，也是會存在問題。Mitems.size與顯示的size不一樣。
5） 在additem中，mitems的變化出現異步問題。
今天：
1） 將removeDuplicate中修改爲也同時改變LongSparseArray數組的情況。
2） 不能將mitems按照最後開始重複項刪除的原則來刪除所謂的被刪除條目，因爲會存在最後幾項存放的本應被刪除的條目不存在重複項。
1>改進使得根據實際剩餘items數來刪除所謂被刪除條目。
Cacheservice .loadMediaItemsIntoMediaFeed中獲取數目存在問題，概率性不正確。
通過在additem中獲取的數字記下每個相冊的個數不可行，因爲此數字也許不準確。因此通過此記下每個相冊的確切數目會有問題。
3）
當出現多個相冊時，使用本方法會出現問題。
是否是異步出現問題？
1> 嘗試查看synchronized的調用是否正確。
可以將additems中synchronized修改範圍。
不能修改範圍。
7）
當存在多個相冊時，概率性有些相冊不會調用additem去更新。
8）
可以嘗試將updateNumExpectedItems回退，觀察相片張數的變化。
關於SMPCQ00009711問題的情況
Gallery這個刪除照片的問題目前能的情況如下：
1） 經過初步修改，對於手機中存在單個相冊的情況，可以在刪除圖片後在gallery3D中及時更新過來，但是測試時還會存在概率性不能及時更新的情況，20%的概率，代碼修改仍然存在問題，問題所在，但是不知如何修改。
2） 對於手機中存在多個相冊的情況，仍會有問題。
3） 目前很大可能需要將SMPCQ00003717、SMPCQ00007699這兩個bug回退回去，再進行修改，相當於要解3個bug。對於該相關代碼邏輯關係，仍然存在問題，此問題有跟shaking一起看過，都覺得比較難改。
4） 若要修改，還需考慮sideeffect，而七月份就要latam版的SA，風險覺得還是有的。
結論：
誠然，這個bug的確是個問題，jimmy也曾經要求需要修改，即使是在對比機以及一些已經上市機型也存在該問題時，也要解決該問題。但是鑑於目前已經花費一段時間在該問題上仍未能解決該問題，建議不要解決該問題。
另外，手頭還有幾個latam以及taiwan的bug，鑑於項目進展，想盡快解決這些問題。
6. Adb install時more than one device解決方法 2012-06-06
問題描述：
如下，
解決方案：
使用adb kill-server。