7

私はこのエラーに遭遇し、エラーメッセージのヒットが見つからなかったので、私の仕事を繰り返す問題に直面している他の誰かを救うために思いついた解決策を共有したいと思いました.

(大規模な) アプリケーションで使用する新しい Android ライブラリ (apklib) を作成しているときに、新しいプロジェクトを依存関係として追加すると、dexing 中に次のエラーが発生します。

出力の書き込みに問題があります: フィールド参照が多すぎます: 70185; 最大は 65536
です。 --multi-dex オプションを使用してみてください。
パッケージごとの参照:
<...フィールド数が省略されたパッケージの長いリスト...>

失敗する特定のビルドステップは次のとおりです。

java -jar $ANDROID_SDK/build-tools/19.0.3/lib/dx.jar --dex \
--output=$PROJECT_HOME/target/classes.dex \
<... long list of apklib and jar dependencies elided ...>

エラー メッセージで推奨されているように使用--multi-dexすることが解決策になる可能性がありますが、私はアプリケーション プロジェクトの所有者ではなく、すでに大規模で複雑なビルド プロセスがあり、それを変更することをためらっています。

この問題は、文字通りフィールドを持たないノーオペレーション テスト ライブラリ プロジェクトで再現できますが、エラー出力には 6000 以上のフィールドがあるとリストされています。エラー出力にリストされたパッケージの中で、同様の 6k+ フィールド カウントを持つ一握りのパッケージがありますが、大部分はより妥当な <1k フィールド カウントを持っています。

この問題は、 Facebook がハッキングで回避したことで有名な「メソッドが多すぎる」問題に似ています。FB ソリューションは正気ではないようで、私が見つけた唯一の他のソリューション (たとえば、この Android バグ チケット、またはこれ、この SO 回答、この他の SO 回答) はすべて、メイン アプリのコードを変更することを伴いますが、これは、私がしたいこと。

他の解決策はありますか？

4

1 に答える 1

2

解決策は、メイン アプリケーションのパッケージと一致するように AndroidManifestのパッケージを変更することでした。

次のようなマニフェスト:

<manifest package="com.example.testlibrary" ...

6k 以上のフィールドが発生し、ビルドが失敗しました。メインアプリケーションのパッケージに合わせて変更する

<manifest package="com.example.mainapplication" ...

プロジェクトの構築に成功しました。

マニフェスト内のパッケージのみが変更されていることに注意してください。ライブラリの Java ソースまたはそのレイアウトには変更を加えていません (Java パッケージは、ディレクトリ構造が一致する com.example.testlibrary のままでした)。

別のパッケージ名が原因で、すべての Android フィールドがそのパッケージの下に再び含まれていると仮定します。6k 以上のフィールドを持つエラー リスト内のすべてのパッケージは、メイン アプリケーションとは異なるパッケージ名を持っていました。

私も（後で、grr）、同じ問題と最終的な同じ解決策について詳しく説明しているこのブログ投稿を見つけました。

于 2014-05-20T01:26:49.450 に答える