How to Prepare an Android App for Production

The first week after launch is when you learn what you didn't test: the crash on a specific manufacturer, the login loop after a password change, the screen that breaks in Hindi. Preparing for production means reducing those surprises and making the remaining ones visible and recoverable.

Readiness areas

Build configuration

• ☐ Correct applicationId, versionCode (always increasing) and versionName
• ☐ targetSdk meets the current Play requirement; behaviour changes tested
• ☐ R8 and resource shrinking enabled; minified build tested end to end
• ☐ Release build is not debuggable; debug-only tools (LeakCanary, StrictMode) excluded
• ☐ Production API endpoints and config; feature flags have safe defaults

android {
    buildTypes {
        debug {
            applicationIdSuffix = ".debug"            // install side by side with release
            buildConfigField("String", "API_BASE", "\"https://staging.api.example.com/\"")
        }
        release {
            isMinifyEnabled = true
            isShrinkResources = true
            buildConfigField("String", "API_BASE", "\"https://api.example.com/\"")
        }
    }
}

Observability

• ☐ Crash reporting (for example Crashlytics) with R8 mapping files uploaded
• ☐ Analytics for key funnels, with privacy-respecting events. See Analytics and Crash Reporting
• ☐ Non-fatal error logging for important failures (payments, sync)
• ☐ Android vitals reviewed, with alerts configured

Performance

• ☐ Cold start measured on a mid-range device; Baseline Profile included
• ☐ No StrictMode violations on main flows; no jank in key lists
• ☐ App size checked with APK Analyzer

Quality and accessibility

• ☐ Loading, empty, error and offline states on every data screen
• ☐ Rotation, dark mode, large font, small and large screens checked
• ☐ TalkBack pass on key flows; content descriptions; touch targets
• ☐ Play Console pre-launch report reviewed

Security and privacy

• ☐ No secrets in the APK; release logging scrubbed
• ☐ Exported components audited; TLS only
• ☐ Privacy policy published; Data safety form accurate, including SDKs
• ☐ Account deletion available if users can create accounts

Localisation

• ☐ All user-facing strings in resources; translations reviewed by native speakers
• ☐ Long-text languages and RTL layouts checked; numbers, dates and currency formatted per locale

Rollout and recovery

1. Release to internal, then closed testing, then a staged production rollout.
2. Define halt criteria: for example, a crash-free user rate dropping below your baseline.
3. Be able to disable features remotely (feature flags or remote config).
4. Have an in-app update prompt strategy for critical fixes.
5. Prepare support channels and review responses.

Right-size it

Frequently asked questions

Conclusion

Production readiness is a checklist across build, observability, performance, quality, security, privacy, localisation and rollout. Run it before every major release, and you'll spend launch week improving the app instead of firefighting.

Next step: master the console you'll live in after launch with Google Play Console: A Developer's Guide.