DEV Community: Emre P.

Lost your keystore? You can still publish updates on Google Play. Here is how

Emre P. — Fri, 02 Oct 2026 17:24:34 +0000

You open Android Studio to ship a small fix and the build asks for a keystore you no longer have. Maybe it was on an old laptop. Maybe a freelancer built the app and never handed the key over. Maybe you still have the file but the password is gone.

Whether you can publish updates again depends on one setting you may never have looked at. Here is how to check it, and what to do in each case.

First, the two keys

Google Play apps can have two different keys, and people mix them up all the time.

App signing key: the key that signs the APKs your users install. If your app uses Play App Signing, Google keeps this key. You never see it and you can't lose it.
Upload key: the key you sign your AAB with before uploading it to Play Console. This is the one that lives in your .jks or .keystore file.

If you are on Play App Signing, what you lost is the upload key. That one can be reset.

Check if you are on Play App Signing

In Play Console, open your app and go to the app signing page. Google moves the menu around, but at the time of writing it is under Protected with Play → Play Store distribution → Manage Play app signing (older layouts: Test and release → App integrity).

If you see "Releases signed by Google Play" or an App signing key certificate managed by Google, you are fine. Every app published for the first time since August 2021 uses Play App Signing, because new apps have to publish as app bundles.

Case 1: Play App Signing is on (most apps)

You are not locked out. You create a new upload key and ask Google to accept it.

1. Create a new upload key on your own computer:

keytool -genkey -v -keystore upload-keystore.jks -keyalg RSA -keysize 2048 -validity 10000 -alias upload

Pick a password you will actually keep, and store the file somewhere that is not your laptop only: a password manager, an encrypted drive, anywhere you'll still have in three years.

2. Export its certificate:

keytool -export -rfc -keystore upload-keystore.jks -alias upload -file upload_certificate.pem

3. Request the reset. On the same app signing page, in the upload key certificate section, choose Request upload key reset, pick a reason, upload upload_certificate.pem and submit.

4. Wait for Google. The account owner gets an email when the request is approved, with the date and time from which the new key works. It usually takes a day or two. Until then, uploads signed with the new key will be rejected, so don't panic if an early try fails.

5. Point your build at the new key. In a Flutter project that usually means updating android/key.properties (storeFile, storePassword, keyAlias, keyPassword). In a native project it's the signingConfigs block in build.gradle. Then build a release AAB and upload it as usual.

That's it. Your users notice nothing: the installs are still signed with Google's app signing key, which never changed.

Forgot the password but still have the file? Same fix. Without the password the file is useless, so treat it as lost and reset.

Case 2: Play App Signing is off and the key is gone

This is the bad one. If you manage the app signing key yourself and lose it, Google can't reset it, and no one else can either. Nobody can "recover" a keystore from your app, whatever a gig title says.

What is left:

Search properly before giving up: old laptops, backup drives, CI secrets, the freelancer or agency that built the app, email attachments with .jks or .keystore files.
If it's really gone, the app can't be updated. The way forward is to publish it again under a new package name and move your users over with an in-app message or a final update of the old listing if you still can.

A real case

A client of mine hired me for something else, the developer verification check, and mentioned on the side that she didn't have her signing key anymore.

The first thing I checked was the app signing page: "Releases signed by Google Play". So the app was on Play App Signing and a reset was possible. What sounded like "I can never update my app again" turned into a short checklist. With the target API 36 deadline for updates coming on November 1, the reset is the first step, because no update can go out without a working upload key.

Don't lose it again

Keep the upload keystore and its password in two places, one of them off your computer.
Write down the alias. People keep the file and forget the alias.
If someone else builds your app, ask for the upload key and passwords as part of the handover.
Never send your keystore or passwords to anyone who offers to "fix it for you". A reset never needs them.

I help small teams and solo developers with Google Play problems like this one. If you'd rather not do the reset on your own, I walk you through it as a fixed-price job, and your key stays on your computer the whole time: my Upwork profile.

