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.
6 Comments
That is clearly and simply explained. Thank you very much for this useful entry !
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.
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.
Thank you. Nice explanation, very useful !
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
There is some overlap between the two types of packages. The generated R.java 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.