Skip to content

Android package name

There are two independent notions of “package” in Android. One is the usual Java package, which is how the Java classes are organized inside your project. The other is the Application package, which is an unique application identifier used by Android to manage the installed applications. The two package names are completely independent and serve different purposes.

Java package

The Java package organizes the classes inside the application. Usually you have multiple Java packages in an application. You may put your own classes in a package that’s specific to your app (e.g. “com.domain.myapp”) and you keep the library classes that your project uses in their predefined Java package (e.g. “org.apache.lucene”). The Java packages in your app are mostly the internal business of your app and have little visibility outside of the application — they are visible only for the classes that are exposed to the system such as Activities, Views, Services etc you implement and specify in your app’s AndroidManifest.

What’s more, the Java packages of an application are local to that app. There can be multiple independent applications that implement the same class in the same package, and there is no conflict whatsoever.

The Java package is always scoped inside the application. Two Java packages with the same name (e.g. “org.apache.lucene”) located in different apps are in fact different packages and there is no identity or relation between them. This allows applications to use well-known libraries (such as our lucene example) without any possible interference with other apps that may use the same package/classes (or different versions of). The drawback is that there is duplicated code if many apps use the same classes over again (there is no reuse in-between the apps based on the Java package name).

The observation that on Android the Java package is local to the application means that we don’t have to worry about package name conflicts with other applications. Avoiding package name conflicts with unforeseen third-party apps was the main reason for the Java package name format “com.mydomain.myapp”, i.e. prefixing with your domain name avoids conflict — but there’s no possible conflict on Android to avoid.

This leads to the possibility of using liberal Java package names that violate the well-established Java convention. For example if your app is called “Calculator”, you may place classes in the Java package “calculator” instead of “com.mydomain.calculator” — how cool is that? Of course, that fact that you can does not mean that you should, and respecting the established convention is a good thing even though it’s not required on Android.

Application package

The Application package declared in the AndroidManifest.xml is specific to Android and is an identifier of the application. This identifier is unique among all the apps installed on the phone at a given moment — there can’t be two apps with the same Application package installed at the same time.

The Application package is also unique on the Android Market — there can’t be two apps with the same Application package on the Market.

On the other hand it is possible for two independent developers to create two different apps with the same Application package. Of course not both apps can be hosted on the Market — the Market would reject the second one due to the “unique App package name across Market” rule.

So conflict over the Application package with unforeseen third-party apps is possible, and that’s why it is recommended to use the Java package name convention (“com.mydomain.myapp”) for the Application package name as it avoids conflict.

Some developers chose to disregard the guideline “com.mydomain.myapp” and use fancy Application package names, e.g. “marcone.toddlerlock” for the ToddlerLock application — this liberal use is likely not recommended but certainly possible.

If you use unorthodox Application package names please be sure to make them very specific in order to minimize the chance of conflict (in the previous example, the “marcone.” prefix is specific to the developer and has little chance of conflict (hint: it’s derived from the developer’s name)).

Identifying Java classes across an Android system

To identify a Java class across an Android system (a class that can be part of any application) you have to specify both the Application package and the Java package and class name. It’s like you first specify the application with the App package, and then you specify the class inside the application with the Java package and class name. This is used for example when constructing an Intent to a specific class.

Because often the Application package is the same as the Java package (i.e. the same string), it appears as if you have to specify the package name twice! This can be a bit confusing in the beginning, but it becomes clear why both package names are needed as soon as you understand the difference between the Application package and Java package.

When specifying activity names in the AndroidManifest.xml you need to indicate the Java package and class name (e.g. “com.mydomain.myapp.MyActivity”). Android also allows the short-hand form “.MyActivity”, which indicates that the Java package for the given activity class is the same as the Application package, which is often the case. Of course if your app uses different Application package and Java package, you can’t use the short-hand form and need to always use the full Java package in the manifest.

