How android works. Wearable electronics and home appliances

27.04.2019 Mistakes

How Android Works

Learn about hidden opportunities software systems You can understand how they work. In some cases, this is difficult to do, since the system code can be closed, but in android case we can study the whole system inside and out. In this article, I will not talk about all the nuances of Android and will focus only on how the OS starts up and what events take place between pressing the power button and the appearance of the desktop.

Along the way, I will explain what we can change in this chain of events and how custom firmware developers use these features to implement things such as tuning OS parameters, expanding application storage space, enabling swap, various customizations, and much more. All this information can be used to create your own firmware and implement various hacks and modifications.

Step one. U-BOOT and partition table

It all starts with the primary bootloader. After the power is turned on, the system executes the bootloader code stored in the device's permanent memory. Most often, its role is played by modified version u-boot bootloader with built-in support for the fastboot protocol, but the manufacturer of the mobile chip or smartphone / tablet has the right to choose any other bootloader to his taste. For example, Rockchip uses its own non-fastboot bootloader, and they have to use proprietary tools to reprogram and manage it.

The fastboot protocol, in turn, is a bootloader management system from a PC that allows you to perform actions such as unlocking the bootloader, flashing a new kernel and recovery, installing firmware, and many others. The point of fastboot is to be able to restore the smartphone to its original state in a situation where all other means fail. Fastboot will remain in place even if, as a result of experiments, you erase all the contents of all sections of NAND memory from your smartphone, losing access to both Android and recovery.

Having received control, u-boot checks the partition table and transfers control to the kernel flashed into the partition named boot, after which the kernel extracts the RAM image from the same partition into memory and starts loading either Android or the recovery console. NAND memory in Android devices is divided into six conditionally mandatory sections:

boot - contains the kernel and RAM disk, usually around 16 MB in size;
recovery - recovery console, consists of a kernel, a set console applications and settings file, size 16 Mb;
system - contains Android, in modern devices it has a size of at least 1 GB;
cache - designed to store cached data, also used to save the firmware during an OTA update and therefore has a size similar to system section;
userdata - contains settings, applications and user data, all remaining NAND memory space is allocated to it;
misc - contains a flag that determines in which mode the system should boot: Android or recovery.

In Linux terminology, a RAM disk is a kind of virtual hard a disk that exists only in RAM. At an early boot stage, the kernel extracts the contents of the disk from the image and mounts it as a root file system (rootfs).

In addition to them, there may also be other sections, however, the general markup is determined at the design stage of the smartphone and, in the case of u-boot, is sewn into the bootloader code. This means that: 1) the partition table cannot be killed, since it can always be restored using fastboot commands oem format; 2) to change the partition table, you will have to unlock and reflash the bootloader with new parameters. There are exceptions to this rule, however. For example, the bootloader of the same Rockchip stores partition information in the first block of NAND memory, so flashing the bootloader is not needed to change it.

Particularly interesting is the misc section. There is an assumption that it was originally created to store various settings independent of the main system, but in this moment is used for only one purpose: to tell the bootloader which partition to boot the system from - boot or recovery. This possibility, in particular, uses the application ROM manager for automatic reboot systems in recovery with automatic firmware installation. On its basis, the mechanism dual boot Ubuntu Touch, which stitches Ubuntu bootloader

in recovery and allows you to control which system to boot next. Erase the misc partition - Android is loaded, filled with data - recovery is loaded ... that is, Ubuntu Touch.

Part of the bootloader code that defines the partition table:

static struct partition partitions = ( ( "-", 123 ), ( "xloader", 128 ), ( "bootloader", 256 ), /* "misc" partition is required for recovery */ ( "misc", 128 ), ( "-", 384), ( "efs", 16384 ), ( "recovery", 8*1024 ), ( "boot", 8*1024 ), ( "system", 512*1024 ), ( "cache" , 256*1024 ), ( "userdata", 0 ), ( 0, 0 ) );

Step two. boot partition

If the misc section does not have a boot to recovery flag, u-boot transfers control to the code located in the boot section. It is nothing but the Linux kernel; it is located at the beginning of the section, and immediately after it is a RAM disk image packed using cpio and gzip archivers, containing the directories necessary for Android to work, the init initialization system, and other tools. There is no file system on the boot partition, the kernel and RAM disk just follow each other. The content of the RAM disk is:

data - directory for mounting the partition of the same name;
dev - device files;
proc - procfs is mounted here;
sbin - a set of auxiliary utilities and daemons (adbd, for example);
res - a set of images for the charger (see below);
sys - sysfs is mounted here;
system - directory for mounting the system partition;
charger - an application for displaying the charging process;
build.prop- system settings;
init - initialization system;
init.rc - settings of the initialization system;
ueventd.rc - settings for the uventd daemon included in init.

This is, so to speak, the skeleton of the system: a set of directories for connecting file systems from NAND-memory partitions and an initialization system that will take care of all the rest of the work of booting the system. The central element here is the init application and its init.rc config, which I'll cover in more detail later. In the meantime, I want to pay attention to the charger and ueventd.rc files, as well as the sbin, proc and sys directories.

The charger file is a small application whose only job is to display a battery icon. It has nothing to do with Android and is used when the device is connected to the charger in the off state. In this case, Android does not boot, and the system simply boots the kernel, connects the RAM disk, and starts the charger. The latter displays the battery icon, the image of which in all possible states is stored in regular PNG files inside the res directory.

