Android Rebranding

Rebranding Android Applications (Part 1)

Did you ever wonder what is the best way to build new Android Apps if you have already the code for a working app and just want  to exchange some Images, adjust some Colors and Styles and alter a bit of Text. Basicaly you want the same App with a different look and feel and maybe connected to another instance of a similar backend. Recently i had to do  several rebrandings of different existing Android Apps, so I had to do this a lot.

One might think, that changing some Images, Texts and URLs is no big deal at all, but there are some pitfalls

you might experience if you do this by Hand. (And by Hand i mean within eclipse).

In this blogpost you will learn how to prepare your Code so that it can be easily rebranded and how you'll can do such a rebranding within eclipse.

You can use this article as a checklist, to avoid missing any important steps. However in "Rebranding Android Applications Part 2" (soon to come) i will offer a more elegant and effortless solution by providing a build script, which does most of the work for you, and allows you to mantain a single code base.

Prepare your App for rebranding

Here is what you'll have to do in eclipse if you want to get a Codebase, which can be easily rebranded and maintained to utilize different sets of assets:

1. Prepare Your App to use colors.xml styles and themes

Of course your App should already use Colors defined in XML and Styles. If you want to rebrand your Application its especially useful if you use the Frameworks mechanisms to centralize such definitions, so you can easly change and mantain them. So if you're not using them to full extend yet, now its the time to change this.

2. Externalize all your Strings

As you did with colors and styles you should also do with your Strings: Externalize and centralize them as String Resources. I would recommend that you'll keep all Strings that contain Text which is presented to the User in one (or more) files and all Strings which contain configuration Information (like URLs to use, API Keys and so on) in another File.

Strings hidden inside the code are prone to be overlooked on rebrandings if you do rebranding a few month after you've last touched your code or if someone else has to do the rebranding.

3. Externalize other configuration values 

If you have other configuration values than strings (like boolean flags) you can also externalize them using the other Resource Types Android provides

4. Check your intents and decide if they should he implizit or explicit

 If you're rebranding your Application you should always double check if you want to use explicit or implicit Intents. Implicit Intents are a powerful Android Concepts, but if you have several Applications with similar Intent-Filters installed on the same device and you don't have a clear strategy for why and how you use them, the user experience might not be as you would like to. With explicit Intents you're always on the safe side (but your App will lack entry-points for other Apps to mesh-up with your App). Go check your Intent-Filters in your AndroidManifest.

5. Separate Activity Package from Application Logic

Last thing you'll have to do is to separate the package in which your Activities are from the application-logic and other custom UI elements.  

 Note: If you use the approach recommended in Rebranding Android Applications Part 2 you can skip this step. But thats here is what you'll have to do if you want do all your rebrandings by hand:

If your Activities are already in a separate Package you can use  "Rename Applikation package" in Eclipses Android Tools which come with the SDK  and than do package refactoring. The goal is that you get a package like com.myaplicationname.activities(the Package which will be renamed during rebranding) with all your activities inside it and a package name like com.mycommoncodebase (a Package which will stay untouched) where all your reusable Application logic is. 

You must do this because Android Applications are identified by their Package-Names and later on you'll have to change the Package Name for each rebranded Application, or the User will ran into trouble if he tries to install different brands of your Application on the same Device. In fact you will probably not be able to upload the branded Applications to the Android Market if they have the same package name. 

It's recommended that you place all of  your logic in an independent package, which will not change its name during rebranding. If you do this you'll have an easier Time if you want to reintegrate and merge Code changes (like Bugfixes) into your new Application. 

To minimize the content of the Package that will be renamed during rebranding, you can put your Activites into the package for the common code base and just extend them with empty classes inside the rebranding package.

After you refactored your package structure you'll have to check your layout XML-Files for stale references if you created custom View-Classes and used them in your XML. Unfortunately eclipses refactoring Tool does not do this for you.

Rebrand your Application (by Hand)

Now that you've prepared your original Application for rebranding, here's a checklist of steps to do for the actual rebranding:

1. Create a new Project and rename application package

First you'll have to create a new Project with a copy of your original code. After the project is set up correctly the first think you should do is 

rename the application package (Use The Eclipse context menu on your Project->Android Tools->Rename Application Package).

2. Refactor Activity package

Refactor the package in which your activities lie (using the eclipse package renaming tool) to match your new application name.

3. Check your AndroidManifext.xml, Intent-Filters and Content-Providers

Check you're IntentFilters (if any) and your ContentProvider authorities (if any) in the AndroidManifest. Make sure your Authority URIs in your ContentProvider-Classes are correct for the rebranding. (You must avoid conflicts with authority URIs of your other Applications, or the rebranded application might not install on devices with conflictingContentProviders).

After this step you should check if your app compiles, installs and still works as expected.

4. Check for Links to Android Market (Updates) and watch the package name

If your Applications contains Links to the Android Market for itself you must change these links for your rebranded App. 

5. Exchange your fx/sound and other media resources

That's the step where you your actual rebranding begins. Exchange any images, sounds and any other branded media files you provide.

6. Update your colors.xml and styles.xml

Update your colors.xml and styles.xml and if you want to other layout resources to match your new design.

7. Update your wording

Update your String resources to match your brands wording (like changing product names, or other information).

Don't forget to change your applications name! 

8. Update Configuaration

Update your other Configuration settings like strings with your API-Keys (For example Twitter, Facebook and or Tracking URLs)

or other URLs your application uses, like links to other sites  or URLs it uses to obtain data or connect to some service.

9. Test your new UI

Test if the User Interface works and looks like you expect.

10. Test for conflicts

Finally  you should test for conflicts. Install your original App together with all rebranded versions you ever published or want to publish. And check if any conflicts exist.

Conclusion

You've learned how to prepare your app for rebranding and how to rebrand your application by hand and where to watch out for conflicts which might occur. All this might be more fuss than you may have expected.

And after all one big problem still remains: Your new App has started as a copy of your old one, which means from now on you'll have to maintain two codebases. If you fix a bug in one source code you'll have to merge the fix into the other codebase by hand, which further includes your workload.

In "Rebranding Android Applications Part 2" (soon to come) you will learn how you can avoid most of the hassle and rebrand your applications from a single code base by using a quite simple build script. 

Discussion

Im eager for your thoughts. Did i miss something? Do you recommend any other steps or strategies? What are your experiences in rebranding apps? Please comment.