ADTでGradleする（のはまだ早い）

mixiさん主催で行われた、app道場#2（http://atnd.org/events/49386）で発表した内容のまとめです。

はじめに

とつぜんですが、自分が個人でandroidアプリの開発を行っているPCを紹介します。

MSI U100

key	value
CPU	Atom1.6GHz
HDD	150GB
メモリ	DDR2-667 2GB
解像度	1024x600
OS	xUbuntu12.04

08年製のネットブックですが、いちおうこれでもアプリを何本か開発できているので、「低スペックPCでもアプリがつくれるのがAndroidのいいところだよ！」という謳い文句が言えました。
そう、android studioがリリースされるまでは……。

android studioでは解像度高が600pxだと、プロジェクト作成時にボタンが隠れて押せません。他は問題ないのに、ここだけが押せません。description欄はこんなに高さいらないよ、ここ削って600pxに収めよ？と思いますが、とりあえずボタンが埋まります。

ちなみに1024x768のディスプレイに外部出力すれば、このボタンは表示されます。

android studio tips

• 解像度の高さが600pxだとプロジェクトが作れない
• 解像度の高さが768px以上だとプロジェクトが作れる

先日のABC2014sでも煽り気味なスライドが公開されたりしましたが、確かにandroid studio、というよりGradleを使った依存性の管理などは非常に魅力的です。

なのでこう思いました。 ADTでもGradleがしたい。

ADTプロジェクトにGradle設定ファイルを追加

ADTにGradleの設定ファイル（build.gradle）を追加するのは簡単です。以前からエクスポートに「Generate Gradle build files」というものが追加されています。

これを使って、Gradle対応させたいプロジェクトにチェックをいれて完了ボタンを押せば、プロジェクトのルートフォルダ直下に対応したbuild.gradleが出力されます。
なお、選択したプロジェクトが読み込んでいるライブラリプロジェクトにも、同様にbuild.gradleが出力されています。

gradleラッパー一式のコピー

android studioでプロジェクトを作成した際に作られているgradleラッパー一式は、android SDKの中に組み込まれているので、これをbuild.gradleと同じ階層、ルートプロジェクトの直下にコピーしておきましょう。

(android SDK)/tools/templates/gradle/wrapper/

gradle/、gradlew、gradlew.bat全てです。.batはwin用のラッパーですが、コピーしたところで何の問題もありません。

Gradleのビルド実行

コンソール上で実行

実行する前に、JDKとandroiSDKのホームを環境変数で設定する必要があります。JAVA_OPTSは特に必要ではないと思いますが、javaから返ってくるメッセージが文字化けするのでいれています。

export JAVA_HOME="(JDKのホーム)"
export ANDROID_HOME="(android SDKのホーム)”
export JAVA_OPTS="-Dgroovy.source.encoding=UTF-8 -Dfile.encoding=UTF-8"

そしてビルドしたいプロジェクトのルートフォルダ直下へ移動し、下記コマンドを打ち込めばビルドできます。

$./gradlew clean build

これでbuild/apk/以下に、apkがビルドされます。いちおう上記の引数に「installDebug」を追加すれば、apkのインストールも実行してくれます。

その他のgradlewで使う引数は、通常のgradleで使うものと同じ（はず）です。

eclipse上で実行

eclipseの「外部ツール構成」でgradlew用の実行構成を追加すれば、eclipse上からでも実行することができます。

-メイン-
名前：（お好きな様に）
ロケーション：${project_loc}/gradlew
作業ディレクトリー：${project_loc}
引数：--daemon ${string_prompt}

-環境-
（新規ボタンを押して以下の2つを追加）

変数：ANDROID_HOME
　値：（シェルで設定したANDROID_HOMEの値）

変数：JAVA_OPTS
　値：（シェルで設定したJAVA_OPTSの値）

これでビルドしたいプロジェクトを選択した状態で先ほど作成した外部ツール構成の実行を選択すると、引数の入力を促されるので同様に「clean build」とうちこめばeclipseからでも実行が可能です。

問題点

.aarが読めない

gradleによるmavenリポジトリを利用した外部ライブラリの管理が、個人的にはgradleを使う一番の利点だと思いますが、実はこれで落としてくるライブラリの大半はAARというフォーマットで構成されていて、これがADTでは読み込めないという最大の欠点があります。

すでにこれはAOSPでも話題になってはいますが、もう半年以上も対応がされていない状態です。
Issue 59183 - android - Allows Eclipse ADT plugin to work with .AAR files - Android Open Source Project - Issue Tracker - Google Project Hosting

AARが読み込めないと、当然ライブラリのクラス関係がADTからは見えないのでエラーの嵐です。
クラス自体であれば、build/explode-aar/以下で引っ張ってきたclasses.jarをjavaのビルドパスに追加するという強引なやり方をすればいいですが、リソース情報の読み込みがどうしてもできません。

「もはや俺達でサポートするものを作ったほうがいいんじゃないか」という意見が、上のIssueのリンク先でもありますが、今後対応されるかは不明です。

※ いちおう公式は「ADTを打ち切るつもりはない」とは言ってるので、対応しないはずはないと思ってはいますが……。

ADTのビルドがGradleビルドに変わるわけではない

ややこしいですが、結局ADT自体がGradleビルドを優先して行うようになっているわけでもないので、両者の設定をキチンと同期させておかないと、ADTでのビルド結果とGradleでのビルド結果に差異が生まれます。せっかくの保守性が根本から死んでしまっています。

じゃあ何に使えるか

こうなるともはや「頑張ってまでやる必要があるのか」という疑問が浮かびますが（同時に答えも）、このやり方だと本来のプロジェクトの構成を変えないまま、Gradleによるビルドが行えるようになるため、非Gradle対応の外部ライブラリを勝手にForkしてAARフォーマット出力＋Github上でMavenリポジトリ形式で公開するときには便利じゃないかと思います。

実際に、自分が以前紹介したことのあるAndEngineというライブラリがありますが、Mavenリポジトリ形式の公開が当分なさそうなので、自分が勝手にAAR出力して、Github上でMavenリポジトリ公開させてます（まだ検証がほとんどできていませんが）

yamacraft/AndEngine

結論

• ADTでGradleを使うのはまだ早い
• 他人のライブラリを勝手Mavenリポジトリ化するのには使えそう

実際AARが読めないことがわかった時点で調査をほとんど止めてしまいましたが「このやり方なら問題なくADT＋Gradleできる」という意見があればコメントにてよろしくお願いします。