Testing Upgrade Paths in a Google Play Closed Test: Will Your Update Keep Testers' Data?

Most developers test a closed-test build the same way: uninstall, install fresh, tap around. But your testers don't do that. They install build 1, use it for several days, and then Play updates it in place to build 2. If that upgrade crashes or wipes their data, you have a bug that a fresh install will never show you.

This post is about testing the upgrade path: going from build N to build N+1 with real data already on the device.

Why upgrades break things fresh installs don't

A fresh install starts with an empty app. An upgrade starts with whatever your previous version left behind. That includes:

A local database in an older schema
Saved preferences or DataStore files with old keys and formats
A stored login session or token
Cached files and downloaded content
Scheduled background work and notification channels created by the old version

Any change to how your code reads that old state can fail. A renamed preference key, a new non-null database column, or a changed serialization format can each cause a crash on launch for existing users only.

Start with the basics: version codes and signing

Before you test migrations, make sure the update can be installed at all.

Increase versionCode every time you upload. Play Console rejects a bundle whose version code was already used. versionName is only a label for humans.
Sign with the same key. If you use Play App Signing, this is handled for you on Play. For local debug installs, an APK signed with a different key cannot be installed over the old one.
Check minSdk changes. Raising it can make the update unavailable on some testers' devices. Lowering it is usually safe, but it widens the range of Android versions you need to think about.

The upgrade test routine

You only need a spare device or emulator and about 15 minutes per release.

Install the previous build. Use the same build your testers have, ideally the AAB-derived version from the closed track on a real phone. For quick local checks, adb install of the old debug APK works.
Create realistic state. Sign in, add several records, change settings, grant or deny permissions, and finish onboarding. An empty account proves very little.
Install the new build over it. For local builds, use adb install -r app-debug.apk. This keeps the app data, just as an update from Play does.
Launch and compare. Is everything still there? Are you still signed in? Do settings hold?
Exercise the changed areas. If you touched the database, edit and delete old records, not just read them.
Check Logcat for exceptions on first launch after the update. Migration crashes usually happen immediately.

Keep one old APK per released version. It costs almost nothing and lets you test from any earlier version, not only the last one.

What to check, area by area

Database migrations

If you use Room, any schema change needs a Migration from the old version to the new one. Be careful with fallbackToDestructiveMigration(): it avoids crashes, but it silently deletes the user's data. That may be fine for a throwaway cache and is a bad surprise for anything the user created. Room ships a test helper for this, and the official guide is at developer.android.com.

Preferences and DataStore

If you rename a key or change a value type, read the old one first, convert it, then write the new one. A simple check is to set every setting to a non-default value before upgrading and confirm each survives.

Login state

Check that the user stays signed in after the update. Also check what happens if your new version expects a field in the stored session that the old version never saved. A missing field should send the user to a clean re-login, not a crash.

Background work and notifications

Scheduled jobs from the old version may still be queued when the new code runs. If you renamed a worker class or changed its input data, old queued work can fail. Notification channels are also persistent: once created, a channel's importance is controlled by the user, so changing it in code won't change it on existing installs.

Permissions

Users who already granted or denied a permission keep that state across updates. If your new version starts needing a new permission, test the flow for someone who has used the app for days, not only someone in first-run onboarding.

Using your testers for upgrade coverage

Your closed testers are a good source of upgrade coverage because they naturally hold an older build and accumulate real data. With TesterMob, for example, testers use each app on their own Android phones for about 20 minutes a day, so by the time your next update arrives they have genuine state on the device. See how it works for developers for the details.

To make that useful, tell them what to look for. In your release notes, add one line such as:

This update changes how saved items are stored. After updating, please check that your existing items are still there and tell us if anything is missing.

That gives testers a concrete task and gives you a specific signal. If you use the optional Android SDK, the dashboard's daily tester activity can also help you see whether testers are actually opening the app after an update, though it won't tell you whether their data survived. For that you need their written feedback.

If an upgrade breaks something

Don't try to remove the bad build. Fix forward. Increase the version code and upload a corrected build to the same closed track.
Write the migration, not a workaround. If data was lost, the fix is a proper migration for users still on the earlier version.
Test from every version in the field. If some testers got build 2 and others skipped to build 3, check both 1→3 and 2→3.
Tell testers what happened. A short, honest note in the release notes helps them recover and keeps them engaged.

Whether and how updates affect your closed test requirements can depend on Google's current rules, so check Play Console Help for the latest details. In general, keeping testers opted in and the app stable is what you want. If you're unsure how many updates make sense, see our FAQ. TesterMob is not affiliated with Google and can't guarantee production approval, but a stable update path is something you control.

A quick pre-update checklist

Version code is higher than every previous upload
Signing key is unchanged
Installed the previous build with realistic data, then updated over it
Database schema changes have a tested migration
Renamed or retyped preferences are converted, not dropped
User stays signed in, or is cleanly sent to login
No crash in Logcat on first launch after the update
Release notes tell testers what to verify

This takes a short time per release and covers the kind of bug that only appears for real users. If you are still planning your closed test, pricing is a one-time $9.99 per app, paid in USDT, with no subscription.