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?

Answer 1

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]

Answer 2

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.

Answer 3

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.

Answer 4

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.

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).