Shipping an Android App Solo: The End-to-End Process From Code to Play Store

When you're a solo developer, "release day" is every phase of the process: QA, build, sign, upload, monitor. No handoffs. No DevOps team. Here's how to do it efficiently without cutting corners.

The Week Before Release

Monday-Wednesday: Feature freeze and bug fixing.

No new features after Monday. Everything goes into fixing what's broken and polishing what's rough. This is hard to enforce on yourself — the temptation to add "just one more thing" is always there. Resist it.

Thursday: Full regression pass.

Run through every major user flow manually:

• Login/signup
• Primary feature flows (create, read, update, delete)
• Settings changes
• Notification behavior
• Offline mode
• The flow you last changed (highest regression risk)

Friday: Build and internal test.

Build the release AAB, install on your personal device (not a debug build — the release build), and test for another 30-60 minutes. Release builds behave differently from debug:

• ProGuard/R8 is active
• Production API keys are used
• No debug logging
• Performance characteristics are different

Building the Release AAB

# Clean build to avoid stale cache issues
./gradlew clean

# Build signed release AAB
./gradlew bundleRelease

# Or, if using CI (preferred):
git tag v2.3.0
git push origin v2.3.0
# CI builds, signs, and uploads automatically

Verify the output:

# Check the AAB was created
ls -la app/build/outputs/bundle/release/

# Verify the signing
./gradlew validateSigningRelease

Pre-Upload Checklist

Before clicking "Upload" in Play Console:

• Version code incremented from previous release
• Version name updated (x.y.z format)
• Release build tested on physical device
• No critical or major bugs open
• What's New text written (1-3 sentences, user-facing language)
• Release notes reviewed — no internal jargon
• Screenshots current (if this release has UI changes)

Writing Good Release Notes

Bad release notes:

• Fixed crash
• Performance improvements
• Various bug fixes

Good release notes:

• Fixed a crash that occurred when completing tasks with long titles
• Task list now loads 40% faster on older devices
• Improved reliability when syncing tasks while offline

Users read release notes. Vague notes communicate "we don't care enough to tell you what changed." Specific notes build trust.

Play Store Upload and Review Settings

In Play Console → Production → Create new release:

1. Upload your AAB
2. Set the release name (usually the version name)
3. Add release notes for each language you support
4. Save and review

Before promoting to production, check:

• "Pre-launch report" (Firebase Test Lab runs automatically for new releases) — review for crashes
• "Release dashboard" — shows any store policy warnings

The Staged Rollout Strategy

Never release to 100% immediately:

At each step, check Android Vitals:

• Crash-free rate should stay above 99.5%
• ANR rate should stay below 0.1%
• If either degrades, pause the rollout

To pause a rollout in Play Console: Production → Manage release → Halt rollout.

The First 48 Hours After Release

Immediately after release:

• Set an alert for crash rate (Android Vitals → Alerts)
• Watch Firebase Crashlytics for new crash types
• Monitor user reviews for new complaints

24 hours later:

• Check crash-free rate trend
• Review any new 1-2 star reviews — they often contain bug reports
• If metrics are stable, promote staged rollout to higher percentage

48 hours:

• If everything's clean, release to 100%
• Write a brief post-mortem note: what shipped, what monitoring showed, any issues

Handling a Post-Release Crash

If a critical crash appears after release:

1. Halt the rollout immediately. In Play Console — don't wait to diagnose first.
2. Identify the crash. Use Crashlytics to find the stack trace and affected devices.
3. Reproduce locally. Can you reproduce it with a release build?
4. Hotfix. Branch from the release tag, fix, test, rebuild.
5. Resume with the fixed build. Increment the version code.

[!WARNING] Never resume a halted rollout with the same build that caused the crash. Always fix and re-upload.

Post-Mortem Template

After every release, spend 10 minutes writing:

## Release 2.3.0 — Post-Mortem

**Release date:** 2026-03-31
**Rollout completed:** 2026-04-02
**Crash-free rate at 100%:** 99.7% (baseline: 99.6%)
**New critical bugs:** 0
**User reviews this week:** 4.1 avg (prev: 4.0)

**What went well:**
- CI automated the build and upload — no manual steps
- Regression pass caught a form validation bug before release

**What to improve:**
- Release notes were vague — improve specificity next time
- Internal test period was only 1 day — extend to 2 days for major releases

Takeaways

• Feature freeze a week before release — late additions are the highest-risk changes
• Test the release build on a real device — not a debug build
• Write specific release notes — users and algorithms both notice
• Staged rollout is mandatory — never ship to 100% immediately
• Halt at the first sign of crash rate increase — don't wait to see if it resolves