先固定候選包與復現條件
同名檔案可能來自不同構建、簽名或保護配置。排查前應記錄包名、版本、簽名證書摘要、檔案摘要、保護配置、裝置、系統版本與安裝方式。
同時準備與候選包對應的未加固基線，並使用相同賬號、網路、資料狀態和啟動入口復現。條件不一致時，很多差異無法歸因給加固過程。
- 檔案與簽名身份固定
- 裝置和系統版本固定
- 安裝升級路徑一致
- 賬號網路和資料狀態一致
找到最早出現差異的啟動階段
把啟動拆成程序建立、Application 初始化、ContentProvider、類載入、Native 庫載入、首屏資源和業務入口。記錄候選包在哪個階段首次偏離基線。
最早差異比最後一條錯誤提示更有價值。後續異常可能只是連鎖反應，直接圍繞末尾堆疊修改配置容易掩蓋真正原因。
按載體檢查常見相容點
Java 與 Kotlin 側重點觀察反射、動態類載入、序列化、註解和被名稱規則依賴的入口。Native 側檢查 ABI、依賴解析、JNI 註冊、符號可見性和初始化順序。
資源與第三方 SDK 還可能依賴 Manifest、檔案路徑、完整性校驗、WebView、熱修復或自身的反篡改邏輯。每次只改變一個變數，才能判斷修復是否真實有效。
- 反射與動態載入入口
- JNI 註冊與依賴庫
- Manifest 和資源路徑
- 第三方 SDK 自校驗
修復後必須回到釋出範圍複驗
某臺裝置不再閃退只說明當前復現點被消除。還需要在同一候選身份上重新執行安裝升級、啟動、關鍵業務、目標系統範圍和異常回滾。
無法獲得的裝置或系統版本應明確標記未覆蓋，並限制釋出範圍。不能用另一個版本的成功結果替代缺失的相容證據。
讓建議落到真實應用上
提交技術棧、關鍵路徑、目標系統範圍和當前候選包，由御盾給出針對性的保護與相容性驗證建議。