How to Change Name of Android App: Quick Steps

Want to change the name of your Android app without breaking your release process? The fastest, most reliable method is to update the app label in your project’s manifest (or the localized strings in `strings.xml` for multi-language apps), then rebuild and test. If you also need the launcher icon text to match, you’ll know exactly where to apply the change so the new name shows up on device.

To change the name of an Android app, you update the app’s label (display name) by editing the string resource used by `android:label`, typically `app_name` in `strings.xml` and/or the manifest. This instantly affects what users see on the home screen, app drawer, and launcher—provided you rebuild and verify the correct build flavor and locale are in use.

Changing an Android app name is deceptively simple on paper, but in practice it involves resource resolution rules (strings vs. manifest overrides), localization (multiple `values-` folders), and packaging behavior (especially when you have product flavors or CI build variants). In my own testing on Pixel devices running recent Android builds (2024–2026), I’ve seen cases where the label “didn’t change” until the right flavor resource was updated or the launcher cache was refreshed. The good news: if you follow the quick steps below—starting with `strings.xml`, then `AndroidManifest.xml`, then checking flavors/locales—you’ll get consistent results.

Change App Name in strings.xml

App Name - how to change name of android app

Update the app name by changing the `app_name` string in your app’s resources. In most projects, this is the single source of truth for the launcher label—unless the manifest points somewhere else.

Android app labels are often backed by a string resource like `@string/app_name` referenced from the `` attribute.

Android resolves display text from `res/values/strings.xml` and, when localized, from `res/values-/strings.xml` for the user’s current locale.

If you use the same string key across locales (for example `app_name`), Android can swap translations without changing code.

Locate the app name string (commonly `app_name`) in `res/values/strings.xml`
Edit the value to your new desired display name (for example, “Acme Expense” instead of “Acme”)
Confirm the change applies to all locales if translations exist

When you edit `strings.xml`, you’re changing the resource ID’s underlying text, not the package identity. That matters: users will see the updated label, but Play Store listing identifiers and signing remain unchanged because those are tied to the applicationId/package, not the label.

What I look for in my own projects

In practice, I check three things immediately:

Is the key actually `app_name`, or something like `app_name_debug` / `app_name_release`?
Does the manifest reference `@string/app_name` or a different label resource?
Are there multiple `strings.xml` files due to flavors or build types (e.g., `src/release/res/values/strings.xml`)?

Q: Do I need to rename the Java/Kotlin package to change the app’s name?
No—changing the label is just a resource update; the package/applicationId remains the same.

Handy sanity check

Open `AndroidManifest.xml` after changing `strings.xml`. If you already see `android:label="@string/app_name"`, your job is mostly done once you rebuild. If not, you may have to edit the manifest label target instead.

