Android Manifest : Specifying Android App and SDK Versions

In previous tutorial, we started building the foundation of our android knowledge base with discussing the project structure, files and folders created with an android app by default. Let’s invest some more time in understanding few basic things which I think you must know beforehand.

The foundation for any Android application is the manifest file AndroidManifest.xml in the root of your project. Here you declare what is inside your application — the activities, the services, and so on. You also indicate how these pieces attach themselves to the overall Android system; for example, you indicate which activity (or activities) should appear on the device’s main menu (i.e. launcher).

In AndroidManifest.xml file, you declare various version attributes which you will be learning in this short tutorial.

The root of android manifest file is “manifest” element. A small manifest looks like below:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.howtodoinjava.demoapp"
android:versionCode="1"
android:versionName="1.0" >

<uses-sdk
	android:minSdkVersion="11"
	android:targetSdkVersion="18" 
	android:maxSdkVersion="21"/>
...
...

</manifest>

The biggest piece of information you need to supply on the element is the package attribute. Here, you can provide the name of the Java package that will be considered the “base” of your application. Your package is a unique identifier for your application. A device can only have one application installed with a given package, and the Play Store will only list one project with a given package. We already learned that in detail when discussed the key terms and concepts used in android development.

Specifying App Versions

Android manifest also specifies android:versionName and android:versionCode attributes. These represent the versions of your application. The android:versionName value is what the user will see for a version indicator in the Applications details screen for your app in their settings. Also, the version name is used by the Play Store listing, if you are distributing your application that way. The version name can be any string value you want.

The android:versionCode, on the other hand, must be an integer, and newer versions must have higher version codes than do older versions. Android and the Play Store will compare the version code of a new .apk file to the version code of an installed .apk file to determine if the new APK is indeed an update. The typical approach is to start the version code at 1 and increment it with each production release of your application, though you can choose another convention if you wish. During development, you can leave these alone, but when you move to production, these attributes will matter greatly.

Specifying SDK / API Versions

Android manifest also contains a element as a child of the element, to specify what versions of Android you are supporting. The most important attribute for your element is android:minSdkVersion. This indicates what is the oldest version of Android you are testing with your application. The value of the attribute is an integer representing the Android API level. So, if you are only testing your application on Android 2.1 and newer versions of Android, you would set your android:minSdkVersion to be 7. Note that your app will not be available for installation in older versions of android devices.

You should also specify an android:targetSdkVersion attribute. This indicates what version of Android you are thinking of as you are writing your code. If your application is run on a newer version of Android, Android may do some things to try to improve compatibility of your code with respect to changes made in the newer Android.

Usually you will not want it but if you want that your app should not be installed on an android device which has an API level greater than certain number, you can put this restriction using android:maxSdkVersion attribute. Most of the times, you will not be needing this attribute at all because android SDKs are always backward compatible and you can be sure almost always that your application will run in future versions without any problem.

That’s all for this short android tutorial having information related to version parameters in manifest file. We will discuss other concepts / features which we can control from AndroidManifest.xml, in our future discussions.

Happy Learning !!

Was this post helpful?

Join 7000+ Fellow Programmers

Subscribe to get new post notifications, industry updates, best practices, and much more. Directly into your inbox, for free.

Leave a Comment

HowToDoInJava

A blog about Java and its related technologies, the best practices, algorithms, interview questions, scripting languages, and Python.