Posts

Android OTA [Seamless] Update Overview [Part2] - Detailed Analysis of OTA[A/B] Update

Image
Detailed Analysis In the previous tutorial we saw an overviw of the OTA [A/B Based] Update mechanism introduced by Android and mandated after Android 11. Changes to Android Makefiles for enabling Android A/B OTA Updates With the introduction of A/B style of updates, The device manufacturers must make changes to the existing Compilation and Flashing steps. Let us have a look at them below. For the present analysis, Let us use the Google’s Marlin device as an example. https://android.googlesource.com/device/google/marlin/+/android-7.1.1_r6/marlin/BoardConfig.mk A/B MUST Define Flags Variables that the system must define AB_OTA_UPDATER := true AB_OTA_PARTITIONS := boot system vendor BOARD_BUILD_SYSTEM_ROOT_IMAGE := true #Put the boot ramdisk in the system partition TARGET_NO_RECOVERY := true BOARD_USES_RECOVERY_AS_BOOT := true #Put the recovery ramdisk in the boot.img file PRODUCT_PACKAGES += update_engine update_verifier

Android OTA [Seamless] Update - Overview of OTA[A/B] Update

Image
Introduction Let’s accept it, We all love our devices and would like to have them updated with the latest and greatest OS/SW, However there are times when we don’t want to switch off these devices and want them to be updated in the background seamlessly and the new update to be available to us when we restart the device next time. This also is very important factor which largely is driven by the amount of time it takes for the OS/SW to be updated. The below is shamelessly copied from Google’s Introduction to OTA or A/B updates. A/B (Seamless) System Updates A/B system updates, also known as seamless updates, ensure a workable booting system remains on the disk during an  over-the-air (OTA) update . This approach reduces the likelihood of an inactive device after an update, which means fewer device replacements and device reflashes at repair and warranty centers. Other commercial-grade operating systems such as  ChromeOS  also use A/B updates successfully. For mor

Android Memory Overview [Part2] - Android LMKD

Image
Introduction In the last tutorial we saw the need and a high level overview of the Low Memory situations and different ways to understand and assign the processes a score which can be used to kill/not kill them when low mwmory conditions happen. Android uses lmkd [LowMemoryKiller Daemon] running in userspace to determine a low memory condition and kill processes as necessary. Let us see the details of the lmkd implementation. Android Low Memory Killer Daemon – Detailed Walkthrough. Android LowMemoryKillerDaemon Startup When Android’s init process parses init.rc, We can see that the memcg [memory cgroup] is initialized Again, Moving further the init.rc starts the lmkd service process. The source for the lmkd is located in  platform/system/memory/lmkd. https://android.googlesource.com/platform/system/memory/lmkd/ Let us look at the main function of the lmkd with some important items marked.