Android
Android用Gradle

C# Language Cordova firebase HTML iOS Java Language JavaScript Kotlin PHP react-native
サーチ…


前書き

GradleはJVMベースのビルドシステムで、開発者はコンパイルおよびアプリケーション作成のプロセスを自動化するために使用できる高水準のスクリプトを作成できます。これは柔軟なプラグインベースのシステムで、ビルドプロセスのさまざまな面を自動化することができます。 .jarコンパイルと署名、外部依存関係のダウンロードと管理、 AndroidManifestへのフィールドの注入、または特定のSDKバージョンの利用などが含まれます。

構文

  • apply plugin ：通常使用されるはずのプラグインは、 'com.android.application'または'com.android.library'です。

  • android ：あなたのアプリの主な設定

    • compileSdkVersion ：コンパイルSDKのバージョン
    • buildToolsVersion ：ビルドツールのバージョン
    • defaultConfig ：フレーバーとビルドタイプによって上書きされるデフォルト設定
      • applicationId ：あなたが使用するアプリケーションIDは、例えばPlayStoreの中ではあなたのパッケージ名とほとんど同じです
      • minSdkVersion ：必要最小限のSDKバージョン
      • targetSdkVersion ：あなたがコンパイルしたSDKのバージョンです（常に新しいものにする必要があります）
      • versionCode ：各更新時に大きくなる必要がある内部バージョン番号
      • versionName ：ユーザーがアプリの詳細ページに表示できるバージョン番号
    • buildTypes ：他の場所を見る（TODO）

  • dependencies ：あなたのアプリのMavenやローカルの依存関係

    • 単一の依存関係をcompileする
    • testCompile ：ユニットまたは統合テストの依存関係

備考

も参照してください

Android用Gradle - 拡張ドキュメント：

あなたがAndroidでgradleの使用についてより多くのトピックと例を見つけることができる別のタグがあります。
http://www.riptinar.com/topic/2092

基本的なbuild.gradleファイル

これは、モジュール内のデフォルトのbuild.gradleファイルの例です。 

apply plugin: 'com.android.application'

android {
    compileSdkVersion 25
    buildToolsVersion '25.0.3'

    signingConfigs {
        applicationName {
            keyAlias 'applicationName'
            keyPassword 'password'
            storeFile file('../key/applicationName.jks')
            storePassword 'keystorePassword'
        }
    }
    defaultConfig {
        applicationId 'com.company.applicationName'
        minSdkVersion 14
        targetSdkVersion 25
        versionCode 1
        versionName '1.0'
        signingConfig signingConfigs.applicationName
    }
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])

    compile 'com.android.support:appcompat-v7:25.3.1'
    compile 'com.android.support:design:25.3.1'

    testCompile 'junit:junit:4.12'
}

DSL（ドメイン固有言語）

上記のファイルの各ブロックは、 DSL （ドメイン固有言語）と呼ばれます。

プラグイン

最初の行、 apply plugin: 'com.android.application'は、 GradleのAndroidプラグインをビルドに適用し、 android {}ブロックを使用してAndroid固有のビルドオプションを宣言します。

Androidアプリケーションの場合 ： 

apply plugin: 'com.android.application'

Androidライブラリの場合 ： 

apply plugin: 'com.android.library'

上のサンプルのDSLを理解する

2番目の部分、 android {...}ブロックは、あなたのプロジェクトに関する情報を含むAndroid DSLです。

たとえば、アプリのコンパイルにGradleが使用するAndroid APIレベルを指定するcompileSdkVersionを設定できます。
サブブロックdefaultConfigは、マニフェストのデフォルトが保持されます。それらをProduct Flavorsで overrideすることができoverride 。

以下の例で詳細を見つけることができます：

依存関係

dependenciesブロックはandroidブロックの外で定義されています{...} ：これはAndroidプラグインで定義されていませんが、標準のGradleです。
dependenciesブロックは、アプリに含める外部ライブラリ（通常はAndroidライブラリですが、Javaライブラリも有効です）を指定します。 Gradleはこれらの依存関係を自動的にダウンロードします（ローカルコピーが利用できない場合）。別のライブラリを追加する場合は、同様のcompile行を追加するだけです。

ここにある行の1つを見てみましょう：

compile 'com.android.support:design:25.3.1'

この行は基本的に

私のプロジェクトにAndroidサポートデザインライブラリへの依存関係を追加してください。

Gradleはライブラリがダウンロードされていることを確認し、アプリで使用できるようにします。コードもアプリに含まれます。

Mavenに慣れている場合、この構文はGroupId 、コロン、 ArtifactId 、別のコロン、次にインクルードする依存関係のバージョンであり、バージョン管理を完全に制御できます。

プラス記号（+）を使用してアーティファクトバージョンを指定することは可能ですが、回避することをお勧めします。ライブラリがあなたの知識なしに変更を破って更新されると、アプリケーションにクラッシュする可能性があります。

異なる種類の依存関係を追加することができます：

aarのフラット依存性に特に注意する必要があります。

詳しくは、 このトピックを参照してください。

appcompat-v7の -v7に関する注意

compile 'com.android.support:appcompat-v7:25.3.1'

これは、このライブラリ （ appcompat ）がAndroid APIレベル7以降と互換性があることを意味します。

junitに関する注意：junit：4.12

これはユニットテストのテスト依存性です。

異なるビルド構成に固有の依存関係の指定