Official sources:

"Not registered" but it is: 4 real cases before the Sept 30 deadline

Emre P. — Sun, 27 Sep 2026 16:23:43 +0000

The September 30 deadline for Play package name registration has passed. Apps that were not registered were removed from Play. Most apps were registered automatically, and my earlier post covers how to check yours.

This post is about the other situation: Play Console says one thing, the release page says another, and you are not sure what to believe. These are four real cases I ran into in the last week, from the Play Help Community and from a client. Each one looked like a Google bug. Most of them were not.

Case 1: "Registered", but the package name is "already in use"

What they saw: A Flutter app. The package showed as registered under Android developer verification, but creating the app in Play Console failed with "already in use".

Why: The package name was com.example.hello_flutter. That is the Flutter template default. Thousands of projects ship with it, and Play does not accept apps under com.example at all.

Fix: Change the package name. If the app was never published, you lose nothing:

In android/app/build.gradle (or build.gradle.kts), change applicationId to something unique, like com.yourname.appname. namespace can stay as it is.
If you use Firebase, add a new Android app with the new package name and download the new google-services.json (or run flutterfire configure again). Your Firebase project and data stay the same.
Register the new name under Android developer verification, then create the app in Play Console with it.

After the first release the package name can never change, so pick one you are happy with.

Case 2: "No eligible signing keys are available"

What they saw: The developer had two certificates for the app. Neither one appeared as an option for registration.

Why: Eligibility is based on known installs per signing key. From Google's help page:

A key with over 50% of known installs has priority.
If no key passes 50%, every key with 50 or more installs is eligible.
Under 50 installs, it is first come, first served.

This app was also preinstalled on a manufacturer's devices. That build can easily count for most of the installs. If the manufacturer signed it with their own key, the eligible key belongs to them, not to the developer.

Fix: Find out who holds the key used for the preinstalled build. Then open a case from the Help page inside Play Console with the package name, the SHA-256 fingerprints of both certificates, and a note that one build is a manufacturer preinstall. With the deadline this close, open the case today instead of waiting for forum replies.

Case 3: Registered, but the release is still blocked

What they saw: The package showed as registered, but the production release failed with an "unregistered package name" error.

This one I could not solve from the outside, but there are three things worth ruling out before your ticket sits in a support queue:

Same account. The package has to be registered in the same Play Console developer account that owns the app. Not in a separate Android Developer Console account, and not in another Play account.
Same key. Compare the certificate you registered with the app signing key under Test and release → App integrity. If you registered the wrong one (for example the upload key instead of the app signing key), Play may treat the release as coming from an unregistered key.
Fresh release. If you registered after creating the release draft, discard the draft and create a new release. An old draft does not always pick up the new state.

A related case from the same week: a developer who used Internal app sharing got the same kind of error. Internal app sharing builds are signed with a different key, and the fix was to register that key as an additional key for the package.

If all of this checks out, the problem is on Google's side. Open a case from the Help page inside Play Console and attach two screenshots: the one showing "Registered" and the release error.

Case 4: "My registration disappeared"

What they saw: A client of mine. We had checked her app together, confirmed it was registered and closed the order. Then she wrote back: "It says Package not registered."

Why: Nothing was wrong. On the Android developer verification page there is a filter menu, and one of the options is literally called "Package not registered". She was reading the filter's label as the status of her app.

How to actually check:

Select the "Package not registered" filter. If the list is empty (0 apps), you are fine.
Open Package names. The status column should say Registered.

I am including this case because it is the most common one, and it causes real panic when a deadline says "removed from Play".

After September 30

Google's wording is clear: apps not registered by September 30 "will be removed from Play". Identity verification for installs outside Play also starts in Brazil, Indonesia, Singapore and Thailand on the same day, and goes global in 2027. So this topic is not going away.

Quick checklist

