I have been searching for an answer of how mobile companies and carriers get their branding like the bootanimation on a device. Do they do the same on every rom like go to /system/media folder and replace the bootanimation.zip file? How can they do this on a large scale? There must be another way also.


They don't have to change the ROM on every phone by hand. They have a relationship with the phone's manufacturer, so the carrier's customized ROM gets installed on the phones at the factory. This customized ROM might include their boot animation, bloatware, settings (e.g. APNs) for their network. These phones often also have slightly modified hardware: the outer shell badged with the carrier's logo, or in a different "exclusive" colour.

| improve this answer | |
  • So how the manufacturer do it ? I need to know that if the bootanimation.zip file can be created after building the android source or it have to be copied manually. – mrigendra Nov 11 '14 at 13:25
  • 1
    Obviously they change it in the source as part of the build process. – Dan Hulme Nov 11 '14 at 13:28
  • Do you know how, or can point some tutorials on it.. – mrigendra Nov 11 '14 at 13:36
  • I don't expect every company does it the same way. Since this isn't a programming site, and AFAIK nobody here works for a phone manufacturer, I don't think you'll get a more specific answer than that. – Dan Hulme Nov 11 '14 at 13:37

These carrier specific modifications are committed to the source code and are automatically included during the build process through the buildsystem to compile the source code and resources into a factory image (ROM as flashable ZIP-file or whatever format is used for distribution) or software update.

HTC relased an infographic a few years ago illustrating why software updates took so long.

  1. Google provides source code to HTC. HTC evaluates new Android version's requirements.

So Google releases the source code and the manufacturers evaluate which of their devices would be able to run the new software and how profitable it would be for the manufacturer to develop and ship the software update.

  1. HTC assigns people and resources to support development of the new software version […]
  2. HTC begins working with each carrier to define the scope of carrier modifications for that device including apps, services and other requirements.
  3. HTC incorporates carrier modifications to the code.

In point 6 manufacturers like HTC assign staff to work on different work items like device compatibility with the new software, but also developing new features. Which in HTC's case leads to a not very much AOSP-flavoured version Android, but an HTC-flavoured Android.

At first, you would probably ask why a manufacturer would assign people from their staff to work with people from carriers in point 7. The manufacturer spends a lot of resources to create it's own version of Android, but then someone else has a say? That's because to the manufacturer a carrier is a customer with particular demands, who is buying large quantities and most manufacturers measure success with selling large quantities. So assigning and paying a few more people to help carriers with branding devices to sell more devices through contracts to carriers (not to be confused with your carrier contract) suddenly makes sense from the perspective of a device manufacturer.

That's how different people from different companies like software engineers, quality assurance, network operations and marketing staff come together to modify the source code.

The last bit here is to use overlays and similar mechanisms to maintain source code efficiently. So you would have device X and Y, as well as carrier A and B and changes/modifications are committed accordingly. You would just issue the build system to create builds for all possible combinations. This way, if people from marketing of carrier A come up with a new bootanimation.zip and network operations of carrier B found a flaw in how device X behaves in the network you would commit two changes, but be able to build at least three new updated builds (if you didn't find that device Y is also affected). Of course this is oversimplified.

You can download the source code of popular Android custom ROMs to your Linux box peek around and try it yourself. Here is the example for the Nexus 5 from the CyanogenMod Wiki, it's almost the same for all devices up until "Prepare the device-specific code". If you look into the shell scripts that follow after, you get a glimpse of what's going on.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.