誰かがdxのドキュメントを知っていますか?
特に、私は--core-library
オプションにはあります。
誰かがそれに光を当てることはできますか?
これは、いくつかのフレームワークjar(core.jar、framework.jarなど)を構築するときにのみ使用される特別な目的のフラグです。通常、dxはJava。*またはjavax。*クラスの処理を拒否します。したがって、このオプションはこれらのすべてのクラスが実際に定義されているcore.jarに使用されます。
以下は、dxソース(dalvik/dx/src/com/Android/dx/command/dexer/Main.Java)からの関連する宣伝文です。アプリケーションにJava。*またはjavax。*クラスを含めようとすると出力されます。 。
コアライブラリをビルドしない場合の、コアクラス(Java。*またはjavax。*)の不適切な使用または誤った使用。これは、IDE(Eclipseなど)を使用しているときに、アプリケーションのプロジェクトに誤ってコアライブラリファイルを含めたことが原因であることがよくあります。コアクラスを意図的に定義していないことが確かな場合は、これは、何が起こっているかを説明する最も可能性の高い説明です。
ただし、コア名前空間でクラスを定義しようとしている可能性があります。そのソースは、たとえば、Android以外の仮想マシンプロジェクトから取得した可能性があります。これは確実に機能しません。少なくとも、プラットフォームの将来のバージョンとアプリの互換性を危険にさらすことになります。また、合法性が疑われることもよくあります。
アプリケーションをコンパイルするのではなく、コアライブラリを完全に構築するつもりである場合(完全な仮想マシンディストリビューションの作成の一部としてのみ適切です)、このエラーを抑制するために\ "-core-library \"オプションを使用します。メッセージ。先に進んで\ "-core-library \"を使用しても、実際にアプリケーションをビルドしている場合は、アプリケーションがいつかはビルドまたは実行に失敗することに注意してください。たとえば、オペレーティングシステムをアップグレードするとアプリケーションが機能しなくなることに気付いた怒っている顧客に備えてください。この問題の責任はあなたにあるでしょう。
コアパッケージにあるコードを合法的に使用している場合、最も簡単で安全な方法は、そのコードを再パッケージすることです。つまり、問題のクラスを独自のパッケージ名前空間に移動します。つまり、コアシステムクラスと競合することはありません。 JarJarは、この作業に役立つツールです。あなたがこれを行うことができないとわかった場合、それはあなたが進んでいる道が最終的に痛み、苦しみ、悲しみ、そして嘆きにつながることを示しています。
dxツールは、Javaクラスファイルを。dex(Dalvik Executable)ファイルに変換します
Dx.jarは、元々Android-sdk/platforms/Android-X/tools/lib /の下にあり(特にAndroid-3およびAndroid-4の場合)、 後でAndroid-sdk/platform-tools/lib /。
Javaソースファイルは、JavaコンパイラによってJavaクラスファイルに変換されます。
dxツールは、Javaクラスファイルを。dex(Dalvik Executable)ファイルに変換します。アプリケーションのすべてのクラスファイルは、この.dexファイルに配置されます。この変換プロセス中に、クラスファイルの冗長な情報が.dexファイルで最適化されます。
たとえば、同じ文字列が異なるクラスファイルで見つかった場合、.dexファイルにはこの文字列の参照が1つだけ含まれます。
したがって、これらの.dexファイルは、対応するクラスファイルよりもサイズがはるかに小さくなります。
.dexファイルとAndroidプロジェクトのリソース(画像やXMLファイルなど)は、.apk(Androidパッケージ)ファイルにパックされます。
理解を深めるためにAndroidビルドプロセスをよく見てください
プログラムaapt(Android Asset Packaging Tool)はapkの作成を実行します。結果の.apkファイルには、Androidアプリケーションを実行するために必要なすべてのデータが含まれており、adb(Androidデバイスブリッジ)ツールを介してAndroidデバイスに展開できます。
dxの--core-libraryオプションは、誤ってJavaコアライブラリをあなたに含めることを防ぐ愚かさのチェックをバイパスしますAndroidアプリ。
Java。*またはjavax。*名前空間にパッケージを含むライブラリを含めようとすると、DXはバーフします。その名前空間のクラスは、他のJDKの「コア」クラスに依存する可能性が高いと考えられています。これらのクラスは、Androidに存在しない場合があるため、アプリを破壊します。
もちろん、JavaパッケージがJava。*またはjavax。*で始まるからといって、必ずしもJDK固有に依存しているとは限りません。Androidで完全に正常に動作する可能性があります。推奨事項、何をしているのかがわかっていて、Java/x。*クラスがJDKコアクラスに依存していないことがわかっている場合は、JarJarなどのツールを使用して、別の名前空間でJARを再パッケージ化します。
そうは言っても、愚かさのチェックを回避するには、--core-libraryオプションをdxに追加します。 $Android_HOME/platform-tools/dx
の最後の行を
exec Java $javaOpts -jar "$jarpath" "$@"
に、
exec Java $javaOpts -jar "$jarpath" --core-library "$@"
私の場合は、JAXBに依存するJacksonに依存するライブラリを含めていました。私にとって、ライブラリのジャクソンの使用はJSONのためだけであり、XMLシリアル化のためではないため(私はJAXB APIライブラリのみを含み、implを含まない)、愚かさのチェックのオーバーライドは許容されました。もちろん、これについてより明確な方法があればいいのにと思っていますが、ジャクソンの使用を避けるためにトップレベルのライブラリを書き直すことはできませんでした。