The ueventd.rc file is a config that defines which device files in the sys directory should be created at the system boot stage. In kernel-based Linux systems hardware is accessed through special files inside the dev directory, and the ueventd daemon, which is part of init, is responsible for creating them in Android. Normally, it works in automatic mode, accepting commands to create files from the kernel, but some files need to be created by yourself. They are listed in ueventd.rc.

sbin's directory stock Android usually contains nothing but adbd, that is, the ADB daemon, which is responsible for debugging the system from the PC. It starts at an early stage of OS boot and allows you to identify possible problems at the stage of OS initialization. In custom firmware, you can find a bunch of other files in this directory, such as mke2fs, which may be required if partitions need to be reformatted to ext3/4. Also, modders often put a BusyBox there, with which you can call hundreds of Linux commands.

During the boot process, Android displays three different boot screens: the first one appears immediately after pressing the power button and is flashed into the Linux kernel, the second one is displayed during the early stages of initialization and is written to the /initlogo.rle file (almost not used today), the last one is launched using the bootanimation application and is contained in the /system/media/bootanimation.zip file.

The proc directory for Linux is standard, in the next boot steps init will connect procfs to it, a virtual file system that provides access to information about all the processes on the system. The system will connect sysfs to the sys directory, which opens access to information about the hardware and its settings. With sysfs, you can, for example, put the device to sleep or change the power-saving algorithm used.

The build.prop file is intended to store low-level android settings. Later, the system will reset these settings and overwrite them with values from the system/build.prop file, which is not yet available.

Step two, alternative. recovery section

In the event that the recovery boot flag in the misc section is set or the user turned on the smartphone while holding down the volume down key, u-boot will transfer control to the code located at the beginning of the recovery section. Like the boot partition, it contains the kernel and a RAM disk, which is decompressed into memory and becomes the root of the file system. However, the contents of the RAM disk are somewhat different here.

Unlike boot partition, acting as a transitional link between different stages of OS loading, recovery partition is completely self-sufficient and contains a miniature operating system that is not related to Android in any way. Recovery has its own core, its own set of applications (commands) and its own interface that allows the user to activate utility functions.

In a standard (stock) recovery, there are usually only three such functions: installing firmware signed with the key of the smartphone manufacturer, wipe and reboot. In modified third-party recovery, such as ClockworkMod and TWRP, there are much more functions. They can format file systems, install firmware signed with any keys (read: custom), mount file systems on other partitions (for OS debugging) and include script support that allows you to automate the firmware process and many other functions.

With the help of scripts, for example, you can make it so that after loading recovery automatically finds on the memory card required firmware, installed them and rebooted into Android. This feature is used by the ROM Manager, autoflasher tools, and the automatic cyanogen mod updates and other firmware.

Custom recovery also support backup scripts located in the /system/addon.d/ directory. Before firmware recovery checks for scripts and executes them before flashing. Thanks to such scripts, gapps do not disappear after installation new version firmware.

Step three. Initialization

So, having received control, the kernel connects the RAM disk and, after the initialization of all its subsystems and drivers, starts the init process, from which Android initialization begins. As I said, init has configuration file init.rc, from which the process learns what exactly it must do to bring the system up. In modern smartphones, this config has an impressive length of several hundred lines and is also equipped with a trailer of several child configs that are connected to the main one using the import directive. Nevertheless, its format is quite simple and is essentially a set of commands divided into blocks.

Each block defines a loading stage or, in the language of Android developers, an action. Blocks are separated from each other by an on directive followed by an action name, such as on early-init or on post-fs. The block of commands will be executed only if the trigger of the same name fires. As it boots, init will fire the early-init, init, early-fs, fs, post-fs, early-boot, and boot triggers in turn, thus running the appropriate command blocks.

If the configuration file pulls several more configs listed at the beginning (and this is almost always the case), then the command blocks of the same name inside them will be merged with the main config, so that when the trigger fires, init will execute commands from the corresponding blocks of all files. This is done for the convenience of generating configuration files for several devices, when the main config contains commands common to all devices, and specific commands for each device are written to separate files.

The most notable of the additional configs is initrc.devicename.rc where the variable name is determined automatically based on the contents of the ro.hardware file. This is a platform-specific configuration file that contains command blocks specific to specific device. In addition to the commands responsible for tuning the kernel, it also contains something like this:

mount_all ./fstab.devicename

It means that init should now mount all the file systems listed in the ./fstab.devicename file, which has the following structure:

device_name (partition) mount_point file_system fs_options other options

It usually contains instructions for connecting file systems from internal NAND partitions to the /system (OS), /data (application settings) and /cache (cached data) directories. However, by modifying this file slightly, we can force init to boot the system from the memory stick. To do this, it is enough to split the memory card into three to four partitions: 1 GB / ext4, 2 GB / ext4, 1 GB / ext4 and the remaining fat32 space. Next, you need to determine the names of the partitions of the memory card in the / dev directory (for different devices they are different) and replace them with original names devices in the fstab file.

At the end of the boot block, init will most likely encounter the class_start default command, which will tell you to start all the services listed in the config that are related to the default class. Descriptions of services begin with a service directive followed by the name of the service and the command that must be executed to start it. Unlike the commands listed in blocks, services must run all the time, so throughout the life of the smartphone, init will hang in the background and monitor this.

Modern Android includes dozens of services, but two of them have a special status and determine the entire life cycle of the system.

Step four. Zygote and App_process

At a certain stage of loading, init will encounter a block like this at the end of the config:

