Implementation of Android based set-top box

Implementation of Android based set-top box

This paper gives an overview of extending Android system with the Disaster Recovery Agent (DRA). The focus of this paper is on switching from bad, critical system state to working, default system state. Adding this feature involves changing existing bootloader and recovery of Android.

Android comes with default, stock recovery console which is very limited. Its main purpose is to perform system updates and wipes user data. Source code of Android is open and has the recovery source code available, so there is a possibility of making custom recoveries. These custom recoveries offer more tools than stock recoveries. Backup and restore, selective deletion of data, mounting various partitions and much more is available using these recoveries. However, there is no recovery which offers automatic system restore when system is corrupted. Our DTV (Digital television) set-box solution runs on Android OS[1], and we need fully automated system update and system recovery. In order to achieve that we have customized stock recovery and developed Disaster Recovery Agent (DRA). In our Android system, Disaster Recovery Agent refers to the dedicated, bootable partition that has DRA console installed. This partition will boot in case of unstable or corrupted system state, and DRA console will be started. Whole DRA system is fully automated, and no user interaction is needed. CodeShoppy

DRAFROMBOOTLOADERANDBOOTLOADERCHANGES Starting the Disaster Recovery Agent, or more precisely checking if there is a need to start Disaster Recovery Agent has to be performed during the Android startup sequence. During the Android startup sequence it is easy to find out if there is a bad behavior of important elements of Android OS which can cause Android OS failure. Two processes of Android startup sequence initializes and start these important elements of Android OS. The first process is a system program that loads and starts the operating system – Bootloader, while the secondprocess is a program that performs initialization and run elements of the Android OS – init program. Bootloader is code that is executed before any Operating System starts to run. Bootloader sets the instructions to boot an operating system. Every Android device has a bootloader that instructs the operating system kernel [2] to boot normally. There are five steps in bootloader workflow: 1)Configure pinmux for UART and NAND 2)Load and verify System Manager, kick off System Manager 3)Load and verify Linux 4)Send message to System Manager to indicate Linux boots up 5)Start Linux Kernel First critical point of this workflow is “Load and verify Linux” step. In this step boot and kernel image should be loaded. If some error occurs here, system will not be able to boot. In order to avoid system boot failure, we have added error checking subsystem here which will initiate proper actions if an error occurs. At starting point, bootloader is in normal boot mode and tries to load and verify boot and kernel image. If bootloader fails it will set flags for DRA boot mode, and notify system manager about failure, and the boot mode change. Then DRA will be loaded in step “Load and verify Linux”.

DRA FROM SYSTEM INITIALIZATION AND INIT PROGRAM CHANGES One key component of the Android bootup sequence is the program “init”. This is program which initialize elements of Android system. The Android “init” program processes two files and executes all the commands it finds in them. The first file is the “init.rc” and the second one is the “init.{nameofmachine}.rc”, where “nameofmachine” is the code word for the hardware that Android OS is running on. The file “init.rc” is used for general initialization, and “init.{nameofmachine}.rc” is used for machine-specific initializations. If some crucial part of initialization fails to execute, the system will not boot and probably get caught in a “boot loop”. “Boot loop” is an endless rebooting process caused by the boot failure.The “Boot loop” failure is avoided with the boot failure counter and Disaster Recovery Agent. If a system fails to boot for a specific number of times, it is rebooted with DRA parameters for boot. Changes made in the “init” program are related to a signal handler [3] of the “init” program. Signal handler of the “init” program is realized to wait for the SIGCHLD signal. The SIGCHLD signal is sent to the parent of a child process when it exits, is interrupted, or resumes after being interrupted. The “init” program represents parent process, while all programs and elements which “init” program initializes and starts represent child processes. If a SIGCHLD signal for some program from initialization process is caught, a crash counter is increased. If this crash counter reaches a specific value, a reboot command with DRA specific parameters will be executed.

 Implementation of Android based set-top box
https://codeshoppy.com/php-projects-titles-topics.html