could not parse aggregated battery stats

之前有一篇文章Android5.0系統耗電分析中提到用Battery Historian來分析耗電問題，但是在最近幾次用Battery Historian2.0分析的時候點選Submit按鈕analyse成功後，進入介面的報錯“Note: Could not parse aggregated battery stats.”，點選error按鈕，出現如下提示： 

也就是說你檢視不了Battery Historian2.0檢視，可能在解析的時候報錯了，那麼我們可以不檢視Battery Historian2.0的分析檢視，只檢視Battery Historian1.0的，可以進入…\battery-historian\scripts目錄，在這裡面你就看到了“historian.py”這個就是把bugreport.txt轉化成html檔案的py實現，然後在這裡目錄開啟cmd之下一下命令：python historian.py -a bugreport.txt > battery.html就可以看到在這個目錄下生成了html檔案，然後用谷歌瀏覽器直接開啟html檔案即可檢視耗電的一些資訊，但是個人感覺Battery Historian1.0的耗電分析檢視沒有2.0來的詳細和直觀，以下為截圖：    Battery Historian1.0耗電分析檢視： 

但是我對這個問題“could not parse aggregated battery stats”感覺特別不爽，因為我用我們android系統5.0（MTK提供）的user debug版本手錶（root）都可以正常使用，為啥一換到root過的手機，還是google官方的6.0系統就不行了呢？於是乎，一頓google，記住。一定要用google，不要用百度，用百度你用換搜尋不到重點。在這裡我找到靈感：could not parse aggregated battery stats，這裡面有很多Battery Historian的issu問答，我們關注的是：  Definitely not server-side, it means your bugreport is invalid. Yes, a bug in the ROM is likely the cause. It may be possible to fix the report in a text editor though. There will likely be two lines with “,vers,” lines in them. If you delete one of them the first error should disappear. Same should be the case for “,bt,”. If you look for lines with that in it there should be two of them. Delete one and things might work.（大概的意思是說bugreport檔案不可用，可能是rom的一個bug導致的，那麼要解決這個bug就找到bugreport.txt檔案下的“,vers,”發現有兩個這個東西，那麼刪除其中一個，然後再搜“,bt,”也有兩個，也刪除其中一個，當然，刪除哪一個？） It definitely helps for the errors, even though it doesn’t fix the fact I only see the Historian-tab. I now get a new error about ‘global network field already exists’, I’ll try to fix this in the same way. I’ll also try another nightly, maybe this is an incidental bug.（當你刪除了一個“,vers,”後，你會發現又報錯“global network field already exists”） If there are a lot of these you can look through this. The “,bt,” and “,vers,” are section identifiers. If you’re seeing “global network field already exists”, you should look for “,gn,”.  I’ll also add that you should probably delete the first line in the case of battery stuff and the second line in the case of version. I think they should probably be ordered chronologically but really there shouldn’t be multiple at all so who knows.（針對2中問提，找到“,bt,”也發現有兩個，刪除其中一個，這個“,bt,”應該是緊跟著剛才刪除的“,vers,”，“,gn,”也是如此，也要刪除多餘的那一行）  至此：按照如上三個步驟我們已經在bugreport.txt檔案中的這三行內容： 9,0,i,vers,15,133,MOB31K,MOB31K

9,0,l,bt,0,0,0,238067037,173720359,1483685378198,0,0

9,0,l,gn,0,0,0,0,0,0,0,0 1 2 3 4 5 很可惜的是，依然報錯： 

但是很明顯，報錯變少了，說明我們以上做的修改還有有點用的，於是我預測是不是還有些東西沒有刪除掉，經過上面的一個過程下來，隱約感覺到是不是由於bugreport.txt檔案裡面有些引數重複了導致檢視解析不出來，例如“,vers,”，“,bt,”，“,gn,”都是重複的，然後刪除掉一行，繼續google，證實了這個問題：Battery Historian is complaining because it only expects one log per file.，於是我就再去bugreport.txt檔案中找，是不是還有類似的引數沒有刪除呢？在剛才刪除的那三行下面我看到這麼一些東西：

9,0,i,vers,15,133,MOB31K,MOB31K

9,0,l,bt,0,0,0,238067037,173720359,1483685378198,0,0

9,0,l,gn,0,0,0,0,0,0,0,0 // 以上三行是已經刪除的 9,0,l,gwfl,0,0,0,0,0,0

