Android app changed dev team, only got the APK but no keystore—can existing users still update normally?

Conclusion: When an Android app changes development teams and only the APK is handed over without the keystore for the old package signature, whether existing users can still update normally depends on who hosts the signing key, whether the store backend allows resetting the upload key, and whether the old package certificate can be recovered. If the store already hosts the official signing key, the upload key can usually be reset and updates can continue. If you rely only on a local keystore and cannot recover it, overwrite upgrades for the original package usually will not work, and you may need to recover a backup, request a store reset, or migrate to a new package name. This applies to scenarios where the app is already published, certificate handover is unclear, or the certificate is nearing expiration.

Why do existing user updates get stuck when only the APK is handed over but not the keystore?

The Android system uses the package name, applicationId, plus the signing certificate fingerprint to determine whether two installation packages are the same app. During an overwrite install, the new package must match the old package's signing certificate; if they do not match, the overwrite will fail, you may get a parsing package error, or the store will reject the update. Signing governs app identity, not the UI, source code, or server APIs. As a common practice in 2026, signing assets include the keystore file, alias, password, certificate fingerprint, and store backend permissions, and these should be checked together during handover.

• Signing determines upgrade identity: When installing over the same package name, the system first verifies whether the signing certificate matches.
• The store side also verifies: App stores keep the upload key or official signing key, and an update package that does not match will be rejected.
• Test packages cannot be mixed in: Debug signing and release signing are different, and releasing a test package as an official update will fail directly.
• Having only the APK is not enough: An APK can be installed, but that does not mean you have the ability to update it later.

Who hosts the signing key determines whether existing users can upgrade seamlessly

If you discover the certificate is lost or was not handed over, do not rush to change the package name. In 2026, there are typically three categories: local keystore self-signing, Google Play App Signing hosting, and domestic app market or hardening platform hosting. Treating a lost upload key separately from a lost official signing key can save you a round of migration cost.

• Local keystore self-signing: The certificate and password are kept by the developer or client. If lost, recovery is relatively difficult, and only if the file can be recovered can you continue upgrading the original package.
• Google Play App Signing: The official signing key is hosted by the platform. If the upload key is lost, you can usually apply for a reset through the backend process, and existing users generally do not notice.
• Domestic store signing hosting: Some markets provide signing services or re-sign after hardening. Whether you can view and reset depends on platform rules and should be checked in the backend.

A common misconception is that if the team only receives the APK or AAB, it has obtained the app's update capability. In reality, without the keystore, alias, and password, and without store backend permissions, future updates may still get stuck.

Can you upgrade the original package? Check these four steps before deciding

When a certificate is lost or expired, it is advisable to check in a fixed order: first confirm whether it can be saved, then decide whether to change the package name. This order can reduce ineffective builds and store submissions, because upgrading the original package, resetting the upload key, and changing the package name differ significantly in cost and user impact.

1. Check the old package signing fingerprint: View the certificate SHA-256 fingerprint from the published package or store backend to confirm which certificate the old package uses.
2. Find the certificate source: Check the previous team's handover documents, CI keystore, build servers, and client backups to confirm whether the keystore, alias, and password are complete.
3. See whether the store hosts it: Log in to the app market backend to confirm whether hosted signing is enabled and whether the upload key or official signing key can be reset.
4. Choose a remediation path: If the original certificate can be reused, upgrade the original package; if only a reset is possible, follow the platform process; if neither works, consider migrating to a new package name.

Delivery field experience: The budget and timeline were tight. The previous team handed over only the source code and APK, not the keystore, alias, or password, and the store backend was still under a departed employee's personal account. Before delivery, we checked the store backend certificate SHA-256, CI key variables, and client backups. We found the upload key was still there but the password was not recorded, so we had to go through the store reset process and wait several extra days for review. In another project, because the official signing key could not be recovered, we had to change the package name; existing users had to re-download, and reactivation costs rose noticeably. Based on delivery experience range, when signing asset handover is unclear, the remediation cycle is typically a few days to a few weeks, and package name migration typically falls in an experience range of 2 to 6 weeks, though specifics still depend on store rules.

