Android Free and Non-Free Builds

Anyone who has browsed around the iTunes store or Android marketplace is familiar that many of the applications have a free and non-free version.  While it would certainly be possible to maintain two complete branches of code, anyone who has done software development for more than trivial projects knows that duplication is a Bad Thing (tm).  The Android SDK provides a mechanism to build multiple projects based on a single library without duplicating all of the code.

See iOS Free and Non-Free Builds also.

Create Library Project

The odds are you already have a project you are planning on turning a free and non-free version.  It is probably safer to start with a new project to figure out any of the details before jumping in with your current project.  To just jump in with an existing project skip this step and go into the Android properties for the project and set the project as a library.

Android will have you create multiple projects to accomplish multiple build targets.  For organizational purposes create a root directory for the over all product, in this case 'A Example'.  Under that directory create the 'library' project first.

Follow through choosing the options for the project until the project is created.

Create Application

The next step is to create the application which will use the library project created in the previous step.  This project will need a different package, usually a subpackage of the library project.

On the next screen skip adding an activity.  The activities will be used from the library project.  After finishing this step project will be created.

In the project properties on the Android tab click the Add button.  Select the library created in the first step.

 

Create Free Application

Follow the same procedure to create the application for the free version, choosing another unique subpackage of the library project.  At this point there should be three projects: library, application, and free application.  It would be good practice at this point to create a test project, but it will be skipped for this post.  Be aware that the test project needs to be built for one of the applications rather than the library directly.

 

 

Update Manifests

Perhaps my biggest complaint for Android's mechanism for creating multiple releases is the necessity to duplicate manifest.  The manifest in the library project is unused, but I like to keep it updated anyway as it it were a full project.

One limitation to note about the manifests in the application and free application project is that android:name attribute of the activity elements must be the full package and class name from the library project.  The shorthand .ActivityClassName does not work since it would look for the class in the current project's package.

Update Layout

To demonstrate separate targets add a label and button to the main activity layout.

Resources

All of the resources are loaded in a heirarchacal fashion, checking the application project directory first and then falling back to the library project.  This allows customization of the assets required for the application or using shared assets from the library project.  One limitation for the library project is that all resources it references must be setup in the library project, even if you plan on all of the application projects overriding it.

The library res/strings/values.xml has the greeting value set to "Hello, Library!" and the doit value set to "DOIT".  It can only be seen on the eclipse graphical layout the project is a library and not an application project.

The application res/strings/values.xml has the greeting value set to "Free stuff is overrated." and the doit value set to "Gloat".

The free application res/strings/values.xml has the greeting value set to "Free stuff is cool." and the doit value set to "Whine".

Functionality

Changing functionality for a free version can be done in a couple ways.  Each mechanism has advantages and disadvantages, and in all likelihood a combination of techniques will be used.

Resources

The free version of an application could remove widgets from application layouts which expose the pay only options.  Then the library activity classes would check for the existence of those widgets before setting up them up.  The non-free functionality would then not be exposed.  The downside to this having multiple layouts defined for an activity, depending on the application, with a risk of duplication.

Programmatically

Android creates an R class in the project's defined package.  A simple helper class can be used to attempt to load the R class to determine the application project.

Then the class can be referenced to determine which features need to be enabled programmatically.  This does add complexity to the code with if statements to enable or disable behaviors.

Resources

• https://github.com/crazydays/android_multiple_releases.git