Can You Change Your App's Package Name on Google Play?

The short answer: no rename, and the lock is the first upload

Short answer: you cannot change an app's package name. Google fixes it when the first artifact reaches Play Console, and nothing afterwards renames it: not a Console setting, not a support ticket, not an app transfer. The only documented route to a different package name is a second app entry, which means a second tester list, second opt-ins and a fresh fourteen days.

There is one narrow exception, and it is the part almost nobody knows. If you delete the app while it has zero lifetime installs, Google frees the package name for reuse by anyone. One install from one tester and that door shuts permanently, including for you.

So the useful question is not whether the name is changeable. It is which of three moments you are standing between: before the first upload, after the upload but before the first install, or after a tester's phone has finished downloading your build.

What Google's documentation says, in its own words

Four statements settle the rule. They live on four different pages, which is why the picture looks contradictory until you put them side by side.

• App setup: “Package names for app files are unique and permanent, so name them carefully. Package names can't be deleted or re-used.” (Create and set up your app)
• Testing setup: “Once you upload an artifact, the package name for that app is fixed and cannot be changed.” (Set up an open, closed, or internal test)
• Updates: “The package name of the updated Android App Bundle must be the same as the current version.” (Update or unpublish your app)
• Android build docs: “Once you publish your app, you should never change the application ID. If you change the application ID, Google Play Store treats the upload as a completely different app.” (Configure the app module)

Put them together and the model is plain. Identity attaches to the artifact, updates must carry the same identity, and a different identity is a different app. What the first sentence does not say is what happens if you delete the app. That answer is conditional, and it is the reason this is not a dead end.

Where the lock actually lands: creation, upload, first install

Three separate events get merged in developers' heads. Only one of them is irreversible at the time it happens, and only one of them cannot be undone afterwards.

• App creation. The Create app screen asks for a package name and Google's instructions describe typing it. That field is not the identity yet. Developers on Stack Overflow and the Play Console forum report uploading a bundle with a different package name and finding Play Console adopt the uploaded one. Do not rely on that behaviour — make the typed name and the built name match deliberately — but know that the artifact is the authority.
• First upload. This is the lock. Google's wording is about the artifact, not the install: “Once you upload an artifact, the package name for that app is fixed and cannot be changed.” Uploading to internal testing counts. A Play Console Diamond Product Expert answers the obvious follow-up on the forum directly: “Even then, the package name is set the first time you upload a bundle.”
• First install. This is where the escape door closes. Deleting the app frees the package name only while lifetime installs are zero, and an install is an install whichever track served it.

The practical consequence is that a window exists between the first upload and the first tester install. It is short — a live closed test can produce installs within minutes of the opt-in link going out — but inside it, a wrong package name is a ten-minute fix rather than a fourteen-day restart.

If you upload a bundle whose package name does not match the app you are inside, Play Console rejects the upload and names the package it expects. That error message is the cheapest warning you will get all year. It arrives before anything is locked, and the fix belongs in your build file, not in Play Console.

The one documented exit: deleting the app

Google's Delete an app page is the only place the permanence rule softens, and it softens to a single condition. The steps are not obvious, because deleting requires unpublishing first and unpublishing has its own prerequisites.

The eligibility rules are narrower than people assume:

• You must be the account owner or an admin, and you need the registration transaction ID.
• “The app must be unpublished and any changes in review resolved.”
• “The app must be installed on fewer than 1000 active devices” — an active device being one that has been turned on at least once in the past 30 days. Twelve testers is nowhere near the ceiling.
• The app “must not be rejected, blocked, or suspended” and must not have changes in review.
• Paid apps, apps with in-app purchases and apps with subscriptions are excluded from self-service deletion unless they have zero lifetime installs. For a monetised app with installs, only support can remove it.

Then the sentence that matters: “For a deleted app with zero lifetime installs, the package name will be freed up for reuse by anyone.” Its mirror is the one to read twice: “For a deleted app with any lifetime installs, the package name can't be reused by any other app, including apps created by the developer account that created the deleted app.”

That is stronger than most guides admit. It is not that you cannot reuse the name. Nobody can, permanently. A package name that has served a single install is retired from the namespace for good, and Google's app setup page — “Package names can't be deleted or re-used” — is describing the same rule from the other side.

