Review of the mobile operating system Android. Internal device of Android systems Android OS system structure

Longtime iPhone users know how early versions of iOS worked. In fact, it was a single-tasking operating system that allowed only preinstalled applications to work in the background or interrupt the current application: you read a book, they call you - the book reader is minimized, and a call window appears on the screen. But the reverse operation is impossible: the book reader not only cannot interrupt the work of other applications, but will also be killed immediately after minimizing.

The raison d'être of such a system is, of course, to save 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 they will all remain in memory and can even work in the background. You open your browser, enter the address and, while the page is loading, launch the mail client and read the letters. Everything is like on a desktop, with the exception that you do not need to worry about closing applications, the system will do it itself when the RAM comes to an end or it is not enough to accommodate the application being launched (of course, rarely used applications will be consumed first. ). This mechanism is called lowmemorykiller.

As root, the lowmemorykiller settings can be adjusted directly or using special applications

An important element of the multitasking system was services. These are special application components that could work in the background in absolutely any conditions: screen turned on or off, application minimized or expanded, services do not even care if the parent application is running at all. It just said, "Hey Android, I need CPU resources, I want to do some math," and it received those resources. In Android terminology, such a request to the system is called wakelock(or more precisely, the processor wakelock).

However, supporting such a powerful and useful tool has played a cruel joke on Google. A huge number of applications appeared that produced services for every sneeze, constantly did some kind of work and did not let the smartphone sleep. Having installed 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).

Things were so deplorable that Chinese manufacturers, not burdened with the task of maintaining compatibility with the original Android (this is required if you want to install the Play Store on your smartphones), simply turned off 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 privileges and installed the Greenify application, which allowed them to freeze the services of the 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, where an intelligent mechanism appeared that determined if a service was running for too long and if it was overloading the processor, and, if it turned out to be so, nailed it in place and prevented it from starting. Even at a superficial glance, this version of the system lived on 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) put it into a special energy-saving mode. One of the features of this mode is the prohibition on wakelock, that is, neither applications nor services simply can wake up the smartphone to do any work. By eye, Android 6.0 didn't live longer, so it's not known if this mechanism worked at all.

Doze work bar

Finally, in Android 8.0, Google took a radical step by disabling 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.
User-visible services are still allowed. This is the so-called foreground service, a service that is visible in the notification panel and has an icon in the status bar.

It would seem, yes, services are evil, but now how can applications such as anti-theft, which should work invisibly in the background, be? Or the same email client? Due to the need to periodically check your 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 do a certain job at a certain time or when such and such an event occurs (an Internet connection, for example). And yes, JobScheduler closely resembles a similar function from iOS.

Binder

Contrary to popular belief, Android has used sandboxes to isolate applications since the earliest versions. And they were implemented in a very interesting way. Each application ran as 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 notifies applications about system events, such as an incoming call, incoming SMS, plugging in a charge, and so on. Apps received messages and could respond to them.

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

This feature gave Android the very rich automation capabilities that we know about from apps like Tasker, Automate, or Locale. All of these applications are available for Android 8 as well, except that some dangerous features, such as turning on / off airplane mode, are now prohibited from normal applications.

The warning system is based on 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 a specific page in a browser, you just need to send a broadcast intent with a link to the page, and all applications that can display web pages will respond to it. or just the default browser) or just launch a component of an application. For example, applications in Android are launched not directly, but using 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 go immediately to all applications that have declared that they are capable of responding to them. And for the application to be able to react to the intent, it must be launched. The picture looks like this: there are twenty applications on a smartphone that can respond to the android.net.conn.CONNECTIVITY_CHANGE intent, and every time you connect to the network and disconnect from it, the system launches these applications so that they can respond to the intent. How does this affect energy consumption - imagine yourself.

Google corrected this misunderstanding again in Android 8.0. Applications can now register broadcast intent handlers only 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. On the one hand, the Android code is really open source, which is why we have access to so many different custom firmwares. On the other hand, collecting Android from official sources, you will get a system without several important components: 1) individual drivers, the sources of which are hidden by the manufacturer as a trade secret, 2) Google services, which are needed primarily to gain access to your account, launch Google Play and cloud backup.