特定のビルド構成に対してのみ依存関係を使用するようにtestCompileか、通常のcompile代わりにdebugCompile 、 testCompileまたはreleaseCompileを使用して、 ビルドの種類または製品のフレーバー （たとえば、デバッグ、テストまたはリリース） 。

これは、リリースビルドからテストおよびデバッグ関連の依存関係を守るために役立ちます。これにより、リリースAPKを可能な限りスリムに保ち、デバッグ情報を使用してアプリケーションに関する内部情報を取得できなくなります。

signingConfig

signingConfig使用すると、 keystore情報を含むようにGradleを設定し、これらの設定を使用して構築されたAPKが署名され、Playストアリリースの準備が整っていることを確認できます。

ここでは、 専用のトピックを見つけることができます。

注意 ：Gradleファイル内に署名の認証情報を保存することは推奨されません。署名設定を削除するには、 signingConfigs部分を省略します。
さまざまな方法で指定できます。

詳細については、このトピックを参照してください： キーストアのパスワードを公開せずにAPKに署名してください。

Gradle for Androidの詳細については、 専用のGradleのトピックをご覧ください 。

製品のフレーバーの定義

製品のフレーバーは、以下のようにandroid { ... }ブロック内のbuild.gradleファイルで定義されています。 

...
android {
    ...
    productFlavors {
        free {
            applicationId "com.example.app.free"
            versionName "1.0-free"
        }
        paid {
            applicationId "com.example.app.paid"
            versionName "1.0-paid"
        }
    }
}

こうすることで、 freeとpaid 2種類の商品が追加さpaid 。それぞれは独自の固有の構成と属性を持つことができます。たとえば、両方の新しいフレーバーには、既存のmainフレーバーとは別のapplicationIdとversionNameがありversionName （デフォルトで使用できるので、ここには表示されません）。

製品フレーバー固有の依存関係の追加

特定のビルド構成に対して追加する方法と同様に、特定の製品のフレーバーに依存関係を追加することができます。

この例では、 freeとpaidという2つの製品フレーバーを既に定義しているとします（ここではフレーバーの定義について詳しく説明します ）。
freeフレーバーにはAdMobの依存関係を、 paidものにはPicassoのライブラリを追加することができます。 

android {
    ...

    productFlavors {
        free {
            applicationId "com.example.app.free"
            versionName "1.0-free"
        }
        paid {
            applicationId "com.example.app.paid"
            versionName "1.0-paid"
        }
    }
}

...
dependencies {
    ...
    // Add AdMob only for free flavor
    freeCompile 'com.android.support:appcompat-v7:23.1.1'
    freeCompile 'com.google.android.gms:play-services-ads:8.4.0'
    freeCompile 'com.android.support:support-v4:23.1.1'

    // Add picasso only for paid flavor
    paidCompile 'com.squareup.picasso:picasso:2.5.2'
} 
...

製品フレーバー固有のリソースを追加する

特定の製品の味のためにリソースを追加することができます。

この例では、 freeとpaidと呼ばれる2つの製品フレーバーを既に定義しているものとします。製品フレーバー固有のリソースを追加するために、 main/resフォルダーの横に追加のリソースフォルダーを作成します。このフォルダーは通常のようにリソースを追加できます。この例では、製品フレーバーごとに文字列status定義します。

/ src / main /res/values/strings.xml 

<resources>
    <string name="status">Default</string>
</resources>

/ src / free /res/values/strings.xml 

<resources>
    <string name="status">Free</string>
</resources>

/ src / paid /res/values/strings.xml 

<resources>
    <string name="status">Paid</string>
</resources>

製品のフレーバ固有のstatus文字列は、 mainフレーバのstatusの値を上書きします。

ビルド構成フィールドの定義と使用

BuildConfigField

Gradleを使用すると、 buildConfigField行で定数を定義できます。これらの定数は、実行時にBuildConfigクラスの静的フィールドとしてアクセスできます。これは、 defaultConfigブロック内のすべてのフィールドを定義し、必要に応じて個々のビルドフレーバのためにそれらをオーバーライドすることで、 フレーバを作成するために使用できます。

この例では、ビルドの日付を定義し、テストではなくプロダクションのビルドにフラグを付けます。 

android {
    ...
    defaultConfig {
        ...
        // defining the build date
        buildConfigField "long", "BUILD_DATE", System.currentTimeMillis() + "L"
        // define whether this build is a production build
        buildConfigField "boolean", "IS_PRODUCTION", "false"
        // note that to define a string you need to escape it
        buildConfigField "String", "API_KEY", "\"my_api_key\""
    }

    productFlavors {
        prod {
            // override the productive flag for the flavor "prod"
            buildConfigField "boolean", "IS_PRODUCTION", "true"
            resValue 'string', 'app_name', 'My App Name'
        }
        dev {
            // inherit default fields
            resValue 'string', 'app_name', 'My App Name - Dev'
        }
    }
}

自動的に生成された<package_name> genフォルダのBuildConfig .javaには、上記の指示に基づいて以下のフィールドがあります。 

public class BuildConfig {
    // ... other generated fields ...
    public static final long BUILD_DATE = 1469504547000L;
    public static final boolean IS_PRODUCTION = false;
    public static final String API_KEY = "my_api_key";
}

定義されたフィールドは、生成されたBuildConfigクラスにアクセスすることで、実行時にアプリ内で使用できるようになりました： 

