Android Studio:build.gradle配置

24002 ワード

Android スタジオ

転載元:http://www.cnblogs.com/niray/p/5242985.html
署名の設定を定義
WeChat微博sdkを共有する時にデバッグは対応する署名バージョンを使ってこそsdkを呼び出すことができます.
1.署名ファイルをプロジェクトのルートディレクトリの下に置きます.(これは経路の統一を維持するためです.)
2.Graadleには次のコードを導入する:

//  keystore  
    signingConfigs {
        release {
            storeFile file("xxxxxxxxStore")
            storePassword "xxxxxxxx"
            keyAlias "timehut team"
            keyPassword "xxxxxxxx"
        }
    }


    buildTypes {
        debug {
            signingConfig signingConfigs.release
        }
        release {
            signingConfig signingConfigs.release
        }
    }

Android Manifestのプレースホルダを置換します.${app_label}を@string/app_nameに置き換える.

android{
    defaultConfig{
        manifestPlaceholders = [app_label:"@string/app_name"]
    }
}

debugバージョンだけを置き換えたい場合:

android{
    buildTypes {
        debug {
              manifestPlaceholders = [app_label:"@string/app_name_debug"]
        }
        release {
        }
    }
}

もっと多くの需要は代替ルート番号です.

android{
    productFlavors {
        //  dev     apk AndroidManifest  channel  dev
        "dev"{
            manifestPlaceholders = [channel:"dev"]
        }
    }
}

署名情報を個別に設定
署名に関する情報は、直接にgradleに書くのはもちろんよくないです.特にいくつかのオープンソースプロジェクトは、gradle.propertiesに追加できます.

RELEASE_KEY_PASSWORD=xxxx
RELEASE_KEY_ALIAS=xxx
RELEASE_STORE_PASSWORD=xxx
RELEASE_STORE_FILE=../.keystore/xxx.jks

その後、build.gradleで引用すればいいです.

android {
    signingConfigs {
        release {
            storeFile file(RELEASE_STORE_FILE)
            storePassword RELEASE_STORE_PASSWORD
            keyAlias RELEASE_KEY_ALIAS
            keyPassword RELEASE_KEY_PASSWORD
        }
    }
}

バージョンライブラリに提出したくないなら、local.propertiesに追加して、build.gradleで読みます.
マルチチャンネル包装
マルチチャネル包装のポイントは、異なるプロジェクトflavorを定義し、Android Manifestのチャンネル番号を対応するflavorの標識に置き換えることです.

