6

Android Studio Gradle i/o を見たことがある人もいるかもしれませんが、Xavier Ducrohet は素早いスピーチの中で、android gradle ビルド システムの使用方法について言及しました。私の問題は、ドキュメンテーションとプレゼンテーションに、手っ取り早く始めるための情報が欠けていることです。または少なくとも私にとっては。次のコードでは、gradle android プラグイン システムの使用法を解決しようとしましたが、いくつかの手順が間違っていて、いくつかの手順が正しいと確信しています。（私はantやmavenをあまり使っていません）

たぶん、これまでやってきたことを段階的に進めていくでしょう。

android {
    compileSdkVersion 17
    buildToolsVersion "17.0.0"

    defaultConfig {
        minSdkVersion 7
        targetSdkVersion 16

        signingStoreLocation = "debug.keystore"
        signingStorePassword = "***************"
        signingKeyAlias = "***************"
        signingKeyPassword = "**************"
    }

最初に、デバッグビルドのデフォルト設定を構成します（または、デフォルト設定を使用するすべてのビルド..ビルドタイプやフレーバーがないことを意味しますか？）

ソースセット:

    sourceSets {

        main {
            manifest.srcFile 'AndroidManifest.xml'
            java.srcDirs = ['com.project.maingradle', 'com.otherproject.changedsourcefilesforthisproject']
            res.srcDirs = ['res', 'resfromotherprojectusingpartsofsamecode']
            assets.srcDirs = ['assets']
        }
    }

このステップでは、sourceSets を定義しました。これが私の最初の質問がある場所です。2 つのプロジェクトで使用したい同じコードがある場合、それは可能ですか、または次のようなソースセットをさらに定義する必要がありますか? -->

    sourceSets {

        main {...}
        srcsetforanotherproject {...}
    }

...基礎となるsrcフォルダーに応じて？または、最初の sourceSets 宣言のように、sourceSets の定義を行う必要があります。たとえば、Xavier Ducrohet が言及したように、res フォルダーなどのさまざまなセットを定義する必要がありますか? (また、この方法で res フォルダーに対してのみ、または java.srcDirs = ['com.project.maingradle', 'com.otherproject.changedsourcefilesforthisproject'] のような Java src コード フォルダーに対してもこれを実行できるかどうかも明確ではありません。

署名構成:

    signingConfigs {
        debugRelease {
            storeFile file("debug.keystore")
        }

        release {
            storeFile file("release.keystore")
        }

        testflight {
            storeFile file("testflight.keystore")
        }
    }

このステップでは、さまざまなリリースを使用してさまざまなキーを定義しました。大丈夫なはず…

ビルドタイプ:

    buildTypes {

        debugRelease.initWith(buildTypes.release)
        testflight.initWith(buildTypes.release)

        sourceSets.debugRelease.setRoot("src/release")
        sourceSets.debugRelease.setRoot("src/release")
        sourceSets.debugRelease.setRoot("src/release")

        debugRelease {
            packageNameSuffix ".debugRelease"
            versionNameSuffix "-DEBUG"
            debuggable true
            signingConfig signingConfigs.debug
        }

        testflight {
            packageNameSuffix ".testflight"
            versionNameSuffix "-TESTFLIGHT"
            signingConfig signingConfigs.testflight
        }

        release {
            packageNameSuffix ".release"
            versionNameSuffix "-RELEASE"
            runProguard true
            proguardFile getDefaultProguardFile('proguard-android.txt')
            signingConfig signingConfigs.release
        }
    }

このステップは、gradle android プラグインの他のどのステップよりも明確に説明されています。バックグラウンドで動作する事前定義されたリリースまたはデバッグ設定があるかどうかわからないことを除いて...とにかくそれを明確にする必要があります...少なくとも私はそう思います。このビルドのキー (signingConfig)。

フレーバー:

    flavorGroups "abi", "version"

    productFlavors {

        arm {
            flavorGroup "abi"
        }

        standardproject1 {
            flavorGroup "version"
            minSdkVersion 7
            targetSdkVersion 14
            packageName "com.project.maingradle.normal"
            sourceSet sourceSets.main
        }

        standardproject2 {
            flavorGroup "version"
            minSdkVersion 6
            targetSdkVersion 14
            packageName "com.otherproject.normal"
            sourceSet sourceSets.main
        }

        testflightproject1 {
            flavorGroup "version"
            minSdkVersion 7
            targetSdkVersion 14
            packageName "com.project.maingradle.testflight"
            sourceSet sourceSets.main
        }

        testflightproject2 {
            flavorGroup "version"
            minSdkVersion 6
            targetSdkVersion 14
            packageName "com.otherproject.testflight"
            sourceSet sourceSets.main
        }
    }
}

個人的にはフレーバーが一番面白い部分だと思います。Xavier Ducrohet は、異なるフレーバー ビルドに異なるキーを使用したい場合、ビルドタイプで (代わりにフレーバーで宣言するのではなく) キーを定義するべきではないと言いましたか? 私はそれを正しく理解したかどうかわかりません。

とにかく...私がここでやろうとしていたのは、さまざまなシステムのSDKバージョン管理、排他的なパッケージ名、例にあるように依存するソースセットの設定など、さまざまな設定でビルドする必要があるさまざまなフレーバーを定義することです。よくわからないのは、ビルドタイプがフレーバーにどのように依存するかです...すべてのフレーバーをすべてのビルドタイプに乗算するだけですか? そして...フレーバーでこのように、sourceSetを設定しても大丈夫ですか（さらにsourceSetを設定できる場合）？

4

1 に答える 1

1

ビルドタイプがフレーバーにどのように依存するか...すべてのフレーバーをすべてのビルドタイプに乗算するだけですか?

はい、Gradle はビルド タイプと製品フレーバーのすべての組み合わせを生成します。Gradle プラグイン ユーザー ガイドに従って、各ビルド タイプと製品フレーバーの組み合わせはビルド バリアントと呼ばれます。

フレーバーでこのように、sourceSet を設定しても問題ありませんか (より多くの sourceSet を設定できる場合)。

もちろん！製品フレーバー (およびビルド バリアント) には、ソースセットと依存関係のドキュメントsrc/myFlavorNameに従って、からの独自のソースセットも自動的に含まれます。

于 2013-10-04T20:18:25.430 に答える