android 动态修改manifest,Android动态替换AndroidManifest的值

名称

gradle中的manifestPlaceholders

场景

场景举例：项目中集成了推送，管理后台设计了“全量用户推送”功能，该功能的测试不能影响线上用户，固需要将debug与release环境的推送AppKey和AppSecret区分开，第三方推送的AppKey和AppSecret常配置在AndroidManifest中的，每次发版的时候去修改，极容易忘记，则可以用到gradle中的manifestPlaceholders

用法

要区分debug与release环境的配置，则在项目module的buildeTypes的debug和release下增加manifestPlaceholders，示例代码：

build.gradle

buildTypes{

release{

……

manifestPlaceholders = [APP_KEY:"1111122222",

APP_SECRET:"4d32bbbda76sdf23fxv11ccf27c21fc74"]

}

debug{

……

manifestPlaceholders = [APP_KEY:"3333344444",

APP_SECRET:"8a1c2d8fac99ff91as3fsc3bbd189ba"]

}

AndriodManifest.xml

android:name="app_key"

android:value="${APP_KEY}" />

android:name="app_secret"

android:value="${APP_SECRET}" />

检查是否生效

在启动过程中任意一个Java类中加入检查代码，比如Application的onCreate方法中：

try {

ApplicationInfo applicationInfo = getPackageManager().getApplicationInfo(appContext.getPackageName(), PackageManager.GET_META_DATA);

int pushAppKey = applicationInfo.metaData.getInt("app_key");

String pushAppSecret = applicationInfo.metaData.getString("app_secret");

StringBuilder pushLog = new StringBuilder();

pushLog.append("PushAppKey=");

pushLog.append(pushAppKey);

pushLog.append("PushAppSecret=");

pushLog.append(pushAppSecret);

LogCat.i(pushLog.toString());

} catch (PackageManager.NameNotFoundException e) {

e.printStackTrace();

}

注意与思考

manifestPlaceholders可以直接加在defaultConfig和buildType(release和debug)里，如果key重复，则release和debug会覆盖defaultConfig；

Manifest中的变量引用是${}，而不是@{}，别被DataBinding带沟里去了；

在Java中可以检查时，applicationInfo.metaData.getString传的是AndroidManifest中meta-data的name，而不是manifestPlaceholders的key；如果值是数字，把getString()换成getInt()；

若需要release生效而debug不生效的配置，也可以用相同的方法，debug下设为空就好了，如：错误日志统计。