gradle experimentalを日本語訳してみた

http://tools.android.com/tech-docs/new-build-system/gradle-experimental
のサイトを勝手に翻訳(意訳?)しました。
内容が誤っているかもしれないので自己責任でお願いします。

はじめに

この新しい試験的なプラグインはGraleの新しいコンポーネントモデルの仕組みをベースとしており、設定時間の短縮を約束します。これはJNIアプリケーションのためのNDKの統合を行います。このガイドはこれらの詳細とオリジナルのプラグインと新しいプラグインとの差異について詳細内容を提供します。

警告：このプラグインは試験的なステージにあることに留意ください。この新しいGradle APIのコンポーネントは最終版ではありません。そのため、このガイドで説明する内容は最終版まで変更される可能性があります。
また、DSLはDSLを作成するAPIが変更されると大幅に変更される可能性があります。
これは、パフォーマンスとNDK統合に関するフィードバックのごく初期版に当たります。

要求事項

l  Gradle(必要なバージョンを以下に記載します)
l  Android NDK r10e(もしNDKを使用する場合)
l  SDKのビルドツールのバージョンは19.0.0以上で、この機能を使用するため、最小限の変更作業が必要となります。幾つかの機能は、より新しいバージョンが必要となります。

Gradleの要求事項

それぞれの試験的プラグインのバージョンは特定のGradleのバージョンが必要です。以下に必要なGradleのバージョンのリストを記載します。
プラグインバージョン
Gradleバージョン
0.1.0
2.5
0.2.0
2.5
0.3.0-alpha3
2.6
0.4.0
2.8
0.6.0-alpha1
2.8
0.6.0-alpha5
2.10

従来のアンドロイド向けGradleプラグインの変更

典型的なAndroidStudioプロジェクトのディレクトリ構造は以下の通り。変更が必要となるファイルについては赤字で表現します。
新しいプラグインと従来のプラグインのDSLの間でいくつか重要な変更点があります。
├── app/
│ ├── app.iml
│ ├── build.gradle
│ └── src/
├── build.gradle
├── gradle/
│ └── wrapper/
│ ├── gradlewrapper.jar
│ └── gradlewrapper.properties
├── gradle.properties
├── gradlew*
├── gradlew.bat
├── local.properties
├── MyApplication.iml
└── settings.gradle

./gradle/wrapper/gradle-wrapper.properties
l  新しいプラグインの各バージョンは、特定のGradleのバージョンをサポートしています。最新のプラグイン(0.6.0-alpha5)はGradle-2.10のみをサポートします。
#Wed Apr 10 15:27:10 PDT 2013
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle2.10all.zip
./build.gradle
l  プラグインのClassパスの設定を従来の「com.android.tools:gradle」から「com.android.tools.build:gradle-expermental」に変更します。
l  最新バージョンは0.6.0-alpha5です。

// 最上位のビルドファイルでは、すべてのサブプロジェクト/モジュールに共通する設定が可能です。
buildscript {
repositories {
jcenter()
}
dependencies {
classpath "com.android.tools.build:gradle-experimental:
0.6.0alpha5"
// メモ：あなたのアプリケーションに依存関係を記述してはいけません。
// これらは個別のモジュールのbuild.gradleファイルで記述します。
}
}
allprojects {
repositories {
jcenter()
}
}

./app/build.gradle
これらは重要なDSLの変更になります。不必要と思われる多くの変更はイライラさせることを理解しています。従って、私たちの目標は、将来的に従来のプラグインからの変更を最小限に抑えるために、これらの変更の一部を除去することです。
メモ： 0.6.0-alpha5以降で、以前のバージョンから重要なDSLの改善(変更?)がありました。そのため、例えば以前のバージョンのコードでは動作しなくなったりします。もし、古いバージョンのプラグインを使用する場合、ユーザーガイド「https://sites.google.com/a/android.com/tools/techdocs/newbuildsystem/gradleexperimental/0-4-0」を参照してください。

DSLの変更点

l  プラグインの名前を「com.android.application」から「com.android.mo-del.application」に変更します。
l  modelブロックで設定を囲います。
l  コレクションに追加する要素はaddメソッドを使用して行うようにします。