service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server class default socket zygote stream 660 root system onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart restart media onrestart restart netd

This is a description of the Zygote service, a key component of any Android system that is responsible for initialization, starting system services, starting and stopping user applications, and many other tasks. Zygote is launched using a small application /system/bin/app_process, which is very clearly visible in the above piece of config. The task of app_proccess is to start the Dalvik virtual machine, the code of which is located in the /system/lib/libandroid_runtime.so shared library, and then run Zygote on top of it.

When all this is done and Zygote is in control, it starts building the Java runtime environment by loading all of the framework's Java classes (currently over 2000). It then starts the system_server, which includes most of the high-level (written in Java) system services, including the Window Manager, Status Bar, Package Manager, and, most importantly, the Activity Manager, which in the future will be responsible for receiving start and end signals applications.

After that, Zygote opens socket /dev/socket/zygote and goes to sleep, waiting for data. At this time, the previously launched Activity Manager broadcasts the Intent.CATEGORY_HOME intent to find the application responsible for creating the desktop, and gives its name to Zygote over the socket. The latter, in turn, forks and launches the application on top of virtual machine. Voila, we have a desktop found on the screen by Activity Manager and launched by Zygote, and a status bar launched by system_server as part of the Status Bar service. After tapping on the icon, the desktop will send an intent with the name of this application, it will be accepted by the Activity Manager and will pass the command to start the application to the Zygote daemon.

All this may seem a bit confusing, but the most important thing is to remember three simple things:

