Androidはgradleパッケージを使用した様々な構成

10764 ワード

ASでgradleパッケージを利用することで、さまざまなパラメータを効率的かつ自由に構成し、異なるバージョンをリリースすることができます.gradleファイルの構成方法については、以下にまとめます.
一.AndroidManifestのプレースホルダを置換
たとえば、AndroidManifestファイルでは、オーロラがプッシュするkey値をプレースホルダとして指定します.

在build.gradleファイルでは、このプレースホルダを置き換える3つの方法を紹介する.gradlew assembleコマンドで入力したカスタムパラメータの値を受信

manifestPlaceholders = [        
            //         key        
            JPUSH_APPKEY: "\"" + JPUSH_APPKEY_PARA + "\""
]

2.stringファイルの値の使用

manifestPlaceholders = [JPUSH_APPKEY:"@string/JPUSH_APPKEY"]

3.gradleを使用する.propertiesファイルの値は、9番目を参照してください.
二.独立した構成署名情報
署名に関する情報はgradleに直接書くのは安全ではありません.これらの情報を工事主moduleルートディレクトリのsigningに書くことができます.propertiesファイル、このファイルをバージョン管理に追加しないでください.

KEYSTORE_FILE=  keystore    
KEYSTORE_PASSWORD=   keystore    
KEY_ALIAS=   keystore       
KEY_PASSWORD=   keystore

そしてbuild.gradleにこのファイルをロードし、そのパラメータを参照すればいいです.