現状のDSLの願わくはなくなってほしい制限事項について

l  リスト(List)プロパティは直接的なタイプのみの設定となっており、これらを接続するのに他のタイプでの方法がありません。
Ø  例）あなたが文字列を使用してFileタイプのプロパティを設定できますが、List<File>のプロパティについてはFileオブジェクトのみしか受け付けません。
l  プロダクトフレーバーもしくはビルドタイプを生成するとき、Createメソッドを呼び出します。ビルドタイプのリリースとデバッグは名前だけを使用すればよいように変更します。
l  DSLの変更範囲は、現状は非常に限られた範囲でしかできません。


apply plugin: "com.android.model.application"
model {
  android {
    compileSdkVersion 23
    buildToolsVersion "23.0.2"
    defaultConfig {
      applicationId "com.example.user.myapplication"
      minSdkVersion.apiLevel 15
      targetSdkVersion.apiLevel 22
      versionCode 1
      versionName "1.0"
      buildConfigFields {
        create() {
          type "int"
          name "VALUE"
          value "1"
        }
      }
    }
    buildTypes {
      release {
        minifyEnabled false
        proguardFiles.add(file("proguard-rules.pro"))
      }
    }
    productFlavors {
      create("flavor1") {
        applicationId "com.app"
      }
    }
    // Configures source set directory.
    sources {
      main {
        java {
          source {
            srcDir "src"
          }
        }
      }
    }
  }
}
dependencies {
  compile fileTree(dir: "libs", include: ["*.jar"])
  compile "com.android.support:appcompat-v7:22.2.0"
}

コードへの署名

$()構文を使用して、異なるモデルの要素を参照することができます。2.10以下のバージョンで使用するには”-Dorg.gradle.model.dsl=true”をGradleのコマンドラインの引数に追加する必要があります。
ノート：「android.signingConfigs」はandroid{}ブロックの外側に記述しなければなりません。
model {
  android {
    compileSdkVersion 23
    buildToolsVersion "23.0.2"
    buildTypes {
      release {
        signingConfig = $("android.signingConfigs.myConfig")
      }
    }
  }
  android.signingConfigs {
    create("myConfig") {
      storeFile "/path/to/debug.keystore"
      storePassword "android"
      keyAlias "androiddebugkey"
      keyPassword "android"
      storeType "jks"
    }
  }
}

NDKとの統合

試験的プラグインでは、ネイティブアプリケーションを作成するためにNDKと統合しています。NDKと統合するために以下をおこなう必要があります。
l  AndroidStudioのSDKマネージャを使用してNDKをダウンロードします。
l  NDKが配置されたディレクトリパスを「ndk.dir」の「local.properties」もしくは、ANDROID_NDK_HOME環境変数に設定します。
l  build.gradleのモデルに「android.ndk」を追加します。

単純なNDKアプリケーションのbuild.gradleファイルは以下のような感じです。
apply plugin: 'com.android.model.application'
model {
  android {
    compileSdkVersion 23
    buildToolsVersion "23.0.2"
    ndk {
      moduleName "native"
    }
  }
}
ノート：生成されるネイティブライブラリの名前を決定するためにmoduleNameの設定は必須です。

ソースセット

