Question

Typically when you build and debug Android application, you would have debuggable=true in manifest and you would sign application with development key.

When it is time to release your application you would need to change to debuggable=false, sign with your own key, optionally run ProGuard and possibly do something else.

Certain external operations like signing with different key can be easily coded with Ant. In fact those tasks come out of the box. However, changes in AndroidManifest.xml seem to require manual intervention every time.

Another aspect is maintaining release versions of application. For example, out of the box Android tasks will not use any version information. Maven will use SNAPSHOT versions and will require manual update for the release.

Dealing with all those issues is quite tedious and some automation is highly desirable. So far my approach was to create separate branch in git for release where I would keep final manifest, as well as poms with correct version.

But I would like some advice from other people on best practices for dealing with Android release cycle.

Any recommendation?

Answer 1

However, changes in AndroidManifest.xml seem to require manual intervention every time.

In places where we had to do manual xml manipulation for our automated Android builds, we use the built-in XSLT support in Ant, using the <style /> task. A stylesheet might look something like:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:android="http://schemas.android.com/apk/res/android">
  <xsl:output method="xml" version="1.0" encoding="UTF-8" indent="yes"/>

  <xsl:template match="application[@android:debuggable='true']">
    <xsl:copy>
      <xsl:copy-of select="@*[name(.)!='android:debuggable']" />
      <xsl:apply-templates />
    </xsl:copy>
  </xsl:template>

  <xsl:template match="@*|node()">
    <xsl:copy>
      <xsl:apply-templates select="@*|node()"/>
    </xsl:copy>
  </xsl:template>

</xsl:stylesheet>

As for the SNAPSHOT release cycle: The way the automated Jenkins build and release process does it is with a maven goal that will automatically perform these steps:

1. Update the pom versions (e.g., android:versionName/android:versionCode) to remove “-SNAPSHOT” — e.g., x.y.y-SNAPSHOT becomes simply x.y.y
2. Commit that as the “version x.y.y release”
3. Tag that release in the git repo
4. Update the pom versions to SNAPSHOT of the next logical release: x.y.z-SNAPSHOT
5. Commit that as the “prepare for next version” starting point

At step #3, it also pushes that code to the public git server (if applicable), and publishes the release tag to the Jenkins plugin repository, so it becomes available as an update.

I would imagine a similar approach for an Android release cycle would be fairly trivial to script as well.