第 5 章 Android Gradle プロジェクト逆引きリファレンス 84
5.10 メソッド数上限を回避したい
manifestPlaceholders
については、「5.22 Build Type
ごとに異なる値をAndroidManifest
に書きたい」で詳しく説明します。5.9 Build Type で applicationId を変更したい
Build Type
でapplicationId
を変えることはお勧めはしませんが、設定としては行うこと ができます。applicationId
を変更することで、release
ビルドとdebug
ビルドや、設定の異なって
debug
ビルドのアプリを一つの端末の中に共存させることができます。Build Type
でのapplicationId
変更では、defaultConfig
やProduct Flavor
で指定されたも のに対してサフィックスを付加します（つまり、後ろに".debug"
のような文字列を付け加える ことのみ可能）。表5.1 Build Typeの設定可能項目と初期着
項目 debug release 意味
debuggable true false デバッグ可能かどうか
jniDebuggable false false JNIのデバッグの有効/無効
renderscriptDebuggable false false RSのデバッグの有効/無効
renderscriptOptimLevel 3 3 RSの最適化レベル
applicationIdSuffix null null アプリIdのサフィックス
versionNameSuffix null null バーション名のサフィックス
signingConfig debug証明書設定 null 署名設定
zipAlignEnabled false true zipalign実行の有無
minifyEnabled false false ProGuardの有効/無効
shrinkResources false false 未使用リソース削除の有効/無効
proguardFile なし なし ProGuard設定ファイル
proguardFiles なし なし ProGuard設定ファイルリスト
multiDexEnabled false false multi-dex用ビルドの有効/無効
manifestPlaceholders null null AndroidManifest用変数定義
app/build.gradle
のandroid.buildTypes.*
の中で、applicationIdSuffix
を記述します。初期 値はnull
です（サフィックスなし）。リスト
5.10
は、デバッグビルドの場合はapplicationId
に.debug
を追加する設定例です。リスト5.10: Build Type設定でのapplicationId変更
apply plugin: 'com.android.application' android {
...
buildTypes { ...
debug { ...
// applicationId の後ろに .debug を付加 applicationIdSuffix '.debug'
} } } ...
5.10 メソッド数上限を回避したい
Android
が使用しているdex
ファイルでは、65k
個のメソッドしか内包できないという制限があります。そのため、アプリが大きくなると、この制限に到達してしまうことがあります。
この制限を回避するためにはアプリを複数の
dex
ファイルに分割する必要があるのですが、そのための仕組みが提供されています*3。
複数の
dex
ファイルの作成を有効化するためには、リスト5.11
のようにapp/build.gradle
を修正します。リスト5.11: multidexサポートを有効化する ...
android { ...
defaultConfig { ...
multiDexEnabled true }
}
dependencies { ...
compile 'com.android.support:multidex:1.0.0' }
リスト
5.11
ではdefaultConfig
で有効化の設定を行っていますが、Product Flavor
やBuild Type
で指定を行うこともできます。現時点では、ビルドバリアントに対して指定を行うこと はできません。ま た 、
AndroidManifest.xml
で 、ア プ リ ケ ー シ ョ ン ク ラ ス と し て android.support.multidex.MultiDexApplication ま た は そ の サ ブ ク ラ ス を 指 定 す る 必 要 が あ り ま す 。他 の ラ イ ブ ラ リ 等 の 都 合 で こ れ が で き な い 場 合 は 、独 自 のAppli-cation
ク ラ ス の 中 で attachBaseContext(Context) メ ソ ッ ド を オ ー バ ー ラ イ ド し 、 android.support.multidex.MultiDex.install(this); の呼び出しを行う必要があり ます。*3 詳細はhttps://developer.android.com/tools/building/multidex.html参照
リ ス ト
5.12
は android.support.multidex.MultiDexApplication ク ラ ス を ア プ リ ケーションクラスとして指定する場合の例です。リスト5.12: AndroidManifest.xmlの修正
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example.myapplication" >
<application ...
android:name="android.support.multidex.MultiDexApplication">
...
</application>
</manifest>
minSdkVersion 21
未満を対象とした現状のmultidex
サポートにはいくつかの制限事項が あります。次にわかっているものを上げておくので、リリース前によくテストを行ってくだ さい。•
アプリ起動時のセカンダリーdex
ファイルロードでANR
が発生する場合があります。この場合は、
ProGuard
で使用していないコードを削除するなどしてセカンダリーdex
のサイズが小さくなるようにしてください。• API Level 14
未満の端末ではDalvik linearAlloc
バグ*4の影響でアプリが起動しない場 合があります。これも、ProGuard
でコードサイズを削減することで改善する可能性が あります。• Dalvik linearAlloc limit
*5の影響でアプリが起動しない場合があります。API Level 14
で制限が緩和されていますが、API Level 21
未満の端末で発生する可能性があります。•
使用しているライブラリによっては、最初にロードされるdex
ファイルにクラスが存 在しないと動作しないものがあります。このようなライブラリは、現時点では使用でき ません。将来的なビルドツールのバージョンアップで、このようなライブラリにも対応 できるようになる予定です。*4 http://b.android.com/22586
*5 http://b.android.com/78035
■コラム : multidex ビルドが遅い場合の対処
minSdkVersion
が21
以上の場合と21
未満の場合では、multidex
の仕組みが異なり ます。minSdkVersion 21
以上であればART
環境で実行されることが保証できるため、ART
が もっている複数のdex
ファイルを一つのoat
ファイルにまとめる機能を前提とすることが できます。そのため、クラス間の依存を気にせずに複数のdex
ファイルへ分割を行うこと ができます。minSdkVersion 21
未満の場合はDalvik
環境で実行される可能性があるため、ひとつ目 のdex
ファイルのみでアプリを起動し、その中の処理でふたつ目以降のdex
ファイルを読 み込む処理を実行する必要があります。ひとつ目のdex
ファイルに入れておかなければな らないクラスとふたつ目以降のdex
ファイルでも問題のないクラスを、クラスの依存関係 を解析したうえで適切に振り分ける必要があります。この解析処理は時間がかかるため、