How to change the name of an application in Android Studio

Mobile software development often requires making changes at the prototyping stage, when the draft name of the project no longer matches the concept or marketing strategy. In a development environment Android Studio changing the display name is not just renaming a file, but a complex process that affects configuration files and project resources. Failure to do this correctly may result in the user's device displaying a technical identifier instead of a clear brand name.

The process of changing the name depends on which entity you want to modify: the name visible to the user on the desktop, or the internal system name of the package. It is important to understand the difference between these concepts, since they are stored in different parts of the project structure. In this article, we will analyze in detail all aspects of renaming, from editing the manifest to setting up build systems.

For beginners, this task may seem confusing due to the abundance of settings in the IDE, but sequential execution of the steps guarantees the correct result. We'll cover both manual file editing and the use of built-in refactoring tools that make a developer's life much easier. Be prepared to touch several key configuration files.

Differences between package name and display name

Before making changes to the code, it is necessary to clearly distinguish between two fundamental concepts in the ecosystem Android. The first is Application ID (application identifier), which is the unique address of your product in the system and application stores, for example com.example.myapp. The second is App Name (application name), the same text that the user sees under the icon on the main screen of his smartphone.

Change Application ID is a serious operation that actually creates a new application from the point of view of the operating system. If you change this identifier, the system will consider your updated software to be a completely different app, unrelated to the previous version. This means the loss of all user data, settings and the ability to update “on top” of the old version through the store.

At the same time, changing the display name is a cosmetic edit that does not affect the internal logic of the package or the identification of the package. You can change it as many times as you like during development without any negative consequences to the database or authorization. It is this aspect that we will consider first, since it is most in demand in the early stages.

⚠️ Attention: Never change applicationId in the file build.gradle for an application already released on Google Play, unless you plan to create a completely new project from scratch. This will break the connection with the existing user base.

Understanding this architecture is critical to avoiding fatal errors during deployment. Many novice developers confuse these entities, trying to rename a package where only the resource string needs to be changed. Let's now move on to the practical implementation of changing the visible name.

Changing the display name through strings.xml resources

The most correct and professional way to change the name of your product is by editing the resource file. In the Android project structure, all text lines that the user sees are placed in a separate file res/values/strings.xml. This is done for ease of localization, but also allows you to centrally manage names.

Open the file strings.xml in the project window. Find the line named app_name. By default, it appears as a resource containing the current name of your project. It is the value of the attribute name inside the tag string that is responsible for what will be written under the icon.

<resources>
My New Application
</resources>

Replace the text inside the tag with the desired name. After saving the file (Ctrl+S or Cmd+S), you need to rebuild the project for the changes to apply. Click the Run or Build Bundle(s) / APK(s)button to compile the new version. On an emulator or physical device, you will immediately see the updated title.

Using a resource file is a best practice as it allows you to easily create different titles for different languages. If you simply hardcode the name in the manifest, you will have to edit it manually when adding support for other locales, which is inefficient and prone to errors.

Direct editing of AndroidManifest.xml

Although working with resources is preferable, sometimes there is a need to understand how the name is tied to the manifest. The file AndroidManifest.xml is a passport of your application, where_declared_ are all its components. The attribute android:label in the tag application refers to the string resource that we changed in the previous section.

By default, you will see a link like this @string/app_name. This means that the system takes the value from the resource file. However, technically you can write the name right here, although it is not recommended by experts. A direct entry looks like this:

<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="Direct Application Name"
android:theme="@style/AppTheme">

This approach deprives you of flexibility. If you decide to release the application to the international market, you will have to create different versions of the manifest or manually edit the code for each language. Linking through resources allows the system to automatically substitute the desired name depending on the language settings of the user's device.

Also in the manifest you can set different names for individual activities (screens) that are displayed in the recent applications menu. This is done through the attribute android:label in the tag activity. Unless otherwise specified, the activity inherits the application's common name from the root tag.

⚠️ Warning: When manually editing AndroidManifest.xml be extremely careful with XML syntax. An extra space or an unclosed tag will result in a compilation error, and the project will not run.

Checking the correctness of the manifest is carried out automatically by the environment Android Studio, which highlights errors in red. Always trust these hints and do not ignore the linter's warnings, especially when it comes to key configuration files.

Changing the package name (Application ID) and refactoring

If your goal is to change not just the “sign”, but the technical name of the project, then you will need a refactoring procedure. This is a more complex process involving directory structure and build configuration. You should start by changing Application ID in the file build.gradle (app module level).

Find the block defaultConfig and change the value applicationId. For example, from com.example.oldname to com.example.newname. However, this is only part of the job. To ensure that the physical code folders match the new name, you need to use the IDE's refactoring tool.

In the project window, switch the view to Project (instead of Android). Expand the directory tree to level java or kotlin. Right-click on the folder with the current package name (for example, oldname) and select Refactor -> Rename. Enter a new name and confirm the action.

• 📂 Folder structure: Refactoring will automatically rename the directories, preserving the nesting of classes.
• 🔗 Updating imports: All imports in code files will be updated automatically, saving hours of manual work.
• ⚙️ Configuration: Don't forget to check the settings in build.gradleso that they match the new structure.

After completing the refactoring, be sure to run the command Clean Projectand then Rebuild Project. This will remove the old compiled files and create new ones based on the changed paths. Ignoring this step can lead to strange runtime errors when the system cannot find classes at old addresses.

Setting names for various assemblies (Build Variants)

In professional development, several versions of one application are often used: free, paid (Paid), version for debugging (Debug) and release (Release). Android Studio allows you to set unique names for each build option using the mechanism product flavors or resource configuration.

To implement this approach, different resource folders are created. For example, you can create a directory src/free/res/values/strings.xml i src/paid/res/values/strings.xml. In each of these files you define a line app_name with different content.

When you switch the build option in the panel Build Variants, Android Studio automatically pulls resources from the corresponding folder. This allows you to have "Lite" and "Pro" versions installed on the same device with different names and icons, without creating package conflicts, if applicationIdSuffix is configured correctly.

android.applicationVariants.all { variant ->
variant.outputs.each { output ->
def appName ="SuperGame"
def versionCode = variant.versionCode
def versionName = variant.versionName
def buildType = variant.buildType.name

def newApkName ="${appName}-v${versionName}-${buildType}.apk"
output.outputFileName = newApkName
}
}