Android - whitelabel app

Question

NOTE: This is an old question, and the correspondingly old upvoted answer may not be relevant - see the newer answers about Build Variants (a.k.a. App Flavors).

I have a question about publishing to the marketplace.

Company, X, provides similar services for companies A & B, and both A & B want an app in the market place. Company X wants to write just one app and differentiate between them using the appropriate logo's, configuration settings, language strings at compile time. However, when it comes to publishing, the apps have the same app package name (using shared code base). The app will be maintained and

So, given that I want to keep a single code base, what is the best practice here?

Smaragd

Answer 1

As far as I know you can't have two apps on Market with the same package name. To avoid copy-paste of shared code, layouts, drawables etc I would recommend to put the these resources into a library project and then reference this project from app A and B that you mention and in these apps just override the values you want to change.

More about library projects in the official documentation.

Mothball

Definitely, that's what library projects were invented for. We just converted an app to a "full + lite" scheme and converting the original project into a library project and then splitting it into two projects was easy as pie. – Shrivel

Thanks @johan - also for reference, its also possible to use the --custom-package command line argument with aapt in build.xml, as described here: blog.elsdoerfer.name/2010/04/29/… - Library approach sounds better long term bet to me tho – Smaragd

given link broken :( – Rehearsal

Answer 2

See this blog post, blog.javia.org/android-package-name/.

[edit] To avoid a loss of information if this link dies: Its a post about the difference of the application package definition and the java package definition. Its possible to change the application package (inside the manifest) without touching the java package of the sources.[/edit]

Vouch

Answer 3

This is a pretty old question. However now I think the best approach will be to use Product Flavours for Android using the new gradle build system.

• For each flavour you can define applicationId. There is a difference between packageName and applicationId. ApplicationId uniquely identifies your app on the device and in Google Play Store. The latter is for code namespace. You can read more here: https://developer.android.com/studio/build/application-id.html
• For each flavour, you can have a different drawables, strings, other xml file using specific folder for the flavour. You only need to put those assets into the new files, which differ from assets in the main folder. Then there is buildConfigField you can define for each flavour in build.gradle which can be accessed from Java files as your configs for each whitelabel.
• Also you can define resValue for each flavour from there.
• You can also make your AndroidManifest.xml configurable for keys etc using manifestPlaceholders.

Nursemaid

Answer 4

johan's answer is correct. In my company, we just built a small script that creates 'brands' of application from one 'base' application, by not only applying new resources, but also creating a custom package name and patching the appropriate XML files.

Macmahon

Can you please guide me about script for creating brands.? – Minsk

Answer 5

I agree with what Reflog said, my company used an ant script to change the package name for each brand, and also to replace resources as needed. I wrote the base app with default behavior in mind, and created folders for each additional brand containing only those files that were different from the base, just like the multiple drawable folders with different dpi sizes ("drawable", "drawable-hdpi"...). Other changes included modifying the strings files for each brand for appropriate colors and legal text.

By naming them in the localization style (for instance "drawable-en-rAA-hdpi", "layout-en-rBB"...), I was able to test this quickly in multiple emulators by opening the "Custom Locale" app in each emulator, and setting the locale to "en_AA", "en_BB" as needed. By saving multiple copies of the base AVD, I was able to save those settings so I didn't have to switch within the emulator to test all the final brands.

One caveat to this approach is this emulated version of the app will include all the files in the .apk, while the ant script strips out the duplicates. Also, while this "full" .apk will install on devices, it will only show the default behavior unless you can set the locale on the device to match the brand locale. (Custom Locale was not installed on any of my physical devices.) This works well if you intentionally use existing named locales (en_AU, en_CA, en_GB), but can be problematic for custom names (en_B1, en_XX).

Rabin

Answer 6

I know I'm a little late to the party but you can do this by:

1) Change your project.properties by adding the line manifestmerger.enabled=true

2) Change your package name in the manifest.

3) Update/change your resources, drawables, strings, whatever.

4) Mark your master project as a library and set the dependency for it in your white-label project. Voila, white-label!

Millinery

Answer 7

What you need is Build Variants (a.k.a. App Flavors).

You can read up on it here https://developer.android.com/studio/build/build-variants.html

In short, this allows you to have different variants of your app that share part of the code and resources, but can have their own replacements as well. You can specify different package name/id for each variant, among other things (like logo, colors, splash screen and even java code).

defaultConfig {
    applicationId "com.example.example"
    minSdkVersion 16
    targetSdkVersion 25
    versionCode 1
    versionName "1.0.0"
}

productFlavors {
    variantone {
            applicationId 'com.company1.example'
    }
    varianttwo {
            applicationId 'com.company2.example'
    }
}

You can create resource folders with the name of the variants where you can place your alternative resources or source code. For instance, src/variantone/res

Switching between build variants in Android Studio does not result in file changes (you just choose the "output"). You can build APKs for all the variants you want at the same time. Use the wizard in Build/Generate signed APK.

P.S. Here's how you can have a different package name for Debug builds:

buildTypes {
    release {
    }
    debug {
        applicationIdSuffix '.debug'
        versionNameSuffix '.debug'
    }
}

Lansing