Prepare Android project for CI

Not all android projects can be build in CI system immediately. Mostly projects for Android are created using IDE (like Eclipse or IntelliJ Android Studio), and developers don't really check if project can be built automatically. This is especially important if you have complex, enterprise grade project, which contain many libraries, dependencies etc.

There are a few easy steps that you can follow in order to make your project CI-enabled. 

1. Make your project checks out cleanly from Version Control system

In case of more complex projects, the applications are split into smaller libraries. Until very recently (changed with New Build System introduction), the only and recommended way of doing that was referring to software libraries source rather than using binary artifacts (.jar files or more recently .aar files).  Also Eclipse's limitation was that it did not support the nested project structure.  That made complex dependencies difficult to manage and the process of checking out the project was usually manual and pretty cumbersome. Unfortunately, out-of-the box it does not work very well with fully-automated approach that is required by CI.

Here are some best practices that you can follow in order to get your project prepared for automated checkout:

1) Keep your project and libraries as separate repositories (in case of modern distributed version control systems like git or mercurial), or as separate paths (in SVN). 

2) Link the libraries using mechanisms provided by the respective version control system. This is provided by mechanism like "svn:externals" in SVN, "submodules" in git, "subrepository" in mercurial. Other VCS system have similar mechanisms.  Usually such mechanism works transitively, so you can have libraries linked to other libraries. The nice feature of those mechanisms is that you can link to either fixed version of the library (if you require stable link) or you can link to a HEAD of any branch or master of the library in case you have a library which is under heavy development and you want to take advantage of frequently switching to latest version.

3) When you checkout the project follow the VCS's instructions on how to checkout the whole project with all the linked repositories (Follow the links above if unsure).

4) When you configure the project in Eclipse, you need to open each of the sub-projects separately ("Import -> Import existing project into workspace" de-selecting "copy project sources"). This will allow your project to compile. 

2. Review your library dependencies (and How Flow can help with those)

In complex project when you have many libraries and cross dependencies between them, you might get into some troubles when there are libraries reffered from several other libraries in single project. This is usually not a big problem in eclipse, but when you want to work on library projects separately, it becomes a challenge to make the whole project compiles. There are problems if the same library is added several times (duplicate .class problem) or when some of the 2nd or 3rd level library uses resources (android's ant only copies resources from the 1st level library - directly linked from the main project). These problems are addressed mostly in New Build System based on gradle (similiarly as Flow). But if you have a lot of legacy projects using ant and you do not want to migrate to the NBS, Flow can sort it out for you. Flow analyses library dependencies and manipulates classes and resources while building dynamically (behind the scenes), so while you will not build the project with 'ant' command, 'gradle buildAll' will do perfectly well. You just have to make sure to use the same versions of libraries everywhere.

New Build System has mechanisms to cope with it on it's own, so this part is pretty much only relevant for ant-driven builds.

3. Make sure the certificates are properly configured

Some of the builds that you generate are Release builds, which require your release certificate to sign the application. The certificate should be specified in file - you can specify location of the certificate, password and key alias there. Flow also allows to specify those properties in command line, so that they are not stored in the source code of the application (for example password) might be a security violation. More information at Make sure that the certificate is copied to the CI server machine, so that they are accessible while the project is build there. 

4. Configure the project for Apphance

Each of the projects can be configured to add Apphance automatically - separately for each variant. This is great help in case you want to produce different builds  - some with Apphance QA and some with Apphance Prod libraries and configured differently. Apphance Flow allows to configure each variant to add Apphance automatically and even to send the build to Apphance automatically after every release. More about this in  Apphance Service.

If you are already using new Android gradle plugin follow to Using Flow with Android gradle plugin otherwise go to Add Flow to Android project