Google services (Google Mobile Services) are also responsible for many other things, including support for push notifications, Instant Apps, Google Maps, access to the calendar, location on cell towers and Wi-Fi routers, Smart Lock mechanism that allows you to unlock the device in depending on some conditions.

In modern versions of Android, Google services have taken over so much of the work that it turns out to be, though possible, very problematic to live without them. And it's not fun with them either: the minimal 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 power. And they are also closed, that is, only Google itself knows what they can do.

You can download a package with Google services and applications for custom firmware from the opengapps.org website (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 to Google maps and determine the location by cell towers. And all this at a size of four mega and almost no requirements for RAM and battery life.

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

Linux kernel and runtime

Android is based on the Linux kernel. The kernel manages the smartphone's resources, including access to hardware, managing RAM and read-only memory, starting, stopping, and transferring processes between processor cores, and many other tasks. As with any OS, the kernel is the heart of Android, the core without which everything else would fall apart.

Layered cake Android

The presence of a Linux kernel, as well as a partially POSIX-compliant runtime environment (primarily the bionic library based on the OpenBSD implementation of the C standard library) makes Android compatible with Linux applications. For example, the wpa_supplicant authentication system used to connect to Wi-Fi networks is exactly the same as in any Linux distribution. Earlier versions of Android used a 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 - it will be possible to access it 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. The same function promises when you connect your smartphones to the monitor using the DeX dock.

Good old mc running in Android

Starting from version 4.4 Android is able to use SELinux forced access control system to protect against hacking and gain root privileges. SELinux is developed by the US National Security Agency and, without going into details, allows you to restrict applications (including low-level system components) in capabilities. And it's not about the permissions that the user grants to applications, but about such things as system calls and access to certain files, regardless of standard UNIX permissions.

A series of Stagefright vulnerabilities that hit Android several years ago made it possible to gain control over the device by simply forcing the user to open the received MMS or special file in the browser. The problem was with the Stagefright multimedia framework containing multiple buffer overflow vulnerabilities. When opening a specially prepared multimedia file, the exploit exploited the vulnerability and ran the code on the device on behalf of Stagefright (which worked under the root).

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

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

(6 estimates, average: 5,00 out of 5)

In this article, you will find out what folders (directories) exist in Android, what files are in them, what these folders and files are responsible for, and why they are needed.

Preface on structure

Many have a computer and have Windows installed on them. Everyone knows perfectly well that in this OS everything is distributed across disks:

C:- this disk contains the system

D:- for personal files (the disk may not be there if it is not "broken")

E: - Z:- flash drives, portable hard drives, CD or DVD drives.

In Windwows, everything is scattered across different drives. On UNIX / Linux, which includes Android (as well as BSD, which includes Mac OS X), things look a little different. The file structure is tree-like. Perhaps it is not clear now, but further on with reading the article it will be more clear.

It is also worth knowing that Android, like Linux, unlike Windows, is very case sensitive. For example the folder Name, NaMe, name, NAME are 4 different folders, whereas Windows can create only one folder with that name.

In order to make it more clear what is at stake, it is recommended to install the file manager Root Browser.

The structure and purpose of Android folders and files

As it was said above, the structure has a tree-like form. Any tree has a root, it also exists on UNIX / Linux. The root is the starting point in the file structure, from the root the system is overgrown with folders and files. Root in UNIX / Linux is marked as a sign:

/

details about the dev section

/ dev /- this section contains information about system devices and files.

[collapse]

details about the data section

section / data /- user section, which contains installed applications, personal settings

folder / data / app- installed applications, games are located here.

folder / data / app-lib- additional libraries required for the operation of certain applications (present in newer versions of Android).

folder / data / dalvik-cache- cache memory, for the Java machine Dalvik, which is the "engine" in Android, which is responsible for launching and running applications.

folder / data / data- this folder contains individual settings of each custom applications, libraries and other files are necessary files for them to work.

folder / data / system /- this section contains the global settings of the user environment, synchronization, accounts, blocking.

files gesture.key, locksettings.db, locksettings.db-shm, locksettings.db-wa l - pattern, pin code.

[collapse]

details about the preload section

section / preload /- this section contains additional files and folders that are mirrored into the section / system /(this section is not available in all Android devices, mainly in Samsung).

[collapse]

details about the system section

partition / system /- this section contains system folders and files necessary for the functioning of Android.

folder / system / app- system applications and services are located here (in new Android operating systems, service applications were moved to a different folder priv-app).

folder / system / bin and / system / xbin- the folder contains files and links to executable binaries.

file / system / xbin / su- the file responsible for Root rights.

folder / system / camerdata- this folder contains files responsible for the operation of the camera.

folder / system / etc- this folder contains the configuration files necessary for loading the OS and also necessary in the course of the work of various programs.

folder /system/init.d- this folder contains scripts that can affect the operation of the system.

file / system / etc / hosts- the file is responsible for blocking, redirecting web addresses.

file / system / etc / apns.conf- a file with information about Internet access points (APN).

file / system / etc / gps.conf- GPS settings.

folder / system / fonts- folder with system fonts.

folder / system / framework- folder with Android "processes".

folder / system / lib /- libraries of system applications and services.

folder / system / lib / modules- system drivers.

folder / system / media- folder with system sounds and turn-on animation.

file /system/media/bootanimation.zip- executable archive with loading animation.

folder / system / priv-app- folder with Android services / applications.

file /system/build.prop- configuration file with which you can change system settings.

[collapse]

details about the proc section

/ proc section- a virtual section containing information about the kernel and its configuration.

Ever wondered how fastboot or ADB works? Or why is an Android smartphone almost impossible to turn into a brick? Or maybe you have long wanted to know where the magic of the Xposed framework lies and why the boot scripts /system/etc/init.d are needed? What about the recovery console? Is it a part of Android or a thing in itself, and why is regular 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 capabilities of software systems by understanding how they work. In some cases, it is difficult to do this, since the system code can be closed, but in the case of Android, we can examine 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 in the interval 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 capabilities to implement such things as tuning OS parameters, expanding space for storing applications, connecting 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. ABOOT and partition table

It all starts with the primary bootloader. After turning on the power, the system executes the bootloader code written in the permanent memory of the device. Then it 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 its choice. For example, Rockchip uses its own, non-fastboot-compatible bootloader, which must be reprogrammed and managed using proprietary tools.

The fastboot protocol, in turn, is a bootloader control 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 raison d'être of fastboot is to be able to restore the smartphone to its original state in a situation where all other means are not working. Fastboot will stay in place, even if you experimentally erase all NAND partitions containing Android and recovery from your smartphone.

Having received control, aboot checks the partition table and transfers control to the kernel, which is stitched into a partition named boot, after which the kernel fetches 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 required sections:

• boot - contains a kernel and a RAM disk, usually about 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 has a size of at least 1 GB;
• cache - intended for storing cached data, it is 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, other sections may also exist, 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, however, exceptions to this rule. For example, the bootloader of the same Rockchip stores information about partitions in the first block of NAND memory, so you do not need to flash the bootloader to change it.

Of particular interest is the misc section. There is an assumption that it was originally created to store various settings independently of the main system, but in this moment is used for only one purpose: to tell the bootloader which partition to load the system from - boot or recovery. This feature, in particular, is used by the ROM Manager application to automatically reboot the system into recovery with the automatic installation of the firmware. On its basis, 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 section - Android is loaded, filled with data - recovery is loading ... that is, Ubuntu Touch.

Step two. Boot section

If the misc section does not have a boot flag in recovery, aboot transfers control to the code located in the boot section. It is nothing more than the Linux kernel; it is located at the beginning of the section, and immediately followed by a cpio and gzip compressed RAM disk image containing the directories necessary for Android to work, the init system, and other tools. There is no filesystem on the boot partition, the kernel and the RAM disk just follow each other. The contents of the RAM disk are as follows:

• 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 - init system;
• init.rc - init system settings;
• 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 handle all the rest of the work of loading the system. The central element here is the init application and its init.rc config, which I will discuss in detail later. In the meantime, I want to draw your 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 sole purpose 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 loads the kernel, connects the RAM disk and starts the charger. The latter displays a 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 determines which device files in the sys directory should be created at boot time. On Linux kernel-based 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 on Android. Normally, it works in automatic mode, accepting commands to create files from the kernel, but some files need to be created yourself. They are listed in ueventd.rc.

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

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

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

Extraction from the text

• Fastboot stays in place even if you experiment with erasing all NAND partitions from your smartphone
• The recovery section is completely self-contained and contains a miniature operating system that has nothing to do with Android
• By modifying the fstab file slightly, we can force init to boot the system from the memory stick.

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 with the volume down key pressed, 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 filesystem. However, the contents of the RAM disk are somewhat different here.

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

In the standard (stock) recovery, there are usually only three such functions: installation of firmware signed with the key of the smartphone manufacturer, wipe and reboot. Modified third-party recovery like ClockworkMod and TWRP have many more features. They know how to 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 automates the firmware process and many other functions.

Using scripts, for example, you can make sure that after downloading, 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.

Fastboot commands

To access fastboot, you need to install the Android SDK, connect your smartphone to your PC using a cable and turn it on by holding down both volume buttons. After that, go to the platform-tools subdirectory inside the SDK and run the command

Fastboot devices

The device name will be displayed. Other available commands:

• fatsboot oem unlock- unlocking the bootloader on nexus;
• update zip file- installing firmware;
• flash boot boot.img- flashing the boot partition image;
• flash recovery recovery.img- flashing the recovery partition image;
• flash system system.img- flashing the system image;
• oem format- restoration of a destroyed partition table;

Step three. Initialization

So, having received control, the kernel connects the RAM disk and upon completion of the initialization of all its subsystems and drivers starts the init process, from which the initialization of Android begins. As I said before, init has a configuration file init.rc, from which the process learns what exactly it should do to get 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, in fact, is 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 command block will be executed only if the trigger of the same name is triggered. As init boots up, it will activate the early-init, init, early-fs, fs, post-fs, early-boot, and boot triggers in turn, triggering the corresponding command blocks.

If the configuration file pulls along a few 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 combined with the main config, so that when the trigger is triggered, 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 for each device are written to separate files.

The most notable of the additional configs is initrc.device_name.rc, where the device name is automatically determined based on the contents of the ro.hardware system variable. It 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 a command like this:

Mount_all ./fstab.device_name

This means that init should now mount all filesystems listed in. / Fstab.device_name, 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 slightly modifying this file, 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 partitions: 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 (for different devices they are different) and replace them with the original device names in the fstab file.

At the end of the boot block, init will most likely encounter the class_start default command, which will inform you that you should then start all the services listed in the config that are related to the default class. A service description begins 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 the blocks, services must be running all the time, so throughout the life of the smartphone, init will hang in the background and monitor it.

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

Init.rc Commands

The init process has a built-in command set, many of which are the same as the standard Linux command set. The most notable ones are:

• exec / path / to / commands- run an external command;
• ifup interface- bring up the network interface;
• class_start class_name- start services related to the specified class;
• class_stop class_name- stop services;
• insmod / path / to / module- load the kernel module;
• mount FS device directory- connect the file system;
• setprop name value- set a system variable;
• start service_name- start the specified service;
• trigger name- enable the trigger (execute the specified block of commands);
• write / path / to / file line- write a line to a file.

Step four. Zygote and app_process

At a certain stage of loading, init will come across 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 initializing, starting system services, starting and stopping custom applications, and many other tasks. Zygote is launched using a small application / system / bin / app_process, which is very clearly seen in the above piece of config. The task of app_proccess is to start the Dalvik virtual machine, the code for which is located in the shared library /system/lib/libandroid_runtime.so, and then start Zygote on top of it.

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

After that, Zygote opens the socket / dev / socket / zygote and goes to sleep, waiting for data. At this time, the previously launched Activity Manager sends the broadcast intent Intent.CATEGORY_HOME to find the application responsible for creating the desktop, and gives its name to Zygote via the socket. The latter, in turn, forks and runs the application on top of the virtual machine. Voila, we have a desktop on our screen, found by Activity Manager and started 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 received by the Activity Manager and will send the command to start the application to the Zygote daemon

INFO

In Linux terminology, a RAM disk is a kind of virtual hard disk that exists only in RAM. Early in the boot phase, the kernel extracts the contents of the disk from the image and mounts it as a root filesystem (rootfs).

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 is displayed in the early stages of initialization and is written to the /initlogo.rle file (almost unused today), the latter is launched using the bootanimation application and is contained in the /system/media/bootanimation.zip file.

In addition to standard triggers, init allows you to define your own triggers that can be triggered by a variety of events: connecting a device to USB, changing the state of a smartphone, or changing the state of system variables.

Among other things, Activity Manager also deals with killing background applications when there is a lack of memory. The free memory thresholds are contained in the file / sys / module / lowmemorykiller / parameters / minfree.

All this may look a little 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 right away. However, if you understand how everything works, there are 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.

middleware, is a set of libraries (Libraries) designed to solve typical tasks requiring high efficiency. That is, it is this level that is responsible for providing the implemented algorithms for the higher levels, supporting file formats, encoding and decoding information (for example, multimedia codecs), rendering graphics, and much more. Libraries are implemented in C / C ++ and compiled for a specific Hardware devices, together with which they are supplied by the manufacturer in a pre-installed form.

Let's list some of the low-level libraries:

1. Surface Manager - Android OS uses a composite window manager similar to Compiz (Linux), but more primitive. Instead of drawing graphics directly to the display buffer, the system sends incoming drawing commands to the offscreen buffer, where they are accumulated together with others, making up a kind of composition, and then displayed to the user on the screen. This allows the system to create interesting seamless effects, window transparency and smooth transitions.
2. Media Framework - libraries based on PacketVideo OpenCORE. With their help, the system can record and playback audio and video data, as well as output static images. Many popular formats are supported, including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG. In the future, OpenCORE should be replaced by the simpler Stagefright framework.
3. SQLite is a lightweight and powerful relational database management system used in Android as the main engine for working with databases.
4. 3D libraries - used for highly optimized drawing of 3D graphics, using hardware acceleration when possible. Their implementations are based on the OpenGL ES 1.0 API.
5. FreeType is a library for working with bitmaps, as well as for rasterizing fonts and performing operations on them. It is a high quality font and text rendering engine.
6. LibWebCore - libraries of the well-known browser engine WebKit, which is also used in the desktop browsers Google Chrome and Apple Safari.
7. SGL (Skia Graphics Engine) is an open source 2D graphics engine. The graphics library is a product of Google and is often used in other programs.
8. SSL - libraries for supporting the cryptographic protocol of the same name based on OpenSSL.
9. libc is a library of standard C language calls, analog of glibc (GNU libc from Linux) for small devices. It is called Bionic.

Rice. 1.5.

At the same level, the Android Runtime is located - the application execution environment. Its key components are a set of standard libraries and virtual machine Dalvik. Each Android application runs in its own instance of the Dalvik virtual machine. Thus, all running processes are isolated from the operating system and from each other. The architecture of the Android Runtime is such that programs run strictly within the virtual machine environment. This protects the operating system kernel from possible harm on the part of its other components. Therefore, code with errors or malware will not be able to spoil the Android OS and devices based on it. This protective function, along with code execution, is one of the key to the Android Runtime.

The Application Framework, sometimes referred to as the Application Framework tier, is one level up. It is through the application frameworks that developers gain access to the APIs exposed by the underlying system components. In addition, thanks to the architecture of the framework, any application is provided with the already implemented capabilities of other applications, which are allowed to be accessed. The basic set of services and systems that underlie each application and are part of the framework include:

1. A rich and extensible set of Views that can be used to create visual application components such as lists, text boxes, tables, buttons, or even an embedded web browser.
2. Content Providers, which manage the data that some applications open for others to use for their work.
3. Resource Manager, which provides access to non-code resources, such as string data, graphics, files, and others.
4. Notification Manager, thanks to which all applications can display their own notifications to the user in the status bar.
5. The Activity Manager, which manages the life cycles of applications, stores data about the history of working with activities, and also provides a navigation system for them.
6. Location Manager, which allows applications to periodically receive updated information about the current geographic location of the device.

At the top of the Android software stack is the Applications layer. This includes a set of basic applications that comes pre-installed on the Android OS. For example, it includes a browser, an email client, a program for sending SMS, maps, a calendar, a contact manager and many others. The list of integrated apps may vary depending on the device model and Android version. And in addition to this basic set, the application level includes all application applications for the Android platform, including those installed by the user.

As a rule, applications for Android are written in the Java language, but it is possible to develop programs in C / C ++ (using the Native Development Kit). Exotic is the use of Basic (using Simple) and other languages. You can also create your own programs using application designers such as App Inventor.

1.6. Kernel features

The kernel is the most important part of the Linux OS, and unlike other parts of it, it has been ported to the Android OS almost entirely. However, about 250 patches were applied to the kernel during the porting process.

In the core of the Android OS, it was decided to abandon the interprocess communication tools of the Linux OS and instead create a single mechanism called Binder. Binder allows you to call methods of one process from another process, passing them arguments and getting the result, just like methods are called within one process. Binder does the job with minimal memory usage.

To provide debugging on small devices, debug output has been added to the kernel in serial port and support for the logcat command has been implemented.

Big changes have been made to working with memory. The traditional Linux shmem shared memory has been replaced by ashmem. The same task, but at the level of physical memory, is solved using the pmem driver. Added a special out of memory handler called Viking Killer, in the simplest case it just kills the process, but more complex rules can be specified.

New security settings have been added to the networking stack, YAFFS2 flash file system support is included in the kernel.

1.7. Dalvik Java Machine

Dalvik Virtual Machine is part of the Android mobile platform. This virtual machine by Dan Bronstein. It spreads like free software under the BSD-compliant Apache 2.0 license. In many ways, it was this fact that played a role in Google's decision to abandon the JME (Java Micro Edition), which would need to be licensed from Sun. Therefore, the corporation, whose goal was to create an open operating system, developed its own virtual machine.

Unlike most virtual machines (the same Java Virtual Machine), which are stack-oriented, Dalvik is case-oriented, which cannot be called a standard solution. On the other hand, it is very well suited to work on RISC-architecture processors, which include ARM processors, which are very widely used in mobile devices.

Dalvik was designed specifically for the Android platform. The fact was taken into account that the platform builds all processes as isolated, each running in its own address space. Virtual machine optimized for low memory consumption and mobile hardware. Since Android 2.2., Dalvik uses JIT (Just-in-Time) compilation. As a result of these features, the result is fast and efficient virtual machine, which cannot but affect the operation of applications in general.

Dalvik uses its own bytecode. When developing, applications for Android are translated by the compiler into a special machine-independent low-level code. When executed on a platform, it is Dalvik that interprets and executes such a program.

In addition, Dalvik is able to translate Java bytecodes into native codes and also execute them in its virtual environment. The program code is written in the Java language, and after compilation, that's it. class files are converted to .dex format (suitable for interpretation by Dalvik) using a special dx utility included with the Android SDK.

1.8. Bionic

Bionic is a BSD (Berkeley Software Distribution) C library of standard calls developed by Google for Android. Bionic lacks some non-Android POSIX features available in the full glibc implementation.

The main differences between bionic:

1. BSD licenses: Android uses a Linux kernel that is under the GNU General Public License (GPL), but Google wanted to isolate Android apps from the effects of the GPL. The GNU libc that is commonly used with the Linux kernel is licensed under the GNU LGPL as an alternative to uClibc.
2. small size: bionic object code is much smaller (about 2 times) than glibc and slightly smaller than uclibc.
3. bionic is designed for processors with relatively low clock speeds.
4. a truncated but efficient implementation of POSIX threads.

1.9. An Overview of Java APIs for the Application Programmer

For the Android application programmer, a set of Java interfaces. Let's see how it is organized. The set is based on packages included in the Java language standard, such as java.util, java.lang, java.io. They are available on any platform where java applications can be run, and are not specific to Android. They are accompanied by extensions that are not included in the language standard, but de facto have long been standard - packages javax.net, javax.xml.

Also included in Android are less common Java extensions - the org.apache.http package, the most solid implementation of the HTTP protocol. The org.json package is responsible for serializing JavaScript objects and supporting AJAX technology. The org.w3c.dom package provides a document object model

The Android operating system consists of a set of components such as applications, application framework, libraries, runtime and Linux kernel. The figure shows a diagram of the main components of the Android operating system.

Figure 2.1 - Main components of Android OS

Application layer

The Android OS includes a set of basic applications: email and SMS clients, a calendar, various maps, a browser, a program for managing contacts, and much more. All applications run on Android platform are written in Java.

Application framework layer

Android OS allows full use of the API used in kernel applications. The architecture is built in such a way that any application can use the already implemented capabilities of another application, provided that the latter opens access to the use of its functionality. Thus, the architecture implements the principle of reusability of OS components and applications.

All applications are based on a set of systems and services:

action manager ( ActivityManager) manages the life cycle of applications and provides a navigation system for the history of work with actions;

content providers ( ContentProviders) Are services that allow applications to access data from other applications, as well as provide access to their own data;

representation system ( ViewSystem) Is a rich set of extensible views that you can use to build appearance applications that include components such as lists, tables, input fields, buttons, etc .;

resource manager ( ResourceManager) is intended for access to string, graphic and other types of resources;

notification manager ( NotificationManager) allows any application to display custom notifications in the status bar.

Library level

The Android platform includes a set of C / C ++ libraries used by various OS components. For developers, access to the functions of these libraries is implemented through the use of ApplicationFramework. Some of them are presented below:

SystemClibrary- BSD implementation of the standard C system library (libc) for embedded devices based on Linux;

MediaLibraries- libraries based on PacketVideo'sOpenCORE designed to support playback and recording of popular audio and video formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, etc.);

LibWebCore- the core of the built-in web browser;

SurfaceManager- the surface manager controls access to the subsystem for displaying 2D and 3D graphic layers;

SGL ( ScalableGraphicsLibrary ) - a library for working with 2D graphics based on the SDL library (SimpleDirectMediaLayer);

3Dlibraries- libraries for working with 3D graphics based on the OpenGLES 1.0 API;

FreeType- a library designed to work with fonts.

SQLite- lightweight relational database management system.

Runtime level

The Android operating system includes a set of core libraries that provide most of the functionality of the Java core libraries.

The platform uses the optimized, register-oriented Dalvik virtual machine, in contrast to which the standard Java virtual machine is stack-oriented. Each application runs in its own process, with its own virtual machine instance. The Dalvik virtual machine uses the DalvikExecutable (*. Dex) format, which is optimized for minimal application memory usage. This is provided by basic Linux kernel features such as threading and low-level memory management. Bytecode The Java that your applications are written in is compiled to dex format using the dx utility included with the SDK.

Linux kernel level

The Android operating system is based on the Linux operating system 2.6, thus the platform provides access to system services of the kernel, such as memory and process management, security, networking and drivers. Also, the kernel serves as an abstraction layer between the hardware and software.