Archive for Posts Tagged ‘Development’


Comments Off on Automating Android Builds

Automating Android Builds

In order to have a fully regression tested application, it is necessary to have an automated build process to ensure all checkins are validated nightly ( or whatever your schedule is). This is a simple task for most Java projects, however you may run into some issues with Android that I point out here.
  • If you started your project from Eclipse, you may not have the Ant build file and supporting properties file in your project
  • If you want to sign your application with a key, the default build keeps prompting you for the keystore password

Both of these are relatively easy to over come and here is a great article on StackOverflow. My only goal here is capture it all in one place.

Environment Setup

The first thing to do, is to make sure that your android SDK folder is on your path. In order to do that, just update your local .bash_profile in your home folder to include the following paths:
export PATH=$PATH:$HOME:$HOME/Documents/Development/android-sdk-macosx/tools:\
export ANDROID_HOME=/Users/Kouroche/Documents/Development/android-sdk-macosx

Note the \ in the first export command. It is there to split the command over two lines, but you don’t need that in there. This will not only add the Android SDK to your path, but also define ANDROID_HOME which is used by the build file (more on that later).

At this point, you will either have to logout and login again, or source .bash_profile to make sure the changes took effect. To verify, run the following command from your home folder:
$ android list targets

Build files

In order to add the build files to your project, you can either create a new project from the command line and copy those build files to your project, or you could update you project from the command line to add in the build files.

Creating a new project

In order to create a new project from the command line, run the following command:
$ android create project --target <target-id> --name MyFirstApp \
--path <path to dev folder>/MyApp --activity MainActivity \
--package com.acme.myapp

The app name nor the package matter. The only thing you may want to match to your current application is the <target-id>.

Once the project is created, copy over the following files to the root of your own project and then delete this app folder.
  • – This is where you store your project specific properties for Ant
  • build.xml – This is the generic build file provided by the Android SDK and will most likely not need changing
  • – This file contains the path to your SDK, but I prefer not to copy it over since it may get checked in by mistake.
  • progaurd-project.txt – This file contains ProGaurd rules if you choose to obfuscate your code, and more can be found here about that.
  • – This file contains the target for your project and is most likely already part of your project.

Updating your existing project

This is probably your best bet since it is less of a hack and should add the same set of files to your project.
$ android update project --name <project_name> --target <target-id> \
--path <path_to_your_project>

Once again, make sure to use the same <target-id>

Customizing the build

Now that you can use Ant to build your project, you may want to customize the build process to meet your needs. For example, I always include a build ID somewhere in the application so users can report which build they are on when reporting issues, or you may want your release build to point to a different backend server than your debug build. In any case, the Android SDK makes this also very easy. Looking at the build file, it optionally imports a custom_rules.xml file that you can create in your project root folder to hook into the build process. The build file even lists out the targets for your to include. Here is a sample one I created:
<?xml version="1.0" encoding="UTF-8"?>
<project name="custom_rules" default="-pre-compile">
    <target name="-pre-compile">
        <!--  get build ID to automate inserting it -->
		<format property="buildId" pattern="yyyyMMddHHmm" locale="en,US"/>
	<replaceregexp byline="true" file="${source.absolute.dir}/com/acme/app/">
        	<regexp pattern='String\s*_VER\s*=\s*"\d*"'/>
        	<substitution expression='String _VER = "${buildId}"'/>
        <!-- Depending wheather this is release or not, update the host file to match -->
        <if condition="${}">
                <property name="" value="" />
                <property name="" value="${}" />
        <replaceregexp byline="true" 
        	<regexp pattern='String\s*HOST\s*=\s*".*"'/>
        	<substitution expression='String HOST = "${}"'/>

What this does, is to update the build ID in my constants class, and also update the backend server my app talks to depending on whether it is a release build or not.

Signing the app

One of the issues I mentioned early on, for the need to have build automation, was having to provide a password each time the app needed to be signed. Well, the key to solving this problem is the file which includes your project specific properties. Unfortunately, i have not found a way around having to include your password in plaintext in some form or fashion so that it can be used, but if your an individual or have a designated build person or machine, you can lock the file down pretty good. So, to get back to the issue at hand, include the following four lines in your file and you are good to go:<path to your keystore file><your keystore password>
 key.alias=<your keystore alias>
 key.alias.password=<your alias password>

