Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Rewrote a troublesome header & deleted a bunch of obsolete info. Most info now duplicates information in the tiapp.xml reference.
Contents

Table of Contents
maxLevel5
minLevel2

Overview

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 tiappFor the most part, if you have to add properties to the AndroidManifest.xml file, you can simply add them to the application's tiapp.xml file. If you encounter a setting that you can't override in tiapp.xml, you can create a custom AndroidManifest.xml file.

How it works

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

Code Block
langxml

<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.

Configuring screen densities

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 <supports-screens> element set to true into tiapp.xml's android->manifest element like thisSee tiapp.xml and timodule.xml Reference for details on elements that you can put in the tiapp.xml file.

Custom Manifest Entries in tiapp.xml

For the most part, if you add a manifest entry to the tiapp.xml file, it replaces the entry in the generated file. Consider the following section of a tiapp.xml file:

Code Block
langxml

<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"
        />
    </manifest>
</android>

Ensuring the minimum SDK version

...

<uses-

...

Code Block
langxml

<android xmlns:android="http://schemas.android.com/apk/res/android">
    <manifest>
        <uses-sdk android:minSdkVersion="7" />
        <supports-screens
            android:smallScreens="false"
            android:normalScreens="true"
            android:largeScreens="true"
            android:anyDensity="false"
        />
    </manifest>
</android>

In other words, things you put in there under `<manifest>` will be put in Most elements inside the <manifest> will be added as children to the `<manifest>` <manifest> element inside of AndroidManifest.xml at build time, with some intelligence built in. Like we won't just plop your The <supports-screen> in there and leave our default one in there as well – we'll intelligently remove our default one and replace it with yours.

...

tag in your tiapp.xml replaces the  default <supports-screen> tag.

The manifest's all-important <application> element is handled differently. Your elements are applied additively, rather than replacing the whole <application> element.

Enabling the debugger by default

For example, let's say you want the debuggable attribute of <application> to be set to `true` true (it's false in our the default manifest template), you can do this:

Code Block
langxml

<android xmlns:android="http://schemas.android.com/apk/res/android">
    <manifest>
        <application android:debuggable="true" />
    </manifest>
</android>

The official Android Developers website describes all the other elements that are supported, such as <service>, <uses-permission> and {{ <activity> for instance, and these will be added using the same logic.

...

Using a Custom Manifest

In rare circumstances, you may still need to create a custom AndroidManifest.xml. If this is the case, be aware of the following advice:

  • Starting in 1.5.0, do not put your custom manifest into a file named AndroidManifest.custom.xml in the build/android directory. Instead, just name the file AndroidManifest.xml, Name the custom manifest  file AndroidManifest.xml, and put it in the directory platform/android beneath your application's root project directory. 

    Create the platform directory if you need to, ensuring that the directory is a sibling of the "Resources" directory, (right below your project root).



  • Starting in 1.5.0, we add a handy feature whereby if If you do have a custom manifest, we'll (of course) use that for the build, but at the same time we'll put generates a file named AndroidManifest.xml.gen into in the {build/android}} directory during each build, to show you what you would've gotten if you used the . You can use this to see the AndroidManifest.xml that we would've *gen*erated for youwould be generated by default.

Ensuring Android

...

Shuts Down Apps Cleanly

The are times when an application needs to be shut down by the platform outside of the application context, such as when the user changes fundamental system settings or lets the app sleep for long periods. Unfortunately, Android's primitive kill process sometimes leads to a known problem where the app is only partially shut down. The solution for Titanium apps is to set the alwaysRetainTaskState parameter in the AndroidManifest.xml file, as follows (this one is taken from the KitchenSink):

Code Block
langxml

<activity android:configChanges="keyboardHidden|orientation" android:label="KitchenSink" android:name=".KitchensinkActivity" android:alwaysRetainTaskState="true" android:theme="@style/Theme.Titanium">
  <intent-filter>
    <action android:name="android.intent.action.MAIN"/>
    <category android:name="android.intent.category.LAUNCHER"/>
  </intent-filter>
</activity>
Note

Be aware that this setting increases memory usage, so only enable it where your app is experiencing the problem.

Titanium SDK < 1.5.0

With Titanium SDK below 1.5.0, the AndroidManifest.xml file will be overwritten on each build. However, you may create a customized version AndroidManifest.custom.xml and place it in the <PROJECT>/build/android directory beside AndroidManifest.xml.  The build tools check for its existence and will use it.

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. However, one of the benefits of a custom file is that it allows you to change your version number when submitting to Google Play.