SO 加固前為什麼先梳理 JNI 與 ABI

依賴圖決定哪些庫能單獨處理

應用可能直接載入主庫，也可能透過主庫繼續載入其他依賴。第三方 SDK 還可能攜帶自己的 Native 元件，並依賴特定的匯出符號或初始化順序。

依賴圖至少應列出庫名、直接與間接依賴、載入入口、初始化時機和呼叫方。缺少這張圖時，對單個 SO 的改動可能在另一個庫載入時才暴露問題。

• 主庫與傳遞依賴
• 系統庫與第三方庫
• 載入入口與初始化順序
• 異常出現的最早階段

JNI 註冊方式影響符號處理

靜態註冊依賴名稱約定，動態註冊通常在初始化階段把 Java 方法與 Native 函式繫結。兩種方式對符號可見性、重新命名和載入時機的約束不同。

在處理匯出或函式表示之前，應確認每個關鍵入口如何註冊、是否被反射或第三方元件呼叫，以及異常時能否在 Java 與 Native 兩側同時定位。

ABI 不是一個可省略的標籤

arm64-v8a、armeabi-v7a 與 x86_64 對應不同的指令、連結產物和依賴組合。某個 ABI 構建成功或在模擬器啟動，不能證明另一個目標架構可用。

釋出前應檢查最終 APK 實際包含的 ABI，並在目標架構上驗證庫解析、應用啟動、關鍵 JNI 呼叫、異常捕獲與第三方 SDK 路徑。

• 最終包包含目標 ABI
• 所有依賴都能解析
• 關鍵 JNI 路徑可重複
• 未覆蓋架構被明確記錄

保護強度要和裝載穩定性一起驗收

刪除符號、處理字串或虛擬化關鍵函式分別減少不同線索，沒有一種動作可以單獨代表完整 Native 保護。啟動初始化和高頻函式還需要額外關注效能與故障半徑。

穩妥的做法是從少量高價值、輸入輸出清楚的函式開始，在同一候選包上逐步擴大範圍，併為每次配置變化保留可回退版本。