Comparing remediation options: recover the certificate, reset in the store, or change the package name?

The cost, timeline, and impact on existing users differ clearly across paths. The comparison below uses experience ranges; specifics should still be based on app store backend rules and official documentation.

• Recover the original certificate and keep signing: Low cost, with a typical timeline of a few days to one or two weeks, and existing users do not notice; the prerequisite is that the keystore and password can be exported.
• Reset the store upload key: Low cost, with a typical range of 1 to 7 days, and existing users do not notice; the prerequisite is that hosted signing is used and the platform allows it.
• Reset the store official signing key: Medium cost, timeline depends on platform review, some platforms support it but with many restrictions, and existing users may need to update the store version.
• Change the package name with migration guidance: Higher cost, with a typical experience range of 2 to 6 weeks; existing users need to re-download, and data migration and reactivation require extra design.
• Notify users to uninstall and reinstall: The cost may look low, but user churn and data loss are expensive, so it usually only suits internal apps or low-activity users.

If you can upgrade the original package, do not change the package name. Changing the package name resets the app identity; store ratings, reviews, some push identifiers, and local data may all be affected, and you will later need to maintain compatibility for two package names. Only when the certificate is completely unrecoverable and the store cannot reset it is changing the package name a realistic option.

Applicable and non-applicable boundaries

Signing certificate remediation suits projects that already have a published package, are preparing to change development teams, have a certificate nearing expiration, or have incomplete handover materials. If the app has not yet released its first version, you can simply set up standardized signing hosting. If it is only for internal testing, the user base is very small, and you can notify each user to uninstall and reinstall, the cost of changing the package name is relatively manageable. The boundary is: once the existing user base is large and cannot be reached uniformly, the ability to upgrade the original package matters more than convenience, and changing the package name requires careful evaluation of reactivation costs.

• Suitable for prioritizing the original package: Apps that already have store ratings, a sizable user base, and need continuous version updates.
• Suitable for directly changing the package name: Scenarios that are not yet published, are internal tools, have users who can be notified centrally, and have rebuildable data.
• No need to be overly anxious: If the app has not yet released its first version, simply host the keystore and store permissions properly; there is no need to migrate a nonexistent old package.

Standalone quotable boundary sentence: If existing users can only update through the store, and you cannot overwrite-upgrade with the original signature, then changing the package name turns from a technical problem into a user retention problem.

FAQ

If the signing certificate expires, will the already published app be removed immediately?

Usually it will not be removed immediately, and installed apps can still run. However, signing a new package with an expired certificate may prevent you from submitting updates, so you should replace or reset the upload key according to the platform's official documentation.

If the new and old package signatures do not match, what prompt will users see?

Common outcomes include overwrite installation failure, package parsing error, or the store showing a signature mismatch. Users often have to uninstall the old version and install the new one, and whether local data is retained depends on the backup strategy.

After changing development teams, how do you confirm the new package can overwrite-upgrade the old package?

Have the other party build a test package and compare the store backend certificate SHA-256 fingerprint. Only a match means it can overwrite-upgrade. Having only the source code and APK is not a valid basis for judgment.

After Google Play App Signing is enabled, can you still update if the local keystore is lost?

If the lost key is the upload key, you can usually request a reset in the backend and continue updating. The official signing key is hosted by the platform; check specific permissions and processes against official documentation.

What are the costs of simply changing the package name and republishing to save effort?

Existing users will not automatically upgrade to the new package; you need in-app guidance or store migration. Ratings, reviews, some data, and push identifiers may reset, and user acquisition and reactivation costs will rise.

It is advisable to first log in to the store backend and check the signing fingerprint, then decide whether to recover the original certificate, reset the upload key, or change the package name. This suits apps that are already published and need long-term updates. If the first version has not yet been released, or users can be centrally notified to reinstall, simply host the signing key properly; there is no need to invest too much in migrating the old package.