If you have been building with Eclipse for while and don’t recall your keystore alias, an easy way is to go through the export process in Eclipse to release the app and see what the keystore alias is.

The build command

OK, so now that it is all set, the easy part is building the application. You can run either of the following commands to build the app for debug or release respectively.
$ ant debug
$ ant release
Good luck.
read more


Comments Off on How to find the key an Android app was signed with

How to find the key an Android app was signed with

I found this on stack overflow, so I am just recapturing here since i found it so useful. First, unzip the APK and extract the file /META-INF/ANDROID_.RSA (this file may also be CERT.RSA, but there should only be one .RSA file). Then issue this command:
     keytool -printcert -file ANDROID_.RSA
You will get certificate fingerprints like this:
     MD5:  B3:4F:BE:07:AA:78:24:DC:CA:92:36:FF:AE:8C:17:DB
     SHA1: 16:59:E7:E3:0C:AA:7A:0D:F2:0D:05:20:12:A8:85:0B:32:C5:4F:68
     Signature algorithm name: SHA1withRSA
Then use the keytool again to print out all the aliases of your signing keystore:
     keytool -list -keystore my-signing-key.keystore
You will get a list of aliases and their certificate fingerprint:
     android_key, Jan 23, 2010, PrivateKeyEntry,
     Certificate fingerprint (MD5): B3:4F:BE:07:AA:78:24:DC:CA:92:36:FF:AE:8C:17:DB
Voila! we can now determined the apk has been signed with this keystore, and with the alias ‘android_key’. Keytool is part of Java, so make sure your PATH has Java installation dir in it.
read more


Comments Off on Installing your Android App on your Phone

Installing your Android App on your Phone

One part of testing an Android app is installing it on an actual phone and making sure that it still behaves as you expect. Given the fact that there are so many different vendors that tweak the OS in order to create a unique experience for their end users before shipping it off with their custom screen resolution phone, there is a lot that can go wrong with an android app. TechCrunch recently had an article about how a hong Kong based company tests their apps and it was a scary realization. Back to our point here! Once you have the app ready, you may want to send it to a customer or another friend to validate and chances are that they do not have and Android development environment setup to compile your code and push it to the device, so here are two other ways: (Note: the instructions here are geared towards linux based systems. Adjust as necessary for Windows)

The some-what technical way

  1. Install the Android SDK. For the sake of this example we will assume it is installed in ~/AndroidSDK. (Note: For Windows you may need to installed the USB drivers as well)
  2. Make sure that USB storage is turned off. This is typically off by default and you can get to the screen once you have connected you phone to your PC via USB. Swipe down from the top of the screen (just like you do to see your notifications) and choose the USB Connected option.
  3. Make sure that you can install apps from unknown sources. To do this, go to ‘Settings’, click ‘Security’ and make sure ‘Unknown sources’ is checked.
  4. Now open a terminal (or command) window and run the following commands to make sure that the SDk can see your device.
    > cd ~/AndroidSDK/platform-tools
    > ./adb devices
    List of devices attached 
    XXXXXXXX5B3900XX	device
  5. Now run the following commands to install your .apk file. For the sake of this example, our file is located at ~/dev/myApp/bin/myApp.apk.
    cd ~/AndroidSDK/platform-tools
    ./adb install ~/dev/myApp/bin/myApp.apk
    You can optionally provide a -s parameter to install the app on the SD card.
  6. You should now see the app in the list of your installed apps

The really easy way

For folks that are not technical, there is an easier way.
  1. Go to the Google Play store and install AppInstaller (free app).
  2. Copy the .apk file to the SD card of your phone. this can be done in two ways:
    1. If your phone has an SD card that can be taken out, you can insert the SD card into your PC and copy the file
    2. If your phone does not have an insertable SD card (like the Nexus S), then connect your phone to your PC via USB, turn on USB storage, copy the .apk file to your phone’s SD card and disconnect the phone
  3. Run the AppInstaller app
  4. The app will list all the apk files on your SD card. Select your .apk file to install it
  5. Note: In this case, you may still have to check the option to be able to install apps from ‘Unknown sources’
read more


Comments Off on Reproducable Development Environments

Reproducable Development Environments

Have not had a chance to try this out yet, but Vagrant seems like a great solution to create small, portable development environment. With this, there will be less of “Well it works on my box!”. You can just receive the development environment where the problem exists and easily reproduce it.
read more