public void example() {
    // format the build date
    SimpleDateFormat dateFormat = new SimpleDateFormat("yyyy/MM/dd");
    String buildDate = dateFormat.format(new Date(BuildConfig.BUILD_DATE));
    Log.d("build date", buildDate);
    
    // do something depending whether this is a productive build
    if (BuildConfig.IS_PRODUCTION) {
        connectToProductionApiEndpoint();
    } else {
        connectToStagingApiEndpoint();
    }
}

ResValue

resValueのproductFlavorsはリソース値を作成します。どのようなタイプのリソース（ string 、 dimen 、 colorなど） dimen 。これは、適切なファイルにリソースを定義することと似ています。たとえば、 strings.xmlファイル内の文字列を定義します。利点は、あなたのproductFlavor / buildVariantに基づいて、gradleで定義されたものを変更できることです。値にアクセスするには、リソースファイルからresにアクセスしている場合と同じコードを記述します。 

getResources().getString(R.string.app_name)

重要なのは、この方法で定義されたリソースは、ファイルに定義されている既存のリソースを変更できないということです。彼らは新しいリソース値を作成することしかできません。

一部のライブラリ（Google Maps Android APIなど）では、マニフェストにmeta-dataタグとして提供されているAPIキーが必要です。デバッグおよびプロダクションビルドに異なるキーが必要な場合は、Gradleで記入されたマニフェストプレースホルダを指定します。

あなたのAndroidManifest.xmlファイル： 

<meta-data
    android:name="com.google.android.geo.API_KEY"
    android:value="${MAPS_API_KEY}"/>

次に、 build.gradleファイルにフィールドを設定します。 

android {
    defaultConfig {
        ...
        // Your development key
        manifestPlaceholders = [ MAPS_API_KEY: "AIza..." ]
    }

    productFlavors {
        prod {
            // Your production key
            manifestPlaceholders = [ MAPS_API_KEY: "AIza..." ]
        }
    }
}

Androidのビルドシステムは、いくつかのフィールドを自動的に生成し、 BuildConfig.javaます。これらのフィールドは次のとおりです。

フィールド説明
DEBUG アプリケーションがデバッグモードであるかリリースモードであるかを示すBoolean
APPLICATION_ID アプリケーションのIDを含むString （例： com.example.app ）
BUILD_TYPE アプリケーションのビルドタイプを含むString （通常は、 debugまたはreleaseいずれか）
FLAVOR ビルドの特定のフレーバを含むString
VERSION_CODE バージョン（ビルド）番号を含むint
これは同じですversionCodeにbuild.gradleまたはversionCodeにAndroidManifest.xml
VERSION_NAME バージョン（ビルド）名を含むString
これは同じですversionNameにbuild.gradleまたはversionNameにAndroidManifest.xml

上記に加えて、フレーバーの複数のディメンションを定義した場合は、各ディメンションに独自の値が設定されます。たとえば、 colorとsizeフレーバーの2つの次元がある場合、次の変数もあります。

フィールド説明
FLAVOR_color 「色」フレーバの値を含むString
FLAVOR_size 「サイズ」フレーバの値を含むString

依存関係を "dependencies.gradle"ファイルで集中管理する

マルチモジュールプロジェクトを扱う場合、依存関係を多くのビルドファイル、特にAndroidサポートライブラリやFirebaseライブラリなどの一般的なライブラリに分散するのではなく、単一の場所に集中させると便利です。

推奨される方法の1つは、モジュールごとに1つのbuild.gradleを含むGradleビルドファイルと、プロジェクトルート内のビルドファイルと、依存関係のための別のビルドファイルを分離することです。 

root
  +- gradleScript/
  |     dependencies.gradle
  +- module1/
  |     build.gradle
  +- module2/
  |     build.gradle
  +- build.gradle

そして、すべての依存関係はgradleScript/dependencies.gradleます： 

ext {
    // Version
    supportVersion = '24.1.0'

    // Support Libraries dependencies
    supportDependencies = [
            design:            "com.android.support:design:${supportVersion}",
            recyclerView:      "com.android.support:recyclerview-v7:${supportVersion}",
            cardView:          "com.android.support:cardview-v7:${supportVersion}",
            appCompat:         "com.android.support:appcompat-v7:${supportVersion}",
            supportAnnotation: "com.android.support:support-annotations:${supportVersion}",
    ]

    firebaseVersion = '9.2.0';

    firebaseDependencies = [
            core:         "com.google.firebase:firebase-core:${firebaseVersion}",
            database:     "com.google.firebase:firebase-database:${firebaseVersion}",
            storage:      "com.google.firebase:firebase-storage:${firebaseVersion}",
            crash:        "com.google.firebase:firebase-crash:${firebaseVersion}",
            auth:         "com.google.firebase:firebase-auth:${firebaseVersion}",
            messaging:    "com.google.firebase:firebase-messaging:${firebaseVersion}",
            remoteConfig: "com.google.firebase:firebase-config:${firebaseVersion}",
            invites:      "com.google.firebase:firebase-invites:${firebaseVersion}",
            adMod:        "com.google.firebase:firebase-ads:${firebaseVersion}",
            appIndexing:  "com.google.android.gms:play-services-appindexing:${firebaseVersion}",
    ];
}

これはトップレベルのファイルbuild.gradleでそのファイルから適用できます。 

// Load dependencies
apply from: 'gradleScript/dependencies.gradle'

