SoFunction
Updated on 2025-04-10

The connection and difference between Android package attributes, package name and Application ID

The connection and difference between Android package attributes, package name and Application ID

  1. package attribute: in the file.
  2. package name: The package name of the application.
  3. Application ID: applicationId property under the module defaultConfig block.

Set Application ID

Each Android application has a unique Application ID similar to the Java package name, for example. On Android devices and on Google App Store, Application ID is the unique identifier for your app. If you want to upload a new version of the application, the Application ID must be the same as it was originally. If you change the Application ID of the new version of the application, the Goolge App Store will think it is a completely different application. So, starting with your first upload of the app,Never change the Application ID.

The Application ID is defined in the module's applicationId property, as follows:

android {
  defaultConfig {
    applicationId ""
    minSdkVersion 15
    targetSdkVersion 24
    versionCode 1
    versionName "1.0"
  }
  ...
}

When you create a new project in Android Studio, you can set the applicationId property, and the Application ID and package name exactly match. Besides that, the two are completely independent. Of course, you can change the package name, but this will not affect the Application ID. Vice versa (Again reminder: do not modify the Application ID, do not modify the Application ID, do not modify the Application ID, do not modify the Application ID after you upload the application). However, you should realize that there is another consequence of modifying package name. For details of this part, please refer to Modify the Package Name (speaks below).

Although Application ID looks similar to traditional Java package names, there are more restrictions on the naming rules of Application ID:

  • At least two sections (at least one.separated)
  • Each paragraph must start with letters
  • All characters can only be letters, numbers and underscores

Notice:Previously, Application ID directly bound the package name. So, some Android APIs use "package name" in method names or parameter names, but they actually refer to Application ID. For example, the () method returns the Application ID. So there is no need to share the real package name outside of your application code.

warn:If you are using WebView, consider using your package name as the prefix for your Application ID, otherwise you may encounter

issue 211768。

Modify the build version's Application ID

When building an APK for your application, the build tool identifies the APK using the Application ID defined in the defaultConfig block in the file (as shown below). However, if you want to create different versions of the app and display different information in the Google App Store, such as "Free Edition" and "Pro Edition". You need to build different versions with different Application IDs.

In this case, each build should define a different product flavor, and each flavor is inside the productFlavors{} block. For each flavor, you can redefine the applicationId property, or add a pre-suffix to the default applicationId as follows:

android {
  defaultConfig {
    applicationId ""
  }
  productFlavors {
    free {
      applicationIdSuffix ".free"
    }
    pro {
      applicationIdSuffix ".pro"
    }
  }
}

After this definition, the Application ID of "free" is "".

On the build type, you can also use the suffix as follows:

android {
  ...
  buildTypes {
    debug {
      applicationIdSuffix ".debug"
    }
  }
}

Since Gradle first applies product flavor before applying build type, the current Application ID of the "free debug" version is "". This will be very useful if you want to install both debug and release on the same phone, as no two applications can have the same Application ID.

Remember that the same application has different Application IDs, and the Google Apps market will consider these two applications. So, if you want to use the same information to distribute multiple applications in order to adapt to different device configurations (such as different API levels). Then for each version you have to use the same Application ID and a different versionCode.

warn:To be compatible with previous SDK tools, if you do not define the applicationId property in it, the build tool will use the package name as the Application ID. In this case, renaming the package name means renaming the Application ID at the same time.

hint:If you need to reference the Application ID in the manifest file, you can use the ${applicationId} placeholder in the manifest property. Gradle will custom replace this tag with the real Application ID when it is built. For more details, see Inject Build Variables into the Manifest.

Test-specific Application ID

By default, the build tool applies the Application ID to your instrumentation test APK using the Application ID (attached.test) of the specified build version. For example, the real Application ID of the test application with a build version of "" is "".

Usually this is not necessary, you can define the testApplicationId property in the defaultConfig or productFlavor block to modify the Application ID.

Notice:To avoid conflicts with test application naming, the build tool uses a namespace generated based on the test Application ID for the test application.

Modify package name

Although the package name exactly matches the Application ID by default, you can still modify it. If you want to modify the package name, please note that the package name (project directory structure) and the package attribute in it are exactly corresponding. As shown below:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:andro
  package=""
  android:versionCode="1"
  android:versionName="1.0" >

For Android build tools, the package attribute is used for two things:

The namespace applied to the generated classes of your application.

For example: in the above manifest file. Class R is ""

Used to parse the relative path of any class in the file.

For example: in the above manifest file. An activity defined as \ will be parsed as.

Therefore, the value of the package attribute should always be the same as the project's package name. Of course, you can set a subpackage name for the project. These files must import R classes from the namespace of the package attribute, and any component defined in the manifest must add subpackage names (or write full paths).

If you need to completely rename the package name, make sure you have updated the package attributes. These will automatically remain synced until you rename the package with Android studio's tools. (If you don't keep in sync, your code will not parse R class correctly because it is no longer under the same package, and manifest will not correctly recognize your activities and other components).

You must top the package attribute in the file, if you add the manifest file in addition, please note that the package name provided by the highest priority manifest file is always used to merge the final manifest. More: [Merge Multiple Manifest Files.

Hope to know: Although your project can set the package attribute not equal to applicationId, it will be combined. The build tool will copy the Application ID and set the value of the unique package attribute of your application when it is finally built. So, if you check the file after the build is successful, don't be surprised by the changes in the package attribute. On the Android platform and Google App Store, the package attribute is the only identity credentials for your application. So, once built with the original value (resolving components in manifest using the R class in the namespace), the build tool will discard the value of the package attribute and replace it with the Application ID.

Original link: /studio/build/#change_the_package_name

Thank you for reading, I hope it can help you. Thank you for your support for this site!