熱更新Sophix的爬坑之路

寫該篇博客就是爲了總結下使用Sophix的過程中碰到的一些Bug及爬坑過程，希望各位極客還沒碰到，看了我的回顧總結後能對可能出現的困惑有幫助。

Sophix與EMAS中的其他產品不一樣，需要單獨的進行穩健接入，使用EMAS的統一接入無效。

爬坑之路會 隨着路程越遠逐步完善

坑一：AndroidX 不兼容

開發環境

win10 + android studio 3.5.1 + gradle-5.4.1 + 設備API 5.1.1 + jdk1.8+ alicloud-android-hotfix:3.2.10

爬坑過程

這個Bug簡單來說就是3.2.10的時候Sophix還不支持androidx，使用了Androidx的Android5.1.1在進行resource 資源更新是就會報如圖錯誤。

使用的Sophix熱更新工具使用的是3.2.4版，此時是不支持Androidx的檢查初始化。
​​

在2019.11，釘釘支持羣說我是第一個使用Androidx進行熱更新的，估計當時阿里對Sophix還未做大量的Androidx兼容測試。最終的解決方法是通過我的堅持，Sophix最終進行修改優化兼容Androidx。版本升級爲3.2.12後支持了Androidx。心酸過程讓我一一道來。

我這個人有升級狂魔症，經常喜歡升級依賴，Gradle、插件等，反正只要能更新的，能升級的我都要立馬升級，更新，因此踩了不少的坑，碰到了不少的雷。本着我不入地獄誰入地獄的精神，依然一往無前，樂此不疲。 不扯遠了，回正題。

首先，我發現將項目轉爲Androidx後，發現自己的Sophix不能正常工作了，app打完補丁就崩潰，於是各種測試，測試其他還未轉androidx的項目正常。沒辦法只能求助全能的技術支持。

此時自己開始懷疑Sophix自身有問題，雖然Sophix是阿里的技術團隊開發的，我也對它迷之自信，但是我的懷疑心戰勝了崇拜心，大膽的猜測。 雖然技術支持堅稱SDK不會有問題，但是我一直堅持自己的觀點。


通過不斷地多種測試，拿出我的多Gradle版本,多Android SDk版本的熱更新測試，終於說服了Sophix 進行Androidx的兼容檢查，最終發現 sophix 3.2.8之前的sdk確實不兼容android 5.0、5.1、 6.0的androidx apk進行熱更新.


問題解決
OK,經過Sophix的工程師修復，Sophix 3.2.10升級到Sophix 3.2.12就能解決5.0，5.1,6.0 中安裝了 Androidx的apk後，進行resource修復報錯崩潰的bug。

總結

1. 常常看到阿里騰訊等大廠的產品我們就會覺得他們的產品肯定厲害，肯定沒問題，其實這是個誤解。 作爲程序員大家其實是認同軟件產品不能不存在Bug,好的和壞的就看bug率的多少了。 軟件產品是一個逐步完善逐步修復bug完善的過程。
2. 對於任何開發中碰到的問題，我們要大膽的假設和猜測，不能根據自己的經驗去認爲不可能。
   一切皆有可能，何況我們大多數人還不是特級大神，我們需要懷疑需要假設，通過實際的排查和驗證，才能排除不是那些因素造成了我們的問題。
   實踐是檢驗一切真理的唯一標準

坑二：patch 補丁反覆失效

這次碰到的Bug是補丁反覆失效，具體症狀是：補丁成功後，下次重啓軟件又恢復了原樣，繼續重啓補丁成功，繼續重啓恢復原樣。簡直就是子子孫孫無窮盡也！

開發環境

1. win10+gradle-5.6.4+android studio 3.6.3 + 設備API 5.1.1+jdk1.8
2. ‘com.aliyun.ams:alicloud-android-hotfix:3.2.14’
3. 有個特殊的情況是，我的軟件需要進行系統簽名，製作成系統軟件以便於軟件的靜默安裝。生成的apk需要經如下文件簽名，讓程序獲得系統級權限。
   
   系統簽名還需在AndroidManifest.xml中配置android:sharedUserId="android.uid.system"

爬坑過程

首先進行相關因素排查，然後根據自己的進行假設，一步步驗證排除假設直至找到最終真相。

1. 緩存清理

首先懷疑我進行了清緩存操作，於是我把各種自動清理垃圾緩存的代碼操作屏蔽 和管理軟件卸載，繼續測試，Bug未解決，該Bug與緩存清理無關。
補充說明： 後面交流才知道patch的下載路徑在/data/data/com.axecom.smartweightdj/files/sophix/patch(非系統簽名app的路徑，系統簽名的下載路徑我也沒權限看不到啊)。

2. MultiDex不正常
各種日誌分析測試，發現apk中有多個.dex文件，懷疑MultiDex失敗的問題。我的apk中有7個.dex文件，後面幾個.dex文件方法數只有幾百個。 一般來說只有方法數超過65535，纔會有兩個.dex文件，後面依次計算，超過65535*2纔會有3個.dex文件。

技術支持小哥讓我生成正常的apk,這可難倒我了，找不出我的apk生成多個.dex文件的原因，，我只能笨辦法，重建工程把內容以過去，好了，發現apk正常了，只有了2個.dex文件。



滿心歡喜的以爲搞定了，測試看看。我去，bug還是沒解決，依然存在。