既定ではC/C++ファイルはsrc/main/jniを検索します。ソースディレクトリを変更するには「android.sources」を設定します。
model {
  android {
    compileSdkVersion 23
    buildToolsVersion "23.0.2"
    ndk {
      moduleName "native"
    }
    sources {
      main {
        jni {
          source {
            srcDir "src"
          }
        }
      }
    }
  }
}
JNIのソースセットはCとC++ファイルが含まれるでしょう。サブディレクトリのすべてのファイルはインクルードされます。拡張子が「.c」のファイルはCファイルとして扱われる一方、C++のファイルは「.CPP」「.c++」「.cc」「.cp」「.cpp」「.cxx」の拡張子を持つでしょう。ファイルを除外したい場合、excludeメソッドを使用する一方、includeメソッドは無視されます。
model {
  android.sources {
    main {
      jni {
        source {
          include "someFile.txt" // これは無視されます.
          exclude "**/excludeThisFile.c"
        }
      }
    }
  }
}
様々なビルドオプションをandroid.ndk{}ブロックに設定することができます。以下に例を挙げます。
model {
  android {
    compileSdkVersion 23
    buildToolsVersion "23.0.2"
    ndk {
      // すべての設定はandroid.ndkを変更することで可能です。
      moduleName "native"
      toolchain "clang"
      toolchainVersion "3.5"
      // Note that CFlags has a capital C, which is inconsistent with
      // the naming convention of other properties. This is a
      // technical limitation that will be resolved
      CFlags.add("-DCUSTOM_DEFINE")
      cppFlags.add("-DCUSTOM_DEFINE")
      ldFlags.add("-L/custom/lib/path")
      ldLibs.add("log")
      stl "stlport_static"
    }
    buildTypes {
      release {
        ndk {
          debuggable true
        }
      }
    }
    productFlavors {
      create("arm") {
        ndk {
          // プロダクトフレーバーやビルドタイプごとの
          // NDK設定をカスタマイズできます。
          abiFilters.add("armeabiv7a")
        }
      }
      create("fat") {
        // ndk.abiDiltersが設定されていない場合、アプリケーションは
        // すべてのサポートしているAPIのパッケージをコンパイルします。
      }
    }
  }
  // 各種NDK設定を変更することができます。
  components.android {
    binaries.afterEach { binary ->
      binary.mergedNdkConfig.cppFlags.add(
         "-DVARIANT=\"" + binary.name + "\"")
      }
    }
  }
}

既知の制限について

l  cpu_features 等を使用したNDKモジュールをサポートしません。
l  他のビルドシステムとの統合をサポートしません。
他のサンプルは「https://github.com/googlesamples/androidndk」にあります。

複数のNDKプロジェクト

バージョン0.4.0のプラグインではNDKの依存関係のための予備的なサポートとして、ネイティブライブラリを作成する機能を追加しました。

スタンドアロンNDKプラグイン

gradle-experimental:0.4.0では、アンドロイドアプリケーションやライブラリを生成することなくネイティブライブラリを生成することができるようになりました。
DSLはapplication/libraryプラグインと似通っています。’src/main/jni’のソースからlibhello.soを生成するbuild.gradleの例は以下の通り。
apply plugin: "com.android.model.native"
model {
  android {
    compileSdkVersion 23
    ndk {
      moduleName "hello"
    }
  }
}

既知の問題点について

l  スタンドアロンプラグインではAndroid Studio上での編集をまだサポートしていません。
l  変更したライブラリ中のソースファイルを、アプリケーションのビルド時に新しいライブラリに自動的にアプリケーションへ再リンクしません。

NDK依存関係

特定の依存関係を指定するための構文は、将来のGradleの依存関係システムのスタイルに従っています。アンドロイドプロジェクトや特定のファイルの依存関係を設定することができます。
例えば、スタンドアロンNDKプラグインを使用した’lib’というサブプロジェクトがあった場合について以下に示します。
lib/build.gradle
apply plugin: "com.android.model.native"
model {
  android {
    compileSdkVersion 23
    ndk {
      moduleName "hello"
    }
    sources {
      main {
        jni {
          exportedHeaders {
            srcDir "src/main/headers"
          }
        }
      }
    }
  }
}

