Thursday, June 11, 2009

The Android boot process from power on

Since mobile platforms and embedded systems has some differences compared to Desktop systems in how they initially start up and boot this post will discuss the initial boot stages of an Android phone in some detail. Since we have used the Beagle Board as reference in some previous examples any specifics here are related to a similar system.

1. Power on and boot ROM code execution
At power on the CPU will be in a state where no initializations have been done. Internal clocks are not set up and the only memory available is the internal RAM. When power supplies are stable the execution will start with the Boot ROM code. This is a small piece of code that is hardwired in the CPU ASIC. For more information on boot ROM and configurations study the initalization chapter in
the Omap 3530 TRM.
  • A. The Boot ROM code will detect the boot media using a system register that maps to some physical balls on the asic. This is to determine where to find the first stage of the boot loader.
  • B. Once the boot media sequence is established the boot ROM will try to load the first stage boot loader to internal RAM. Once the boot loader is in place the boot ROM code will perform a jump and execution continues in the boot loader.
2. The boot loader
The boot loader is a special program separate from the Linux kernel that is used to set up initial memories and load the kernel to RAM. On desktop systems the boot loaders are programs like GRUB and in embedded Linux uBoot is often the boot loader of choice. Device manufacturers often use their own proprietary boot loaders. The requirements on a boot loader for Linux running on an ARM system can be found in the Booting document under /Documentation/arm in the kernel source tree.

  • A. The first boot loader stage will detect and set up external RAM.
  • B. Once external RAM is available and the system is ready the to run something more significant the first stage will load the main boot loader and place it in external RAM.
  • C. The second stage of the boot loader is the first major program that will run. This may contain code to set up file systems, additional memory, network support and other things. On a mobile phone it may also be responsible for loading code for the modem CPU and setting up low level memory protections and security options.
  • D. Once the boot loader is done with any special tasks it will look for a Linux kernel to boot. It will load this from the boot media (or some other source depending on system configuration) and place it in the RAM. It will also place some boot parameters in memory for the kernel to read when it starts up.
  • E. Once the boot loader is done it will perform a jump to the Linux kernel, usually some decompression routine, and the kernel assumes system responsibility.
3. The Linux kernel
The Linux kernel starts up in a similar way on Android as on other systems. It will set up everything that is needed for the system to run. Initialize interrupt controllers, set up memory protections, caches and scheduling.
  • A. Once the memory management units and caches have been initialized the system will be able to use virtual memory and launch user space processes.
  • B. The kernel will look in the root file system for the init process (found under system/core/init in the Android open source tree) and launch it as the initial user space process.
4. The init process
The init process is the "grandmother" of all system processes. Every other process in the system will be launched from this process or one of its descendants.

  • A. The init process in Android will look for a file called init.rc. This is a script that describes the system services, file system and other parameters that need to be set up. The init.rc script is placed in system/core/rootdir in the Android open source project.
  • B. The init process will parse the init script and launch the system service processes.
5. Zygote and Dalvik
The Zygote is launched by the init process and will basically just start executing and and initialize the Dalvik VM.
6. The system server
The system server is the first java component to run in the system. It will start all the Android services such as telephony manager and bluetooth. Start up of each service is currently written directly into the run method of the system server. The system server source can be found in the file frameworks/base/services/java/com/android/server/ in the open source project.

7. Boot completed
Added this part to the post on 20090831 since it is very useful and something I should not have left out from the beginning. Once the System Server is up and running and the system boot has completed there is a standard broadcast action called ACTION_BOOT_COMPLETED. To start your own service, register an alarm or otherwise make your application perform some action after boot you should register to receive this broadcast intent.

