21

Google released version 0.11 of the Android Gradle plugin.

The release notes contains the following:

One of the user visible changes in 0.11 is that we've deprecated the packageName and packageNameSuffix settings, and have renamed them to applicationId and applicationIdSuffix. The purpose of this is to make it clear that this application id is decoupled from package declarations in your manifest, and in particular, the R class and the BuildConfig class, and all the implementation classes inside your app, can be renamed and refactored freely; you just need to keep applicationId the same. If you open your build.gradle file, lint is highlighting these deprecated calls and offering quickfixes to update them:

What exactly does this mean. How is the packagename in the build script decoupled from the one in the manifest?

Jonik
  • 80,077
  • 70
  • 264
  • 372
Janusz
  • 187,060
  • 113
  • 301
  • 369
  • It was already decoupled, the one in the script doesn't reference the one in the manifest. By renaming this in the build script this should become more clear – Tobrun Jun 12 '14 at 06:59
  • 1
    So where is the one in the buildscript ending up once the app is compiled? – Janusz Jun 12 '14 at 07:54
  • Related reading in the official docs: [ApplicationId versus PackageName](http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename) – Jonik Apr 09 '15 at 13:52

1 Answers1

43

package specified in AndroidManifest.xml identify one application installed on the device. The name of the property itself is misleading because one may think that refactoring java classes may require renaming package property as well. package property can be any string respecting limitation described in javadoc.

Because this confusion Google guys decided to rename package to applicationId. However, this change apply to gradle file only. Changing manifest property name would break compatibility with previous versions, that's my guess.

So when you build your APK, gradle replaces manifest's package property value with applicationId value specified in gradle script.

If you would like to test it yourself. Just set applicationId with different value that your manifest's package and build APK. Then go to folder /build/intermediates/manifests/dev/debug and open AndroidManifest.xml. You will find there applicationId value.

Janusz
  • 187,060
  • 113
  • 301
  • 369
Damian Petla
  • 8,963
  • 5
  • 44
  • 47
  • That is clear. The question is where is the applicationId stored, if not in my manifest files once the app is packaged as an apk? – Janusz Jun 17 '14 at 12:04
  • I have updated entire answer including where applicationId is stored. – Damian Petla Jun 17 '14 at 12:54
  • I would say that Manifest Merger is responsible for that http://tools.android.com/tech-docs/new-build-system/user-guide/manifest-merger. – Damian Petla Jun 27 '14 at 14:09
  • Just reference to the release that cause the change. Google has a good overview there http://tools.android.com/recent/androidstudio060released – Skillachie Jul 12 '14 at 15:43
  • 3
    @Skillachie http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename – TWiStErRob Sep 20 '14 at 09:28
  • 1
    If application id from gradle gets copied as package then how is this decoupling. this link http://tools.android.com/tech-docs/new-build-system/applicationid-vs-packagename says **At the same time, the R class you are importing in your code must stay the same at all time; your .java source files should not have to change when you are building the different versions of your app.** . So if app id is copied you still have to go in change the package name of R class and others. – Boss Man Aug 29 '15 at 02:22
  • 1
    Its decoupled because changing `applicationId` affects only `package` in AndroidManifest.xml, your java sources and R class are not changed. – Damian Petla Aug 31 '15 at 11:44
  • Reference Android documentation about applicationId: https://developer.android.com/studio/build/configure-app-module#set_the_application_id – david Oct 12 '22 at 10:53