One detail the page buries: when you paste the transaction ID, strip the order prefix. Google's example discards “0.G.” and the digits before “token” or “Registration”. Search the account owner's inbox for the receipt titled “Developer registration fee”, or open Google Payments and filter the activity log for “Google Play Developer”.

What “lifetime installs” means when your only users are twelve testers

Google does not define “lifetime installs” per track, and it does not say whether an opt-in without an install counts. Read literally, the test is installs: someone who accepted the opt-in link but never completed the install has not installed anything, and the count stays at zero. Treat that as our reading of the wording rather than a published rule — the conservative position is that the door shuts the moment one tester's phone finishes the download.

For a closed test that produces three genuinely different situations:

• No upload yet. Change the application ID, rebuild, upload. Nothing is lost and nothing needs deleting. This is the only free scenario, and it is the one to aim at.
• Uploaded, no installs. Clear the declarations, unpublish, delete, then create the app again with the package name you want. You lose the Console entry, its drafts and its metrics. You do not lose tester time, because nobody's fourteen-day clock has started yet.
• Installed, clock running. The name is spent. Rebuilding under a new package means a new app entry, a new tester list, new opt-in links and a new fourteen days for every tester — the clock is per tester and per opt-in, which is the same mechanic behind dropping below 12 testers.

Based on our analysis of 1,500+ closed-testing campaigns, the package name is almost never what stalls a launch. These are our own campaign records, not Google data, and no approval rate is implied by them. When it does appear, the pattern is always the same: the name was decided after the first upload rather than before it, and the realisation landed three or four days into a fourteen-day window.

What deleting actually costs when a closed test is in progress

Deleting is not a rename. It destroys an app record and leaves you refilling it from the beginning.

• Your testers are not carried over. Opt-ins belong to the app and its track. A new app entry has an empty tester list and its own opt-in link, so twelve people who already opted in have to do it again, and each one's fourteen days restarts from the new opt-in.
• Your testing feedback goes with it. Private feedback sits under Monitor and improve > Ratings and reviews > Testing feedback for that app. The deletion page states you “lose access to all user data and metrics”, and the production access form asks you to summarise the feedback you received and how you collected it — see the production access form questions.
• Seven days of doubt. “You can recover a deleted app within seven days of deleting it.” After that it is permanent, a deleted app “cannot be transferred”, and Console navigation for it is restricted.
• Nothing about the requirement is waived. Deleting does not shorten the fourteen days and does not reset a pending production access application. It only buys you a different package name, at the price of running the test again.

That last point is the one to sit with. On day eleven, with twelve engaged testers and a package name you have gone off, deleting is a fourteen-day decision and not a rename. Ship it, and change the thing users actually read.

What you can change instead, without touching the package name

Almost everything a user perceives is editable, which is why the package name matters far less than developers assume. Google's own instruction for the app name is: “Enter the name of your app as you want it to appear on Google Play. You can change this later.”

• Store listing — app name, icon, feature graphic, screenshots, short and full description, category, contact details.
• Developer identity — the developer name on the listing is an account-level setting, not part of the package.
• Distribution — countries, pricing, in-app products, staged rollout percentages.
• Code-level naming — your Kotlin or Java packages and the Gradle namespace can be reorganised freely. Since Android Gradle Plugin 8 the namespace drives the R class and the manifest package, not the Play identity.

The package name surfaces in exactly one public place: the store URL, play.google.com/store/apps/details?id=your.package.name. That is worth knowing before treating a change as cosmetic. Every link you have sent testers, every QR code and every deep link points at that string, so a rename would break all of them anyway. Google has given you a second reason not to want one.

The three cases where starting over is the right call

There are real reasons to pay fourteen days for a new package name. They are narrow, and none of them is aesthetic.

• The prefix is a domain you do not control. Android App Links verification requires a Digital Asset Links file served at the domain inside your package name. If the app ships as com.someoneelse.app, you can never publish assetlinks.json there, and verified links stay broken for the life of the app.
• The name belongs to a client or a former employer. Shipping under a package name you have no right to use is a problem that gets worse after launch, once reviews and store transfers are involved.
• The name collides with an app that already exists on Play. Console will not accept an artifact whose package name is already taken, so this resolves itself at upload — but if you have already built signing configs, CI and Firebase projects around the rejected name, decide before you invest further.