9,0,l,gble,0,0,0,0

9,0,l,m,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

9,0,l,br,0,0,0,0,0

9,0,l,sgt,0,0,0,0,0

9,0,l,sst,0

9,0,l,sgc,0,0,0,0,0

9,0,l,dct,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

9,0,l,dcc,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

9,0,l,wst,0,0,0,0,0,0,0,0

9,0,l,wsc,0,0,0,0,0,0,0,0

9,0,l,wsst,0,0,0,0,0,0,0,0,0,0,0,0,0

9,0,l,wssc,0,0,0,0,0,0,0,0,0,0,0,0,0

9,0,l,wsgt,0,0,0,0,0

9,0,l,wsgc,0,0,0,0,0

9,0,l,dc,0,0,0,0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 奇怪的是後面跟的引數都是0，覺得不太對勁，找到那個沒有刪除的“,bt,”和“,bt,”看了下：

9,0,l,bt,0,4034182,3304371,6220490,5490679,1483917201211,1405309,675499

9,0,l,gn,7688100,795463,27082229,2909975,7858,7960,26650,28479

9,0,l,gwfl,4034182,4034182,1679358,29311,32558,0

9,0,l,gble,0,0,0,0

9,0,l,m,2628873,0,5225,449536,1002609,34,2620589,0,12,0,0,0,0,19,25225

9,0,l,br,468770,582304,1345121,154945,77733

9,0,l,sgt,2612,43469,782137,2361194,844770

9,0,l,sst,0

9,0,l,sgc,2,7,44,157,160

9,0,l,dct,2910827,0,0,0,0,0,0,0,0,0,0,0,0,1123355,0,0,0

9,0,l,dcc,2,0,0,0,0,0,0,0,0,0,0,0,0,1,0,0,0

9,0,l,wst,0,0,0,0,0,0,0,0

9,0,l,wsc,0,0,0,0,0,0,0,0

9,0,l,wsst,0,149908,0,0,880862,0,15338,1043,13159,104,2973768,0,0

...後面太長了，這裡就省略了... 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 其實“,vers,”，“,bt,”和“,bt,”都是在—— CHECKIN BATTERYSTATS (dumpsys batterystats -c) ——下的，只不過這裡這三行並不連續，中間穿插一大段資料內容，而剛才刪除的那三行卻是連續的，而且後面帶的引數都是0，經過比較發現，後面帶的引數本應該是uid，程序名等引數，這些引數是不可能都為0的所以就猜測剛才刪除的那些資料可能是異常資料，也許就是這裡導致檢視分析報錯，於是就把那一整段都全部刪除：

9,0,i,vers,15,133,MOB31K,MOB31K

9,0,l,bt,0,0,0,238067037,173720359,1483685378198,0,0

9,0,l,gn,0,0,0,0,0,0,0,0

9,0,l,gwfl,0,0,0,0,0,0

9,0,l,gble,0,0,0,0

9,0,l,m,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

9,0,l,br,0,0,0,0,0

9,0,l,sgt,0,0,0,0,0

9,0,l,sst,0

9,0,l,sgc,0,0,0,0,0

9,0,l,dct,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

9,0,l,dcc,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0

9,0,l,wst,0,0,0,0,0,0,0,0

9,0,l,wsc,0,0,0,0,0,0,0,0

9,0,l,wsst,0,0,0,0,0,0,0,0,0,0,0,0,0

9,0,l,wssc,0,0,0,0,0,0,0,0,0,0,0,0,0

9,0,l,wsgt,0,0,0,0,0

9,0,l,wsgc,0,0,0,0,0

9,0,l,dc,0,0,0,0 然後儲存下bugreport.txt，在去submit分析，發現居然成功的顯示出檢視了： 

到這裡有兩個tab頁面，一個是2.0的，一個是1.0的，1.0的tab顯示會被下面的覆蓋掉，而1.0關於wake lock喚醒資訊比較詳細，所以可以用python historian.py -a bugreport.txt > battery.html命令單獨轉換生成1.0的分析檢視，這個上面已經提及，好啦，問題解決！ ---------------------  作者：lhd201006  來源：CSDN  原文：https://blog.csdn.net/lhd201006/article/details/54287494  版權宣告：本文為博主原創文章，轉載請附上博文連結！