Branding of android app

branding.md

Partners want to be able to brand the android app with their name and logo. We can either a) publish n apps (one for each parter), or b) publish one app and replicate branding in the ddoc.

Option A pros

• technically simple
• flexible
• correct branding will be shown in the app store

Option B pros

• allows projects to control their own branding without having to get us package and release their app which also means unknown installations (eg: DIY) can be branded
• all installations have identical code bases so there's no risk of branching and having to maintain legacy apps
• branding can be updated without having to publish to the app store and have every user update their version
• maintains consistency between the webapp and android app branding

Option A drawbacks: Need to be vigilant about scope of customizations; ideally we'd define these in advance. Could make a CI setup more complicated, and/or require lots of branches/merges.

Option B drawbacks: can't change the static icon displayed in the Google Play store; the app will likely use the Medic Mobile icon on the home screen until the first-run login is successful. Need to thoroughly understand where we're providing customization/branding hooks and where we're not supporting them, in advance.

Maybe we can allow for option A, but do it in a way that uses build targets and configuration/asset bundling rather than a branch-based workflow?

I think Option B seems ideal, but not technically simple. I have yet to see a reliable way to programatically update the app's launcher icon & name - which are the primary things to update. As it is right now, we do not have many other labels/icons to update within the app, if any. Even if we did, those could be changed on the server side.

Another thing to consider... will Option A/B make it easier to deploy? For instance, if we have project specifc videos in the resources, we may not want to go to each phone, log in, and download all of the data and media for the forms. Does Option A make that easier since we can include those resources as assets in those project specific builds?

@alxndrsn implemented Option B using this method. This method requires rebuilding the APK every time we add a new project, which still has some drawbacks:

• With every new project users would see an updated version in the app store - and possibly automatically update it.
• That app would get incrementally large as more projects and icons are included.
• Users wouldn't know whether they should update because there is a fix in the container, or if a new project config was added