読者です 読者をやめる 読者になる 読者になる

compileSdkVersion 23でのレガシーな環境構築ネタのメモ

ねた1)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 を提供してくれればだけどね。。(苦笑

  • android.util.FloatMath =>java.util.Math に置き換える件

は内部に書換対象ソース持ってない場合は、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にリフォーマットで消されそうなコード。。。(苦笑



ねた2)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が理想だよなーとか思いつつ
うまい方法が考えつかないでいたりする



ねた3)オフラインビルド環境の構築の話

今はまってるのは android gradle plugin自体をofflineに出来ないかどうか。
com.android.tools.build.gradle

あたりからjarが直接落とせるから、ローカルのflatDirで行けるかな-
というのを試そうかというのが明日辺りのタスク。

でも普通に
> gradlew tasks
を実行した時 jarをジャラジャラ落としてくるので
依存関係が芋づる的に凄いことになってやっぱり無理かもしれない(苦笑

まあセキュリティのためにofflineでというのは普通にある話ですけどね。。

結局のところ

  • IS◎S等のセキュリティ強化の、開発者自体を蔑視してる日本の経営者視点
  • NW前提の欧米スタイルの開発環境

は両立しないということなんだよな。。(苦笑

開発者側に不都合が有っても頭使ってなんとかしろという感じ。。
まあ仕方ないんでしょうけど。。



ねた3補足)

gradleの問題って

  • $HOME/.gradle にキャッシュがDLされる
  • そのキャッシュに絶対パスが書かれてる

あたりだから

set GRADLE_USER_HOME=C:/opt/.gradle
./gradlew tasks

とか

./gradlew tasks --gradle-use-home=C:/opt/.gradle

で位置を固定ができるのは気がついた。
まあこれで可搬性を良くしてオフライン環境に持ち込むぐらいしかないのかな〜

antというかbuild.xml弄りたくないっていう話みたいですし。。*3

*1:過去の同じような話だと、2系端末に対するWebViewのSSL対応の話を思い出す

*2:普通のjavaプロジェクトでもおこるらしいので、paralel指定の弊害らしい。paralel=falseなら起きないとのこと

*3:確かにJSっぽいスクリプト言語の方が楽なのは否定しない