そのため、"Utility"いくつかのプロジェクトにはいくつかのスタイルクラスがあります。アプリ固有ではないグルーコード（ほとんどの場合、ラッパーとインターフェース）のすべてまたはほとんどを含むAndroidライブラリプロジェクトにそれらを移動できるかどうか知りたいです。
だから、私の質問は、そのライブラリで必要のないファイルはどうなるのかということです。Androidライブラリプロジェクトは基本的にコードを他のプロジェクトにコピーするだけなので、「汎用」ライブラリでコードの25％を使用すると言うと、アプリには実際にすべての100％のバイトコードが含まれるのでしょうか、それとも適切に削除されますか必要なものだけに絞ってください。
過去にProguardで未使用のクラスに問題があったので、今はADTに一度噛まれ、2回恥ずかしがり屋になっています...
残念ながら、ライブラリが大きくなると、そのライブラリのほとんどのコンテンツが使用されていなくても、すべてのプロジェクトが大きくなります。アプリAとライブラリLを作成して、自分でテストしました。LがAで使用されるライブラリの場合、クラスを追加すると、classes.dexファイル（したがってA.apkファイル）が大きくなります。使用済み。
要約すると、今のところ、小さくて多くのプロジェクトで使用される可能性のある特定のもの用の基本ライブラリを作成し、大きくなり、一部のプロジェクトでのみ使用される新しいコンポーネントごとに新しいライブラリを作成します。新しいライブラリの適切な候補は、リソースで複数の画像が定義された新しいUIコンポーネントです。基本ライブラリの適切な候補は、一般的に使用されるメソッドや、ファイルキャッシュなどです。コンパイルされたコードは、Dalvik用にかなり圧縮されています。これはここで確認できます。（プレゼンテーション全体は実際に見るのが楽しいです:-)
編集：ProGuardがアクティブ化されている場合、未使用のコードも削除されます。デフォルトのproguard.cfgで十分です。ビルドされた（デフォルトの）デバッグでは実行されませんが、最終的な.apkがコンパイルされたときに実行されます。だから実際に可能です！
ちょっと面倒ですが、3レベルのディープAndroidライブラリプロジェクトをうまく使用しました。主なユースケースは、いくつかのプロジェクト間で共有したいリソースとクラスのセットがある場合です。私はバージョン管理システムを使用しているので、シンボリックリンクは使用しません。
Androidライブラリプロジェクトは、リソースを処理するときにも大きな問題を抱えていることに注意してください。ADTはライブラリごとに1回R.javaを再構築し、各R.javaにはすべてのライブラリからのすべてのリソースIDのコピーが含まれます。ここでの主要な問題は、プロジェクト全体でリソースが再生成され、通常の「ライブラリ」で期待されるような依存関係の「jarを構築」する方法がないことです。私たちはOpenFeintとの統合を試み、ライブラリと依存関係を扱うあらゆる種類の地獄を持っていました。結局、すべてのOpenFeintソースファイルとリソースファイルを独自のプロジェクトにマージし、「ライブラリ」プロジェクトはほとんど価値がなかったため、捨ててしまったと思います。
Androidライブラリプロジェクトは、プロジェクト間でコードを共有するための不格好な方法であり、いくつかの欠点があります。ライブラリプロジェクトで達成されるすべてのことは、シンボリックリンク（2つのプロジェクトへのシンボリックリンクソース）でも達成できることがわかりました。Android Libraryプロジェクトが、他の脆弱性の低い手段では簡単に複製できないものを提供するユースケースをまだ見つけていません。