module1/build.gradleように： 

// Module build file
dependencies {
    // ...
    compile supportDependencies.appCompat
    compile supportDependencies.design
    compile firebaseDependencies.crash
}

別のアプローチ

ライブラリ依存性のバージョンを一元化するためのあまり控えめなアプローチは、バージョン番号を変数として一度宣言し、どこでも使用することで実現できます。

作業領域のルートbuild.gradle追加します。 

ext.v = [
    supportVersion:'24.1.1',
]

同じライブラリを使用するすべてのモジュールで、必要なライブラリを追加します

compile "com.android.support:support-v4:${v.supportVersion}"
compile "com.android.support:recyclerview-v7:${v.supportVersion}"
compile "com.android.support:design:${v.supportVersion}"
compile "com.android.support:support-annotations:${v.supportVersion}"

フレーバー固有のリソースのディレクトリ構造

さまざまな種類のアプリケーションビルドに異なるリソースを含めることができます。フレーバー特有のリソースを作成するには、 srcディレクトリにフレーバーの小文字の名前のディレクトリを作成し、通常と同じ方法でリソースを追加します。

たとえば、風味のあるDevelopment者がいて、独自のランチャーアイコンを提供したい場合は、ディレクトリsrc/development/res/drawable-mdpi ic_launcher.png src/development/res/drawable-mdpiを作成し、そのディレクトリ内に開発固有のアイコンを含むic_launcher.pngファイルを作成します。

ディレクトリ構造は次のようになります。 

src/
  main/
    res/
      drawable-mdpi/
        ic_launcher.png  <-- the default launcher icon
  development/
    res/
      drawable-mdpi/
        ic_launcher.png  <-- the launcher icon used when the product flavor is 'Development'

（もちろん、この場合はdrawable-hdpi、drawable-xhdpi などのアイコンも作成します）。

Android Studioプロジェクトにbuild.gradleファイルが2つあるのはなぜですか？

<PROJECT_ROOT>\app\build.gradleは、 アプリケーションモジュールに固有のものです 。

<PROJECT_ROOT>\build.gradleは、すべてのサブプロジェクト/モジュールに共通の設定オプションを追加できる「トップレベルビルドファイル」です。

プロジェクトで別のモジュールを使用している場合、ローカルライブラリとして別のbuild.gradleファイルがあります。 <PROJECT_ROOT>\module\build.gradle

最上位レベルのファイルでは、共通のプロパティをビルドスクリプトブロックまたはいくつかの一般的なプロパティとして指定できます。 

buildscript {
    repositories {
        mavenCentral()
    }

    dependencies {
       classpath 'com.android.tools.build:gradle:2.2.0'
       classpath 'com.google.gms:google-services:3.0.0'
    }
}

ext {
    compileSdkVersion = 23
    buildToolsVersion = "23.0.1"
}

app\build.gradle 、モジュールのプロパティのみを定義します。 

apply plugin: 'com.android.application'


android {
    compileSdkVersion rootProject.ext.compileSdkVersion
    buildToolsVersion rootProject.ext.buildToolsVersion
}

dependencies {
    //.....
}

gradleからシェルスクリプトを実行する

シェルスクリプトはビルドを基本的にあなたが考えることのできるものに拡張するための非常に多彩な方法です。

例として、protobufファイルをコンパイルし、結果のjavaファイルをソースディレクトリに追加してさらにコンパイルするための簡単なスクリプトを示します。 

def compilePb() {
    exec {
        // NOTICE: gradle will fail if there's an error in the protoc file...
        executable "../pbScript.sh"
    }
}

project.afterEvaluate {
    compilePb()
}

この例の「pbScript.sh」シェルスクリプトは、プロジェクトのルートフォルダにあります： 

#!/usr/bin/env bash
pp=/home/myself/my/proto

/usr/local/bin/protoc -I=$pp \
 --java_out=./src/main/java \
  --proto_path=$pp \
 $pp/my.proto \
 --proto_path=$pp \
 $pp/my_other.proto

Gradleエラーのデバッグ

以下はGradleの抜粋です- ゼロ以外の終了値とは何ですか？どのように修正しますか？完全な議論のためにそれを見てください。

アプリケーションを開発していて、一般的にそうであるように見えるいくつかのGradleエラーが発生したとしましょう。 

:module:someTask FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':module:someTask'.
> some message here...  finished with non-zero exit value X
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: Y.ZZ secs

StackOverflowであなたの問題を検索すると、あなたのプロジェクトをきれいにしたり再ビルドしたり、 MultiDexを有効にしたりしていると言う人もいます。

より多くの情報を得る方法はありますが、Gradleの出力自体は、そのメッセージの上の数行の実際のエラーを示します： module:someTask FAILEDと渡された最後の:module:someOtherTask 。したがって、あなたがあなたのエラーに関する質問をした場合は、あなたの質問を編集して、エラーの詳細を追加してください。

したがって、「ゼロ以外の終了値」が得られます。その数字は、あなたが修正しようとしているものの良い指標です。ここでは、最も頻繁に起こるものがいくつかあります。

  • 1は単なる一般的なエラーコードであり、誤差はGradle出力にある可能性が高い
  • 2は、重複する依存関係やプロジェクトの構成ミスに関連しているようです。
  • 3はあまりにも多くの依存関係やメモリの問題を含んでいるようです。