3. System.exit(0)
繼續測試找背鍋俠。在關閉的過程中，有System.exit(0)這個操作，好吧會不會是它造成的，我猜一般應該和這個沒關係吧。

果然屏蔽了System.exit(0)方法後，Bug還是沒有解決。繼續其他猜想。
關於System.exit(0) 與 android.os.Process.killProcess(android.os.Process.myPid())的使用和區別，請查看我其他博客的分析介紹。博客地址待補充，文章已寫完還未發佈

4. patch補丁是否加載正常
沒辦法，同樣一個補丁，Sophix是不會不斷下載同一補丁的，那麼實時觀察它的狀態吧。

此時不嘗試獲得兩個總結：
1.爲了能看到data\data\package中的patch文件，我取消了系統簽名，發現補丁竟然成功了。
2.非系統簽名app,如果系統未root，一般也看不到data\data\package中的信息，此時只能通過配置debuggable true，此時我們能通過 看到data\data\package中的數據。
意外驚喜是非系統簽名的app debuggable=true時， 補丁能正常。此時能看到data\data\package中的內容

趕緊測試debuggable=false時，補丁也能正常。此時權限問題無法看到data\data\package中的內容

在這裏插入圖片描述
3我的bug造成的原因肯定和系統簽名有關係

5. 系統權限
通過長長的詳細Verbose級日誌，分析到:合成的補丁 ，新的補丁加載可以成功，合成的補丁 拒絕執行denied execute。如果apk不經系統簽名，不會有該問題，所以定位可定是系統權限哪裏的問題。

我們使用Android studio能看到的日誌條數一般是有限制的，爲了不得漏掉日誌，建議使用 adb log技術，使用如： adb logcat -s :V > d:/999.log 。詳細使用方式網上搜索會更詳細。

經過努力已經查找出system app進行Sophix熱更新的補丁反覆失效的原因，這和系統權限確實有關係，將enforce設置爲0 ，也就是降低Android系統的一些安全要求，放款權限限制。

通過對比system app 和普通app的sophix的patch補丁文件夾。
system app

如下是普通app的

此時你會發現兩者的RW權限是一樣的，patch也從後臺下載了。但是最終System app不能成功，是因爲系統的安全限制作怪，設置setenforce 0即可解決問題。

注意：System App的目錄我們看不到，可以通過adb shell 進入通過shell命令查看文件夾詳細信息

問題解決：
bug源碼解決了。這個bug折磨了我一個周的時間去整理和排除，可謂是傷透了心。

我的這個Bug一般人是碰不到的，需要系統簽名的軟件纔會碰到如此問題,希望你們不會碰到，截止20200516，我所知道能讓系統簽名的app也支持Sophix的只有讓Android 系統 setenforce 0 降低安全標準了。

坑三：abandon initialization: callRealAppAttach

這種問題比較簡單，在低Android系統中，當Apk中的方法數量超過限制時，就需要使用MultiDex技術。該處報錯就是因爲未配置MultiDex.install(this)， SophixStubApplication和RealApplication兩個Application沒在一個dex中引起的，只要正確配置即可解決。
​​

注意這個問題的 MultiDex.install(this)要在SophixStubApplication.java文件中，其他Application中不得有 MultiDex.install(this)。

總結

1. 其實生成了多個.dex的原因是：設置了 debuggable= true，此時生成了7個.dex文件，debuggable= false時生成的apk有2個.dex文件。

2. 這個Bug其實與debuggable的設置其實毫無關係，也即與.dex的多寡無關。這是後面經過我多次測試終於明白的。`**

3. 碰到技術bug能耐下心來去研究，排查，網上搜資料，始終能解決問題的。

4. 我的這個Bug的唯一解決方式是系統要root,或者將patch下載到外部空間如public\download中(但是Sophix現在是不支持修改設置patch下載地址的)

補充知識點

1. enforce

**enforce:**加強，這裏指 security enforce安全加強，也就是SELinux，setenforce 0就是表示關閉SELinux（Linux的防火牆）的加強模式
當我們設置setenforce 0 後，可以通過shell 命令getenforce可以看到設置狀態。顯示permissive即爲防火牆關閉了。

0： 切換成 permissive（寬容模式）
1： 切換成 enforcing（強制模式）

2.Root

Android系統本質就是一個Linux 系統，Linux系統的強大在於多用戶管理，對於不同的用戶給不同的權限，Linux系統裏面有一個超級用戶，叫做su。
如果你能獲取su用戶執行的命令，那你就獲得了超級用戶權限。對於系統自帶的文件和apk可見，並且能進行刪除和修改操作。

結語

• 首先要感謝自己的持之以恆，碰到的bug和爬坑過程，時間跨度在一個星期和一個多月。中間要做各種測試操作和驗證，補充相關論點支持，每次自己都未有想放棄的想法，雖然頭疼還是堅持排查最終也得到了解決。

• 非常感謝Sophix的技術支持@塗中和@徐厚、@劉寶文，這些Sophix的技術支持團隊非常的有耐心，對於技術疑惑回答都很及時且對提問者的問題都是有問必答比解決。非常敬佩他們的敬業精神，果然覺得阿里的招牌不是蓋的。

• 我在熱更新方向是從Bugly平臺轉到EMAS的，兩者的技術高低暫且不論，技術支持方面是高低立下的，真的建議大家更偏向Sophix,少踩Bugly的坑，在我的博文《熱更新你都知道哪些？》會分析爲什麼優先使用Sophix 。