How to develop two versions of the same application, one free and the other paid?

Question

I’m starting the development of an application for Android using Android Studio, I intend to make it available in two versions, one paid, with more features, and one free, more basic.

I thought about starting to develop and after finishing the base version, common between the paid and free application, create a copy of the project and start adding new features to the paid application, but I did not find this practice cool, because there would be redundant information (classes, images, layouts, etc) and whenever I find an error I would have to fix in both projects, if the same is in the base version.

I would like to know what to do in these cases and if there is any standard/tool to deal with it.

Note: base version are the common elements between paid and free version, this includes classes, pictures, layouts and all that.

Answer 1

There is a pattern (not a Design Pattern in itself) Android/Gradle’s own to handle this. The prerequisite would be to use Android Studio and compile its apk using Gradle. Because it is Gradle that provides this functionality.

To handle generating two different apk’s, Gradle lets you define Build/Product Flavors.

Just as Build Types (release or debug), Build/Product Flavors are, as the name says, "flavors" (functionality/code, features, settings, etc...) that your app may have. The most common ones are: Free, Paid, Phone and Tablet (these last two being unnecessary depending on the type of customization you will do). You can give the name you want to a launder, has no limitation.

Correction: The combination of a Build Type with a Build Flavor generates a Build Variant. That would be used in the compilation of fact (this I explain better at the end).

And using Gradle it is possible to generate an apk for each combination of launder and build type available. More below I explain how to do this:

Build Configuration

A simple configuration of your file build.gradle would be:

apply plugin: 'com.android.application'

android {
    compileSdkVersion 21
    buildToolsVersion "21.1.2"

    defaultConfig {
        applicationId "br.com.testegradleflavors"
        minSdkVersion 10
        targetSdkVersion 21
        versionCode 1
        versionName "1.0"
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        }
    }

    productFlavors {
        free {
            applicationId "be.tamere.testegradleflavors.free"
        }

        paid {
            applicationId "br.com.testegradleflavors"
        }
    }
}

dependencies {
    compile fileTree(dir: 'libs', include: ['*.jar'])
    compile 'com.android.support:appcompat-v7:21.0.3'
}

In this example, I define two Flavors: free and paid. Like the Google Play requires, each apk needs to have a unique ID. Soon each launder need to have a applicationId different because in the end it will generate a different apk.

No need and no need recommended change the package structure to match applicationId of each launder. That’s because Gradle can handle the "merge" of the Build Variant current.

Of course you can make this configuration more convoluted, like Build variables:

productFlavors {
        free {
            applicationId "be.tamere.testegradleflavors.free"
            buildConfigField "String", "VARIAVEL_ESTATICA", "\"free\""
        }

        paid {
            applicationId "br.com.testegradleflavors"
            buildConfigField "String", "VARIAVEL_ESTATICA", "\"pago\""
        }
    }

There are other settings, such as Multi-flavor Variants who would be Flavors of multiple levels, but this goes far beyond the scope of the question.

To access these Build variables in Java code:

String variavel = BuildConfig.VARIAVEL_ESTATICA;

---

Configuration of code/Resources

With respect to code, just follow this design structure (following the Gradle standard):

In this image, illustrates my project that has three folders on the same hierarchical level: main with the code/Resources common to all Build Variants application possible (default on a currently created Gradle project), paid with the/Resources/files classes that are specific to the paid apk and the free with the classes/Resources/specific files for free apk.

When you modify the Build Variants (choosing a launder different), it visually disables the folders that are not being used. In the image for example appears the MainActivity with a red error symbol in the free folder, but this is because the folder was disabled when I chose the launder paid. When to modify the launder for free, the reverse will occur.

It is good not to use the same resource name (classes, xmls, files in general) between main and free/paid. Because the features of the more specific packages (free and paid) will overwrite the resources of the less specific (main).

When a launder is chosen for the build, it will consider all classes and Resources and will merge everything into the same apk, overwriting what you have repeated (prioritizing the launder). The files that exist in main but that there are no Flavors, will be included without problem in apk.

When building, simply choose the launder and the type. This can both be by command line:

gradlew assembleFreeRelease -- Build para o apk Free em modo Release
gradlew assemblePaidRelease -- Build para o apk Pago em modo Release

gradlew assembleFreeDebug -- Build para o apk Free em modo Debug

-- Demais configurações de build flavor e type

As for Graphical Interface: within Android Studio, just change the combobox option from Build Variants as in the image of the organization of the project.

References for better deepening:

• https://www.youtube.com/watch?v=LCJAgPkpmR0
• http://tulipemoutarde.be/2013/10/06/gradle-build-variants-for-your-android-project.html
• http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Product-Flavors
• https://stackoverflow.com/questions/16737006/using-build-flavors-structuring-source-folders-and-build-gradle-correctly