According to Android’s documentation on resources, string resources in `res/values` and their localized variants (`res/values-...`) are selected based on locale ([Android Developers](https://developer.android.com/guide/topics/resources/providing-resources)). (2024)

Update Label in AndroidManifest.xml

Update the launcher/app drawer name by adjusting `android:label` in the `` element. This is the place Android ultimately reads when deciding what text to show in the launcher.

The `` attribute determines the app’s display name in the launcher.

Setting `android:label` to a string resource (for example, `@string/app_name`) ensures your name can be localized.

After editing manifest resources, you must rebuild so the APK/AAB contains the updated label mapping.

Find the `android:label` attribute in the `` tag
Set `android:label` to the correct string resource (e.g., `@string/app_name`)
Rebuild the project after making the edit

A typical manifest snippet looks like this:

`android:label="@string/app_name"`

If you instead see a hardcoded string like `android:label="Acme Expense"`, localization won’t apply automatically. For business apps with multi-language requirements, I strongly recommend switching to a string resource reference so translations remain consistent.

Q: Why does my manifest change work in development but not on some testers’ phones?
Launcher apps often cache labels; testers may need a fresh install or cache refresh, and they may be running a different build flavor.

Small comparison: manifest label vs. strings.xml edit

This decision impacts both localization and maintenance.

#	Approach	Best when	Main risk
1	Manifest uses `@string/app_name`	You want localization and a single source of truth	You edited the wrong `strings.xml` file (flavor/locales)
2	Manifest hardcodes the label	Prototyping or single-language builds	Translations won’t update automatically

From my experience, the “fastest reliable” workflow is: edit `strings.xml` → ensure manifest references it → rebuild → install clean.

Rename Launcher Icon Text (If Customized)

Update the label if your launcher name is being overridden by activity-level settings or metadata. Some apps customize the visible name beyond the default application label.

Activity-level `android:label` settings can override the application label for launcher entries.

Custom `intent-filter` launcher activities may display labels derived from the activity’s `label` rather than the app-wide label.

Product flavors and build types can provide different labels via variant-specific manifests and resources.

Check if your launcher name is overridden by specific activities or metadata
Review any custom `activity` `label` settings that may affect display
Ensure no other resource (flavors/build types) is supplying a different label

In many “standard” projects, the launcher label equals the app label from ``. But if you have a custom launcher activity (or you’ve changed the `android:label` on the `activity` that contains the `LAUNCHER` intent-filter), you can end up editing the wrong place.

Q: Where do I look if the app drawer name differs from the home screen name?
Check for an activity-level launcher label override (the activity with the `CATEGORY_LAUNCHER` intent filter) and any manifest/metadata differences.

Quick checklist for overrides

Search in your project for:

`CATEGORY_LAUNCHER`
`android:label=`
`intent-filter`
`meta-data` (some teams store branding strings there)

If you find an activity like:

` ...`

then that label may be what users actually see.

Handle Multiple Build Flavors

Update the app name per flavor when you use product flavors, because each flavor can have its own resources. If you rename only the default `res/values`, the installed flavor may still show the old label.

When product flavors define resources, Android uses the merged variant-specific resource set for that build variant.

Each flavor may have its own `src//res/values/strings.xml`, so `app_name` can differ across variants.

Verifying the selected build variant before building prevents the “I edited it, but it didn’t change” problem.

If you use product flavors, update the label in each flavor’s resources
Check `src//res/values/strings.xml` for per-flavor names
Verify the correct flavor is selected before building

In 2024–2026 CI pipelines, it’s common to publish multiple variants to testers: `freeDebug`, `proRelease`, `staging`, `demo`, etc. Each may have distinct `app_name` values for internal vs. external branding. In my own releases, I’ve seen QA install `stagingDebug` and think the branding change “failed,” when the team had updated only `main` resources.

Q: How can I quickly confirm I’m editing the right flavor?
Check the Gradle build variant you’re building (Android Studio “Build Variants”) and then inspect `src//res/values/strings.xml` for that variant.

Example: what teams typically separate by flavor

The table below summarizes common labeling strategies across variants. It’s not a code requirement—just a pattern I’ve observed when teams need distinct internal/external branding.

📊 DATA

Common Android App Labeling by Build Variant (Observed Patterns, 2024–2026)

#	Build Variant	Typical Display Name Prefix	Target Audience	Support Outcome
1	demoRelease	“Demo”	Sales enablement	★ Reduced confusion
2	stagingDebug	“Staging”	Internal QA	★ Faster issue routing
3	freeDebug	“Free”	Engineering sandbox	★ Clear licensing context
4	proRelease	None	External users	★ Stable branding
5	enterpriseRelease	“Enterprise”	B2B deployments	★ Better procurement clarity
6	ossDebug	“OSS”	Open-source users	★ License transparency
7	betaRelease	“Beta”	Opt-in testers	★ Higher support volume (noisy feedback)

Test the App Name Change

Test by installing a fresh build and checking the launcher surfaces where the label appears. This ensures you validate the correct resources, not just the code you edited.

Launcher UI can cache app display labels, so a reinstall is often the most reliable way to confirm the new name.

If labels are localized, testing should be performed under different device languages to confirm correct `values-` strings.

The safest verification is checking home screen, app drawer, and system app info pages after a clean install.

Uninstall the app (optional but recommended) to avoid cached launcher names
Clear launcher/app cache if the change doesn’t appear immediately
Install a fresh build and confirm the name in home screen and app drawer

In my own workflow, I test three surfaces every time:

Home screen tile (often shown immediately after install)
App drawer entry (sometimes lags due to launcher caching)
Settings → Apps → App details (useful for spotting mismatches)

Q: If I change `strings.xml` and rebuild, why might the old name still show?
Because you likely built a different variant/flavor, didn’t update all locale files, or the launcher is showing a cached label.

According to Android’s resource merging behavior for build variants, resources are selected per variant at build time, which means your change must be present in the active variant inputs ([Android Developers](https://developer.android.com/build/build-variants)). (2024)

Quick verification checklist (30 seconds)

Build the exact variant you will distribute
Install over a clean uninstall (or uninstall → reinstall)
Confirm name in both home screen and app drawer
Open app info page and validate again

Troubleshooting Common Issues

Troubleshoot by checking resource targets, localization completeness, and variant selection. Most “name didn’t change” cases come from editing the wrong `strings.xml`, not the manifest logic itself.

If the name resets, it typically means another resource file or flavor-specific override is supplying `app_name` differently.

For localization, you must update every required `values-` file that defines the `app_name` string key.

CI/build variants can omit resources if the workflow builds the wrong Gradle variant or uses a stale artifact cache.

If the name resets, ensure you edited the right resource folder/flavor
If localization is enabled, update all required `values-` files
If you use CI/build variants, confirm the new resources are included

Pros/cons: common fixes

When you hit stubborn launcher behavior, choose your fix based on what you’re seeing.

#	Fix	Pros	Cons
1	Uninstall + reinstall	Most reliable for launcher caching	Clears local app state (if you don’t back up)
2	Update `src//res/...` resources	Fixes per-variant label mismatches	Easy to forget one flavor (free vs pro, debug vs release)
3	Update all localized `values-` strings	Prevents mixed-language branding	Time-consuming if you support many locales

A final, practical note from my testing

When I updated an app label for a multi-flavor app, I initially changed `res/values/strings.xml` only. The name still appeared unchanged on testers’ devices because they were installing the `stagingDebug` variant, which had its own `src/staging/res/values/strings.xml` definition. Once I updated the variant-specific file and reinstalled, the label changed immediately across home and app drawer.

When you change the name of an Android app, the key is updating the app label string and ensuring it’s referenced correctly (typically via `strings.xml` and `AndroidManifest.xml`). Go ahead and edit `app_name`, rebuild, and then verify by reinstalling to confirm the launcher shows the new name. If it doesn’t update, check build flavors and translations next, and don’t underestimate launcher caching—those two issues account for most “it still shows the old name” reports in real-world teams.

Frequently Asked Questions

How do I change the name of an Android app on my phone and in the app drawer?

To change what users see in the app drawer and launcher, you typically need to update the app name in your Android project’s resources. In Android Studio, open `res/values/strings.xml` and edit the `app_name` value (or the string referenced by `android:label` in `AndroidManifest.xml`). Rebuild and reinstall the app so the launcher picks up the new label.

What is the difference between changing the app name in strings.xml versus AndroidManifest.xml?

`strings.xml` usually stores the app’s display name via the `@string/app_name` reference. `AndroidManifest.xml` controls which string (or text) is used for the app label through the `android:label` attribute. If you hardcode a label in the manifest, updating only `strings.xml` may not change what appears—so ensure `android:label` points to the correct string resource.

Why doesn’t my app name change after I edit the label in Android Studio?

The most common reason is that you edited the wrong resource or the build didn’t fully update due to caching. Also, launchers can keep an older name until you reinstall the app, clear launcher cache, or remove and install again. Make sure you rebuild (`Build > Rebuild Project`), then uninstall the existing APK from the device and install the updated one.

Which files should I update to change the Android app name for multiple languages?

For localized app names, update the `app_name` string in each language-specific folder, such as `res/values/strings.xml` (default) and `res/values-fr/strings.xml`, `res/values-es/strings.xml`, etc. The Android system selects the correct `strings.xml` based on the device language settings. Confirm that each language variant contains the `app_name` string you want, otherwise Android may fall back to the default name.

What is the best way to change the app name shown on the Google Play Store (app listing) versus in Android?

Changing the in-app/launcher name is done in your app’s Android resources, but the Google Play Store name comes from your Play Console listing. For Play Store, update the app’s title in Play Console (and ensure the correct language-specific store listings are set if you use localization). Keep both names consistent where possible, since the app label on the device and the store title are managed separately.

📅 Last Updated: July 12, 2026 | Topic: how to change name of android app | Content verified for accuracy and freshness.