Android のソース コードにある程度の時間を費やしたことのあるユーザーにとっては、クラスで生成された IDが、提供された JARandroid.Rのディレクトリにある実際のリソースを 1 対 1 で反映していないことはニュースではありません。res/ドローアブル/スタイル/レイアウトの多くは「パブリック」ではなく、 を参照することでアプリケーションからアクセスできますandroid.R.xxx。
私の質問はAndroid、実際のリソース グラフとは異なる R.java クラスを生成できるメカニズムを知っている人はいますか? 第二に、開発者がライブラリとして使用されるアプリケーションで公開される ID を部分的に保護するために活用できるメカニズム (ビルド ルールなどを使用) ですか?
前もって感謝します！
Android は aapt を使用してリソースをパッケージ化し、ビルド プロセス中にこのツールを使用して R ファイルを生成します。このステップでは、XML ファイルはバイナリにコンパイルされ、他のリソースはそのままパッケージ化されます。.apk ファイルを zip アーカイブとして開き、すべてのリソース ファイルにそのままアクセスできます。ライブラリ プロジェクトには、コンパイル時にプロジェクトに追加されるソース ファイルとリソースが含まれているだけなので、何らかの形で .apk ファイルに存在します。ライブラリ プロジェクト用に XML が既にコンパイルされているため、おそらくレイアウトは 1:1 ではありません。aapt を使用して、ビルド時にライブラリ プロジェクトからファイルが含まれないようにする方法はおそらくありますが、プロジェクトでアクセスできなくなります。aapt と ant を使用してコンパイル時にリソース名を難読化する方法もあるかもしれませんが、それはできません。
実際のリソース グラフとは異なる R.java クラスが必要な理由がわかりません。ビルド時にこれらのリソースを含めないか、apk に含めます。レイアウトは出力でバイナリ ファイルとして圧縮されるため、別のプロジェクトで逆コンパイルまたは再利用するのがどれほど簡単かはわかりません。
ここでのエンドゲームは何ですか？リソースを保護することであれば、それは難しいでしょう。誰かが電話をルート化できる場合、Android は非常に安全ではありません。IP を保護したい場合は、これがここでの終盤であると想定しています。プロジェクトを apk にコンパイルして、apk から重要なリソースを逆コンパイルまたは抽出できるかどうかを確認します。難読化を試してみるのもいいかもしれませんが、コンパイル済みの XML ファイルについて、簡単に逆コンパイルできないほど難読化されているかどうかを知るには、十分な知識がありません。
私が間違っている場合は、誰かが私を自由に訂正してください。ただし、これは私の 2 セントです。