{ 17 } Comments

  1. Pierre | 2010-02-05 at 09:04 | Permalink

    That is clearly and simply explained. Thank you very much for this useful entry !

  2. Bill Dixon | 2010-08-07 at 13:14 | Permalink

    This is a clearly articulated description of the Android package names. I appreciate the post and it clears up a lot of questions that I had.

  3. Free android apps | 2010-08-12 at 23:58 | Permalink

    So, that’s it, very well explained. The two packages has a huge difference, and nothing to compare with them since they manifest in a different way as well. Hands down on you, i have nothing to ask anymore.

  4. Gabo Esquivel | 2010-08-23 at 18:54 | Permalink

    Thank you. Nice explanation, very useful !

  5. Diaz | 2010-10-06 at 13:07 | Permalink

    I’m just starting android development and when I started my new android project , stopped after seeing the “package name” to google what should I worry about when naming my packages and what not. At first, I thought it was the same as Java packages. phew, good thing I’ve found this post. Saved me alot of headach. Thank you so much Mihai

  6. Todd Sproule | 2010-10-13 at 13:25 | Permalink

    There is some overlap between the two types of packages. The generated is created in a Java package that has the same name as the Android package. This causes problems when trying to use Android maven tools to generate two separate Android packages from a common base.

  7. Glad | 2011-01-04 at 16:36 | Permalink

    For us, new beginners, it’s not easy to find a document like this. !priceless!
    Thank you very much..!!! NO more questions regarding packages ….

  8. Suresh Manchi | 2011-01-17 at 15:23 | Permalink

    Explains the notion of application package and java package crisply, Thanks.

  9. andro beginner | 2011-03-18 at 14:14 | Permalink

    I think there is some unspecified limitation in this naming convention in the entry ‘package’ in the manifest.
    My 2 applications x.y.z and x.y.z.t are seen identical by the installer in my android.
    Clearly thses two names are different !

  10. David | 2011-04-21 at 09:35 | Permalink

    Nice, explained. Two packages makes a great difference, and can’t be compared cause they manifest in a different ways. There is a little overlap between the two types of packages but i’m ok with that.

  11. lef | 2011-05-30 at 12:06 | Permalink

    I used Android Tools -> Rename Application Package from within eclipse IDE, and this told me that huge refactoring is necessary to achieve the goal: putting all .java into different JAVA package name. Including the manifest, which I thought that is the one that has to define the application package name. I don’t want my .java sources to be repackaged, someone knows what am I missing?

  12. javan | 2011-06-06 at 09:32 | Permalink

    very thnx .nice

  13. Barry | 2011-06-17 at 17:02 | Permalink

    The most important thing to remember for me is that the package name specified in the manifest will be a unique application name. Remember this when you name your new applications since an Android device can not have two applications with the same package name. For example, you may want to name your facebook app as x.y.facebook.app1 instead of just x.y.facebook in case you will have another facebook application later. Other than this, I will just treat them the same and forget about other differences.

  14. Max | 2011-09-30 at 14:43 | Permalink

    Thanks, clear and very useful.

  15. playpreneur | 2011-11-13 at 00:24 | Permalink

    I’m now wondering if ICANN will step in a force app markets across the board to use the suggested string, namely

  16. vivek | 2012-04-16 at 17:34 | Permalink

    Thanks :-)

  17. Antek Baranski | 2017-01-01 at 23:27 | Permalink

    [On the other hand it is possible for two independent developers to create two different apps with the same Application package. Of course not both apps can be hosted on the Market — the Market would reject the second one due to the “unique App package name across Market” rule.] Only holds true if the second developer does not get a hold of the first developer’s keystore file & password.

{ 1 } Trackback

  1. [...] Next up is to create and configure an Android project.  The application name is very important in creating an Android application.  The application name must be unique across the entire Google market as explained here. [...]

Post a Comment

Your email is never published nor shared. Required fields are marked *