//         
Properties props = new Properties()props.load(new
FileInputStream(file("signing.properties")))
android {
  signingConfigs {    
    release{        
        //  release            
        keyAlias props['KEY_ALIAS']        
        keyPassword props['KEY_PASSWORD']        
        storeFile file(props['KEYSTORE_FILE'])        
        storePassword props['KEYSTORE_PASSWORD']    
    }
  }

...

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

三.マルチチャネルパッケージング
国内のアプリケーション市場は非常に多く、各アプリケーション市場のappダウンロード量と使用状況を統計するために、マルチチャネルのパッケージが必要です.
1.AndroidManifestを構成する.xmlは友盟チャネルを例にとると、チャネル情報は一般的にAndroidManifestに書かれている.xmlファイル:

マルチチャネルパッケージング方法を使用しない場合は、valueの値、xiaomi、360、qq、wandoujiaなどを手動で1つずつ変更する必要があります.マルチチャネルパッケージを使用するには、上のvalueを次のように構成する必要があります.

${UMENG_CHANNEL_VALUE}の値はgradleで構成をカスタマイズした値です.
2.build.gradle設定productFlavorsの書き方は以下の通りです.

productFlavors { 
  wandoujia  { 
    manifestPlaceholders = [UMENG_CHANNEL_VALUE: "wandoujia"] 
  } 
  xiaomi  { 
    manifestPlaceholders = [UMENG_CHANNEL_VALUE: "xiaomi"] 
  }
  qq  { 
    manifestPlaceholders = [UMENG_CHANNEL_VALUE: "qq"] 
  } 
  360  { 
    manifestPlaceholders = [UMENG_CHANNEL_VALUE: "360"] 
  }
}

[UMENG_CHANNEL_VALUE:[wandoujia]]は${UMENG_CHANNEL_VALUE}に対応する値です.ここには簡潔な書き方があります.

android {
  ...

  buildTypes {
      debug {
        ...
      }
      ...    
      release {
        ...
        productFlavors { 
            wandoujia{} 
            xiaomi{} 
            qq{} 
            360 {} 
        } 
        productFlavors.all { flavor -> flavor.manifestPlaceholders = [UMENG_CHANNEL_VALUE: name] 
      }
    }
}

ここで、nameの値は、各productFlavorsに対応するオプション値に対して、チャネル値を自動的に置き換える目的を達成します.このように(AS独自のツールGenerate signed apkで)apkを生成する場合は、対応するFlavorsを選択して指定したチャネルのパケットを生成すればよいし、生成したapkは自動的に対応するチャネルの接尾辞を追加します.
3.一度にすべてのチャネルパッケージを生成し、CMDコマンドを使用して、プロジェクトの所在するディレクトリに入り、直接コマンドを入力する.

gradle assembleRelease

Releaseパッケージを打つか、Android Studioの下の底欄にコマンドラインツールTerminalがあり、直接開いて、上のコマンドを入力してパッケージすることもできます.
注意:gradleを構成していない場合は、上記のコマンドを入力すると、「内部または外部コマンドではない」というプロンプトが表示される可能性があります.焦らないでください.gradleのディレクトリを見つけて、コンピュータの環境変数に構成すればいいだけです.
構成方法は次のとおりです.
まずgraldeのルートディレクトリを見つけ、システム変数に2つの環境変数を追加します.
変数名:GRADLE_HOME、変数値はgradleのルートディレクトリです.
例えば変数値は、D:android android-studio-ide-14.27393321-windowsandroid-studiogradlegradle-2.10
システム変数にPATHにgradleを追加するbinディレクトリもあります
例えば:D:android android-studio-ide-14.27393321-windowsandroid-studiogradlegradle-2.10 bin
これで構成が完了し、gradle assembleReleaseというコマンドを実行し、可能かどうかを確認します.
4.エクスポートパッケージのファイルディレクトリとapk名の変更

//         
def releaseTime() {    
      return new Date().format("yyyyMMdd", TimeZone.getTimeZone("UTC"))
}

android {
  ...

  buildTypes {
      debug {
        ...
      }
      ...    
      release {
        ...
        applicationVariants.all { 
            variant ->    variant.outputs.each { output ->        
                def outputFile = output.outputFile        
                if (outputFile != null && outputFile.name.endsWith('.apk')) {           
                    //   apk   XXX20160328_v1.0.0_vc10_XXXX_test.apk        
                    if (project.hasProperty('ENVIRONMENT_PARA') 
                    def fileName=" XXX${releaseTime()}_v${defaultConfig.versionName}_vc${defaultConfig.versionCode}_${variant.productFlavors[0].name}_${ENVIRONMENT_PARA}.apk"                  
                    //     APK                     
                    if (project.hasProperty('OUT_PUT_DIR_PARA')) {                    
                        File output_dir1 = file("${OUT_PUT_DIR_PARA}");                    
                        output.outputFile = new File(output_dir1, fileName)                    
                         println "      ： " + output.outputFile                
                    } else {                    
                        output.outputFile = new File(outputFile.parent, fileName)                    
                        println "      ： " + output.outputFile                
                    }            
                }        
            }    
        }
      }
  }
}

四.マルチエンジニアリンググローバル構成
製品チャネルの展開に伴い、多くの場合、1つのコードが複数の製品形態をサポートする必要があります.これは、プライマリコードを1つの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は、グローバル統合構成を実現します.
五.混同コード
releaseバージョンオープン混同

//    
minifyEnabled true
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'

混同ファイルはこの文章を参考にしてAndroidコード混同を構成するASの実践を行うことができる.
六.動的に追加情報を設定
現在のコンパイル時間、コンパイルされたマシン、最新のcommitバージョンをapkに追加

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つの文字列リソースを動的に追加することを実現しました:build_time、build_host、build_revisionは、他の場所で参照文字列のように次のように使用できます.

//  Activity   
getString(R.string.build_time) //   2016-09-07 17:01
getString(R.string.build_host) //          PC
getString(R.string.build_revision) //   3dd5823,       commit sha

七.buildConfigFieldカスタム構成
BetaバージョンサーバーとReleaseバージョンサーバーは通常1台のサーバーにありませんが、テストは2つのサーバーのバージョンを同時に発表してテストに使用することを望んでいます.このとき、コードを修正し、おとなしく発注する必要があります.gradleはbuildConfigFieldがマルチチャネルと協力して異なるサーババージョンを作成する方法を提供します.実は使い方は簡単です.まず、対応するノードに定義を加えます.例えば、次のようにします.

buildTypes { 
  debug { 
    buildConfigField "boolean", "LOG_DEBUG", "true"//    LOG     
    buildConfigField "String", "API_HOST", "\"http://api.test.com\""//API Host 
  } 
}

そしてコードにBuildConfigを通す.LOG_DEBUGまたはBuildConfig.API_HOST呼び出しでいいです.
八.dex 65535の制限を突破
プロジェクトが日に日に大きくなるにつれて、徐々に1つのdexが最大65535の方法数のボトルネックに直面し、ANTが構築したプロジェクトであれば面倒になりますが、Gradleはすでに処理してくれて、追加の方法も簡単で、全部で3つのステップに分けられます:1.まずdefaultConfigノードでマルチDEX機能を使用

android { 
  defaultConfig { 
      // dex  65535    
      multiDexEnabled true 
  } 
}

2.次にmultidexライブラリファイルを導入する

dependencies { 
  compile 'com.android.support:multidex:1.0.0' 
}

3.最後に、あなたのApplicationはMultiDexApplicationを継承すればいいです.
九.ここにいるpropertiesファイルでサーバの本番環境と本番環境を構成するアドレス、サードパーティサービスappkey、パッケージ名の構成
プロジェクトにサードパーティ用のSDKを入れると、様々なkeyの書き込みが避けられず、一般的には生産環境と正式環境がそれぞれ使用する値gradleがある.propertiesは次のとおりです.

#        key
JPUSH_APPKEY_VALUE_DEBUG=111111111111111111
#        key
JPUSH_APPKEY_VALUE_RELEASE=111111111111111111
#        key     
APPLICATIONID_JPUSH=com.xxx.xxx
#        key     
APPLICATIONID_RELEASE=com.xxx.xxx
#       
BASE_URL_TEST=
#       
BASE_URL_REAL=

在build.gradleファイルで参照されます.

defaultConfig {
  if (project.hasProperty('JPUSH_APPKEY_PARA')) {    
    //       key      ，           key   appId
    applicationId project.APPLICATIONID_JPUSH
  } else {    
    //     appId    
    applicationId project.APPLICATIONID_RELEASE
  }

   manifestPlaceholders = [                
      //         key
      JPUSH_APPKEY: project.JPUSH_APPKEY_VALUE_RELEASE        
  ]
}

buildConfigFieldカスタム構成にも対応:

buildConfigField("String", "BASE_URL", "\"" + project.BASE_URL_TEST + "\"")

githubバージョン:Androidでgradleを使用してパッケージ化されたさまざまな構成

表示プロパティのための新しい2値構文🪄

AWSで組織を作る