JNIに依存関係があるすべてのプロジェクトが‘exportedHeaders’で指定されたディレクトリが含まれます。以下のように記述することで、アプリケーションのJNIコードにlibプロジェクトの依存関係を追加することができます。
app/build.gradle
apply plugin: "com.android.model.application"
model {
  android {
    compileSdkVersion 23
    buildToolsVersion "23.0.2"
    sources {
      main {
        jni {
          dependencies {
            project ":lib1"
          }
        }
      }
    }
  }
}
あなたはターゲットとするプロジェクトのプロダクトフレーバー及び/もしくはビルドターゲットを指定することができます。言い換えると、プラグインはアプリケーションのビルドタイプとプロダクトフレーバーから同じものを見つけようとします。
例えば、希望する静的リンクするネイティブライブラリのリンケージタイプを指定する場合は以下の通り。
model {
  android.sources {
    main {
      jni {
        dependencies {
          project ":lib1"
          buildType "debug"
          productFlavor "flavor1"
          linkage "static"
        }
      }
    }
  }
}
依存関係となるファイルを宣言するには、事前ビルドするライブラリや依存関係ライブラリを追加します。以下に例を示します。
model {
  repositories {
    prebuilt(PrebuiltLibraries) {
      binaries.withType(SharedLibraryBinary) {
        sharedLibraryFile =
          file("lib/${targetPlatform.getName()}/prebuilt.so")
      }
    }
  }
  android.sources {
    main {
      jniLibs {
        dependencies {
          library "prebuilt"
        }
      }
    }
  }
}
‘jni’もしくは’jniLibs’配下のソースセットをネイティブな依存関係として追加することができます。’jniLibs’をネイティブライブラリの依存関係として追加する場合、application/libraryにパッケージされますが、JNIコードのコンパイルするためには使用されません。以下に例を示します。
model {
  android.sources {
    main {
      jniLibs {
        dependencies {
          library "prebuilt"
        }
      }
    }
  }
}

DSLの変更箇所

このプラグインは試験的なステージにあるため、DSLはプラグインの開発を通じて変更されることがあります。このセクションではマイグレーションの助けとなるように各プラグインのバージョン間で発生した際について記載します。

0.6.0-alpha1→0.6.0-alpha5

l  プラグインはGradle2.10が必要となります。これはDSLに大幅な改善をもたらします。
l  ネストされた設定を以下のように記述することができます。

android {
  buildType { … }
}
を
android.buildType { … }
と記述できます。
l  ファイルタイプが文字列を受け入れるようになりました。List<File>の対応についてはもうしばらくお待ちください。
l  -Dorg.gradle.model=trueがデフォルトになりました。これで別のモデルを参照することができるようになりますが、参照する場合、分離されたブロックとする必要があります。

0.4.x→0.6.0-alpha1

