Want to know how your Android Device Starts? then continue reading this article. The Android operating system has a complex and multistage start-up routine. Manufacturers lock the start-up process to protect revenue and maintain control of the device you purchase. The nature of the Android start-up process allows developers and hackers to replace parts of it to achieve full control of an Android device. Below in detail i explained How your Android Device Starts.
How your Android Device Starts
Table of Article Contents
Bootstrapping (or booting) is a term that describes what a computing device does when turned on. It “pulls itself up by its bootstraps.” When you power on an Android device, a tiny piece of code on a memory chip initializes the memory and CPU. Usually the bootstrap code is referred to as the bootloader. The bootloader is different from device to device, although all bootloaders do the same things: they check for hardware features and load the first part of the operating system into the device’s memory.
The encrypted bootloader is the beginning of all things Android, effectively locking out the user from customizing the firmware and software. Locking the bootloader is the rough equivalent to a computer manufacturer forcing you to use a particular version of Windows, along with a theme of their choosing. The bootloader is the primary point of contention between owners of mobile devices and the original equipment manufacturer (OEM). Many, if not most, OEMs specifically do not want you to have access to that bootloader code.
The reasons that OEMs do not want users to have access to this code are varied but fall into the following categories –
The cost of honoring warranties
Altering the bootloader code can permanently disable the device. This is problematic for device manufacturers because broken devices are returned to them under warranty. It is difficult to determine if a device is broken because the user did
something silly to it or if it is, in fact, defective. This means that the manufacturer may have to replace a device that became defective through no fault of the manufacturer. Replacing defective devices costs money and those costs may be passed on to the consumer.
The need to protect carrier agreements
Carriers are paid to pre-install applications from third parties on devices. Many organizations, from car rental companies to streaming video startups, have a mobile application. To get exposure for their products, they pay carriers to include those applications on your device; to ensure that exposure, the carrier blocks the user’s ability to remove the application. After all, it simply wouldn’t do to have Blockbuster pay hundreds of thousands of dollars to have their application on your device only to have you remove it to make room for Angry Birds three minutes after you walk out of the store. Locking the bootloader allows carriers and OEMs to declare some applications as “system” applications. This removes them from typical management tasks, such as deletion or moving them to an SD card.
Devices with a very long life are bad for OEMs. The development and release cycle of new mobile devices has become incredibly fast, outpacing even old standards in technology. When a device is released, the device that will obsolete it is often already in production. Android operating system updates have new features and stability that users desire. Because OEMs depend on selling new features and the latest Android operating system, they need consumers to want the newest devices. Allowing consumers to update the operating system and software themselves effectively reduces the need to purchase the latest device from the OEM or carrier.
In essence, planned obsolescence from the carriers and OEMs is designed to make the consumer spend more money to get the latest Android updates. If you can hack those updates into the perfectly good device you purchased six months earlier, the OEMs lose money.
When you power on an Android device, the bootloader is the first program code that runs. Bootloading is typically a two-part process, utilizing a primary and a secondary bootloader. On most Android devices, the primary bootloader cannot be replaced. This is because the primary bootloader is hardcoded into an application-specific integrated circuit (ASIC) in the device. These hardcoded instructions load the secondary bootloader into memory and tell it where the memory, CPU and operating system are located and how they can be accessed. If you still confused about bootloader then read my another post on UNDERSTANDING THE BOOTLOADER PROCESS OF ANDROID IN DETAIL