上記の一般的な解決策（プロジェクトのクリーンアップとリビルドを試行した後）は次のとおりです。

  • 1 - 言及されたエラーに対処してください。一般に、これはコンパイル時のエラーです。つまり、プロジェクト内のコードの一部が無効です。これには、AndroidプロジェクトのXMLとJavaの両方が含まれます。
  • 2 ＆ 3 - ここでは、 multidexを有効にする方法がいくつかあります。問題を修正する可能性がありますが、最も一般的な回避策です。あなたがなぜそれを使用しているのか理解できない場合は（リンクを参照）、おそらくそれは必要ありません。一般的なソリューションでは、ライブラリの依存関係の過度の使用（たとえば、マップやサインインなどのライブラリを1つだけ使用する必要がある場合など、すべてのGoogle Playサービス）を減らす必要があります。

ビルドの種類と製品のフレーバに異なるアプリケーションIDを指定する

applicationIdSuffix構成属性を使用して、各buildTypeまたはproductFlavor異なるアプリケーションIDまたはパッケージ名を指定できます。

各buildTypeのapplicationIdの接尾辞の例： 

defaultConfig {
    applicationId "com.package.android"
    minSdkVersion 17
    targetSdkVersion 23
    versionCode 1
    versionName "1.0"
}

buildTypes {
    release {
        debuggable false      
    }

    development {
        debuggable true
        applicationIdSuffix ".dev"
    }

    testing {
        debuggable true
        applicationIdSuffix ".qa"
    }
}

結果のapplicationIdsは次のようになります。

  • 以下のためのcom.package.android release
  • com.package.android。 dev development
  • com.package.android。 testingためのqa

これはproductFlavorsでも同様に行うことができます： 

productFlavors {
    free {
        applicationIdSuffix ".free"
    }
    paid {
        applicationIdSuffix ".paid"
    }
}

結果のapplicationIdsは次のようになります。

  • com.package.android。 フリーフレーバーをfree
  • com.package.android。 支払われた味のためにpaid

キーストアのパスワードを公開せずにAPKに署名する

次のプロパティを使用して、 build.gradleファイルのapkに署名する署名設定を定義できます。

  • storeFile ：キーストアファイル
  • storePassword ：キーストアのパスワード
  • keyAlias ：キーエイリアス名
  • keyPassword ：キーエイリアスのパスワード

多くの場合、 build.gradleファイルでこのような情報を避ける必要があります。

方法A：keystore.propertiesファイルを使用してリリース署名を設定する

keystore.propertiesなどのプロパティファイルから署名設定情報を読み込むように、アプリケーションのbuild.gradleを設定することができます。

このような署名を設定すると便利です：

  • 署名設定情報は、 build.gradleファイルとは別のものです
  • キーストアファイルにパスワードを提供するために署名プロセス中に介入する必要はありません
  • バージョン管理からkeystore.propertiesファイルを簡単に除外することができkeystore.properties

まず、次のような内容のプロジェクトのルートにkeystore.propertiesというファイルを作成します（独自の値で置き換えます）。 

storeFile=keystore.jks
storePassword=storePassword
keyAlias=keyAlias
keyPassword=keyPassword

さて、あなたのアプリのbuild.gradleファイルで、次のようにsigningConfigsブロックを設定してsigningConfigs ： 

android {
...

    signingConfigs {
        release {
            def propsFile = rootProject.file('keystore.properties')
            if (propsFile.exists()) {
                def props = new Properties()
                props.load(new FileInputStream(propsFile))
                storeFile = file(props['storeFile'])
                storePassword = props['storePassword']
                keyAlias = props['keyAlias']
                keyPassword = props['keyPassword']
            }
        }
    }
}

これは本当にありますが、バージョン管理からkeystore.propertiesストアファイルとkeystore.propertiesファイルの両方を除外することを忘れないでください 。

注意すべきことのカップル：

  • keystore.propertiesファイルで指定されたstoreFileパスは、アプリのbuild.gradleファイルからの相対パスである必要があります。この例では、キーストアファイルがアプリケーションのbuild.gradleファイルと同じディレクトリにあることを前提としています。
  • この例では、プロジェクトのルートにkeystore.propertiesファイルがありkeystore.properties 。他の場所に置く場合は、 rootProject.file('keystore.properties')の値をプロジェクトのルートを基準にして自分の場所に変更してください。

方法B：環境変数を使用する

同じことがプロパティファイルなしでも実現でき、パスワードを見つけるのが難しくなります： 

