Android Studio でのライブラリ作成と再利用

ライブラリプロジェクトの作り方

　ざっと調べた限りでは、Android Studio ではライブラリだけのプロジェクトというのは作れないみたい。普通にアプリとしてプロジェクトを作って、その中でライブラリにしたい部分を別モジュールに分ける。

1. まず普通に Empty Activity とかで新しいプロジェクトを作成する。プロジェクトにはデフォルトのモジュールとして app モジュールが作られる。アクティビティなしで作っても app モジュールは必ず作られるので、動作テストアプリとして使えばよろし。

2. File ＞ New ＞ New Module で Android Library を作成すると、ライブラリモジュールの雛形が作られる。

3. app モジュールからライブラリモジュール内のクラスなどを使用するには、app モジュールの build.gradle を編集し、dependencies に以下の一行を追加。Android Studio 3 から記法が変わった ので注意。

   // Android Studio 3.x の場合
   implementation project(':ライブラリモジュール名')
   
   // Android Studio 2.x を使っている場合は 以下のように
   compile project(':ライブラリモジュール名')
   

　これで、アプリとライブラリを分離できたので、再利用したいコードやリソースはライブラリモジュール側に書いていけばＯＫ。

別のプロジェクトのライブラリモジュールを利用

　上の手順で再利用したいコードの分離はできたので、次は他のプロジェクトからライブラリモジュールを利用する手順。

　ここでは例として、以下のようなフォルダ構成で、MyApplication プロジェクトから、MyLib プロジェクトの testlib モジュールを利用したいとする。

+-[MyLib]            ＜ライブラリプロジェクト
|   +-[app]
|   +-[testlib]      ＜ライブラリモジュール
|
+-[MyApplication]  　＜別のプロジェクト
    +-[app]          ＜ここから testlib を利用したい

1. MyApplication 側の setting.gradle を編集。
   incluede に testlib を追加して、testlib の参照先フォルダを指示する。この時点で、MyApplication プロジェクトに testlib モジュールが表示される。

   include ':app', ':testlib'
   project(':testlib').projectDir = new File(settingsDir, '../MyLib/testlib')
   

   上記の場合、settingsDir (setting.gradle のフォルダ) からの相対パスでの指定。絶対パスでもいいけど、共同作業で困るので普通はやらない。

2. あとは、MyApplication 側の app/build.gradle を編集して、dependencies にライブラリモジュールを追加するだけ。

   // Android Studio 3.x の場合
   implementation project(':testlib')
   
   // Android Studio 2.x の場合
   compile project(':testlib')
   

3. もしこの時点で 「Unable to resolve dependency for ...」 などとエラーになる場合は、アプリ側とライブラリモジュール側の Build Variants の構成が違うためうまく連動できない状態なので、詳しくは 次の章 を参照。

　これで、MyApplication から testlib のクラスやリソースの利用はもちろん、まるで同じプロジェクトかのように testlib 側のソースも修正できるし、連動してビルドされるようになる。

アプリとライブラリの Build Variant の連動

　Android Studio 3.x からは、implementation project() で追加したモジュールについては、自動的にアプリ側と同じ Build Variant で連動してビルドされる。Android Studio 2.x では自動的にやってくれなかった（後述）ので嬉しい。

　ただ、この 「アプリ側と同じ Build Variant」 というのが曲者で、アプリ側とライブラリ側で buildTypes や productFlavors の構成が一致しない場合、「依存関係が解決できない！」とか怒られる。

　解決できない状況と対応策についてはざっくり以下。

buildTypes {
    debug {
    }
    beta {
        // ライブラリ側に beta がない場合は代わりに release を使うよう指示
        // 優先度順に複数指定可
        matchingFallbacks = ['release']
    }
    release {
    }
}

defaultConfig {
    // ライブラリ側にだけ存在する dimension について、どのフレーバーを
    // 使用すべきか指示。フレーバーは優先度順に複数指定可。
    // defaultConfig に書いた場合は全フレーバーで共通設定。
    missingDimensionStrategy 'dimension名' 'フレーバー１' 'フレーバー２' ... 
}
productFlavors {
    trial {
        // フレーバーごとに指示する事も可能
        missingDimensionStrategy 'dimension名' 'フレーバー１' ... 
    }
}

BuildConfig はアプリとライブラリで別

　debug ビルドと release ビルドで処理を変えたい場合、

if ( BuildConfig.DEBUG )
{
    // debug 時の処理
}

などと書くが、この BuildConfig はモジュールごとに別 に作られてるので注意。

　ソース内で BuildConfig を初めて使う場合、エディタが気をつかって自動で import してくれるが、よく見ずうっかり関係ないモジュールの BuildConfig をインポートしてしまうと、以後 debug ビルドなら動くはずのコードが動かなかったり、謎の現象に悩まされる。

アプリモジュールとライブラリモジュールのリソースの関係

　ライブラリモジュールを作成すると、ライブラリ側にも AndroidManifest.xml やリソース用のフォルダが自動的に作られるが、マニフェストの各種設定やリソースIDはライブラリ側とアプリ側で独立してる訳じゃなくて、ビルド時に無理矢理マージしてるだけ なので、それを意識して使わないと意図せぬ事態が起きる。以下は特に注意。