ccl8659 wrote:
那是你引用的刷機腳本
delete
我知道，但我一開始測試時不是這個腳本，所以最開始我還要再多刷supersu.zip,只是當時不知道哪裡出問題，有時root會自己失效!
後來我乾脆放deodex的rom裡，當時還做了其他小修正，結果本來的小毛病後來都沒了!所以乾脆就這樣放su在裏頭!
腳本我是故意保留清除的指令，其實本來也該這麼做，否則萬一出現部分仍為odex，要找bug很麻煩哩= ="(cc大你知道的，再framework出現混搭，手機會掛的機率接近100%)
dx9901mk5 wrote:
我知道，但我一開始測...(恕刪)
我的看法
其實你的ROM/system/bin/內有些多余東西(但影響不大,有些刷機解壓時會自動加入的東西)
GOOGLE失效也是
ROOT不穩主要原因加上那時recovery版本的RIC killer不很穩
一但一些有可能會動及busybox的指令都會造成root失效,需再補刷SuperSU(你使用上應該有遇過)
所以我才會指現在的root只能稱Full 不能稱Perfect
deodex刷包置換法,本來就是去舊換新的原理(原理不同,腳本寫法也會跟著變,不能一直引用別的)
但更新的app會存在data/app/內,app的各別設定資料會再更動到
建議一開始就將rom內odex全部換成deodexed的會省事且較沒問題
ccl8659 wrote:
我的看法
其實你的ROM/system/bin/內有些多余東西(但影響不大,有些刷機解壓時會自動加入的東西)
GOOGLE失效也是
ROOT不穩主要原因加上那時recovery版本的RIC killer不很穩
一但一些有可能會動及busybox的指令都會造成root失效,需再補刷SuperSU(你使用上應該有遇過)
所以我才會指現在的root只能稱Full 不能稱Perfect
deodex刷包置換法,本來就是去舊換新的原理(原理不同,腳本寫法也會跟著變,不能一直引用別的)
但更新的app會存在data/app/內,app的各別設定資料會再更動到
建議一開始就將rom內odex全部換成deodexed的會省事且較沒問題
system/bin/裏頭的東西是我故意放進去的，而且你說反了，ROOT不穩定時我沒加那些東西，我加了反而都正常了。
Google失效目前只有一味發生過，但事實上我手邊經手過的所有機子只要我親自刷的，都從來沒發生過問題(目前刷了12隻Z1和6隻ZU)
我一直保留2.71的Recovery，故意沒生是因為我一直在看後續程式碼，越看發現原作者改越多，但也越來越多複雜的結構在裡面，問題自然一堆。
反倒我認為2.71的RIC killer綜合比較起來還不錯，至少刷機正常，大多數其他狀況也少。
當然我認同你說的現在的ROOT並不完整，但出問題的都在busybox部分居多，其實有些修改一下app就ok了，但可惜並非人人都做得到。
我有的deodex刷法，是可以部分保留odex和deodex並存，因為經我實測，大檔案的odex運作效率會比較快，deodex反而變慢，雖然微乎其微，可是搭配RAM優化效果就會出來，但這個必須待配修改/framework裏頭幾個jar檔案(裏頭參數要多一狗票指令)
稍微一改錯系統會直接掛掉！改好後系統效能真的不錯，可是每次app更新就會出問題，還要再改一次，所以要針對已知的檔案寫個轉移指令(內建腳本)，但這個只能正向表列，且還很複雜。(其實很像4.4 ART)
/system/bin/裏頭和xbin是我刻意放那些進去的，目的是就是為了未來假設這方法我找到共通性腳本，這些東西完整一點比較好。
但這事情暫時交給我朋友做了，他們是一個大團隊，要做比較快(其實我只是跟他們接幾個初始程式碼來玩玩XD~)
另外目前doedex的ROOT目前還沒遇到問題就是了，有問題麻煩回報一下@@"
內文搜尋