android {

  signingConfigs {
    release {
        storeFile file('/your/keystore/location/key')
        keyAlias 'your_alias'
        String ps = System.getenv("ps")
        if (ps == null) {
             throw new GradleException('missing ps env variable')
        }
        keyPassword ps
        storePassword ps
    }
}

"ps"環境変数はグローバルにすることもできますが、Android Studioのシェルにのみ追加することで、より安全なアプローチが可能です。
Linuxでは、これはAndroid StudioのDesktop Entry編集することで行うことができます

Exec=sh -c "export ps=myPassword123 ; /path/to/studio.sh"

詳しくは、 このトピックを参照してください。

"version.properties"ファイル経由でビルドをバージョン管理する

Gradleを使用すると、パッケージをビルドするたびに自動的にインクリメントすることができます。これを行うには、次の内容のbuild.gradleと同じディレクトリにversion.propertiesファイルを作成します。 

VERSION_MAJOR=0
VERSION_MINOR=1
VERSION_BUILD=1

（メジャーとマイナーの値を適切に変更する）。次にbuild.gradle androidセクションに次のコードを追加します： 

// Read version information from local file and increment as appropriate
def versionPropsFile = file('version.properties')
if (versionPropsFile.canRead()) {
  def Properties versionProps = new Properties()

  versionProps.load(new FileInputStream(versionPropsFile))

  def versionMajor = versionProps['VERSION_MAJOR'].toInteger()
  def versionMinor = versionProps['VERSION_MINOR'].toInteger()
  def versionBuild = versionProps['VERSION_BUILD'].toInteger() + 1

  // Update the build number in the local file
  versionProps['VERSION_BUILD'] = versionBuild.toString()
  versionProps.store(versionPropsFile.newWriter(), null)

  defaultConfig {
    versionCode versionBuild
    versionName "${versionMajor}.${versionMinor}." + String.format("%05d", versionBuild)
  }
}

この情報は、Javaで、完全な{メジャー}。{マイナー}。{ビルド}番号の文字列BuildConfig.VERSION_NAMEと、ビルド番号の整数のBuildConfig.VERSION_CODEとしてアクセスできます。

出力apk名を変更してバージョン名を追加する：

これは、出力アプリケーションファイル名（.apk）を変更するためのコードです。 newName異なる値を割り当てることによって、名前を設定できます

android {

    applicationVariants.all { variant ->
        def newName = "ApkName";
        variant.outputs.each { output ->
            def apk = output.outputFile;

            newName += "-v" + defaultConfig.versionName;
            if (variant.buildType.name == "release") {
                newName += "-release.apk";
            } else {
                newName += ".apk";
            }
            if (!output.zipAlign) {
                newName = newName.replace(".apk", "-unaligned.apk");
            }

            output.outputFile = new File(apk.parentFile, newName);
            logger.info("INFO: Set outputFile to " 
                        + output.outputFile 
                        + " for [" + output.name + "]");
        }
    }
}

小さなAPKファイルサイズの画像圧縮を無効にする

すべてのイメージを手動で最適化する場合は、APKファイルのサイズを小さくするためにAPT Cruncherを無効にします。 

android {
    
    aaptOptions {
        cruncherEnabled = false
    }
}

gradleを使用してProguardを有効にする

アプリケーションのProguard設定を有効にするには、モジュールレベルのグラデーションファイルで有効にする必要があります。 minifyEnabledの値をtrueに設定する必要がありtrue 。 

buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }

上記のコードは、デフォルトのAndroid SDKに含まれるProguardの設定を、あなたのモジュール上の "proguard-rules.pro"ファイルと組み合わせて、あなたの公開apkに適用します。

GradleとAndroidStudioの実験的なNDKプラグインのサポートを有効にする

実験的なGradleプラグインを有効にして設定し、AndroidStudioのNDKサポートを改善します。次の要件を満たしていることを確認してください。

  • Gradle 2.10（この例の場合）
  • Android NDK r10以降
  • ビルドツールv19.0.0以降を搭載したAndroid SDK

MyApp / build.gradleファイルを設定する

例えばbuild.gradleのdependencies.classpath行を編集します。 

classpath 'com.android.tools.build:gradle:2.1.2'

に

classpath 'com.android.tools.build:gradle-experimental:0.7.2'

（v0.7.2は執筆時点では最新版だったので、最新バージョンを自分でチェックし、それに合わせてラインを修正してください）

build.gradleファイルは次のようになります。 

buildscript {
    repositories {
        jcenter()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle-experimental:0.7.2'
    }
}

allprojects {
    repositories {
        jcenter()
    }
}

task clean(type: Delete) {
    delete rootProject.buildDir
}

MyApp / app / build.gradleファイルを設定する

build.gradleファイルを次の例のように編集します。お使いのバージョン番号が異なる場合があります。 

apply plugin: 'com.android.model.application'