In many ways, Android is very different from other operating systems, and you can’t figure it out with a swoop. However, if you understand how everything works, they open simply endless possibilities. Unlike iOS and Windows phone, Google's operating system has a very flexible architecture that allows you to seriously change its behavior without having to write code. In most cases, it is enough to correct the necessary configs and scripts.

][ 05.14

In the vastness of Runet it is difficult to find constructive and well-presented information about the device of the Android operating system. For the most part, the information is fragmented and incomplete, there is no introductory part with basic concepts which makes it difficult for beginners to understand and understand. With absence basic knowledge device and the algorithm of the Android operating system, it is impossible to debug or customize firmware, develop under the Android OS. This is what prompted me to write this article, in which I will try, in the usual and plain language, convey "difficult" things.

The material is aimed primarily at the study of ordinary users and is presented as an introductory excursion into the world of Android operating systems. Therefore, concise and superficial information without technical depths and nuances will be presented here. This material will be useful to everyone who is engaged in flashing and customizing firmware, developing under the Android OS, repairing mobile computer systems and the average user, for a better understanding of the principles of operation and the capabilities of their Android "a.

Partitions of Android internal memory

The internal memory of the device on android is divided into several logical disks (partitions). Here is a classic memory markup:

Bootloader- here is a program (bootloader) that allows you to run the Android operating system, Recovery and other service modes.

Recovery- as the name implies, it is installed here engineering menu Recovery or just Recovery.

Boot- the heart of the Android OS, here is the kernel, drivers and settings for managing the processor and memory.

System- the system partition, which contains all the files necessary for the operation of the Android OS, files, it's like Windows folder on your C:\ drive (hereinafter, we will associate with Windows OS)

Data- a section for installing applications and storing their data. (program files)

user- this is a well-known sdcard or, more simply, a place for user files (My Documents). Here we are forced to make a digression, because. This section has several options:

The partition is not in the internal memory, and instead an external drive is used - the most popular option. (fig.1)
In devices with large built-in memory, this section seen as sdcard, and external card memory is seen as sdcard2 or extsd (there may be other names). Usually found on devices with Android 3.2. (Fig.2 Option 1)
This option has been replaced previous option, along with Android 4.0. The User section was replaced with a media folder on the Data section, which made it possible to use all the memory available to the user for installing programs and storing data, and not the amount that the manufacturer allocated to us. In other words, sdcard and data are one. (Fig.2 Option 2)

Now that we know what and where it is, let's figure out why it is there and how this information can be useful to us.

Let's start with Bootloader. This is a bootloader that launches Android, recovery, etc. When we press the power button, the bootloader starts and, if not additional commands(pressed keys), starts loading boot. If the key combination was pressed (each device has its own), then it launches, depending on the command, recovery, fastboot or apx. The figure below clearly shows what the Bootloader launches and how the partitions are interconnected.

As can be seen from Figure 3, the Recovery partition does not affect the loading of the Android OS, but why is it needed then? Let's try to figure it out.

Recovery (recovery) is essentially a small utility on the Linux kernel and is loaded regardless of Android. Its regular functionality is not rich: you can reset the device to factory settings or update the firmware (previously downloaded to sdcard). But, thanks to craftsmen, we have modified recovery through which you can install modified (custom) firmware, configure android, create backups and much more. The presence or absence of recovery, as well as its version, do not affect the performance of the Android OS (very frequently asked question on the forums).

Particularly attentive readers could notice a certain Fastboot in Fig. 3. This is an interface for working directly with internal memory sections using the command line. Through it, you can flash the recovery, kernel or new firmware version, or format (delete all information) one or another partition.

Since we are talking about interfaces, I want to talk about another, quite well-known one - adb (android debugbridge). This is the so-called debugging mode and it is named so for a reason - through it you can monitor the work of both the system as a whole and individual applications. But that's not all, adb help available full access to the device's file system and modify system files or pull important information when your device is stuck on loading. I will not describe all the functions of the debug mode. my goal is to convey general information, not detailed overview about the functions of a particular mode.

Having dealt with the theory, let's run the Android OS.

We press the power button - Bootloader starts, which loads the Kernel (boot), it, in turn, starts the system (System), well, it already loads programs (data) and user space (user). (Fig.3)

And now let's go to the root directory and look at the insides of the Android OS itself:

In this scheme, we have given only the directories necessary for familiarization. In fact, there are many more of them, and an entire article will be needed to review only one System folder.

And so, the data folder. As you can guess from the name, it is somehow connected with data, but with what? Yes, with almost everyone, this is data on synchronization and accounts, passwords for wifi access points and vpn settings, and so on. Among other things, you can find the app, data and dalvik-cache folders here - consider their purpose:

app - programs and games are installed here.
data - application data, their settings, game saves and other information are stored here.
dalvik-cache - cache program area for Dalvik programs. Dalvik it Java virtual machine, which is the basis for the operation of programs that have *.apk extension.
In order to make the launch of programs faster, their cache is created.

The System folder contains system data and everything necessary for the operation of the OS. Let's take a look at some of these folders:

app - here are system applications (sms, phone, calendar, settings, etc.), as well as applications installed by the device manufacturer (branded widgets, live wallpapers, etc.).
fonts - system fonts
media - contains standard melodies for calls, notifications, alarm clocks and interface sounds, as well as boot animation (bootanimation)
build.prop - This file is mentioned, almost the first, in conversations and articles about fine-tuning the system. It contains a huge number of settings, such as screen density, proximity sensor delay, wifi control, device name and manufacturer, and many other options.

Root rights in Android OS

As in any Linux-like system, in the Android operating system, access to system files and directories is carried out with Root superuser rights. In this section, we decided to consider the principle of operation of the superuser rights of the Android OS, the ability to edit system files or logical sections of the file space with Root superuser rights.

- Knowing what folder is good, but can you do something about it?

- Yes! But you need superuser (root) rights or, if we draw an analogy with Windows, Administrator rights. Initially, all Android devices come without root rights for end user, i.e. when buying a device, we are not full-fledged owners in it. This was done to protect against malware, and from the user himself - after all, in inept hands, full access to the system can lead to the "death" of the operating system and the subsequent need to flash the device.

“Well, what is the use of such a dangerous thing?”- you ask.

Now we will tell:

The ability to backup data and restore them after flashing or accidental deletion.
Fine-tuning the system manually or using special programs.
Removing system applications, melodies, wallpapers, etc.
Change appearance OS (e.g. battery percentage display)
Adding functionality (support for ad-hoc networks, for example)

This list can be continued for a long time, but I think these examples will be enough to get an idea of the possibilities and breadth of application of root privileges.

- This is all great, but now any program will be able to access the "heart" of the operating system and my data?

- Not. You decide to allow a particular application to receive root access, or not. For this, there is the Superuser program or its advanced sister SuperSU. Without this or a similar program, it is not possible to use root.

As you can see, Android is not that complicated. operating system to understand the user. If you have previously had experience with Linux-like operating systems, you will find many similarities with Android systems and this similarity is justified. The Android system is a derivative and based on the Linux kernel. I hope that after reading the article, you have learned something new or received an answer to a question that has long interested you.

Every smartphone is made up of many complex components and you won't always think about them before choosing a phone model. But, nevertheless, it is important to know what hardware helps your smartphone function.

In this article, we will break down the main parts of what has become one of the most important electronic devices on the market. Consider what a smartphone consists of and why this or that component is needed. Now there are many different models of smartphones, different designs, with different characteristics, battery life and so on. But if you understand the hardware stuffing of a smartphone, then choosing the right model will be much easier.

1.Display

One of the most obvious components of a smartphone is its screen. Everything you see on the screen is processed and controlled by internal components. Now there are two technologies for manufacturing displays:

LCD screens, they are manufactured using IPS or TFT technology;
LED screens made using AMOLED technology or Super AMOLED.

The liquid crystal display uses a backlight to produce an image. White light passes through the filters and thanks to the ability to control the properties of the crystals, you can see different colors. Light is not created by the screen itself, it is created by a light source behind it.

The LED screen works differently. Each pixel you see on the screen is a separate LED. Here, the screen itself creates bright and colorful colors. The advantage of Super AMOLED over IPS is that when the pixel is turned off you will see black, it does not use the battery. Therefore, smartphones with AMOLED are more efficient for battery life. But AMOLED screens more expensive than IPS, so a smartphone with such a display will cost significantly more.

2. Battery

Smartphones typically use lithium-ion batteries and may or may not be removable. Thanks to this technology, you do not need to calibrate or test the battery as you would with nickel-based batteries. However, these batteries have many problems of their own.

3. System-on-a-Chip (SoC)

SoC or motherboard with a processor is the most important component of your smartphone. Some users may think it's the device's processor, but it's more than that. The SoC includes not only the CPU, but also the GPU, LTE modem, screen controller, wireless adapters, and other blocks of silicon that make the phone work.

There are smartphones using SoCs from Qualcomm, MediaTek, Samsung, proprietary chips from Krirn, Apple, but they all use the same architecture - ARM. ARM not only manufactures processors, but also licenses their architecture to other companies, so everyone can use the same technology to create modern and powerful SoCs.

Some companies release their architectural lines that are compatible with ARM and can be used in smartphones. An example would be Apple chipsets running on Cyclone processors or Qualcomm Kryo processors. SoC - these are the main components of what a smartphone consists of.

4. Internal and RAM

No smartphone can work without RAM and system storage. Most devices use either LPDDR3 or LPDDR4 RAM, and some high-end models ship with LPDDR4X. The combination LP means Low Power, the supply voltage of these microcircuits is reduced, and this makes them more efficient in terms of power consumption.

LPDDR4 is more efficient than LPDDR3, and LPDDR4X is more efficient and more economical than both. There is also an even more affective memory - LPDDR5.

As for the internal storage, flash memory from 32 to 256 GB is used here. User requirements are constantly growing and volumes will grow in accordance with them. When you turn on the phone, you will see that the size of the drive is smaller than advertised. For example, it says that the drive is 64 GB, and 53-55 GB is available for recording. This memory is occupied by the operating system and applications.

5. Modems

Since smartphones are still phones, they need communication components to receive and make calls, send text messages and connection to the Internet. That's what modems are for. Each SoC manufacturer has its own modem brand, these are Qualcomm, Samsung, Huawei and others.

Each of the manufacturers is trying to release the fastest LTE chip. Currently the fastest 9-LTE chip, but it makes no sense to take it if your cellular network does not support such a speed.

6. Camera

All smartphones have front and front cameras. The chambers are made up of three main parts:

Sensor- detects light;
Lens- concentrates the image;
Image Processor.

The number of megapixels of a smartphone camera is still a very important criterion, but now it matters a lot less. Now the main limiting factor is the camera sensor, as well as its sensitivity when light passes through it.

The sensor may behave differently in each smartphone, so a photo or video will have a different contrast, hue, saturation compared to other smartphones. Because smartphones have a small sensor size, they tend to perform poorly in low light conditions.

7. Sensors

Most modern smartphones have built-in five main sensors that will allow you to use your smartphone more conveniently. Here they are:

Accelerometer- used by applications to determine the orientation of the device and its movements. For example, it allows you to use shaking your smartphone to switch music;
Gyroscope- works with the accelerometer to detect the rotation of your phone. Useful for racing games;
digital compass- helps to find the North for normal orientation on maps;
Light sensor- This sensor allows you to automatically set the brightness of the screen depending on the ambient light and helps to increase battery life.
Proximity sensor- During a call, if the device approaches your ear, this sensor will automatically lock the screen to prevent unwanted touches.

These were all the main elements of a smartphone, in various models there may be other sensors, such as a pulse sensor, pressure and temperature, but they are much less common.

conclusions

We looked at what a smartphone consists of. Now that you have more information about the complex components that make up every smartphone, you can choose your future purchase by comparing the characteristics of various components. So you choose the best device that will fully meet your needs.

Have you ever wondered how fastboot or ADB work? Or why is it almost impossible to turn an Android smartphone into a brick? Or maybe you have long wanted to know where the magic of the Xposed framework lies and why the /system/etc/init.d boot scripts are needed? What about the recovery console? Is this part of Android or a thing in itself, and why is the usual recovery not suitable for installing third-party firmware? You will find answers to all these and many other questions in this article.

How Android Works

You can learn about the hidden features of software systems by understanding the principle of their work. In some cases, this is difficult to do, since the code of the system can be closed, but in the case of Android, we can study the entire system inside and out. In this article, I will not talk about all the nuances of Android and will focus only on how the OS starts up and what events take place between pressing the power button and the appearance of the desktop.

Step one. ABOOT and partition table

It all starts with the primary bootloader. After the power is turned on, the system executes the bootloader code stored in the device's permanent memory. It then transfers control to the aboot bootloader with built-in support for the fastboot protocol, but the manufacturer of the mobile chip or smartphone / tablet has the right to choose any other bootloader of his choice. For example, Rockchip uses its own, non-fastboot-compatible bootloader, which requires the use of proprietary tools to reprogram and manage.

The fastboot protocol, in turn, is a bootloader management system from a PC that allows you to perform actions such as unlocking the bootloader, flashing a new kernel and recovery, installing firmware, and many others. The point of fastboot is to be able to restore the smartphone to its original state in a situation where all other means fail. Fastboot will remain in place even if, as a result of experiments, you erase all sections of NAND memory containing Android and recovery from your smartphone.

Having received control, aboot checks the partition table and transfers control to the kernel flashed into the partition named boot, after which the kernel extracts the RAM image from the same partition into memory and starts loading either Android or the recovery console. NAND memory in Android devices is divided into six conditionally mandatory sections:

boot - contains the kernel and RAM disk, usually around 16 MB in size;
recovery - recovery console, consists of a kernel, a set of console applications and a settings file, size 16 MB;
system - contains Android, in modern devices it has a size of at least 1 GB;
cache - designed to store cached data, also used to save the firmware during an OTA update and therefore has a size similar to the size of the system partition;
userdata - contains settings, applications and user data, all remaining NAND memory space is allocated to it;
misc - contains a flag that determines in which mode the system should boot: Android or recovery.

In addition to them, there may also be other sections, however, the general markup is determined at the design stage of the smartphone and, in the case of aboot, is sewn into the bootloader code. This means that: 1) the partition table cannot be killed, since it can always be restored using the fastboot oem format command; 2) to change the partition table, you will have to unlock and reflash the bootloader with new parameters. There are exceptions to this rule, however. For example, the bootloader of the same Rockchip stores partition information in the first block of NAND memory, so flashing the bootloader is not needed to change it.

