DEV Community

Anand Rathnas
Anand Rathnas

Posted on • Originally published at jo4.io

Why Our Android Build Was Signed with the Wrong Key (A Regex Cautionary Tale)

#reactnative #android #debugging #regex

This article was originally published on Jo4 Blog.

"Your Android App Bundle is not signed with the correct key."

That was the Google Play Console rejection after what should have been a routine release. The SHA1 fingerprint on the uploaded AAB didn't match the expected upload key. We'd been deploying to the Play Store for weeks with no issues. What changed?

Nothing, as it turned out. The signing had been broken the whole time -- we just hadn't noticed until Google tightened its fingerprint check.

The Setup

We use Expo with expo prebuild --clean to generate the android/ directory before each build. Because it's regenerated every time, the entire android/ folder is gitignored. This means any customization to build.gradle needs to happen through a post-prebuild injection script.

Our scripts/release.sh runs after prebuild and uses Node.js to patch the generated build.gradle with the release signing configuration. It finds the release buildType block and replaces signingConfig signingConfigs.debug with signingConfig signingConfigs.release.

Sounds straightforward. But the regex doing this work had a subtle, devastating bug.

The Symptom

After release.sh ran, we expected build.gradle to look like this:

buildTypes {
    debug {
        signingConfig signingConfigs.debug
    }
    release {
        signingConfig signingConfigs.release  // patched
    }
}
Enter fullscreen mode Exit fullscreen mode

Instead, it looked like this:

buildTypes {
    debug {
        signingConfig signingConfigs.release  // WRONG
    }
    release {
        signingConfig signingConfigs.debug    // WRONG
    }
}
Enter fullscreen mode Exit fullscreen mode

The configs were swapped. Debug was using the release keystore. Release was using the debug keystore. The build succeeded (both keystores are valid), but the release AAB was signed with the debug key.

The Buggy Regex

Here's the regex our script used:

const patched = buildGradle.replace(
  /release \{[\s\S]*?signingConfig signingConfigs\.debug/,
  match => match.replace('signingConfig signingConfigs.debug', 'signingConfig signingConfigs.release')
);
Enter fullscreen mode Exit fullscreen mode

The intent: find release { followed (lazily) by signingConfig signingConfigs.debug, then replace that debug with release.

The problem: release { appears twice in the generated build.gradle.

signingConfigs {
    debug {
        // ...
    }
    release {        // <-- FIRST occurrence of "release {"
        storeFile file("release.keystore")
        storePassword "..."
        keyAlias "..."
        keyPassword "..."
    }
}

buildTypes {
    debug {
        signingConfig signingConfigs.debug   // <-- target line
    }
    release {        // <-- SECOND occurrence of "release {"
        signingConfig signingConfigs.debug   // <-- intended target
    }
}
Enter fullscreen mode Exit fullscreen mode

The lazy quantifier [\s\S]*? matched the first release { (inside signingConfigs), then expanded minimally until it found signingConfig signingConfigs.debug. The first signingConfig signingConfigs.debug it encountered was inside the debug buildType. So the regex matched from signingConfigs.release { all the way down to the debug buildType's signing config -- and replaced it.

This is the core misunderstanding: lazy quantifiers don't find the closest release { to the target. They find the first release { in the file, then minimize the gap from there. If the first match is in the wrong block, the lazy expansion crosses block boundaries to reach the target string.

The Fix

Anchor the regex to the buildTypes section:

const patched = buildGradle.replace(
  /(buildTypes\s*\{[\s\S]*?release\s*\{[\s\S]*?)signingConfig signingConfigs\.debug/,
  '$1signingConfig signingConfigs.release'
);
Enter fullscreen mode Exit fullscreen mode

By requiring buildTypes { before release {, the regex skips the signingConfigs.release block entirely. The capture group grabs everything from buildTypes { through release { and any content before the signing config line. Then we replace just the signingConfig reference while preserving the surrounding structure.

The key difference:

BEFORE: /release \{[\s\S]*?signingConfig signingConfigs\.debug/
AFTER:  /(buildTypes\s*\{[\s\S]*?release\s*\{[\s\S]*?)signingConfig signingConfigs\.debug/
Enter fullscreen mode Exit fullscreen mode

The buildTypes\s*\{ anchor ensures we're in the right block before we ever look for release {.

Bonus Bug: versionCode Stuck at 1

While debugging the signing issue, we found a second problem. Expo prebuild defaults versionCode to 1 in every generated build.gradle. Google Play requires versionCode to be strictly increasing -- you can never upload a version code equal to or lower than a previously uploaded one.

Our fix: auto-generate versionCode from epoch minutes in the release script:

VERSION_CODE=$(($(date +%s) / 60))
Enter fullscreen mode Exit fullscreen mode

This produces a value like 29432517 that increases every minute. No manual tracking, no CI state to maintain, and no collisions as long as you don't release twice in the same minute.

The Node.js injection then patches this into build.gradle:

buildGradle = buildGradle.replace(
  /versionCode \d+/,
  `versionCode ${process.env.VERSION_CODE}`
);
Enter fullscreen mode Exit fullscreen mode

Lessons Learned

1. Lazy quantifiers aren't always lazy enough.

The *? quantifier minimizes the match after fixing the start position. If your start anchor (release {) appears multiple times, the regex locks onto the first occurrence and expands from there. It doesn't backtrack to try the second occurrence unless the first one fails entirely.

2. When a pattern appears in multiple blocks, anchor to the surrounding context.

Don't match release { when you mean buildTypes { ... release {. The extra context eliminates ambiguity. This applies to any structured text you're patching with regex -- Gradle files, XML, YAML, anything with nested blocks.

3. Gitignored generated files need persistent injection scripts -- and those scripts need tests.

We tested the app. We tested the build. We never tested release.sh in isolation. A simple assertion -- "after running the script, the release buildType should have signingConfigs.release" -- would have caught this immediately.

4. Always verify build artifacts before pushing to a store.

A one-line check would have saved hours:

# Verify the AAB is signed with the correct key
jarsigner -verify -verbose -certs app-release.aab | grep "SHA1:"
Enter fullscreen mode Exit fullscreen mode

If the fingerprint doesn't match your expected upload key, stop. Don't submit and hope for the best.

The Meta-Lesson

Regex on structured data is inherently fragile. Every time expo prebuild changes the generated build.gradle format, our regex could break in new and creative ways. The real long-term fix is to use Expo's config plugins to inject signing configuration declaratively, removing the regex entirely. We're migrating to that approach now.

But until then -- anchor your patterns, test your scripts, and verify your artifacts.

Have you been burned by regex matching across block boundaries? What's your approach to patching generated build files? We'd love to hear about it in the comments.

Building jo4.io -- a URL shortener with analytics, QR codes, and a mobile app that is now correctly signed.

Top comments (0)