model {
    android {
        compileSdkVersion 19
        buildToolsVersion "24.0.1"

        defaultConfig {
            applicationId "com.example.mydomain.myapp"
            minSdkVersion.apiLevel 19
            targetSdkVersion.apiLevel 19
            versionCode 1
            versionName "1.0"
        }
        buildTypes {
            release {
                minifyEnabled false
                proguardFiles.add(file('proguard-android.txt'))
            }
        }
        ndk {
            moduleName "myLib"
            
            /* The following lines are examples of a some optional flags that 
               you may set to configure your build environment
            */ 
            cppFlags.add("-I${file("path/to/my/includes/dir")}".toString())
            cppFlags.add("-std=c++11")
            ldLibs.addAll(['log', 'm'])
            stl = "c++_static"
            abiFilters.add("armeabi-v7a")
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

続行する前に、Gradleファイルにエラーがないことを同期して確認します。

プラグインが有効かどうかをテストする

まず、Android NDKモジュールをダウンロードしてください。 AndroidStudioで新しいアプリを作成し、ActivityMainファイルに次の行を追加します： 

public class MainActivity implements Activity {
    onCreate() {
        // Pregenerated code. Not important here
    }
    static {
        System.loadLibrary("myLib");
    }
    public static native String getString();
}

getString()部分は、対応するJNI関数が見つからないという赤色で強調表示されます。赤い電球が表示されるまで、関数呼び出しの上にマウスを移動します。電球をクリックして、 create function JNI_...を選択create function JNI_... 。これにより、正しいJNI関数呼び出しでmyApp / app / src / main / jniディレクトリにmyLib.cファイルが生成されます。これは次のようになります。 

#include <jni.h>

JNIEXPORT jstring JNICALL 
Java_com_example_mydomain_myapp_MainActivity_getString(JNIEnv *env, jobject instance)     
{
    // TODO

    return (*env)->NewStringUTF(env, returnValue);
}

表示されない場合は、プラグインが正しく設定されていないか、NDKがダウンロードされていません

すべてのgradleプロジェクトタスクを表示する

gradlew tasks -- show all tasks

 

Android tasks
-------------
androidDependencies - Displays the Android dependencies of the project.
signingReport - Displays the signing info for each variant.
sourceSets - Prints out all the source sets defined in this project.

Build tasks
-----------
assemble - Assembles all variants of all applications and secondary packages.
assembleAndroidTest - Assembles all the Test applications.
assembleDebug - Assembles all Debug builds.
assembleRelease - Assembles all Release builds.
build - Assembles and tests this project.
buildDependents - Assembles and tests this project and all projects that depend on it.
buildNeeded - Assembles and tests this project and all projects it depends on.
classes - Assembles main classes.
clean - Deletes the build directory.
compileDebugAndroidTestSources
compileDebugSources
compileDebugUnitTestSources
compileReleaseSources
compileReleaseUnitTestSources
extractDebugAnnotations - Extracts Android annotations for the debug variant into the archive file
extractReleaseAnnotations - Extracts Android annotations for the release variant into the archive file
jar - Assembles a jar archive containing the main classes.
mockableAndroidJar - Creates a version of android.jar that's suitable for unit tests.
testClasses - Assembles test classes.

Build Setup tasks
-----------------
init - Initializes a new Gradle build. [incubating]
wrapper - Generates Gradle wrapper files. [incubating]

Documentation tasks
-------------------
javadoc - Generates Javadoc API documentation for the main source code.

Help tasks
----------
buildEnvironment - Displays all buildscript dependencies declared in root project 'LeitnerBoxPro'.
components - Displays the components produced by root project 'LeitnerBoxPro'. [incubating]
dependencies - Displays all dependencies declared in root project 'LeitnerBoxPro'.
dependencyInsight - Displays the insight into a specific dependency in root project 'LeitnerBoxPro'.
help - Displays a help message.
model - Displays the configuration model of root project 'LeitnerBoxPro'. [incubating]
projects - Displays the sub-projects of root project 'LeitnerBoxPro'.
properties - Displays the properties of root project 'LeitnerBoxPro'.
tasks - Displays the tasks runnable from root project 'LeitnerBoxPro' (some of the displayed tasks may belong to subprojects)
.

Install tasks
-------------
installDebug - Installs the Debug build.
installDebugAndroidTest - Installs the android (on device) tests for the Debug build.
uninstallAll - Uninstall all applications.
uninstallDebug - Uninstalls the Debug build.
uninstallDebugAndroidTest - Uninstalls the android (on device) tests for the Debug build.
uninstallRelease - Uninstalls the Release build.

Verification tasks
------------------
check - Runs all checks.
connectedAndroidTest - Installs and runs instrumentation tests for all flavors on connected devices.
connectedCheck - Runs all device checks on currently connected devices.
connectedDebugAndroidTest - Installs and runs the tests for debug on connected devices.
deviceAndroidTest - Installs and runs instrumentation tests using all Device Providers.
deviceCheck - Runs all device checks using Device Providers and Test Servers.
lint - Runs lint on all variants.
lintDebug - Runs lint on the Debug build.
lintRelease - Runs lint on the Release build.
test - Run unit tests for all variants.
testDebugUnitTest - Run unit tests for the debug build.
testReleaseUnitTest - Run unit tests for the release build.

Other tasks
-----------
assembleDefault
clean
jarDebugClasses
jarReleaseClasses
transformResourcesWithMergeJavaResForDebugUnitTest
transformResourcesWithMergeJavaResForReleaseUnitTest

自動的に "unaligned" apkを削除する

自動的に生成されたapkファイルのunaligned接尾辞（おそらくそうではない）が必要ない場合は、 build.gradleファイルに次のコードを追加することができます： 

// delete unaligned files
android.applicationVariants.all { variant ->
  variant.assemble.doLast {
    variant.outputs.each { output ->
        println "aligned " + output.outputFile
        println "unaligned " + output.packageApplication.outputFile

        File unaligned = output.packageApplication.outputFile;
        File aligned = output.outputFile
        if (!unaligned.getName().equalsIgnoreCase(aligned.getName())) {
            println "deleting " + unaligned.getName()
            unaligned.delete()
        }
    }
  }
}

ここから

ビルドバリアントを無視する

何らかの理由で、ビルドバリアントを無視することができます。たとえば、製品の味を模倣し、ユニット/計装テストなどのデバッグ目的でのみ使用します。

プロジェクトからmockReleaseを無視しましょう。 build.gradleファイルを開いて次のように記述します。 

    // Remove mockRelease as it's not needed.
    android.variantFilter { variant ->
        if (variant.buildType.name.equals('release') && variant.getFlavors().get(0).name.equals('mock')) {
            variant.setIgnore(true);
        }
    }

依存関係ツリーを見る

タスクの依存関係を使用します。あなたのモジュールが設定されている方法に応じて、それがいずれであってもよい./gradlew dependenciesやモジュールのアプリ使用の依存関係を確認するために./gradlew :app:dependencies

build.gradleファイルの次の例

dependencies {
    compile 'com.android.support:design:23.2.1'
    compile 'com.android.support:cardview-v7:23.1.1'

    compile 'com.google.android.gms:play-services:6.5.87'
}

次のグラフが生成されます。 

Parallel execution is an incubating feature.
:app:dependencies

------------------------------------------------------------
Project :app
------------------------------------------------------------
. . .
_releaseApk - ## Internal use, do not manually configure ##
+--- com.android.support:design:23.2.1
|    +--- com.android.support:support-v4:23.2.1
|    |    \--- com.android.support:support-annotations:23.2.1
|    +--- com.android.support:appcompat-v7:23.2.1
|    |    +--- com.android.support:support-v4:23.2.1 (*)
|    |    +--- com.android.support:animated-vector-drawable:23.2.1
|    |    |    \--- com.android.support:support-vector-drawable:23.2.1
|    |    |         \--- com.android.support:support-v4:23.2.1 (*)
|    |    \--- com.android.support:support-vector-drawable:23.2.1 (*)
|    \--- com.android.support:recyclerview-v7:23.2.1
|         +--- com.android.support:support-v4:23.2.1 (*)
|         \--- com.android.support:support-annotations:23.2.1
+--- com.android.support:cardview-v7:23.1.1
\--- com.google.android.gms:play-services:6.5.87
     \--- com.android.support:support-v4:21.0.0 -> 23.2.1 (*)

. . .

ここでは、プロジェクトがcom.android.support:designバージョン23.2.1を直接含んでいることがわかります。それ自体com.android.support:support-v4がバージョン23.2.1になります。しかし、 com.google.android.gms:play-services自体は、同じsupport-v4 -v4に依存していますが、古いバージョン21.0.0では、gradleによって検出された競合です。

(*)は、それらの依存関係がすでに以前にリストされているため、gradleがサブツリーをスキップするときに使用されます。

中央versionnumber / buildconfigurationsにgradle.propertiesを使用する

中央の設定情報を定義することができます

root gradle.propertiesファイルをgradle.properties

プロジェクトの構造

root
  +- module1/
  |     build.gradle
  +- module2/
  |     build.gradle
  +- build.gradle
  +- gradle.properties

gradle.propertiesのすべてのサブモジュールのグローバル設定

# used for manifest
# todo increment for every release
appVersionCode=19
appVersionName=0.5.2.160726

# android tools settings
appCompileSdkVersion=23
appBuildToolsVersion=23.0.2

サブモジュールでの使用

apply plugin: 'com.android.application'
android {
    // appXXX are defined in gradle.properties
    compileSdkVersion = Integer.valueOf(appCompileSdkVersion)
    buildToolsVersion = appBuildToolsVersion

    defaultConfig {
        // appXXX are defined in gradle.properties
        versionCode = Long.valueOf(appVersionCode)
        versionName = appVersionName
    }
}

dependencies {
    ...
}

注意： F-Droidアプリストアにあなたのアプリを公開したい場合は、f-droidロボットが現在のバージョンナンバーを読んでバージョンの変更を検出/確認することができないため、gradleファイルのマジックナンバーを使用する必要があります。

署名情報を表示する

状況によっては（たとえば、Google APIキーを取得するなど）、キーストアのフィンガープリントを見つける必要があります。 Gradleには、キーストアのフィンガープリントを含むすべての署名情報を表示する便利なタスクがあります。 

./gradlew signingReport

これはサンプル出力です。 

:app:signingReport
Variant: release
Config: none
----------
Variant: debug
Config: debug
Store: /Users/user/.android/debug.keystore
Alias: AndroidDebugKey
MD5: 25:08:76:A9:7C:0C:19:35:99:02:7B:00:AA:1E:49:CA
SHA1: 26:BE:89:58:00:8C:5A:7D:A3:A9:D3:60:4A:30:53:7A:3D:4E:05:55
Valid until: Saturday 18 June 2044
----------
Variant: debugAndroidTest
Config: debug
Store: /Users/user/.android/debug.keystore
Alias: AndroidDebugKey
MD5: 25:08:76:A9:7C:0C:19:35:99:02:7B:00:AA:1E:49:CA
SHA1: 26:BE:89:58:00:8C:5A:7D:A3:A9:D3:60:4A:30:53:7A:3D:4E:05:55
Valid until: Saturday 18 June 2044
----------
Variant: debugUnitTest
Config: debug
Store: /Users/user/.android/debug.keystore
Alias: AndroidDebugKey
MD5: 25:08:76:A9:7C:0C:19:35:99:02:7B:00:AA:1E:49:CA
SHA1: 26:BE:89:58:00:8C:5A:7D:A3:A9:D3:60:4A:30:53:7A:3D:4E:05:55
Valid until: Saturday 18 June 2044
----------
Variant: releaseUnitTest
Config: none
----------

ビルドタイプの定義

android {}ブロック内のモジュールレベルのbuild.gradleファイルでビルドタイプを作成および設定できます。 

    android {
        ...
        defaultConfig {...}
    
        buildTypes {
            release {
                minifyEnabled true
                proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            }
    
            debug {
                applicationIdSuffix ".debug"
            }
        }
    }


Modified text is an extract of the original Stack Overflow Documentation
ライセンスを受けた CC BY-SA 3.0
所属していない Stack Overflow