Part of the bootloader code that defines the partition table

Particularly interesting is the misc section. There is an assumption that it was originally created to store various settings regardless of the main system, but at the moment it is used for only one purpose: to tell the bootloader which partition to boot the system from - boot or recovery. This feature, in particular, uses the ROM Manager application to automatically reboot the system into recovery with automatic firmware installation. Based on it, the Ubuntu Touch dual boot mechanism is built, which flashes the Ubuntu bootloader into recovery and allows you to control which system to boot next time. Erase the misc partition - Android is loaded, filled with data - recovery is loaded ... that is, Ubuntu Touch.

Step two. boot partition

If the misc section does not have a recovery boot flag, aboot transfers control to the code located in the boot section. It is nothing but the Linux kernel; it is located at the beginning of the section, and immediately after it is a RAM disk image packed using cpio and gzip archivers, containing the directories necessary for Android to work, the init initialization system, and other tools. There is no file system on the boot partition, the kernel and RAM disk just follow each other. The content of the RAM disk is:

data - directory for mounting the partition of the same name;
dev - device files;
proc - procfs is mounted here;
res - a set of images for the charger (see below);
sbin - a set of auxiliary utilities and daemons (adbd, for example);
sys - sysfs is mounted here;
system - directory for mounting the system partition;
charger - an application for displaying the charging process;
build.prop - system settings;
init - initialization system;
init.rc - settings of the initialization system;
ueventd.rc - settings for the uventd daemon included in init.

