Android is the world's most used operating system and as an end mobile user, we are very familiar with Android. We often get OTA updates to our Android device. Some of them are minor updates and some are major. The minor updates may include the patches that are intended to address the flaws in the device like over heat from the device, optimize battery consumption or update firmware etc.
Android version numbering nomenclature:
If we observe the OS version under "Settings" of our mobile phones, we can see the version as 6.0.1 for Android M devices. The preceding Android version is 5.2.2, which is the last version in Lollipop. Here, the change from 5.x to 6.x is a major update from Lollipop to Marshmallow and the change from 6.0.0 to 6.0.1 or to 6.0.2 is a minor update fixing the bugs. Suppose that the Marshmallow version on you mobile changes from 6.1 to 6.2, then this is a medium updates i.e., it may include functionality updates or some other UI updates.
All these updates are released by Google and the user gets a prompt to update the device software, which is scheduled on the basis of regions. These updates are easy to be delivered to the device, as they belong to the same build version of the OS, and they are minimal in size. But coming to the major updates, the scenario completely changes, as it is a complete change in the build of the operating system. On the other hand, these major updates are very high in size.
Every operating system comes in the form of an image, which essentially consists of three parts - a boot loader, a root file system (RFS) and a kernel. Also, every operating system has three layers - kernel layer, application layer and the user interface layer. The so-called Google's stock Android has the kernel layer of UNIX, and the application layer and the user interface layer developed by Google. But, every mobile vendor has their own variant in Android. These variants come by customizing the application layer and the user interface layer. This the reason fo which the same Android look a like in Samsung, another like in Asus and different vendors have different UIs.
What is a build?
A build is simply the image file that installs an operating system onto the device. As mentioned earlier, it has a boot loader, an RFS and a kernel. Upon the kernel sits the customization/optimization by the vendor. Every build has a life cycle and this article is about the life cycle of an Android Major update release.
Life Cycle of Android Release:
Google follows five-step life cycle to deliver updates to the user as mentioned in the image below.
Here is an example that you can relate to this life cycle. Let's take the example of Nexus 5 getting a Marshmallow update from Lollipop.
If we observe the OS version under "Settings" of our mobile phones, we can see the version as 6.0.1 for Android M devices. The preceding Android version is 5.2.2, which is the last version in Lollipop. Here, the change from 5.x to 6.x is a major update from Lollipop to Marshmallow and the change from 6.0.0 to 6.0.1 or to 6.0.2 is a minor update fixing the bugs. Suppose that the Marshmallow version on you mobile changes from 6.1 to 6.2, then this is a medium updates i.e., it may include functionality updates or some other UI updates.
All these updates are released by Google and the user gets a prompt to update the device software, which is scheduled on the basis of regions. These updates are easy to be delivered to the device, as they belong to the same build version of the OS, and they are minimal in size. But coming to the major updates, the scenario completely changes, as it is a complete change in the build of the operating system. On the other hand, these major updates are very high in size.
What is a build?
A build is simply the image file that installs an operating system onto the device. As mentioned earlier, it has a boot loader, an RFS and a kernel. Upon the kernel sits the customization/optimization by the vendor. Every build has a life cycle and this article is about the life cycle of an Android Major update release.
- Always remember that the kernel is modified very rarely.
Life Cycle of Android Release:
Google follows five-step life cycle to deliver updates to the user as mentioned in the image below.
 |
| Life cycle of Android release Image source: android-developers.googleblog.com |
- The Android developers team works on the projected modifications/upgrades/optimizations in the existing build. These changes may be in any/all the layer(s) of the operating system. After the final image is built, Google announces and exhibits in Google I/O. Later, this build is released to the silicon manufacturer partners.
- The silicon manufacturer partners develop a package called Board Support Package (BSP) for a given board. All the mobile manufacturers do not use the same chipsets. As the operating system needs to be hardware-specific, the respective firmware is developed by the silicon manufacturers and is integrated into the build released by Google.
- The build released by the silicon manufacturers is collected by the mobile manufacturers and modifies/optimized them based upon their requirement - modifying the UI, changing the default apps, developing vendor-specific apps etc.
- The build from mobile manufacturers is collected by the carriers for testing and certification of the build with their carrier and for delivering to the user later.
- Once the user gets the prompt for update and updates the device software, the user if up-to-date.
Here is an example that you can relate to this life cycle. Let's take the example of Nexus 5 getting a Marshmallow update from Lollipop.
- The Android developers release a Marshmallow build for update, to its silicon manufacturer Qualcomm.
- Qualcomm generates the BSP based upon the architecture and implementation of the Qualcomm MSM8947 Snapdragon 800 chipset. This build is specific to Snapdragon 800 hardware.
- As Nexus is a Google product, all the application and UI changes will be take care by Google itself. Most probably, all these changes will done in the initial stages itself. If the product is from any other vendor like Samsung, they modify the UI and replace/modify with their specific apps.
- The build from vendor is collected by the carriers like AT&T and certifies them after verification. Once the verification is done, then they are released to the end user OTA.
- Once the device is updated, the user can experience the new version of Android.
Google is trying to eliminate some of these steps under the Project Treble, in order to reduce the vendor implementation.