Two build-level traps sit inside that decision. A debug build with an applicationIdSuffix of .debug is a different package, so it cannot be uploaded to the same app. A product flavour with a suffix such as .staging or .dev behaves identically. If an upload is rejected for a package mismatch and you changed nothing, look at the build variant before you look at Play Console.

If you built with an AI tool, check what it chose for you. Lovable, Bolt, Replit, Base44, v0 and Google AI Studio all scaffold a project, and the generated application ID is whatever the tool decided — often com.example.<slug>. Our walkthroughs for Lovable, Bolt.new, Replit and Base44 run the same steps, and this is the one that has to happen before the first upload rather than after.

The ten-minute check before your first upload

Everything above collapses into one habit: confirm the identity inside the artifact, not in the Console field and not in your memory.

• Open your module's build file and read applicationId inside defaultConfig. That value, not namespace, is what Play sees.
• Check every variant for a suffix — applicationIdSuffix, flavour suffixes, and any testApplicationId copied into the wrong block.
• Read the value out of the bundle you are about to upload: run bundletool dump manifest --bundle app-release.aab and look at the package attribute. The App bundle explorer shows the same value after an upload, which is too late to be useful.
• Compare that string with what you typed on the Create app screen, and fix whichever one is wrong before the upload rather than after it.

Ten minutes now, or a deleted app and a new fourteen-day window later. That asymmetry is the entire argument for doing it in this order.

What else a new package name breaks outside Play Console

If you do decide to start over, budget for the integrations keyed to the package name. Each one fails quietly, and usually at the worst moment.

• Google Sign-In and Firebase. OAuth clients are registered against the package name and signing certificate, so a new package needs new client entries and a new SHA-1 registration. This is the same mechanism behind Google Sign-In failing for testers.
• Play Games Services. The game project is bound to the package name, and Play Games sign-in failures in closed testing follow any identity change.
• Maps, Places and other restricted API keys. Key restrictions reference the package name and certificate fingerprint.
• Installed users. A different package installs alongside the old app instead of updating it, so anyone holding the old build keeps a second icon and no update path. Harmless during a closed test. Not harmless after launch, which is why the window to decide is before production.

Frequently asked questions

Can I change the package name after uploading only to internal testing? No. Google's wording is about the first artifact — “Once you upload an artifact, the package name for that app is fixed and cannot be changed” — and Play Console forum experts say the same of apps that are not live yet. Internal testing is still an upload.

If I delete the app, does the package name become available again? Only if the app has zero lifetime installs. With any installs, “the package name can't be reused by any other app, including apps created by the developer account that created the deleted app.”

Does changing the package name reset my 14 days? Yes. The clock is per tester and per opt-in, and opt-ins belong to the app's track. A new app entry starts with none, and no tester data transfers across.

Is the package name the same as the name users see? No. Users see the app name, which is editable. The package name appears in the store URL and as the app's identity on the device.

Can I rename the display name and keep the package? Yes, and for most developers that is the correct answer. Google documents the app name as changeable at creation time and afterwards, while the package name is fixed at first upload.

Why was my upload rejected for a package mismatch when I changed nothing? Almost always a build variant. A .debug or .staging applicationIdSuffix produces a different package name, and Play accepts only the one already registered for that app.

Do I need the transaction ID to delete an app? Yes. Console asks for the package name and the developer account's registration transaction ID. The receipt email is titled “Developer registration fee”, and the order prefix has to be stripped before pasting.

Can I transfer the app to another account instead of deleting it? A transfer moves the existing app record, package name included. It is a change of owner, not a rename, so it does not solve a wrong package name.

Sources and verification

Policy and product claims here come from pages read in full on 10 November 2026: Create and set up your app, Set up an open, closed, or internal test, Update or unpublish your app, Delete an app, App testing requirements for new personal developer accounts, and Android's Configure the app module.

Where this article draws an inference Google does not state — how “lifetime installs” applies to a closed test, and whether an opt-in without an install counts — it says so in the sentence. The campaign observation is our own record and is labelled as ours.