The charger file is a small application whose only job is to display the battery icon. It has nothing to do with Android and is used when the device is connected to the charger in the off state. In this case, Android does not boot, and the system simply boots the kernel, connects the RAM disk, and starts the charger. The latter displays the battery icon, the image of which in all possible states is stored in regular PNG files inside the res directory.

The ueventd.rc file is a config that defines which device files in the sys directory should be created at the system boot stage. On Linux kernel-based systems, the hardware is accessed through special files inside the dev directory, and the ueventd daemon, which is part of init, is responsible for creating them in Android. Normally, it works in automatic mode, accepting commands to create files from the kernel, but some files need to be created by yourself. They are listed in ueventd.rc.

The sbin directory in stock Android usually contains nothing but adbd, which is the ADB daemon that is responsible for debugging the system from the PC. It starts at an early stage of OS boot and allows you to identify possible problems at the stage of OS initialization. In custom firmware, you can find a bunch of other files in this directory, such as mke2fs, which may be required if partitions need to be reformatted to ext3/4. Also, modders often put a BusyBox there, with which you can call hundreds of Linux commands.

The build.prop file is designed to store low-level Android settings. Later, the system will reset these settings and overwrite them with values from the system/build.prop file, which is not yet available.

OUYA TV Box Root Partition

Step two, alternative. recovery section

In the event that the recovery boot flag in the misc section is set or the user turned on the smartphone while holding down the volume down key, aboot will transfer control to the code located at the beginning of the recovery section. Like the boot partition, it contains the kernel and a RAM disk, which is decompressed into memory and becomes the root of the file system. However, the contents of the RAM disk are somewhat different here.

Unlike the boot partition, which acts as a transitional link between different stages of booting the OS, the recovery partition is completely self-sufficient and contains a miniature operating system that has nothing to do with Android. Recovery has its own core, its own set of applications (commands) and its own interface that allows the user to activate utility functions.

With the help of scripts, for example, you can make it so that after loading recovery automatically finds the necessary firmware on the memory card, installs them and reboots into Android. This feature is used by the ROM Manager, auto-flasher tools, as well as the automatic update mechanism for CyanogenMod and other firmware.

Custom recovery also supports backup scripts located in the /system/addon.d/ directory. Before flashing, recovery checks for scripts and executes them before flashing. Thanks to such scripts, gapps do not disappear after installing a new firmware version.

Step three. Initialization

So, having received control, the kernel connects the RAM disk and, after the initialization of all its subsystems and drivers, starts the init process, from which Android initialization begins. As I said, init has a configuration file init.rc, from which the process learns what exactly it must do to bring the system up. In modern smartphones, this config has an impressive length of several hundred lines and is also equipped with a trailer of several child configs that are connected to the main one using the import directive. Nevertheless, its format is quite simple and is essentially a set of commands divided into blocks.

Part of the init.rc config from CyanogenMod

The most notable of the additional configs is initrc.devicename.rc, where the device name is determined automatically based on the contents of the ro.hardware system variable. This is a platform-specific configuration file that contains device-specific command blocks. In addition to the commands responsible for tuning the kernel, it also contains something like this:

Mount_all ./fstab.device_name

It means that init should now mount all the file systems listed in the ./fstab.devicename file, which has the following structure:

device_name (partition) mount_point file_system fs_options other options

It usually contains instructions for connecting file systems from internal NAND partitions to the /system (OS), /data (application settings) and /cache (cached data) directories. However, by modifying this file slightly, we can force init to boot the system from the memory stick. To do this, it is enough to split the memory card into three 4 sections: 1 GB / ext4, 2 GB / ext4, 1 GB / ext4 and the remaining fat32 space. Next, you need to determine the names of the memory card partitions in the /dev directory (they differ for different devices) and replace the original device names in the fstab file with them.

Typical contents of an fstab file

Modern Android includes dozens of services, but two of them have a special status and determine the entire life cycle of the system.

Step four. Zygote and app_process

At a certain stage of loading, init will encounter a block like this at the end of the config:

Service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server class default socket zygote stream 660 root system onrestart write /sys/android_power/request_state wake onrestart write /sys/power/state on onrestart restart media onrestart restart netd