android {
    productFlavors {
        dev{
            manifestPlaceholders = [channel:"dev"]
        }
        official{
            manifestPlaceholders = [channel:"official"]
        }
        // ... ...
        wandoujia{
            manifestPlaceholders = [channel:"wandoujia"]
        }
        xiaomi{
            manifestPlaceholders = [channel:"xiaomi"]
        }
        "360"{
            manifestPlaceholders = [channel:"360"]
        }
}

ここのflavorの名前は数字の先頭であれば、引用符で呼び出さなければなりません.
ビルドすると、一連のBuild Varantが生成されます.

devDebug
devRelease
officialDebug
officialRelease
wandoujiaDebug
wandoujiaRelease
xiaomiDebug
xiaomiRelease
360Debug
360Release

その中でdebugは、releaseはgradleがデフォルトで持参した二つのbuild typeで、次のセクションでも説明します.
一つを選ぶと、対応チャネルのアプリがコンパイルできます.
カスタムBuild Type
前に言ったデフォルトのbuild typeには二つのdebugとreleaseがあります.違いは以下の通りです.

// release     BuildConfig    
public final class BuildConfig {
  public static final boolean DEBUG = false;
  public static final String BUILD_TYPE = "release";
}
// debug     BuildConfig    
public final class BuildConfig {
  public static final boolean DEBUG = true;
  public static final String BUILD_TYPE = "debug";
}

今は一つの需要があります.一つのbuild typeを追加して、debugとreleaseの間で、releaseのバージョンと同じですが、debugの状態を保持します.(rom開発をしたら、user debugバージョンに似ています).previewバージョンと呼びます.

android {
    signingConfigs {
        debug {
            storeFile file(RELEASE_STORE_FILE)
            storePassword RELEASE_STORE_PASSWORD
            keyAlias RELEASE_KEY_ALIAS
            keyPassword RELEASE_KEY_PASSWORD
        }
        preview {
            storeFile file(RELEASE_STORE_FILE)
            storePassword RELEASE_STORE_PASSWORD
            keyAlias RELEASE_KEY_ALIAS
            keyPassword RELEASE_KEY_PASSWORD
        }
        release {
            storeFile file(RELEASE_STORE_FILE)
            storePassword RELEASE_STORE_PASSWORD
            keyAlias RELEASE_KEY_ALIAS
            keyPassword RELEASE_KEY_PASSWORD
        }
    }

    buildTypes {
        debug {
            manifestPlaceholders = [app_label:"@string/app_name_debug"]
        }
        release {
            manifestPlaceholders = [app_label:"@string/app_name"]
        }
        preview{
            manifestPlaceholders = [app_label:"@string/app_name_preview"]
        }
    }
}

また、build typeにはもう一つのメリットがあります.一度にすべてのpreviewバージョンを生成したいなら、asemble Previewを実行すればいいです.debugとreleaeバージョンは同じです.
build typeのカスタマイズパラメータ
上記のように、私たちは異なるbuild typeで$appuulabelを別の文字列に置き換えます.携帯電話にインストールすれば、明らかに違ったbuild typeのバージョンを区別できます.
これ以外にも、いくつかのパラメータを設定することができます.ここにいくつかの私が仕事で使ったものを並べます.

android {
        debug {
            manifestPlaceholders = [app_label:"@string/app_name_debug"]
            applicationIdSuffix ".debug"
            minifyEnabled false
            signingConfig signingConfigs.debug
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        release {
            manifestPlaceholders = [app_label:"@string/app_name"]
            minifyEnabled true
            shrinkResources true
            signingConfig signingConfigs.release
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
        preview{
            manifestPlaceholders = [app_label:"@string/app_name_preview"]
            applicationIdSuffix ".preview"
            debuggable true //   debug  
            minifyEnabled true
            shrinkResources true
            signingConfig signingConfigs.preview
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }
}

これらは多すぎます.ちょっと説明してください.

// minifyEnabled     
// shrinkResources       
// signingConfig   
// proguardFiles     
// applicationIdSuffix   APP ID   
// debuggable         
// ... ...

プロジェクト全体の設定
製品のチャネルが広がるにつれて、コードのセットは多くの製品形態をサポートする必要があります.これは主にLibraryを抽象的に出して、それからLibraryに基づいていくつかのApp Moduleを拡張します.
各moduleのbuild.gradleにはこのコードがあると信じています.

android {
    compileSdkVersion 22
    buildToolsVersion "23.0.1"

    defaultConfig {
        minSdkVersion 10
        targetSdkVersion 22
        versionCode 34
        versionName "v2.6.1"
    }
}

sdk、build tool、target sdkなどをアップグレードすると、いくつかのmoduleが変更されます.大変です.最も重要なのは、忘れがちで、最終的にはapp moduleとの違いが不揃いになり、コントロールできなくなります.
強力なgradleプラグインは1.1.0でグローバル変数設定をサポートし、この問題を一挙に解決しました.
まずプロジェクトのルートディレクトリの下のbuild.gradleでextグローバル変数を定義します.

ext {
    compileSdkVersion = 22
    buildToolsVersion = "23.0.1"
    minSdkVersion = 10
    targetSdkVersion = 22
    versionCode = 34
    versionName = "v2.6.1"
}

そして、各moduleのbuild.gradleから以下を引用する.

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

    defaultConfig {
        applicationId "com.xxx.xxx"
        minSdkVersion rootProject.ext.minSdkVersion
        targetSdkVersion rootProject.ext.targetSdkVersion
        versionCode rootProject.ext.versionCode
        versionName rootProject.ext.versionName
    }
}

そしてプロジェクトレベルのbuild.gradleを修正するたびにグローバル統一構成を実現することができます.
カスタムエクスポートAPK名前
デフォルトのAndroid studioで生成されたapp-debug.app-release.appという名前のアプリは、複数のチャンネルがある場合、同時に50個のパッケージを作る必要があります.誰が誰なのか分かりません.
この場合は、カスタマイズしてエクスポートするAPKの名前が必要です.別のルートで作成したAPKのファイル名は違っているはずです.

android {
    // rename the apk with the version name
    applicationVariants.all { variant ->
variant.outputs.each { output ->
output.outputFile = new File(
                    output.outputFile.parent,
                    "ganchai-${variant.buildType.name}-${variant.versionName}-${variant.productFlavors[0].name}.apk".toLowerCase())
        }
    }
}

appkが多すぎる時、appkをdebug、release、previewに分類したらもっといいです.(実は、私のようによく配布している人に対しては、一編で四、五十個のバージョンを編む人が多いです.debugとreleaseバージョンが全部混ざっていて見られません.分類しなければなりません.)

android {
    // rename the apk with the version name
    // add output file sub folder by build type
    applicationVariants.all { variant ->
        variant.outputs.each { output ->
            output.outputFile = new File(
                    output.outputFile.parent + "/${variant.buildType.name}",
                    "ganchai-${variant.buildType.name}-${variant.versionName}-${variant.productFlavors[0].name}.apk".toLowerCase())
        }
    }
}

今はganchai-dev-preview-v 2.4.0.0.appkのようなフォーマットのカバンが生まれました.previewのカバンは自然にpreviewのフォルダの下に置いてあります.
紛らわしいテクニック
混淆は逆コンパイルのコードの可読性を悪くし、APKパッケージのサイズを著しく減らすことができます.
最初のテクニック
多くの友達が混同に迷惑をかけていると信じています.紛らわしいルールを追加するには、公式の説明文書を調べなければならないので、まだ説明していない公式文書もあります.あまりにも多くのライブラリを参照すると、混淆規則を追加し、悪夢を作ることになります.
ここでは、公式文書を調べる必要がない技術を紹介します.ライブラリごとにルールを追加することを考えなくてもいいです.
まず、デフォルトの混淆構成以外に、自分のコードは必ず自分で設定します.

##   module  proguard-rules.pro
#####################################
#########            #########
#####################################

-dontwarn xxx.model.**
-keep class xxx.model.** { *; }

##   ，         

#####################################
###########          ##########
#####################################

-keepattributes Signature
-dontwarn cn.jpush.**
-keep class cn.jpush.** { *; }

次に面倒な第三者ライブラリです.一般的にオーロラプッシュなら、そのパッケージ名はcn.jpushです.次のコードを追加すればいいです.
他の第三庫もそうです.一つずつ追加して、疲れました.実は第三者の逆コンパイルツールを使ってもいいです.https://github.com/skylot/jadx)appkを開けたら、引用されているすべての第三者ライブラリのパッケージ名が一目で見えます.すべてを混同したくない、または混同できるかどうかは不明です.直接追加してもいいです.

#####################################
#########       jar  ###########
#####################################

-dontwarn cn.jpush.**
-keep class cn.jpush.** { *; }

-dontwarn com.squareup.**
-keep class com.squareup.** { *; }

-dontwarn com.octo.**
-keep class com.octo.** { *; }

-dontwarn de.**
-keep class de.** { *; }

-dontwarn javax.**
-keep class javax.** { *; }

-dontwarn org.**
-keep class org.** { *; }

-dontwarn u.aly.**
-keep class u.aly.** { *; }

-dontwarn uk.**
-keep class uk.** { *; }

-dontwarn com.baidu.**
-keep class com.baidu.** { *; }

-dontwarn com.facebook.**
-keep class com.facebook.** { *; }

-dontwarn com.google.**
-keep class com.google.** { *; }

## ... ...

第二のテクニック
一般的にreleaseバージョンが混同された後、友盟のような統計システムが崩壊したら下記のように記録されます.

java.lang.NullPointerException: java.lang.NullPointerException
    at com.xxx.TabMessageFragment$7.run(Unknown Source)

このUnknown Sourceは大変です.エラーを排除して具体的な行に位置決めできなくなり、デバッグ効率を大幅に低減します.
もちろん、友盟はMappingファイルのアップロードをサポートしています.位置を特定するのに役立ちます.mappingファイルの位置は以下の通りです.

project > module
        > build > outputs > {flavor name} > {build type} > mapping.txt

もしバージョンが多くなると、mappings.txtは毎回再生成され、アップロードされます.やっぱり面倒くさいです.
実は、プログレッシブ-rules.proに下記のコードを追加すればいいです.

-keepattributes SourceFile,LineNumberTable

もちろんapping.txtではなくてもいいです.このような解脱のために、この価格は個人的には価値があると思います.
追加情報を動的に設定します.
現在のコンパイル時間、コンパイルされたマシン、最新のcomitバージョンをappkに追加したいなら、これらの情報はコードに書きにくいです.強いgradleは私に可能な自信を与えました.

android {
    defaultConfig {
        resValue "string", "build_time", buildTime()
        resValue "string", "build_host", hostName()
        resValue "string", "build_revision", revision()
    }
}

def buildTime() {
    return new Date().format("yyyy-MM-dd HH:mm:ss")
}
def hostName() {
    return System.getProperty("user.name") + "@" + InetAddress.localHost.hostName
}
def revision() {
    def code = new ByteArrayOutputStream()
    exec {
        commandLine 'git', 'rev-parse', '--short', 'HEAD'
        standardOutput = code
    }
    return code.toString()
}

上記のコードは3つの文字列リソースを動的に追加することを実現しました.time、build_ホット、build_revisionは、他のところで参照文字列のように次のように使用できます.

//  Activity   
getString(R.string.build_time)  //   2015-11-07 17:01
getString(R.string.build_host)  //   jay@deepin，           PC 
getString(R.string.build_revision) //   3dd5823,       commit sha

このところ、コマンドラインから結果を読み取るにはどうすればいいですか?
実はこのコードはVLCのソースコードを勉強している時に偶然に見ました.
vlcソースコードとコンパイル住所:https://wiki.videolan.org/AndroidCompile興味があれば、行ってみてもいいです.
自分に「裏口」を残してください.七時からです.
デバッグを便利にするために、私達はよくデバッグバージョンで私達が見たいインターフェースを残します.(覚えています.前の微博のiOSバージョンからデバッグインターフェースが漏れました.)どうやってインターフェースに入りますか?android開発者のオプションを真似して、7時に表示します.

private int clickCount = 0;
private long clickTime = 0;

sevenClickView.setOnClickListener(new View.OnClickListener() {
    @Override
    public void onClick(View view) {

        if (clickTime == 0) {
            clickTime = System.currentTimeMillis();
        }
        if (System.currentTimeMillis() - clickTime > 500) {
            clickCount = 0;
        } else {
            clickCount++;
        }
        clickTime = System.currentTimeMillis();

        if (clickCount > 6) {
            //        ，  debug  
        }
    }
});

releaseバージョンはきっとこのインターフェースを暴露することができないので、amを使ってコマンドラインで調整することもできません.どうやって防ぐことができますか?releaseバージョンでこのdebugインターフェースのexportdをfalseに設定することができます.
自動化構築
どうやってjenkinsを使ってandroidとiosを包装して、蒲公英プラットフォームにアップロードしますか?これは私のもう一つの文章を参考にして専門的に紹介します.
結び目
androidパッケージはgroovy言語の強大さのため、強くなると同時に必ず複雑になります.今日は私が経験したこれらのドアを取り出して言います.小さなまとめをして、後から更新します.また追加します.

公式サイトに従ってソロを学ぶ(二):Dockment、Field説明