AS3.0 と AS2.3をスイッチコンパチで試せる環境を作る

はじめに

AS3.0-Beta 以降古いプロジェクトは、AS2.3で動かさざるをえない状況ですごいストレスなんですが

G様が過去互換対応してくれることを祈りつつ、どちらでもすぐ試せる環境を作っておく*1

動作環境

  • macOS Sierra
  • 16G
  • HDDタイプのiMac
  • gradle plugin 2.3.3
  • gradle plugin 3.0-Beta2
  • gradle runtime-4.1-bin

現状のAS3.0 Beta以降の問題点

Google APIsをつかったプロジェクト

local.aarをつかったProjectは動かせない

  • issueにあがっているので、コチラは多分治るんではないかと
  • というか、library projectをつかったProjectは補完index作成が不安定になった
    • 基本的にG様は社内mvnに上げる運用だとお聞きしたしな・・*2

検証状況

コマンドラインビルドベースの話

これBetaからaapt2をデフォルトに使うようになってるという話で、

aapt2に対応していない *3UIライブラリを使っている場合はoffってくださいとのことらしい

これ いつものG様サイトだと3倍速みたいな表記されるんだけど、環境依存なんですかね(汗

InstantRunも2秒と表示されることあるけど、実際測るともっと時間かかってるし変更を認識してくれないことが多々。

最近は下記な状況になってて、正直微妙や・・

  • InstantRun offっててもbuild cacheを勝手に使ってしまい変更認識してくれない
  • clean project / rebuild project=> debug実行が必須な場合が多い*4

26.0.1 なら治ってる? みたいなStackOverFlowも出てたけど、、、そんなことはない感じ

これはissue対応待ち。GUI Plugin側には aapt2をoffるオプション無いからなー

今回使った検証用のスイッチコンパチが出来る環境設定

毎回書き換えるのが大変なので下記の環境は作っておく

ファイル構成

build.gradle
   app
      build.gradle
      build30.gradle  ・・3.0ベースに書き換えたもの
   library
      build.gradle
settings.gradle
gradle.properties

切り替え設定

  • gradle.properties
#ここに記述すると GradleSync が抑えられるらしい
#_compileSdkVersion=25
_compileSdkVersion=26

_buildToolsVersion=26.0.1
#_buildToolsVersion=25.0.3


_playServicesVersion=11.0.4
#_playServicesVersion=10.2.6

# 26.0 にすると3.0系だと Gradle sync failed: java.lang.AssertionError(IDE上のみ)
_supportLibraryVersion=26.0.+
#_supportLibraryVersion=25.3.1
#_supportLibraryVersion=24.2.+


# === using 3.0 is disable ====
org.gradle.caching=true
#android.enableBuildCache=false
android.enableD8=true

# G様 UIライブラリ以外を使う時はfalse
android.enableAapt2=false

#_JavaVersion=VERSION_1_7
_JavaVersion=VERSION_1_8

# switch plugin//★ 切り替え用
_use30File=true
_use30Plugin=true
  • settings.gradle
include ':app'
include ':library'

def props = loadProperties("$rootDir/gradle.properties")
println "_use30File="+props._use30File
if(props._use30File == 'true'){
    setBuildFileName(rootProject)
}else{
    println "[buildFile(any)]build.gradle"
}

def setBuildFileName(project) {
    String myFileName="build30.gradle"

    project.children.each { childProject ->
        //childProject.buildFileName = "${childProject.name}.gradle"
        def fullPath = "${childProject.projectDir}/${myFileName}"
        if(new File(fullPath).exists()){
            childProject.buildFileName = myFileName
        }
        assert childProject.projectDir.isDirectory()
        assert childProject.buildFile.isFile()
        println "[buildFile(${childProject.name})]"+ childProject.buildFileName
    }
}

def loadProperties(filename) {
    def props = new Properties()
    file(filename).withInputStream {
        props.load(it)
    }
    return props
}

settings.gradle のタイミングだと gradle.propertiesは読み込まれていないので、変数として認識できないので直読みする

また、root/build.gradle の buildScript も同じ形になります

DSL記述変更により一部修正が必要な箇所

gradle 2.3とコンパチで動かす記述

  • app/build.gradle
android {
    applicationVariants.each { variant ->
        if (variant.buildType.name.equals("release")) {
            // releaseビルドのみ、ファイル名にVesionNameとビルド時間を付与
            variant.outputs.each { output ->    //★
                if (output.outputFile != null && output.outputFile.name.endsWith('.apk')) {
                    def versionName = variant.versionName
                    def date = new java.text.SimpleDateFormat("yyyyMMdd_HHmmss").format(new Date())
                    def newName = "apk_v${versionName}_${date}.apk"
                    
                    //=== 修正 ====
                    if (output. hasProperty('outputFileName')) { 
                        output.outputFileName = newName 
                    } 
                    else{ 
                        output.outputFile = new File(output.outputFile.parent, newName) 
                    }
                }
            }
        }
    }
}

ちなみに★はallである必要はない。eachで問題なく動きます

gradle.propertiesの変数で切り替えている所

  • rootの部分も書き換えできたので記述修正

 

  • root/build.gradle
buildscript {
    repositories {
        jcenter()
        google()
    }
    dependencies {
        if(project.hasProperty('_use30Plugin') && _use30Plugin == 'true'){ 
              classpath 'com.android.tools.build:gradle:3.0.+' 
        } else{ 
              classpath 'com.android.tools.build:gradle:2.3.+' 
        }
  • app/build.gradle
android {
    if( _compileSdkVersion.isNumber()){
        compileSdkVersion _compileSdkVersion as int
    }
    else{
        compileSdkVersion "$_compileSdkVersion"
    }
    buildToolsVersion "$_buildToolsVersion"

   //javaのコンパイラの設定
    compileOptions {
        encoding "UTF-8"
        sourceCompatibility _JavaVersion as org.gradle.api.JavaVersion
        targetCompatibility _JavaVersion as org.gradle.api.JavaVersion
    }
}

plugin変更による記述差分

一応コマンドラインベースでは変更しなくても問題なく動きますが、、

AS3.0化はどちらかと言うと補完index作成の時間を抑制するのが目的みたい

  • app/build.gradle
dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])

    androidTestCompile('com.android.support.test.espresso:espresso-core:2.2.2', {
        exclude group: 'com.android.support', module: 'support-annotations'
    })
    testCompile 'junit:junit:4.12'

    compile "com.android.support:appcompat-v7:$_supportLibraryVersion"
    compile "com.android.support:design:$_supportLibraryVersion"
    compile "com.android.support:recyclerview-v7:$_supportLibraryVersion"
    compile "com.android.support:cardview-v7:$_supportLibraryVersion"
}
  • app/build30.gradle
dependencies {
    implementation fileTree(dir: 'libs', include: ['*.jar'])

    androidTestImplementation('com.android.support.test.espresso:espresso-core:2.2.2', {
        exclude group: 'com.android.support', module: 'support-annotations'
    })
    testImplementation 'junit:junit:4.12'

    implementation "com.android.support:appcompat-v7:$_supportLibraryVersion"
    implementation "com.android.support:design:$_supportLibraryVersion"
    implementation "com.android.support:recyclerview-v7:$_supportLibraryVersion"
    implementation "com.android.support:cardview-v7:$_supportLibraryVersion"
}

fkmさんが色んな所で公演されているように、G様ライブラリだけで固めれば

compile => implementation 書き換えでだいたい問題なくイケる


TLメモ

はい。data-binding がちゃんと動かない(正確にはbuildが不安定)のは実は認識してました。

kapt経由だと実は動くらしいんだけど、G様開発陣が既に kotlinしかつかってないから気づかない

ってことなのかなーとか思いつつ


TLメモ(補完index作成に関するメモ)

*1:まあ過去を振り返らないG様だから望み薄だけど

*2:日本だとそういうの用意しない所がほとんどでしょうけど・・

*3:G様純正以外の

*4:なんかJenkinsのCI運用みたい<汗