HowTo: Maintain a Custom AndroidManifest.xml

For mobilesdk 1.5.0 or higher

Starting with mobilesdk 1.5.0, the need for a custom AndroidManifest.xml has decreased dramatically. As an alternative to having a custom AndroidManifest.xml, we've expanded the possibilities for what you can put into your application's tiapp.xml file.

When you create a new mobile application with 1.5.0 installed, you will now see an "android" section inside tiapp.xml. When empty, it just looks like this:

<android xmlns:android="http://schemas.android.com/apk/res/android">
</android>
Note we've included the official android namespace qualifier, and the reason for that is because we wanted the ability to take things out of this section and plop them right into the AndroidManifest.xml for you. To that end, things that you put inside of a "manifest" sub-element will be put into your android manifest for you at build time. Say, for example, you want to indicate that your application supports any screen densities, which was a common use-case that led people to create their own custom AndroidManifest.xml files in previous versions of the Titanium mobile SDK. Now you can just plop the true &lt;supports-screens&gt; element into tiapp.xml's android->manifest element like this:
<android xmlns:android="http://schemas.android.com/apk/res/android">
    <manifest>
        <supports-screens 
            android:smallScreens="false"
            android:normalScreens="true"
            android:largeScreens="true"
            android:anyDensity="true"
        />
    </manifest>
</android>
You can put other stuff in there too, like &lt;uses-sdk&gt;:
<android xmlns:android="http://schemas.android.com/apk/res/android">
    <manifest>
        <supports-screens 
            android:smallScreens="false"
            android:normalScreens="true"
            android:largeScreens="true"
            android:anyDensity="false"
        />
        <uses-sdk android:minSdkVersion="7" />
    </manifest>
</android>
In other words, things you put in there under &lt;manifest&gt; will be put in as children to the &lt;manifest&gt; element inside of AndroidManifest.xml at build time, with some intelligence built in. Like we won't just plop your &lt;supports-screen&gt; in there and leave the our default one in there as well -- we'll intelligently remove our default one and replace it with yours.

(NOTE: a bug was discovered that affects 1.5.0 and 1.5.1: if the only customization you put on the &lt;manifest&gt; element is one or more attributes (as opposed to child elements), those attributes will not be processed. This was fixed for 1.5.2 and higher. See Lighthouse issue 2973.)

Stuff for the manifest's all-important &lt;application&gt; element is also handled intelligently. In tiapp.xml, if you have stuff for &lt;application&gt;, put it in an &lt;application&gt; element below &lt;manifest&gt;. We'll be smart enough not to replace the whole &lt;application&gt; element in AndroidManifest.xml with whatever you put here. In terms of the &lt;application&gt; element's attributes, you can consider this "additive" and "replaceative" (that's our word, don't use it!) For example, let's say you want the debuggable attribute of &lt;application&gt; to be set to true (it's false in our default manifest template). You can do this:

<android xmlns:android="http://schemas.android.com/apk/res/android">
    <manifest>
        <application android:debuggable="true" />
    </manifest>
</android>
And if you want to list some extra &lt;service&gt;, &lt;uses-permission&gt; and &lt;activity&gt; elements, put them in there and we'll add them to the manifest.

Do you still want a custom manifest?

If, after reading all that, you still need to create a custom AndroidManifest.xml, read these bullets:

  • Starting in 1.5.0, do not put your custom manifest into a file named AndroidManifest.custom.xml sitting in the build/android directory. Instead, just name the file as the standard "AndroidManifest.xml", and put it in the directory platform/android beneath your application's root project directory. You can create that directory if you need to. So if you do, note that the directory "platform" should be a sibling of the "Resources" directory, i.e., right below your project root.

  • Starting in 1.5.0, we add a handy feature whereby if you do have a custom manifest, we'll (of course) use that for the build, but at the same time we'll put a file named AndroidManifest.xml.gen into the build/android directory during each build, to show you what you would've gotten if you used the AndroidManifest.xml that we would've generated for you.

Older notes concerning mobilesdk < 1.5.0

Starting with mobilesdk 0.8.0 the AndroidManifest.xml file will be overwritten on each build. The first pieces of a more intelligent build system have gone in and one of those requirements is to be able to re-generate files based on the Titanium APIs that you use in your application.

We recognize the fact there are many reasons to edit and maintain your own file, so along with the automatic re-generation of the AndroidManifest.xml we've provided a method for you to maintain a custom AndroidManifest.xml.

All that is required is to name your customized version AndroidManifest.custom.xml and place it in the directory beside AndroidManifest.xml. Specifically, place the AndroidManifest.custom.xml in &lt;YOUR PROJECT&gt;/build/android. The build tools check for its existence and will use it instead of generating the AndroidManifest that uses only the features and permissions of the Titanium methods actually used in your application.

Our end goal is having a build system that only includes the minimum capabilities for the APIs used in your application. That will allow you to simply use an API and not worry about maintaining build files.

One of the uses for the custom file is changing your version number when submitting to the Android Market.