React Native CodePush：打包Release APK切换部署密钥的方法与自动化方案

Hey there! Let's break down the best way to switch your CodePush deployment key to Production and automate the process—no more manual edits to strings.xml every time.

直接修改strings.xml isn't a sustainable long-term practice—it's easy to make mistakes, and hardcoded keys complicate environment switching. Instead, we can use Gradle to dynamically inject deployment keys, making environment changes seamless and automatable.

1. 基础配置：用Build Types/Product Flavors区分环境 #

方式A：扩展Build Types（快速适配现有构建流程） #

If you already use release and debug build types, you can add a stagingRelease type for your Staging environment:

Add this to your android/app/build.gradle file:

android {
    buildTypes {
        release {
            // Production deployment key
            resValue "string", "reactNativeCodePush_androidDeploymentKey", '"ppp"'
            // Keep your existing Release configuration here
        }
        stagingRelease {
            initWith release // Inherit all Release settings
            // Staging deployment key
            resValue "string", "reactNativeCodePush_androidDeploymentKey", '"sss"'
        }
    }
}

Now you can build for each environment with simple commands:

• Production Release: ./gradlew assembleRelease
• Staging Release: ./gradlew assembleStagingRelease

方式B：用Product Flavors（适合多环境长期维护） #

If you need to maintain multiple environments (like Production, Staging, QA) long-term, Product Flavors are more organized:

Add this to your android/app/build.gradle file:

android {
    productFlavors {
        production {
            resValue "string", "reactNativeCodePush_androidDeploymentKey", '"ppp"'
        }
        staging {
            resValue "string", "reactNativeCodePush_androidDeploymentKey", '"sss"'
        }
    }
}

Build commands become:

• Production Release: ./gradlew assembleProductionRelease
• Staging Release: ./gradlew assembleStagingRelease

Pro tip: After setting this up, delete the reactNativeCodePush_androidDeploymentKey field from your strings.xml—Gradle's resValue will auto-generate this resource, eliminating conflicts.

2. 自动化切换：适配CI/CD流水线 #

For automated builds (like in GitHub Actions, GitLab CI, or Jenkins), use one of these methods to switch keys dynamically based on your environment/branch:

方式A：Gradle Build Parameters #

Pass the key directly via the command line:

# Build Production Release
./gradlew assembleRelease -PcodePushKey="ppp"

# Build Staging Release
./gradlew assembleRelease -PcodePushKey="sss"

Then read the parameter in build.gradle (with a default fallback to Staging):

android {
    def defaultKey = '"sss"'
    def codePushKey = project.hasProperty('codePushKey') ? "\"${project.codePushKey}\"" : defaultKey

    buildTypes {
        release {
            resValue "string", "reactNativeCodePush_androidDeploymentKey", codePushKey
        }
    }
}

方式B：Environment Variables #

Set an environment variable in your CI system (e.g., CODE_PUSH_KEY), then read it in build.gradle:

android {
    def defaultKey = '"sss"'
    def codePushKey = System.getenv("CODE_PUSH_KEY") ? "\"${System.getenv("CODE_PUSH_KEY")}\"" : defaultKey

    buildTypes {
        release {
            resValue "string", "reactNativeCodePush_androidDeploymentKey", codePushKey
        }
    }
}

This works great for pipelines where you set environment variables per branch (e.g., CODE_PUSH_KEY=ppp for main branch, CODE_PUSH_KEY=sss for staging branches).

总结 #

• Prioritize Product Flavors or Build Types for environment-specific keys to avoid hardcoding.
• For automation, use Gradle parameters or environment variables to dynamically inject keys in CI/CD pipelines.
• Always remove the hardcoded key from strings.xml to prevent conflicts.

内容的提问来源于stack exchange，提问作者Poni