compileSdkVersion 23でのレガシーな環境構築ネタのメモ
ねた１）compileSdkVersion 23 の話
AS版の compileSdkVersion 23 の記事は
で記載されているわけですが、
この形式だとant/ADTだとbuildできない。
android {
compileSdkVersion 23
buildToolsVersion "23.0.2"
useLibrary 'org.apache.http.legacy'
}
は確かに楽なんだけどね・・。
小規模な編集/ソース解析のために検索するだけならASでいいんだけど
デバック機能はまだADTに追いついていないからな。。（遠い目
> $ANDROID_SDK_HOME/platforms/android-23/optional/org.apache.http.legacy.jar
にあるから、それをlibsに突っ込むほうがはやい話になるわけですけど
> ant build
は今だオフライン環境での CIビルド としては現役のはずで、
そちらのサポートをしない時点で死んでるよな-
とか思ったりもしてる。。。
まあ書くとしたら
android {
//compileSdkVersion 22
compileSdkVersion 23
buildToolsVersion "23.0.2"
}
dependency {
if(android.compileSdkVersion.CompareTo("android-23")>=0){
compile files("${android.sdkDirectory.getAbsolutePath()}/platforms/${android.compileSdkVersion}/optional/org.apache.http.legacy.jar")
}
あたりのほうが切り替えやすいかと思う。
まあ今後もoptionalで org.apache.http.legacy.jar を提供してくれればだけどね。。（苦笑
は内部に書換対象ソース持ってない場合は、SDKのソースをコピって持ってくるのかな〜
とか思って読んでましたね *1
12/24追記)
上記のbuild.gradleは gradle assembleDebugだと問題ないのですが
gradle assembleReleaseで proguardをかけると
- jarを二度読みエラー ＝＞duplicate entry
になる*2
どうも
> compile files(XXX)
指定をするとダメらしくて、libsに org.apache.http.legacy.jar を突っ込むと問題ない
org.apache.http.legacy.jarを入れない場合は、以下の書き方となる
- build.gradle
dependency {
}
if(android.compileSdkVersion.CompareTo("android-23")>=0){
android.useLibrary "org.apache.http.legacy"
}
でもこの書き方は苦しいね。
gradle syncとかproject structure とか
何からのタイミングでASにリフォーマットで消されそうなコード。。。（苦笑
ねた２）library-project をASとADT共用する話
なお話があるわけだけど、
ADT形式を活かしつつ導入していると、
- library-project側のmin-sdk等の記述をマージして、一番大きい物を使おうとする
というmanifestmergerの挙動対策ができる。
> manifestmerger.enabled=true
記載すればADTでも同じ動きになるらしいが。。。
最近安易に アプリが4.0以降みたいな対応になるのは、
aarの中のAndroidManifest.xmlの記述のせいで
- 特定のバージョン以降で機能が使える
- それ以下の場合は機能を表示させない/使わない
みたいな書き方ができなくなってきている。
の話みたいに build.gradleで頑張る話があるけど
- AS上でGradleSync/Project Settingsで設定をいじる
とよく記述が消えるので
> apply from :'XXXX'
な形で外出ししておかないと凄く危ない・・。
まあ理想を言えば
のsoの話も複数apkを作るという話になると、業務だと凄く揉めるので
soを自動的に後から追加Downloadが理想だよなーとか思いつつ
うまい方法が考えつかないでいたりする
ねた３）オフラインビルド環境の構築の話
Offlineな環境にandroidアプリのGradleのビルド環境作ってて発狂しそうになった。
@momontyo 一つ質問なのですが、android grade plugin自体は NETからダウンロードすると思うのですが、他の環境で実行してから$HOME/.gradle を持っていく感じですか？ それともjcenterからplugin自体を落として参照できます？
2015-11-19 22:22:21 via YoruFukurou to @momontyo
@kimukou2628 他の環境で実行してから$HOME/.gradle を持っていく感じにしました。-gでGradleHome指定したらちょっとはマシですが絶対パスで記憶されててきったないですね。
今はまってるのは android gradle plugin自体をofflineに出来ないかどうか。
com.android.tools.build.gradle
Gradleになる前はADTに付属するantで、あれはあれでbuild-tools/ant/build.xml依存してる感じがして微妙だったような気がするが、ビルドできるかできないかで困ったりしなかった。
あと困ってたのは、Android Studioだと普通にビルドできるのに、コマンドからのGradleだとjcenterにhttps接続できなかった。keystoreにSSL証明書を登録とかしてみたが変わらず。jcenterをhttp定義して切り抜けた。
プロキシ関係かなとは思う。
あたりからjarが直接落とせるから、ローカルのflatDirで行けるかな-
というのを試そうかというのが明日辺りのタスク。
でも普通に
> gradlew tasks
を実行した時 jarをジャラジャラ落としてくるので
依存関係が芋づる的に凄いことになってやっぱり無理かもしれない（苦笑
まあセキュリティのためにofflineでというのは普通にある話ですけどね。。
結局のところ
- IS◎S等のセキュリティ強化の、開発者自体を蔑視してる日本の経営者視点
- NW前提の欧米スタイルの開発環境
は両立しないということなんだよな。。(苦笑
開発者側に不都合が有っても頭使ってなんとかしろという感じ。。
まあ仕方ないんでしょうけど。。
ねた３補足）
gradleの問題って
- $HOME/.gradle にキャッシュがDLされる
- そのキャッシュに絶対パスが書かれてる
あたりだから
set GRADLE_USER_HOME=C:/opt/.gradle ./gradlew tasks
とか
./gradlew tasks --gradle-use-home=C:/opt/.gradle
で位置を固定ができるのは気がついた。
まあこれで可搬性を良くしてオフライン環境に持ち込むぐらいしかないのかな〜
