Copyright © 2014 Soichiro Kashima All rights reserved. Android App Development with Gradle & Android Studio Tech Circle #3 2014.8.19 Soichiro Kashima
Jun 13, 2015
Copyright © 2014 Soichiro Kashima All rights reserved.
Android App Development with Gradle & Android Studio
Tech Circle #3 2014.8.19 Soichiro Kashima
Introduction
‣ Android の新ビルドシステムのご紹介
‣ UI などの 作り方 が注目されがちだが…
‣ ビルド は納品/リリースに関わる重要作業
‣ ストア や OS のアップデートが頻繁にあるため 常に最新仕様でリリースができる知識が必要
2
Agenda
1. 従来の Android アプリのビルド
2. Gradle & Android Studio
3. Product Flavor
4. 活用例(CI)
5. まとめ
3
従来の Android アプリのビルド
4
アプリの中身
‣ アプリ = APK ファイル = ZIP ファイル
‣ Dalvik VM / ART で動作
‣ Java → .class → .dex
5
アプリの中身
‣ Java プログラム以外にもいろいろ
‣ AndroidManifest.xml
‣ リソース
‣ 文字列,画像,色,アニメーション,…
‣ ネイティブライブラリ(*.so)
6
APK ファイルができるまでの工程
‣ ソースファイル生成(R.java,BuildConfig.java)
‣ コンパイル
‣ ProGuard(難読化)
‣ 署名なし APK ファイル作成
‣ ZipAlign
‣ 署名
7
必要になる APK ファイルの種類
‣ デザイン確認用(モックアップ)
‣ デバッグ用
‣ ステージング環境接続用
‣ UAT用(お客様用)
‣ 本番用
8
さらに種類が必要な場合も… Free/Pro,Google Play,
Amazon,…
手作業での管理は困難
‣ あまりにも種類が多い
‣ 自動化するためにビルドの知識が重要
9
従来の Android アプリビルド
‣ 元々 Android がサポートしていたビルド方法
‣ Eclipse ADT → Export (GUI)
‣ Ant
10
Ant の限界
‣ 表現力が低い
‣ 標準で用意されているのは Debug / Release のみ
‣ 工夫すれば増やせるが…
11
さすがに無理がある
‣ XXX 環境向けの APK 作って
‣ お客さんが XXX に YYY の設定で試したいって
‣ 途中でもいいから試させて
‣ これ前入れてもらったのと何が変わったの?
12
新しいシステムへの期待…
‣ ビルドの管理は大変になるばかり…
‣ そろそろ新しい仕組みが必要なのでは?
‣ と思っていたところに…!
13
Gradle & Android Studio
14
Android Studio 登場15
https://developer.android.com/sdk/installing/studio.html
Android Studio 登場
‣ 2013年登場,つい最近までα版,現在β版(0.8.0)
‣ Eclipse でなく IntelliJ IDEA ベース
‣ Gradle と統合されている
‣ Gradle + Android Gradle Plugin
16
Android Studio 登場
‣ Gradle は Groovy の DSL であり拡張が容易
‣ Gradle
‣ http://www.gradle.org/
‣ Groovy
‣ http://groovy.codehaus.org/
17
Android Studio 登場
‣ Product Flavor による複数のビルド設定管理が可能
‣ Ant / Maven / Ivy を統合できる依存関係管理
‣ マルチプロジェクト構成が可能
18
Android Studio 登場
‣ IDE でもコマンドラインでも同じ動作
19
IDE - Android Studio CLI - Gradle
Ant と Gradle
‣ ビルド定義
‣ Ant: build.xml = XMLファイル
‣ Gradle: build.gradle = Groovyスクリプト
‣ コマンド
‣ Ant: ant
‣ Gradle: gradle / gradlew
20
Gradle 自体はインストール不要
‣ Gradle Wrapper という数ファイルだけあれば OK
‣ シェルスクリプトと .bat がセット
‣ バージョン管理すれば皆同じバージョンを使える
‣ IDE がなくても IDE と同じビルドができる
21
‣ コマンド例
Gradle Wrapper
$ ./gradlew tasks # タスク一覧
$ ./gradlew assembleDebug # Debugビルド
$ ./gradlew assemble # 全種類ビルド
$ ./gradlew installDebug # インストール
$ ./gradlew connectedAndroidTest # 端末接続テスト
$ ./gradlew uninstallDebug # アンインストール
$ ./gradlew uninstallAll # 全アンインストール
22
依存関係管理
‣ 数行書くだけで簡単にライブラリを取り込める
‣ Eclipse のような面倒な設定が不要
23
‣ フェーズごとに依存関係を定義できる
依存関係管理
dependencies {
compile 'com.android.support:support-v4:20.0.+'
compile 'com.google.android.gms:play-services:5.0.77'
compile 'com.actionbarsherlock:actionbarsherlock:4.4.0@aar'
! androidTestCompile ‘xxxx:yyyy:1.0.0’
!}
24
APKに含める
テストのみ利用
‣ 機会があればぜひ使ってみてください!
依存関係管理
dependencies {
// ダイアログライブラリ
compile 'com.github.ksoichiro:simplealertdialog:1.1.1@aar'
// 入力チェックライブラリ
compile 'com.github.ksoichiro:androidformenhancer:1.1.0@aar'
// ボタンUIライブラリ
compile 'com.github.ksoichiro:richbuttons:0.1.1@aar'
}
25
カバレッジ計測
‣ JaCoCo が使える
‣ リフレクションがあると失敗する…(VerifyError)
26
android { jacoco { version = '0.7.0.201403182114' } : buildTypes { debug { testCoverageEnabled = true
利用するバージョン指定
計測有効化
ディレクトリ構成
‣ Eclipse と違い自由に構成可能
‣ Java ソースコード
‣ XML リソース
‣ テストコード
‣ AndroidManifest.xml
27
‣ Eclipse に合わせることも可能 → 段階的に移行可
ディレクトリ構成
android { sourceSets { main { manifest.srcFile 'AndroidManifest.xml' java.srcDirs = ['src'] resources.srcDirs = ['src'] aidl.srcDirs = ['src'] renderscript.srcDirs = ['src'] res.srcDirs = ['res'] assets.srcDirs = ['assets'] }
28
Product Flavor
29
Product Flavor
// アプリのIDをFlavorごとに分けて同時にインストールできるようにする
productFlavors { dev { // 開発用ID
applicationId "com.domodomo.android.dev" } dgate { // DeployGate用ID
applicationId "com.domodomo.android.dgate" } prod { // 本番用ID
applicationId "com.domodomo.android" } }
30
‣ ビルド時に少しだけ内容を変えられる
Product Flavor
‣ ソースも分離可能
‣ デバッグ機能の ON / OFF
‣ アプリ名の切り替え
‣ アイコンの切り替え
‣ Permission の有無
31
Build Variant
‣ ビルド構成を変える要素は2つある
‣ BuildType : ビルド自体の設定を切り替える
‣ ProGuard の有無,署名の種類など
‣ ProductFlavor : プログラムの内容を切り替える
‣ 有料/無料,アプリ名,API接続先など
32
Build Variant
‣ コマンドは ProductFlavors x BuildTypes
‣ installDevDebug / installDevRelease
‣ installStgDebug / installStgRelease
‣ installProDebug / installProRelease
33
Build Variant
‣ コマンドがやたら長くなるが省略可能
‣ 単語ごとに識別可能な分だけ入力すればOK
‣ installStagingDebug → iSD
‣ lintDevDebug → lDD
‣ check → ch
34
Build Variant
‣ 依存関係も Flavor ごとに指定できる
‣ dgateCompile ‘com.deploygate:sdk:2.4.+’
‣ DeployGate 配布用ビルドのみ DeployGate SDK
を含めてビルドする
(dgate という Flavor を定義している場合)
35
複数の Product Flavor
‣ Flavor の種類が複数ほしい
‣ API X の環境(開発/ステージング/本番)
‣ API Y の環境(開発/ステージング/本番)
36
複数の Product Flavor
‣ flavorDimensions で複数グループを組み合わせ
37
flavorDimensions "abi", "version"
!!productFlavors {
freeapp {
flavorDimension "version"
...
}
x86 {
flavorDimension "abi"
...
x86-freeapp-debug
x86-freeapp-release
arm-freeapp-debug
arm-freeapp-release
mips-freeapp-debug
mips-freeapp-release
x86-paidapp-debug
x86-paidapp-release
arm-paidapp-debug
arm-paidapp-release
mips-paidapp-debug
mips-paidapp-release
有料/無料アーキテクチャ
少し前まではflavorGroupsだった
利用例
‣ グルーピング例
‣ API等の外部接続先
‣ アーキテクチャ(ARM,x86,MIPS,…)
‣ リリース先のストア,配布サービス
‣ 製品/サービスのグレード(Lite,Pro)
‣ α/β/製品版(バグレポート自動送信機能の有無等)
38
Groovy / Gradle の活用
‣ 少しスクリプトを書けばこんなことも
‣ APK ファイル名にバージョン番号を入れる
‣ APK ファイル名にコミットハッシュ値をつける
‣ APK ファイル名に Flavor 名を入れる
39
Java プラグイン
‣ Javaプラグインと互換性がないのが難点
‣ Javaプラグイン?
‣ 標準的な Java プロジェクトをビルドできる
‣ Java プラグイン依存のライブラリが使えない
40
Java プラグイン
‣ .gradle ファイルを分ければ OK → CI 等に有効
‣ ./gradlew :app:connectedCheck
‣ 通常の端末接続テスト
‣ ./gradlew -p app -b app/coveralls.gradle coveralls
‣ カバレッジ計測結果を Coveralls へ送信
41
活用例(CI)
42
‣ Push をトリガーにして Gradle でビルドDocker container (Ubuntu)
CI で最新アプリを常時利用可能に43
JenkinsDocker
Android SDK
Git repo
GitLab
App project
Gradle Wrapper
APK
PC
1. git push
2. web hook
3. git clone4. docker run
5. ./gradlew assemble
APKAPKAPKMaven Central
android m2repository
‣ Push をトリガーにして Gradle でビルドDocker container (Ubuntu)
CI で最新アプリを常時利用可能に44
JenkinsDocker
Android SDK
Git repo
GitLab
App project
Gradle Wrapper
APK
PC
1. git push
2. web hook
3. git clone4. docker run
5. ./gradlew assemble
APKAPKAPKMaven Central
android m2repository
‣ Push をトリガーにして Gradle でビルドDocker container (Ubuntu)
CI で最新アプリを常時利用可能に45
JenkinsDocker
Android SDK
Git repo
GitLab
App project
Gradle Wrapper
APK
PC
1. git push
2. web hook
3. git clone4. docker run
5. ./gradlew assemble
APKAPKAPKMaven Central
android m2repository
‣ Push をトリガーにして Gradle でビルドDocker container (Ubuntu)
CI で最新アプリを常時利用可能に46
JenkinsDocker
Android SDK
Git repo
GitLab
App project
Gradle Wrapper
APK
PC
1. git push
2. web hook
3. git clone4. docker run
5. ./gradlew assemble
APKAPKAPKMaven Central
android m2repository
‣ Push をトリガーにして Gradle でビルドDocker container (Ubuntu)
CI で最新アプリを常時利用可能に47
JenkinsDocker
Android SDK
Git repo
GitLab
App project
Gradle Wrapper
APK
PC
1. git push
2. web hook
3. git clone4. docker run
5. ./gradlew assemble
APKAPKAPKMaven Central
android m2repository
‣ Push をトリガーにして Gradle でビルドDocker container (Ubuntu)
CI で最新アプリを常時利用可能に48
JenkinsDocker
Android SDK
Git repo
GitLab
App project
Gradle Wrapper
APK
PC
1. git push
2. web hook
3. git clone4. docker run
5. ./gradlew assemble
APKAPKAPKMaven Central
android m2repository
‣ Push をトリガーにして Gradle でビルドDocker container (Ubuntu)
CI で最新アプリを常時利用可能に49
JenkinsDocker
Android SDK
Git repo
GitLab
App project
Gradle Wrapper
APK
PC
1. git push
2. web hook
3. git clone4. docker run
5. ./gradlew assemble
APKAPKAPKMaven Central
android m2repository
Job終了後は Docker containerは破棄, Workspaceは残るので APKダウンロード可能
‣ Gradle じゃなくてもできる? Gradle だと簡単かも
GitHub + Travis CI + Coveralls
50
GitHubPC Travis CI Coveralls
‣ Gradle じゃなくてもできる? Gradle だと簡単かも
GitHub + Travis CI + Coveralls
51
GitHubPC
1. git push 2. web hook
Travis CI Coveralls
3. POST
‣ Gradle じゃなくてもできる? Gradle だと簡単かも
GitHub + Travis CI + Coveralls
52
GitHubPC
1. git push 2. web hook
Travis CI Coveralls
3. POST
複数のAPIレベルのエミュレータで ./gradlew assemble や
./gradlew connectedAndroidTest を実行できる
‣ Gradle じゃなくてもできる? Gradle だと簡単かも
GitHub + Travis CI + Coveralls
53
GitHubPC
1. git push 2. web hook
Travis CI Coveralls
3. POST
複数のAPIレベルのエミュレータで ./gradlew assemble や
./gradlew connectedAndroidTest を実行できる
成功したら JaCoCoのカバレッジデータを
Coverallsへ送信
‣ Gradle じゃなくてもできる? Gradle だと簡単かも
GitHub + Travis CI + Coveralls
54
GitHubPC
1. git push 2. web hook
Travis CI Coveralls
3. POST
複数のAPIレベルのエミュレータで ./gradlew assemble や
./gradlew connectedAndroidTest を実行できる
成功したら JaCoCoのカバレッジデータを
Coverallsへ送信
テスト結果やカバレッジは プロジェクトトップページで バッジとして確認できる
まとめ
55
Gradle/Android Studio 採用メリット
‣ ビルド管理が従来に比べて圧倒的に柔軟で便利
‣ IDE と CLI の結果が同じでありビルドに安心感
‣ 依存関係管理が手軽でライブラリ導入しやすい
‣ 開発スタートに必要なセットアップが少ない
56
Gradle/Android Studio 採用リスク
‣ α 版の間は激しく仕様変更があった→今後は…?
‣ Gradle 自体が頻繁にバージョンアップしている
‣ CheckStyle 等,Eclipse と統合してツールを使っていた場合は移行が難しいかも
‣ Eclipse に最適化された人が多いと抵抗があるかも
57
最新情報をチェックしよう
‣ New Build System - Android Tools Project Site
‣ http://tools.android.com/tech-docs/new-build-system
58
Thank you!
59