l  特定のライブラリファイルの依存関係を指定するためのDSLがGradleのネイティブに従うように変更されました。(「https://github.com/gradle/gradle/blob/master/subprojects/docs/src/samples/native-binaries/prebuilt/build.gradle」を参照してください。)
model {
  android.sources {
    main {
      jniLibs {
        dependencies {
          library file("lib/x86/prebuilt.so") abi "x86"
          library file("lib/armeabi-v7a/prebuilt.so") abi "armeabiv7a"
          library file("lib/mips/prebuilt.so") abi "mips"
        }
      }
    }
  }
}
が次のように変更されました。
model {
  repositories {
    prebuilt(PrebuiltLibraries) {
      binaries.withType(SharedLibraryBinary) {
        sharedLibraryFile =
          file("lib/${targetPlatform.getName()}/prebuilt.so")
      }
    }
  }
   android.sources {
    main {
      jniLibs {
        dependencies {
          library "prebuilt"
        }
      }
    }
  }
}

0.2.x→0.4.0

l  +=はコレクションのためにもはや動作しません。アイテムのリストに追加する場合、’add’もしくは’addAll’メソッドを使用します。
例）CFlags += “-DCUSTOM_DEFINE”はCFlags.add(“-DCUSTOM_DEFINE”)に置き換えることができます。

0.1.x→0.2.x

l  jniDebuggableはビルドタイプの設定から除去されndkブロックに移動しました。
release {
  jniDebuggable = true
}
は以下のようになります。
release {
  ndk.with {
    debuggable = true
  }
}

変更履歴

0.6.0-alpha3
l 依存関係のある事前ビルドライブラリのDSLを変更しました。
l  Gradle2.8にアップデートしました。
l  ネイティブライブラリの依存関係解決の様々な問題点を解決しました。
0.4.0
l  試験的なライブラリのプラグインでjniコード使用して問題を解決しました。
l  compileSdkVersionからプラットフォームのバージョン設定を分離できるようになりました。
l  複数のABIが含まれているバリアントで特定のABIの設定ができるようになりました。
l  NDKプラグインと動的オブジェクト(shared object)/静的ライブラリファイルの依存関係のサポートを追加しました。
l  ネイティブコードのコンパイルのためのスタンドアロンプラグインのプレビューバージョンを追加しました。これを利用することでGradleでアプリケーションをビルドできますが、Android Studioのサポートはまだ実装されていません。


コメント

コメントを投稿

このブログの人気の投稿

シンボルサーバーを設定する

シンボルサーバーを設定した（する）ので自分用のメモ シンボルサーバーを設定する マイコンピュータの環境設定の環境変数「_NT_SYMBOL_PATH」にシンボルサーバーへのパスを設定します。 例えば、 D:\symbols \\symserver\symbols http://msdl.microsoft.com/download/symbols にシンボルサーバーだよと設定したい場合、環境変数に Srv*D:\symbols*\\symserver\symbols*http://msdl.microsoft.com/download/symbols というように設定します。 これを設定しておくと、「D:\symbols」と「\\symserver\symbols」共有フォルダにシンボルファイルが格納されます。 シンボルサーバーへシンボルの追加 共有フォルダへシンボルファイルを追加する場合、「symstore.exe」を使用します。 これはMicrosoft Debugging Tools for Windowsのパッケージに含まれています。 例えば、「C:\svn\projects」フォルダ下に生成されたシンボルファイルを共有フォルダに登録したい場合、以下のように実行します。 symstore.exe add /f "c:\svn\projects\*.pdb" /s "\\symserver\sysmbols" /r このコマンドで「C:\svn\projects」フォルダ下の*.pdbファイルを再帰的探して共有フォルダに設定します。
続きを読む

マルチモニタをやめてみた

クラムシェルをやってみたくて一時的にマルチモニタをやめてみたら意外に作業が捗る事がわかった 理由を考えたところ作業スペースが有効に使え、マルチモニタのときは狭くて使って無かった紙とペンを使うようになったことと、何より集中力が上がった気がする。 目の前に余計な物がないのが良いみたいだ。 マルチモニタと作業効率でググると良いことしか書いてないページばかり引っ掛かるが、シングルモニタと集中力でググると真逆のことが書かれていて面白い。 マルチモニタ派の人は作業効率おしだがシングル派はかつてマルチモニタを使っていた人ばかりというのがより説得力がある。 結局は人それぞれなのかもしれないが、試しに片方のモニタの電源オフしてみるのも良いかも知れない
続きを読む

Xamarinのxamlのデータバインディングのpart4について訳してみた。

Part4. データバインディングの基礎 データバインディングは２つのオブジェクトのプロパティをリンクし、片方の変更を契機に もう片方の変更を発生させることができます。 これは大変価値のあるツールです。そしてデータバインディングはソースコード上で完璧に 定義することができ、XAMLはそのショートカットと利便性を提供します。 その結果として、バインティングがXamarin.Formsのマークアップ拡張は最も重要な機能 の一つとなります。 データバインディング データバインティングは２つのオブジェクトのプロパティを接続し、ソースからターゲットへ 呼び出しを行います。コードの中では、２つのステップが要求されます。 一つ目は、ターゲットオブジェクトのBindingContextプロパティを必ずソースオブジェクト にセットする必要があります。 二つ目は、SetBindingメソッド（しばしばBindingクラスと組み合わせて使用される）で、 ソースオブジェクトのプロパティに、そのオブジェクトのプロパティをバインドするために、 ターゲットオブジェクトから呼び出されなければなりません。 ターゲットプロパティは、バインディング可能なプロパティである必要があります。 つまり、ターゲットオブジェクトは必ずBindingObjectから継承されている必要があります。 オンラインのXamain.Formsのドキュメントでは、プロパティはバインド可能なプロパティで あることを示しています。 マークアップ中では、これらは同じ２つのステップが要求され、バインディングマークアップ の拡張機能は、SetBindingの呼び出しと、Bindingクラスの代わりに使用されます。 しかしながら、これらはターゲットオブジェクトのBindingContextへセットする単一の テクニックではありません。 しばしば、StaticResourceもしくはx:Staticマークアップ拡張機能を使用して、コード ビハインドのファイルからこれらは設定されます。 バインディングが最も頻繁に使用されるのは、画面表示系のプログラムとベースのデータモデル を接続する時で、しばしばMVVM(Model-View-ViewModel)アプリケーションアーキテクチャ で実現されます。MVVMについては
続きを読む