[ ] Package name does not start with com.example
[ ] Registered in the same account that owns the app
[ ] Registered certificate matches the app signing key in App integrity
[ ] Extra keys (Internal app sharing, builds outside Play) added
[ ] New release created after registration
[ ] "Package not registered" filter shows 0 apps

I fix Google Play problems for small teams and solo developers: developer verification, target API updates, rejected releases. If one of your apps is still flagged and you want it sorted soon, I do it as a fixed-price job through Upwork: my Upwork profile. I never need your keystore file.

Official sources:

Google Play removed unregistered apps on September 30. What to do if yours was one of them

Emre P. — Wed, 23 Sep 2026 17:06:21 +0000

Update: if your app shows as registered but you still get errors, I wrote up 4 real cases and their fixes.

Android developer verification has been in the news for a year, mostly as "sideloading is changing". That part is real, but it hides the part that affects every developer on Google Play:

Apps not registered by Sep 30, 2026 will be removed from Play.

That is Google's wording, not mine. Not "cannot be updated". Removed. Globally.

The good news is that for most of you it is already done. Google says about 99% of Play apps were registered automatically. This post is for the other 1%, and for everyone who has not checked yet, because checking takes two minutes and finding out on October 1 does not.

What is actually changing

There are two separate things, and people mix them up.

1. Identity verification. Every developer who distributes apps to certified Android devices has to be a verified developer. If you publish on Google Play, you most likely already did this when Play introduced its own developer verification. Google's guide says that for most Play developers no new action is required. You can confirm it under Settings → Developer account in Play Console.

2. Package name registration. Every package name has to be registered to a verified developer, and you may need to prove you own the private signing key for it. This is the part with the September 30 deadline on Play.

Separately, from September 30, 2026 installs of apps from unverified developers are blocked on certified devices in Brazil, Indonesia, Singapore and Thailand. It expands globally in 2027. If you only publish on Play and your packages are registered, you are fine there too.

Check your status

Open Play Console.
Look at the Home page. Apps that still need registration are flagged there.
Open Android developer verification to see the status of each app.

If every app shows as registered, you are done. Close the tab.

Why some apps were not registered automatically

Google registered packages based on which signing key the installs came from:

If one key accounts for more than 50% of known installs, that key has priority.
If no key passes 50%, every key with 50 or more installs is eligible.
If no key has 50 installs, it is first come, first served.

So the apps that fall through are usually edge cases: an app signed with more than one key over its lifetime, an app that was also distributed outside Play with a different key, a small app with very few installs, or a package name that someone else registered first.

If you have to prove key ownership

Play Console walks you through it, but it looks scarier than it is:

In the app list, select Add key.
Choose the app's public certificate.
Play Console gives you a small snippet. Put it in the APK's assets folder.
Sign that APK with your private key and upload it.

The APK is only a proof of ownership, it does not replace your app. Your private key never leaves your machine; you only upload something signed with it. If anyone offers to "handle it" and asks for your keystore file, say no.

If you also ship builds outside Play (a direct download, another store, an internal build with a different key), register those extra keys under Android developer verification → Package names once the package itself is registered.

If you distribute outside Google Play

You need the Android Developer Console instead:

A $25 fee and a government ID.
Organizations need a D-U-N-S number. It is free, but Google warns it can take up to 28 days. If you are an organization and have not started, you are already late for the four launch countries.
A limited distribution account is free, needs no ID and covers up to 20 devices. It is meant for students, hobbyists and closed groups, not for a real release.

ADB installs for your own testing keep working either way.

The checklist

[ ] Play Console → Settings → Developer account: identity verified
[ ] Play Console → Home / Android developer verification: every package registered
[ ] Apps with old or multiple keys: key ownership proven with the signed APK
[ ] Builds shipped outside Play: extra keys registered
[ ] Organization distributing outside Play: D-U-N-S requested

If all five are ticked, September 30 is a normal Wednesday for you.

I fix Google Play problems for small teams and solo developers: target API updates, rejected releases, and now this. If one of your apps is flagged and you would rather not spend an evening on it, I do it as a fixed-price job through Upwork: my Upwork profile.

