御盾APK 被重簽名後為什麼還能安裝，風險在哪裡
解釋 APK 當前簽名自洽、官方釋出身份、覆蓋升級、渠道產物和服務端版本策略之間的區別，並給出重打包治理門禁。
讓加固後的 APK 仍能順利升級和釋出
御盾不只處理 DEX，還把資源保護、簽名身份、二次打包檢查、版本升級和渠道產物放進同一條交付鏈，避免“能安裝、不能升級”或最終渠道包失去保護。
你的 App 是否正遇到這些問題
- DEX 中的業務邏輯和介面規則容易被直接閱讀
- 資源、Manifest 或配置被替換後仍能重新打包
- 重新簽名後產生仿冒包，服務端卻無法區分
- 加固包能全新安裝，卻無法覆蓋線上版本升級
御盾如何處理
DEX 與資源保護
收斂關鍵程式碼和敏感資源的靜態可讀面，按業務風險選擇保護強度。
簽名與重打包治理
把簽名身份、包體完整性和服務端合法版本策略放在一起驗證。
升級與渠道驗收
測試全新安裝、覆蓋升級、渠道修改和最終產物身份，結論只繫結最後交付的 APK。
本次公開了什麼
- 同時檢查啟動鏈、類載入、Native bridge 與 SO VMP
- 核對資源載荷、簽名摘要和敏感資訊收斂
- 把候選樣本與最終釋出版本明確分開
說明： 公開結果屬於候選包靜態測評，仍需真機執行、效能、服務端回執和灰度驗證。
從評估到交付
檢視交付方法- 01
提交最終構建
提供原始 APK、簽名與版本計劃，以及渠道工具會修改的內容。
- 02
完成保護配置
分別處理 DEX、資源、Native 載體與完整性，再生成可追蹤的候選包。
- 03
驗證釋出鏈
核對簽名、升級、安裝啟動和關鍵業務，最終以渠道產物完成驗收。
購買前常見問題
APK 加固是否只保護 DEX？
不是。DEX 是重要層面，但資源、Manifest、Native 庫、簽名和版本升級同樣影響重打包與釋出風險。
重新簽名後還能正常安裝就安全嗎？
不能這樣判斷。安裝成功只說明系統接受該包，不代表簽名身份、服務端版本校驗和業務完整性仍然成立。
渠道包應在加固前還是加固後生成？
取決於渠道修改範圍和簽名流程。應先固定構建順序，再驗證每個渠道產物的簽名、資源、啟動和升級。
如何證明發布的是正確 APK？
記錄構建來源、版本、簽名證書摘要、檔案摘要和迴歸結果，並讓釋出系統只接收已批准的候選身份。
安全標準與平臺依據
- Android 應用簽名
簽名身份、升級鏈和釋出一致性
- Android 安全最佳實踐
Android 應用安全設計與釋出邊界
- Play Integrity API
服務端判定與應用完整性訊號邊界
- OWASP MASVS
移動應用安全控制與驗證範圍
- Android NDK ABI 指南
Native 架構、ABI 和打包相容