依存関係マップは、単独で変更できるものを示します
アプリケーションは、推移的な依存関係をロードする 1 つのプライマリ ライブラリをロードする場合があります。サードパーティ SDK には、エクスポートまたは特定の初期化順序に依存するネイティブ コンポーネントを含めることができます。
ライブラリ名、直接的および推移的な依存関係、ロード エントリ ポイント、初期化のタイミング、呼び出し元を記録します。 1 つの SO での変更は、別のライブラリが後でロードされるときにのみ失敗する可能性があります。
- 主な依存関係と推移的な依存関係
- システムおよびサードパーティのライブラリ
- ロードエントリと初期化順序
- 初期の故障段階
JNI 登録によりシンボルの処理が制限される
静的登録は命名規則に依存しますが、動的登録は通常、初期化中に Java メソッドをネイティブ関数にバインドします。これらは、可視性、名前変更、読み込みタイミングにさまざまな制約を課します。
エクスポートまたは関数の表現を変更する前に、すべての重要なエントリがどのように登録されるか、それをリフレクションまたはサードパーティ コードが呼び出すかどうか、および Java とネイティブの障害の両方がどのように診断されるかを特定します。
ABI はラベルではなく実行境界です
arm64-v8a、armeabi-v7a、および x86_64 は、異なる命令、リンクされた出力、および依存関係を使用します。 1 つの ABI のビルドまたはエミュレーターの起動が成功しても、別のターゲット アーキテクチャは確立されません。
最終的な APK の ABI を検査し、依存関係の解決、アプリケーションの起動、重要な JNI 呼び出し、エラー処理、各ターゲット アーキテクチャ上のサードパーティの SDK パスを確認します。
- 最終パッケージにはターゲット ABI が含まれています
- あらゆる依存関係が解決される
- クリティカルな JNI パスが繰り返される
- 明らかになったアーキテクチャは明示的です
保護強度と荷重安定性を両立
シンボルの削減、文字列の処理、関数の仮想化により、さまざまな手がかりが取り除かれます。単一のアクションは完全なネイティブ保護を表すものではないため、アプリケーションの起動や頻繁に実行される機能には特別なパフォーマンスの注意が必要です。
明確な入力と出力を持つ貴重な関数の小さなセットから始めます。同じ候補の範囲を拡張し、構成変更ごとに回復可能なバージョンを保持します。
ガイダンスを実際のアプリケーションに適用する
Yudun が焦点を絞った保護と互換性のレビューを推奨できるように、スタック、クリティカル パス、ターゲット システム、および現在の候補を提供します。