Official sources:

I upgraded three Flutter apps to API 36. Here is what actually broke

Emre P. — Sun, 20 Sep 2026 15:37:00 +0000

Google Play's deadline passed on August 31, 2026. Since that date you cannot publish an update to an existing app unless it targets Android 16, API level 36. Not a new app. Any update. A five year old app with a hundred thousand installs cannot ship a one line crash fix until targetSdk goes to 36.

You can request an extension until November 1, 2026, which buys you six weeks and nothing else. The work is the same.

I went through this on three of my own apps: a prayer times app, a jewelry store SaaS and a puzzle game. Changing two numbers in build.gradle.kts took about a minute. Everything after that took two days. Here is the list, in the order it cost me time.

1. The release build broke and debug did not

This one is the reason I am writing the post.

My prayer times app schedules a notification for each prayer. In debug everything worked. In release the notifications simply never fired, with no crash and no log line. The app looked fine. People just stopped getting notified.

The cause was R8. flutter_local_notifications serializes its scheduled notification data with Gson, and Gson needs generic type information at runtime. R8 stripped it, so zonedSchedule threw RuntimeException: Missing type parameter deep inside the plugin, and the exception was swallowed by my own state handling. Immediate notifications kept working, because show() does not go through Gson. That difference is what made it so confusing.

The fix is a few lines in proguard-rules.pro:

-keepattributes Signature
-keep class com.dexterous.** { *; }
-keep class * extends com.google.gson.reflect.TypeToken

Turning off minification also "fixes" it, and that is the advice you find in most issue threads. It is a bad trade. With the keep rules in place and minification back on, my dex went from 14.8 MB to 2.0 MB and the APK from 60.2 MB to 55.1 MB.

If you take one thing from this post: build the release version and install it on a real device before you upload. Debug builds hide this entire class of bug.

2. Plugins that no longer compile

Anything unmaintained since 2023 is a coin flip on the current Android Gradle Plugin. In two cases I replaced the plugin instead of forking it, because a package that has not seen a commit in three years will break again at the next deadline, and there is another deadline every year.

Before you start, run flutter pub outdated and look at the packages with no recent releases. Those are your real work items, not the SDK number.

3. Gradle, AGP and Kotlin disagreeing

Bumping one of the three and not the others produces errors that point at the wrong thing. You get a Kotlin compile error that is actually an AGP version problem, or a Gradle daemon failure that is actually a JDK mismatch.

Do them together, check the official compatibility table, and pin the Java version in gradle.properties so your machine and CI agree.

4. The Data safety form drifts

Your app now pulls newer SDK versions, and newer SDK versions collect different things. The form you filled in two years ago no longer matches what your app actually does, and Play checks this.

Go through the form again with your current dependency list in front of you, especially advertising IDs, crash reporting and analytics.

5. Permissions and service types

Declarations that were fine two API levels ago now need to be explicit. Foreground services need a type. Notifications need a runtime permission. Exact alarms need a separate one, and on Samsung and Xiaomi devices battery optimization will still kill your scheduled work unless you handle it.

The permission audit is also a good moment to delete what you are no longer using. Every permission you remove is one less question on the Data safety form.

A checklist you can actually use

targetSdk and compileSdk to 36
Gradle, AGP and Kotlin to compatible versions, pinned JDK
flutter pub outdated, upgrade or replace the dead packages
Build the release AAB, install it on a real device, exercise the features that rely on background work
Check keep rules if anything silently misbehaves only in release
Permission audit, then update the Data safety form
Upload to a closed test track first, not straight to production

If you are stuck

Most of the pain here is not the SDK bump, it is the archaeology in a project nobody has touched in two years. If your app is blocked and you are hitting one of these, leave a comment with the error and I will tell you what worked for me.

If you would rather hand it off, I do this upgrade as a fixed-price job through Upwork: my Upwork profile.