This is a description of the Zygote service, a key component of any Android system that is responsible for initialization, starting system services, starting and stopping user applications, and many other tasks. Zygote is launched using a small application /system/bin/app_process, which is very clearly visible in the above config piece. The task of app_proccess is to start the Dalvik virtual machine, the code of which is located in the /system/lib/libandroid_runtime.so shared library, and then run Zygote on top of it.

After that, Zygote opens socket /dev/socket/zygote and goes to sleep, waiting for data. At this time, the previously launched Activity Manager broadcasts the Intent.CATEGORY_HOME intent to find the application responsible for creating the desktop, and gives its name to Zygote over the socket. The latter, in turn, forks and runs the application on top of the virtual machine. Voila, we have a desktop found on the screen by Activity Manager and launched by Zygote, and a status bar launched by system_server as part of the Status Bar service. After tapping on the icon, the desktop will send an intent with the name of this application, it will be accepted by the Activity Manager and will pass the command to start the application to the Zygote daemon

All this may seem a bit confusing, but the most important thing is to remember three simple things:

System services and kernel threads

conclusions

In many ways, Android is very different from other operating systems, and you can’t figure it out with a swoop. However, if you understand how everything works, the possibilities are simply endless. Unlike iOS and Windows Phone, Google's operating system has a very flexible architecture that allows you to seriously change its behavior without having to write code. In most cases, it is enough to correct the necessary configs and scripts.

Those who have been using the iPhone for a long time know how the early ones worked. iOS versions. In fact, it was a single-tasking operating system that allowed you to work in the background or interrupt work. current application only preinstalled apps: you are reading a book, they call you - the book reader is minimized, and a call window appears on the screen. But reverse operation impossible: the book reader not only cannot interrupt the work of other applications, but will be killed immediately after minimizing.

The reason for the existence of such a system, of course, is to save the processor, RAM, and battery life. Thanks to her (but not only), the iPhone could work quickly in conditions of limited resources and was very careful about the battery.

How the Android operating system works

Android has always worked differently. Here you can run many different applications and all of them will remain in memory and even be able to work in the background. You open a browser, enter an address, and while the page is loading, launch your email client and read the emails. Everything is like on the desktop, with the exception that you do not need to take care of closing applications, the system will do it itself when the operating memory will do by the end, or it will not be enough to host a running application (of course, rarely used applications will go to the expense first of all). This mechanism is called low memory killer.

As root, lowmemorykiller settings can be adjusted directly or with the help of special applications

Services were an important element of the multitasking system. These are special application components that could work in the background absolutely in any conditions: the screen is on or off, minimized application or deployed, services don't even care if it's running parent application generally. It simply said, "Hey Android, I need CPU resources, I want to do some calculations" and received those resources. In Android terminology, such a request to the system is called wakelock(more precisely, a processor wakelock).

However, the support of such a powerful and useful tool played a cruel joke on Google. A huge number of applications appeared that produced services for everyone, constantly performed some kind of work and did not let the smartphone sleep. By installing a hundred applications on a smartphone, the user received several dozen services, each of which periodically did something (updating the Twitter feed while the phone is sleeping is so important).

The situation was so deplorable that Chinese manufacturers, not burdened with the task of maintaining compatibility with original android(this is required if you want to install on your Smartphones Play Store), simply disabled the mechanisms for maintaining the life cycle of services for non-system applications in their smartphones.

Advanced users went the other way: they got root rights and installed the Greenify application, which allowed them to freeze the services of selected applications so that no one could wake them up. There were also more radical options, for example, to demolish all the software that you use less than once a day.

Google itself has also taken action to combat "poisonous" services. A big step in this direction was taken in Android 4.4, which introduced an intelligent mechanism that determined if the service was running too long and if it was CPU intensive, and if so, nailed it in place and prevented it from starting. Even at a superficial glance, this version of the system lived on a battery much longer than the previous ones.

In Android 6.0, Google went even further and equipped it with a mechanism Doze, which after a certain time of inactivity of the smartphone (about one hour) transferred it to a special power saving mode. One of the features of this mode is the ban on wakelock, that is, neither applications nor services simply can wake up the smartphone to do any work. By eye, Android 6.0 did not live longer, so it is not known whether this mechanism worked at all.

Doze work scale

And finally, in Android 8.0, Google took a radical step - it banned the work background services. But with two exceptions:

The application in some cases, for example, when it is on the screen, can start services, but Android will kill them after the application goes to sleep.
Services visible to the user are still allowed. This so-called foreground service, a service that is visible in the notification bar and has an icon in the statusbar.

It would seem, yes, services are evil, but what about applications like anti-theft, which should work quietly in the background? Or the same mail client? Due to the need to periodically check mail, should it hang in the notification bar?

Not really. Google has been moving towards banning services since version 5.0, where the so-called JobScheduler. This is a special subsystem that allows applications to ask Android to perform this or that work at such and such a time or when such and such an event occurs (connection to the Internet, for example). And yes, JobScheduler strongly resembles a similar function from iOS.

Binder

Contrary to popular belief, Android has been using sandboxes to isolate applications since its earliest versions. And they were implemented in a very interesting way. Each application was launched on behalf of a separate Linux user and thus only had access to its own directory inside /data/data .

Applications could communicate with each other and with the operating system only through the IPC mechanism. Binder, which required authorization to perform an action. The same mechanism was used for several other purposes: with its help, the system notified applications about system events, such as an incoming call, incoming SMS, charging, and so on. Applications received messages and could respond to them.