The separate boot steps and possible places to add your own functionality are covered in more detail in separate posts.



  1. Hi,
    It's really help full. Good explanation i got.
    I want to ask one more thing...?
    Can you tell me, what are the files I need to look into, while mobile is booting??


  2. Hi RK,
    I sent you an e-mail about this if you are still interested. Apologies for missing this comment, the blog was left drifting a bit during vacations here in Sweden.

    Basically if you want to know what is being started on the native level init.rc is the place to look. Binaries for these services are kept in system/bin on the device. For system server threads one actually have to look at the source directly, see my post on this.

    If there was something else you where aiming for please respond to my e-mail and I will update here.

    /Mattias - Enea Android team

    1. Hi,
      Can you send the e-mail on boot time optimization , u-boot related articles to my email id :

      Regards ,

    2. Hi Mattias,

      If you could also email me about the files that I need to look into, while mobile boots up, I would be thankful to you.



  3. i got over all information from this link but i need more information about system server in android, and dynamic package or library loading in android....

  4. If I want to add a new Android System Server service, how do I go about doing this ? This service needs to be accessible from the application. What is the interface to be provided to application ? I am new to Android framework, any basic information on how a android system server service works and integrates with an app will help.

  5. My recommendation about expanding the services in the System Server would be to study the way it is done by the default services. There is some info in the post from July about the system server. The file to start from would be frameworks/base/services/java/com/android/server/ in the open source project.
    Basically this is something you would only want to do if you are working with your own device and for some reason must include the functionality directly in the system server.

  6. Mattias,Thanks for your response. Is anyone from Enea working on a post that gives information on adding a new service to and accessing it from application ?

  7. We have done some work on this before and I talked to a colleague who was willing to write a post about it. I hope we will be able to put it up shortly.
    Once again a word of caution about modifying the base framework since it may lead to a lot of maintenance later on. Keep your changes small and try to separate the code for your service as much as possible.

  8. Thanks Mattias. Looking forward to that post from your colleague. Yes I agree that it's lot of work if framework code is changed.

  9. Hi Mattias, first of all thanku very much for a very good explanation on core things to know for a early bird android enthusiast like me, few more things i want to know, i have cell phone with ARM11 434Mhz processor, how to create a boot loader or where to find one for ARM, may be i need ARM compiler as well.

    Thanks -- DJ

  10. Hi Deepak,
    In general it is quite tricky to create a boot loader for an existing phone since they often come with tailor made boot loaders from the manufacturer. To add to the difficulty they also have security features that aim to prevent you from downloading your own bootloader.
    However, if you have an open platform you need an initial bootloader stage and a main bootloader able to start and/or flash software to the device.
    For the main bootloader you probably want to check out u-boot, The initial bootloader stage needed to start u-boot need to be aware of the boot-protocol in the hardware requiring some documentation or reverse engineering in order to create or download a suitable one.
    To sum things up reprogramming of existing phones is often more work than its worth unless you are really interested in which case there are a lot of forums dedicated to that sort of thing.

  11. Hi,

    Really a good Artical for a fresher to know about the basic of boot process in Android.


  12. Hi Mattias,

    Really wonderful article explaining about the android boot process.Thank you

  13. Really helpful article!!
    Thank you very very much!
    Saved me so many hours of research.

  14. hi, i try to modified init.rc file.
    but why, init.rc always back like before edit after reseting phone.
    even i tried to delete init.rc, the file always be in the folder after reseting phone too..

    can you explain this??

  15. Hi

    I need to launch and start the activity from an external Java App. I dodnt want to lauch it using through Process commuication, but as Java Object. Is there any way to do it.


  16. Hi,
    About modifying the init.rc file there are a few things to be aware of. In the case of the emulator and the Android open source project there are two ways to do this. For testing purposes one possibility is to just modify the init.rc file generated by the build system in out/target/product/generic/root and then only generate a new system image by running "make snod". This modification will only last until you rebuild the platform.
    For more permanent changes modify the original init.rc in the source (system/core/rootdir) and rebuild the platform. The tricky thing about the build system is the it sometimes caches the system image used by the emulator requiring a make snod for it to show up.
    For any modifications of the init.rc file you need to restart the emulator with an image containing the new init.rc file since it is being parsed during boot.

    When working with init.rc on an actual device it may be even more tricky. It works fine to modify it on the dev boards I have tried but if you are using an off-the-shelf phone then there may be safeguards in place. This is speculation on my side but it may be of the form that there is some monitoring system in place the checks for changes to critical system files and replaces them with the original in tampering is detected. In general you should be fine if you are able to get your modified init.rc into the system image when rebooting however.

    For James comment I don't really understand the question. Are you looking for a way to launch activities without using intents or broadcasts?

    /Mattias - Enea Android Team

  17. Mattias, thanks for this post. More than 1 year on and it's still helping newbies (like me!).

    I've only started 2 days ago to look at Android so excuse the noob questions, and inevitable misunderstandings :)

    To me, from your explanation, it's looking like Android is actually a stack of code culminating in the Dalvik VM, ie a linux kernel that is essentially bootstrapping a java platform, and providing it with low level stuff (ie phone modem etc).

    1. Does this actually mean that one could relatively easily port Dalvik over to another OS ie for the sake of argument, a FreeBSD kernel. Or is Dalvik way too intertwined with the underlining linux kernel and associated code (I don't know what init on android loads, and what Dalvik expects to find!).

    2. Because of Dalvik, does this mean that practically everything has to be written in (google/android flavoured) Java?

    I know you can link c-code to call but is it practically possible to write an app (ie a game) in C? Where would I go to find out?

    3. Could I trouble you for one last question? What is the best place to ask these sorts of questions? I am assuming the official google android forums would be one such place, but are there others you'd recommend?

    Thanks very much in advance


  18. Hi,
    Your description of Android as a stack of Linux userspace code that is there to support and run the Dalvik VM is relatively accurate at first glance. This is however a simplified way of viewing Android and the idea that "it is just Linux with a Java VM" is not true. There are modifications in the kernel and c-runtime (Android uses its own c-library) that makes direct porting of code problematic sometimes. There are also a lot of native support libraries that are used from the Android application level through JNI calls. So to answer your questions:
    1.) A limited port of Dalvik to some other OS is relatively straight forward. Dalvik itself does not depend very much on the Linux kernel. That said, all of the native libraries and support services that make up the full application API:s may take some effort to port. Just to mention a few examples you need matching versions of webkit, sqlite, codec support and so on. Implementing the Binder IPC mechanism that Android uses is another challenge.

    2.) Most things with a UI will have to written in Android flavored Java, the exception being if you use OpenGL calls directly. But the way Android is set up a number of applications only use Java as a UI interface layer for functionality written in C or C++. The platform supports this through the Native Development Kit. I would recommend checking out the NDK pages on the Google developer site to get started on how to use this.

    3) The official android mailing lists on google groups is a good place for questions and information. Stack overflow is also very active on Android development and a place where you can find a lot of information if you search a little.


  19. thanks, It was really helpful to understand android booing steps.

  20. Hey!
    How to prevent some services such as google map from starting on OS boot up.

  21. Is the address space pointing to the boot rom code (what is run before the boot loader) available after the linux kernel is running?

    i.e., is there any conceivable way to read the boot rom code ?

  22. On ARM, does the rom, boot code and Linux run in Thumb 2 mode ? Or does it depend on the make of device and linuc version eg some documentation suggests need 2.6.38 or later for Thumb 2

  23. The Android emulator seems to imply need Android 4.0 for Armeabi-v7a support

  24. This comment has been removed by the author.

  25. Step 2D It will load this (the Linux kernel) from the boot media ... and place it in the RAM

    What 'file' is the Android linux kernel, and where is it?
    Was expecting to see it as a file in / or in /system, but cant find it

  26. carl4lvj question about accessing the boot code
    cat /proc/mtd seems to show some related stuff
    see also

    and various romdump programs

  27. Answer to the Step 2D question about the linux kernel.
    It is the ZImage (zImage.debug) file that come with updated firmware (a self extracting gzipped kernel)
    It is NOT stored in the actual root filesystem
    It is (usually) stored and booted from a special partition of the NAND / MTB
    usually /dev/mtd2

  28. Other good article on ANdroid linux boot

  29. A couple of questions here that I have not answered, better late than ever...
    First @FD_point:
    Google maps is not started from init but launched like a regular application more or less. If you have control over the device simply remove services that you do not need either from the system image when building or from the init.rc script if you do not want them managed by init. If you are asking about removing bundled applications from a production phone that is a different topic altogether...

    Next @carl4lvj:
    Boot rom access is very chip maker dependent. Normally the boot rom address space is protected in some way, especially on secure production devices. Some boot roms expose parts of the address space to allow software to use routines from it.

    And @xsoliman:
    Regarding thumb or arm mode I have not done any particular study but I would assume it depends on architecture and version as you say. On newer cortex platforms I believe it is Thumb2.
    Regarding files and partitioning the boot loader and kernel are stored in a separate partition on the boot media as you say. This is because the initial boot stages are not able to run a full file system and need a more direct approach to finding the executables to load. In general you need the following files to fully flash an android device: first stage loader, loader, kernel image, system image, data image.
    First stage loader may sometimes be a separate files, sometimes it is bundled with the main loader. Loaders and kernel are placed in a boot partition of the nand that is normally not visible from Androids point of view. The system and data images are full file system images that are placed in their respective partition on the nand/eMMC.

  30. Theres some good videos on YouTube about Android Internals (incl boot)

  31. Nice article Thank You Very Much

  32. hi mattis,
    can u please tell me the separate boot steps and possible places to add your my functionality after the boot intent is broadcasts.

  33. Nice document. Good for Android newbie leike me..
    I just wonder, if there are some log tool can be used to capture the boot log from very beginning, for exp, from bootloader running(rather than ADB captured Androind runtime log)? this maybe a practical for us to further understand what happen there during boot?
    Is such a tool only avaliable from each platform vendor?

  34. Hi,
    I am working on a project wherein I need to determine the memory requirements of phones dynamically while booting and allocate the memory in that way. I also want to preset the register contents while loading the stub. Also that if there are two different devices with different memory allocation how can i allocate the memory to them ( Eg. If one device 512 Kb and its booted on a 1Mb memory space what should I do with the remaining 512 Kb left over space i.e. how do I flag it for other uses).


  35. Regarding the last couple of questions:
    Getting log events out from the very beginning is usually very hard, or near to impossible since the first steps of the bootloader run in a very constrained environment. When developing these things hardware debuggers are often used to get data out of the system instead of some serial channel. Even though a lot of loaders set up some kind of log system as early as possible they will still vary between loaders and devices. To get more info on that my suggestion would be to check the mod forums for the specific hardware you are interested in. On a development board it may be possible to use a modified bootloader to get more info out.

    @SJ I am not sure I understand exactly what you are after but one of the tasks of the bootloader is to probe for external memory and pass that info on to the operating system. Exactly how this is done depends on hardware platform and boot loader design.

  36. Hey Mattias,
    As we know Android does not have X Window System that is generally started as default by init. If android doesnt have XWS, then what does init start first? Can you list the runlevels in order run by init on Android?


    P.S: GR8 work!

  37. When we boot into recovery in android what does the bootloader load first...kernel or recovery partition?

  38. Is there a possibility to boot Android in single-user mode? It seems that there are some software application/services that have tested (as required by FIPS140-2 standard) on various versions of Android booted up in "single-user mode".

    Samsung and Cisco are two that claim they have tested their application on Android single-user mode:

  39. Good article but what happens when you press volume up/down+power button together? How does processor goes straight to recovery partition? What will be the sequence then?. You didn't cover this scenario.

  40. Hi Mattias
    There is an issue i am facing, the time take for boot up has gone up in the latest kernel(3.4) from the previous one, i have to debug why this has happened. Can you tell me how can i look into this issue, and how do i get the required logs for analysis. Will looking into init.rc and bugreport be enough?
    Avinash Rao

  41. Hi Mattias,
    Is that possible to have some delta compare between Android and the Desktop OS (for exp, Linux)? That would be more interesting..Thanks.

  42. Hi Mattias,

    Which step detects if a touch screen is connected?


    1. Robert,
      The touch screen, as well as all other input devices and displays, are activated by their respective device driver.

      For a touch screen, which is probably always connected, the device driver is loaded in step 3 (The Linux kernel) for a statically linked driver, or step 4 (init), for a load module.

      Devices that are plugged in at runtime (hotplug) are detected by a hotplug event, which in turn triggers the loading. Please note that not many devices are supported by vanilla Android.

      /Robert, on behalf of the Xdin Android Comepetence Center.

    2. Thanks so much for the helpful reply. I want to make a device by transforming an android phone and need to remove the touch screen. But after I removed the touch screen, android couldn't boot up. Can I disable touch screen check by simply modifying any configuration file or need to modify the kernel/init source code? Could you provide any suggestion?


  43. Hi
    Can anybody tell me about security in this booting process. In iOS each step of the boot-up process contains components that are cryptographically signed by Apple o ensure integrity, and proceeds only after verifying the chain of trust.
    So in android do we have something like that for verification ?

    1. Anuj,
      The most critical parts from a security point of view is step 1 and 2. Lack of security here opens up for the possibility to boot another kernel, or perhaps manipulate the kernel in some way.
      The scenario you describe is a very typical way to deal with security, and almost all phone vendors do it in a similar way (although the exact details are well-guarded secrets).

      Also note that step 1 and 2 are not really part of Android. These steps contain program code that execute before any parts of Android is started. A secure bootloader is not provided by Android and is not required. You will often see u-boot being used when working on open Android systems, such as development boards like Panda and Beagle.

      /Robert, on behalf of the Xdin Android Competence Center.

  44. This comment has been removed by the author.

  45. Hi,
    I have one confusion. In BIOS system, first it copies the MBR(first sector) of the HDD to the RAM and then it will load the boot loader. If I am trying to boot android from SD card, will it read the first sector before copying the primary boot loader(MLO)?

  46. Can you tell me what part of the sequence loads of the bootanimation and why some ROMS have boot audio and some do not?