最新のAndroid Weeklyニュースレターの1つには、プロジェクトのアセンブリ組織の興味深い機能についての記事が含まれていました 。 それを読んだ後、Androidプロジェクトのアセンブリを構成するために使用するもののいくつかを共有したいと思いました。

build.gradleファイルのコードの重複を取り除きます

簡単なアイデアのように思えますが、このアプローチはほとんど使用されません。



アプリケーションに複数のモジュールがあり、それぞれにbuildToolsVersionを登録する必要があるとします。 多くの場合、この問題は特定のバージョンをext変数に入れることで解決されます。

さらに、この値を1か所でのみ設定することにより、コードを最適化できます。



build.gradleで別のgradleファイルのコードを使用できることを思い出させてください。

apply plugin: 'com.android.application' apply from: "$buildSystemDir/application.gradle"
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、application.gradleファイルでは、必要なバージョンを既に指定できます。

 android { compileSdkVersion 24 buildToolsVersion "24.0.1" defaultConfig { minSdkVersion 15 targetSdkVersion 24 testInstrumentationRunner 'android.support.test.runner.AndroidJUnitRunner' } compileOptions { sourceCompatibility JavaVersion.VERSION_1_7 targetCompatibility JavaVersion.VERSION_1_7 } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここで、プロジェクト全体の設定を行うことができます。 次に、特定の各モジュールで、必要に応じて値をオーバーライドできます。



別のgradleファイルでは、Android-拡張機能の構成だけでなく、依存関係、jacoco、findbugs、pmd設定などをテストすることもできます。 など

プロジェクトにプロパティを追加する

既に$ buildSystemDir変数に気付いているかもしれません。 ルートプロジェクトのbuild.gradleファイルで指定されます。

 allprojects { it.extensions.add("buildSystemDir", "$rootProject.projectDir/buildSystem/") }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、各モジュールで、プレフィックスなしでこのプロパティを使用できます。 これも、コードをわずかに削減します;）

署名apk

証明書のキーとパスワードを安全に保存するというトピックは非常に興味深いものであり、誰かが私に（ciで安全な）良い解決策を教えてくれればとても嬉しいです。



各証明書に関する情報は* .propertiesファイルに保存されます。 プロジェクトアセンブリマシンに存在する場合と存在しない場合があります。



sign.gradle：

 Properties signProp = new Properties() try { signProp.load(rootProject.file('signForTest.properties').newDataInputStream()) project.ext { forTest = new Object() { def storeFile = signProp.get("forTest.storeFile") def storePassword = signProp.get("forTest.storePassword") def keyAlias = signProp.get("forTest.keyAlias") def keyPassword = signProp.get("forTest.keyPassword") } } } catch (IOException e) { project.ext { forTest = new Object() { def storeFile = "/" def storePassword = "" def keyAlias = "" def keyPassword = "" } } } android { signingConfigs { forTest { storeFile file(project.ext.forTest.storeFile) storePassword project.ext.forTest.storePassword keyAlias project.ext.forTest.keyAlias keyPassword project.ext.forTest.keyPassword } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以上です。 このファイルをアプリケーションのbuild.gradleに適用し、buildTypeで構成済みのsigningConfigを使用することは残ります。

buildSrc

ビルドシステムに完全なコードが必要で、プラグインを作成する時間がない場合はどうしますか？ これを行うには、buildSrcディレクトリを使用できます。



プロジェクトのルートディレクトリ（gradlewが存在する場所）で、新しいbuildSrcモジュールを作成します。 このモジュールは、次のbuild.gradleファイルを含む通常のJavaプロジェクト（またはgroovyなど）である必要があります。

 apply plugin: "groovy" repositories { mavenCentral() } dependencies { compile localGroovy() compile gradleApi() } // START SNIPPET addToRootProject rootProject.dependencies { runtime project(path) } // END SNIPPET addToRootProject
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、このプロジェクトでは、いくつかのクラスAwesome.groovyを作成し、このクラスをAndroidモジュールbuild.gradleにインポートして使用できます。



プロジェクトのビルドを開始すると、buildSrcモジュールが最初に実行されます。 その後、残りのモジュールが構成されます。



このソリューションの使用をお勧めするとは言えません。なぜなら、 これにより、プロジェクトのビルド時間がゼロからわずかに増加します。 しかし、極端な場合には役立ちます。

フレーバー寸法

プロジェクトを構成するこの機能は、ドック（// tools.android.com/tech-docs/new-build-system/user-guide#TOC-Multi-flavor-variantsで詳しく説明されています

） しかし、誰もがそれを知っているわけではないか、どのような場合に使用できるか理解していないため、私はそれについて話すことにしました。



有料の無料アプリケーションを作成する必要があるとします。 同時に、アプリケーションはテレビ、タブレット、携帯電話向けにリリースされます。 さらに、アプリケーションはさまざまな市場で公開されています。



build.gradleに次のコードを追加します。

 android { flavorDimensions "device", "paid", "market" productFlavors { tv { dimension 'device' } tablet { dimension 'device' } phone { dimension 'device' } free { dimension 'paid' } premium { dimension 'paid' } google { dimension 'market' } amazon { dimension 'market' } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

3つの異なるグループで7つのフレーバーを発表することにより、12の異なるアプリケーションオプションが用意されました。 ここにbuildTypesを追加すると、大量のapk-shekが取得されます。

phoneFreeGoogleDebug

phoneFreeGoogleRelease

phoneFreeAmazonDebug

phoneFreeAmazonDebug

phonePremiumGoogleDebug

... など

宣言する各フレーバーは、独自のsourceSetを作成します。 たとえば、phoneFreeAmazonDebugフレーバーを選択した場合、次のsourceSetsが使用されます。

src / phoneFreeAmazon

src / phoneFree

src / phoneAmazon

src / freeAmazon

src /電話

src /無料

src / amazon

したがって、アセンブリをカスタマイズする大きな機会があります。

buildTypeにminSdkVersionを指定します

開発段階でアプリケーションのアセンブリを高速化するには、多くの場合、個別のフレーバー「開発」を作成し、minSdkVersion = 21を指定することをお勧めします。ただし、これはあまり便利ではなく、このパラメーターをbuildTypeデバッグで指定することがよくあります。 最初は、ビルドプラグインはこれを許可していませんが、必要に応じて、次のハイキングでこの問題を解決できます。



目的のbuildTypeには、ext変数を追加する必要があります。

 … buildTypes { ... debug { ... ext.minSdkVersion = 21 } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以下に、次のコードを追加する必要があります。

 preBuild.doFirst { android.applicationVariants.all { if (it.buildType.hasProperty("minSdkVersion")) { int i = it.buildType.ext.minSdkVersion; it.mergedFlavor.setMinSdkVersion(new com.android.builder.core.DefaultApiVersion(i)) } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これで、デバッグアセンブリのすべてのフレーバーについて、minSdkVersionは21になります。ただし、プラグインの内部と密接な結びつきがあるため、プラグインバージョンの更新時に何かが壊れる可能性があります。 したがって、このハックの使用はお勧めできません-選択はあなた次第です。



結論ではなく、Gradleはプロジェクトを構築するための非常に強力なツールであることに注意してください。 アプリケーションのコードの品質に多くの注意を払う場合、build.gradleファイルのコードを整理することを忘れないでください。