Binder is powered by a driver in the Linux kernel and Service Manager

This feature has given Android very rich automation capabilities, which we know about thanks to applications such as Tasker, Automate or Locale. All of these apps are also available for Android 8, except that some dangerous features, such as enabling/disabling Airplane mode, are now prohibited from being used by regular apps.

The notification system is based on intents (intent), a special mechanism implemented on top of Binder and designed to exchange information between applications (or OS and applications), as well as launch application components. Using intents, you can notify applications about events, ask the system to open an application to process certain types of data (for example, to open specific page in the browser, it is enough to send a broadcast intent with a link to the page, and all applications capable of displaying web pages will respond to it, or only the default browser) or simply launch a component of an application. For example, applications in Android are not launched directly, but with the help of intents.

Unfortunately, like services, intents have become a problem for Google and Android users. The fact is that broadcast intents used to notify applications about events come immediately to all applications that have declared that they are able to respond to them. And in order for the application to be able to respond to the intent, it must be launched. The picture is this: there are twenty apps on the smartphone that can respond to the android.net.conn.CONNECTIVITY_CHANGE intent, and each time you connect to and disconnect from the network, the system launches these applications so that they can respond to the intent. How this affects energy consumption - imagine for yourself.

Google fixed this misunderstanding again in Android 8.0. Applications can now only register broadcast intent handlers while they are running (with a few exceptions).

Google Services

Google likes to flaunt that Android is an open source operating system. This, of course, is not entirely true. One side, android code is really open, which is why we have access to so many different custom ROMs. On the other hand, by building Android from official sources, you will get a system without several important components: 1) individual drivers, the source of which the manufacturer hides as a trade secret, 2) Google services, which are needed first of all to gain access to the account, launch Google Play and cloud backup.

Google Mobile Services is also responsible for many other things, including support for push notifications, Instant Apps, Google Maps, calendar access, location by cell towers and Wi-Fi routers, mechanism smart lock, which allows you to unlock your device depending on certain conditions.

AT modern versions Android Services Google has taken on so much of the work that life without them is possible, but very problematic. And they are also sad: the minimum version of the GApps package (which contains only Google and Google Play services) weighs more than 120 MB, and the services themselves are famous for their love of RAM and battery life. And they are closed, that is, only Google itself knows what they can do.

Download the package with services and Google apps for custom firmware, you can from the site opengapps.org (the word open does not mean that they are open)

That is why the microG project was born, whose task is to recreate the most important functionality of Google services in open source. Already, microG allows you to access your account, activate push notifications, access Google maps and determine the location by cell towers. And all this with a size of four mega and almost total absence requirements for RAM and battery life.

The project has its own assembly of the LineageOS firmware, which out of the box includes microG and all the modifications necessary for its operation.

Linux kernel and runtime

Android is based on the Linux kernel. The kernel manages the resources of the smartphone, including access to hardware, management of RAM and permanent memory, starting, stopping and transferring processes between processor cores, and many other tasks. Like any other OS, the kernel is the heart of Android, the central part without which everything else would fall apart.

Layer Cake Android

The presence of the Linux kernel, as well as a runtime environment partially compatible with the POSIX standard (primarily a bionic library based on the implementation standard library C from OpenBSD) makes Android compatible with Linux applications. For example, the wpa_supplicant authentication system used to connect to Wi-Fi networks is exactly the same here as in any Linux distribution. AT early versions Android used the standard Linux bluetooth stack called bluez (later replaced by Qualcomm's implementation called Bluedroid). It even has its own console with a set of standard UNIX / Linux commands implemented in the Toybox set, originally created for embedded Linux systems.

Most console applications written for Linux can be ported to Android by simple recompilation using a cross compiler (the main thing is to use static compilation so as not to get a library conflict), and having root rights, you can run a full-fledged one on an Android device without any problems. One caveat - access to it can be obtained either only through the console, or using a VNC connection. There is also a Maru OS project that allows you to use your smartphone as a Debian-based PC when connected to a  monitor. It promises the same function when connecting its smartphones to the monitor using the DeX dock.

Good old mc running in android

Starting with version 4.4, Android can use the SELinux forced access control system to protect against hacking and obtaining root rights. SELinux was developed by the US National Security Agency and, without going into details, allows you to limit applications (including low-level system components) in capabilities. And it's not about the powers that the user grants to applications, but about such things as system calls and access to certain files, despite the standard UNIX permissions.

A series of Stagefright vulnerabilities that hit Android a few years ago made it possible to take control of the device simply by forcing the user to open an incoming MMS or a special file in the browser. The problem was in the Stagefright multimedia framework, which contains several buffer overflow vulnerabilities at once. When opening a specially prepared multimedia file, the exploit used the vulnerability and ran code on the device on behalf of Stagefright (which ran as root).

Google successfully closed all these bugs, and also worked on modularizing the framework code and running it in special SELinux domains. These domains prevent media processing components from using most of the Linux system calls, including the execve group system calls that were involved in running the malicious code.

Today SELinux is used to protect almost all system components Android. And this was the reason for a sharp decrease in the number of bugs found in Android. But it led to crackers focusing on the kernel, or rather those very closed drivers, whose code was not audited by anyone and whose security is not guaranteed (and, as it turned out, it is in a deplorable state).

(1 ratings, average: 5,00 out of 5)

How android works. Wearable electronics and home appliances