とりあえず正式版がでたので、ちょこちょこ触りながらメモ
新機能的なのは全部触れていないので、触ったら追記する予定
フルパッケージ構成
今回のバージョンからOpenJDKが同梱される形になったようです
今後こっちでしかテストしないんでしょうか。。（汗
一時期 STUDIO_JDK とかの指定も動かなくなりましたし（汗
ビルドが通る環境
android gradle plugin 2.1.+ のまま動かす
従来通りの開発が可能。現状はこちらでOKだと思います
特に InstantRun 使わないならこのままで良いかなと思います。
android gradle plugin 2.2.+ に変更する
2.2.0-RC あたりからですが
MultiDexが動く構成じゃないと、構成チェックタスクで IllegalStateException になる形になっています
理由としては、InstantRun実行時に、自動的に内部でMultiDexがtrueになる形で動くからのようです*1。
したがって、ManifestMagerを弄る記述があるとNGです。
テクブの本だと生成apkファイル名を弄る記述を書くのも基本NGって話が書いてましたね。。*2
android.applicationVariants.all{ variant ->
variant.outputs.each { output ->
output.processResources.manifestFile = file('src/main/AndroidManifest.xml')
output.processManifest.enabled=false
}
}
ただこれは大事だと思っていて、
- 低い minSDKでも基本動かせて
- 4.4以上のOSであれば wear対応になる
とかいうアプリは今後作れないことになるかと思います。*3
これに対する現実解として下記の状況が有ります
また、出力先等のフォルダ構成が2.1ベースに比べて大幅に変わっていますので
AspectJ/Kotolin? とか深いところをいじっているPluginはマダ使えないようです*6
- APT-plugin に関してはissueにあがって対応しているっぽい？
- でもうごかせないよーとか書いてるStackOverFlowの記事見たりとか。。
みたいな記述がありますがそこら辺完全に試せていません*7
tools:overrideLibrary によるlibrary側のmanifest宣言無視
一応ManifestManager には 下記の回避方法があるらしい
tools:overrideLibrary で指定された minsdk/targetSdkVersion を無視する形になるとのこと*8
- app/AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" package="hoge.fuga.app"> <uses-sdk tools:overrideLibrary="android.support.v17.leanback"/> <uses-sdk tools:overrideLibrary="hoge.fuga.wearapp"/> <uses-sdk android:targetSdkVersion="24" android:minSdkVersion="10"/>
なら、記述的に一番最後の宣言が有効になる*9
ただこの書き方だと
＝＞ * 出力AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" package="hoge.fuga.app"> <uses-sdk android:targetSdkVersion="24" android:minSdkVersion="10"/> <uses-sdk android:targetSdkVersion="24" android:minSdkVersion="10"/> <uses-sdk android:targetSdkVersion="24" android:minSdkVersion="10"/>
と置換されて最終AndroidManifest.xmlが生成されてしまうらしく
複数タグが生成されるのは、やはりよろしくないそうなので
<?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" xmlns:tools="http://schemas.android.com/tools" package="hoge.fuga.app"> <uses-sdk android:targetSdkVersion="24" android:minSdkVersion="10" tools:overrideLibrary="hoge.fuga.wearapp,android.support.v17.leanback" />
が良い形になるよう
2.2.+ ベースで gradle runtimeのバージョンを上げてみる
標準の 2.14.1より
- gradle 3.0 で1/4
- 1-2割程度？
- gradle 3.1 でさらに1/2
- 2-3割程度？
はやくなるみたいな記事や話が書いてありましたが、実測値は上記な感じでした。
また、下手にruntimeを上げてしまうとビルドが失敗することがあったり。。*10
差分ビルドが上手くいってないのかもしれません。
twitterみててちょっと思ったこと
がすごくRTされていましたが、GUI任せで設定する場合、偶にbuild.gradleが大幅に壊れることがあるので*11
カスタムTaskは極力ROOT側のbuild.gradleに書いたほうがいいです。
aospのコード見たときに、新しい機能をG様側がさっと実装しようとした時、もろテキストデータとして操作していたりするので
そこらへんは仕方ないのかなーとか思う面も実はあります*12
新機能的な物の調査
Build Cache
AS 2.3以降ではdefaultでONになる予定のとの記載有り
gradle.properties
android.enableBuildCache=true
を定義すれば使えると記載がありますが、実際はAS上から実行しないと動きません。
InstantRun/InstantRunをOFFにした初回時に下記の位置にキャッシュが作られます*13
$HOME/.android/build-cache
挙動を見ていると、
- cleanビルドをしてもココからdex済みのバイナリをコピーして使うのでビルドが速くなる
- 2.2.Xから動かなくなっていた、ソースに変更なし時にapkをそのまま転送する 辺りをちゃんと動かすっぽい挙動
- 現実的にはこのチェック動いて無くて毎回 gradlew assembleDebug が走っていますが其のTaskの戻りの高速化
あたりかなと。
あとHot Swapは結局辞めたんですね。Cold Swap*14のみ。
JRebelはHot Swap出来るんだけどな。。まあアッチは有料ですし・・
あとこのキャッシュIDE終了しても残っているんですが、どんどん溜まっていく一方なんでしょうか。。（汗 まだ ExperimentalだからOK?
Java8 support
ちゃんとコンパイルが出来るようになったよ。と書いていたので再トライ。
以前はよくわからないエラーチェックでコンパイルTaskすら行きませんでした。
まず簡単に切り替えられるように下記のように記述。☆だけ書き換えれば動く形に。
android {
...
defaultConfig {
...
jackOptions {
enabled true//☆
}
}
compileOptions {
if(defaultConfig.jackOptions.enabled){
sourceCompatibility JavaVersion.VERSION_1_8
targetCompatibility JavaVersion.VERSION_1_8
}
else{
sourceCompatibility JavaVersion.VERSION_1_7
targetCompatibility JavaVersion.VERSION_1_7
}
}
}
で、動かしてみました
- コンパイルエラー
- => まともな内容になったけど、MessageタブからJump出来ない。
- エラー文字列Copyだけって使わせる気があるのか？
- コンパイルエラーとりあえず潰した
- dex処理
- 30分たっても終わらず。アクティビティモニターで見るとCPU 200-300%彷徨いてる。。。
で論外かなと。実際通った状況を凄く知りたい
因みに、
InstantRun時には enable=trueでも無視
と有りましたが、 ビルドTaskのlow levelでjackTaskを呼んでいて、そこから戻ってこないので
挙動仕様がデグレってませんか？ と聞きたいけど、なんか裏環境設定があるのかもしれないですね。。
Layout Editor
- 今表示されているレイアウトエディタの状態が、右メニューからスナップショット保存できる
という機能が追加されたらしい。*15
相変わらず、カスタムThemeはエラーバリバリなので
AppCompat系の継承したスタイルの奴しかまともに表示できないのかなーとか思いつつ。
Layout Inspector
APK Analyzer
- Build>analize apk の項目から apkの中身を見れますよという機能。
Espresso Test Recorder
- 昔あって今は動かなくなった MonkeyRunner のEspresso版
- Espressoのテストコードを吐く
これ初めて今回使ってみた感想としては
- MonkeyRunnerのときは、waitとかのコードが入っていたのに入ってないので
- 生成テストコードをそのまま実行するとID not foundで真っ赤になる
- なぜかこの生成コードをテスト実行すると毎回clean reinstallされるので
- 毎回初回install状態からしかテストが出来ない
これ使えるのか？？ とか正直思ってしまいました。
普通にEspressoのtest codeを実行した時 clean installし直し
というお話は聞いたことがないので、この構成でできるjunit のtest構成がなんかおかしいのかもしれない
あくまでデモ用なのかな・・・（汗
Virtual Sensors in the Android Emulator
確かにEmuratorの設定の箇所に、Virtual Sensors のタブが増えていました。
体感としては
- カクカクしていて凄く重ｗ
- youtubeとかで流している、一見サクサクな環境の状態を凄く知りたい。
ほかは全然目新しく感じられず。
- GoogleApi対応のx86イメージは 5.0系まで
- 高速なエミュとかよく言われているのはこっち
- MSが出しているHyper-V対応エミュ/genymotion とかもこっち系
- arm系のimageの場合は 7.0系まで存在するが、何時もの重い状況は変わらず
- この状態で Emurator上に入っているGoogleMapが 真っ白のままだったり固まったりする
相変わらず公式のエミュは使えないな～というのが感想。
とりあえず転送してエラーが出ないことを確認するぐらい？
EmuのGPS機能について
相変わらず、使いづらいままずっと治ってない。
- genymotionとかみたいに、地名から緯度経度とか取得できない
- 緯度経度の数値入力部分がコピペしたり、入力自体も上手く出来ない
- ADTの頃に比べて、KMLの再生機能があるがこれ10行ぐらい再生するとMapがハンぐる。
多分使ってないんだろうな。。 G様の開発の方々。
一見面白そうな機能をRelease Noteに色々と書いていただいてるけど
どうなんでしょうね。。（苦笑
EmuのFingerPrint機能について
らしい。ヘルプもないので設定画面でなんかタブがあるのは分かるんですが、使い方がぜんぜんわかんないんだよな（汗
*1:そこら辺を一律エラーにしてG様が横着している
*2:InstantRunは現状Debugでしか動かないので releaseの時のみ適応するとか記述が必要かと
*3:基本チェックTaskに入っちゃってるので 5.34 IDEからのビルドを判別したい とかで逃げる方法は無いかなと
*4:リビジョンが上がると偶にビルドできなくなったりとか・・
*5:したがってADT形式のサポートは。2.2.0から完全に終了します
*6:ここらへんは出力先フォルダとか割り込みタスクとか挙動を解析して開発者の方々が対応されているので仕方ないと思う
*7:APT使っているサンプルって、単に2.2.+にしただけだとエラーになるので他のlibrary等が悪さしているのか正直判別がつかなかったり。。
*8:build.gradle側での回避方法は見当たらず・・・
*9:この順に書かないと何故かエラーになる
*10:clean rebuildすると問題なかったりしますが
*11:こういうときにgit管理していると便利〜
*12:サブプロジェクト側は結構書き換えが頻繁にあります
*14:アプリ完全再立ち上げ
*15:でもMapとかSurfaceViewとかレイアウトに張っても真っ白とか。。＜苦笑
*16:当たり前かもしれないけど。。。