表題の件ですが、今はpfn/android-sdk-pluginを使うのがオススメです。
なぜか。
2013年6月にScalaでAndroidアプリを作るにはという記事を書いたのですが、その後Android SDKのディレクトリ構造が(r22〜？)変わったものの、記事中で使用していたjberkel/android-pluginがその変更に追従しておらず、Could not find tool “aapt”エラーが出てビルドできない問題が発生しています。
参考のSO記事はこちら。mavenのpluginの話ですが同じ問題。
pfn/android-sdk-pluginの、jberkel/android-pluginとの主な違い
- Proguardしたclassファイルをキャッシュしてくれるので、デバッグ時のビルド時間が半分くらいになる。
- ディレクトリ構造がsbtではなく、Android SDKデフォルト(android create project …)。
- local.propeties,project.properties,proguard-project.txtなどAndroidSDKの各種configファイルも使用可能(なのでbuild.sbtが膨れ上がらずに済む)。
- Android NDKサポートがない
- proguardのデフォルトの設定が違うので、書き直しが必要（これが面倒…）
また思い出したら上に書き足します。
pfn/android-sdk-pluginの問題
- sampleコードが古い
- configファイルなどを更新した場合も、reloadが必要
- ScalaTestなどScalaのテストフレームワークと相性悪い？（回避方法模索中）
AndroidアプリをScalaで書くときの問題
あと、AndroidアプリをScalaで書くと、以下の問題にぶつかりやすくなります（DalvikVM自身の問題も多分に含まれるのですが）。
- DalvikVMのmethod数上限65,535個に引っかかる
- DalvikVMのLinearAllocの上限を超えてinstall_failed_dexoptエラー
- Scalaの変なバグ(e.g.こんなの)を踏みやすくなる…けど、そのぶんScalaに貢献できる（Scalazみたいに！）
- あんまりimmutable collectionを多用するとGCが頻繁走ってカクカクする。mutable collectionを多用しつつandroid:largeHeap=“true"推奨？
ちなみにLinearAlloc問題が起きるのは基本的にAndroid2.3以下だし、DalvikVMに代わるARTがAndroid4.4から試験導入されているので、時間とともに改善するという説もあります。