The term OTA is most commonly used for wireless updates in mobile phones. An over-the-air update is the wireless delivery of new patches, data or software to mobiles and tablets. Sometimes, the term is also used for updating phone’s firmware and thus called as FOTA (Firmware over-the-air).
Wireless carriers have historically used over-the-air updates to deploy code and put together phones to be used on their networks. The formatting of a freshly purchased phone, as an example, needs an over-the-air update. With the increase of smartphones and tablets, carriers and makers have additionally turned to over the air updates for deploying the new software to those devices.
Starting with iOS 5.0.1, Apple said it would make all iOS updates available over the air. Previous iOS updates required iTunes and a physical connection between the iOS device and a computer.
Similarly, Android devices in the field can receive and install over-the-air (OTA) updates to the system and application software. Devices have a special recovery partition with the software needed to unpack a downloaded update package and apply it to the rest of the system.
LIFE OF AN OTA UPDATE
A typical OTA update contains the following steps:
- The device performs regular check in with OTA servers and is notified of the availability of an update, including the URL of the update package and a description string to show the user.
- Update download to a cache or data partition and its cryptographic signature is verified against the certificates in /sytem/etc/security/otacerts.zip. The user is prompted to install the update.
- Device reboots into recovery mode, in which the kernel and the system in the recovery partition are botted instead of the kernel in the boot partition.
- Recovery binary is started by init. It finds command-line arguments in /cache/recovery/command that point it to the downloaded package.
- Recovery verifies the cryptographic signature of the package against the public keys in /res/keys (part of the RAM disk contained in the recovery partition).
- Data is pulled from the package and used to update the boot, system and/or vendor partitions as necessary. One of the new files left on the system partition contains the contents of the new recovery partition.
- Device reboots normally.
- The newly update boot partition is loaded, and it mounts and starts executing binaries in the newly updated system partition.
- As part of a normal startup, the system checks the contents of the recovery partition against the desired contents (which were previously stored as a file in/system). They are different, so the recovery partition is reflashed with the desired contents. (On subsequent boots, the recovery partition already contains the new contents, so no reflash is necessary.)
Source: Google Android