What is boot in android. What is Bootloader on Android. Downloading and installing FastBoot

To be able to fine-tune OS and hardware parameters, users of mobile devices running Android sometimes root their gadgets and also make changes to . But that's not all available methods obtaining expanded access to device and system settings. You can look under the “hood” of the device using a mode called Fastboot Mode.

What is Fastboot Mode

What does Fastboot Mode mean and what does it have to do with fine tuning? In some laptop models, it really serves to maximize system boot speed, bypassing the BIOS and debugging applications; in mobile devices, its purpose is somewhat different. On Android smartphones and tablets, this mode is necessary primarily to provide access to and control of the system components of the device using a computer.

Using the capabilities of Fastboot Mode, service center specialists and experienced users can install software, flash the gadget, restore applications, perform backup and recovery, change hidden system settings. Developers often resort to “fast loading”, using it for software testing and other purposes.

Having explained the purpose of the mode, it seems that we still haven’t answered the question of what Fastboot Mode essentially is. So, fastboot in Android is separate, independent from the operating system software component, implemented at the hardware level and registered in the memory chip. It is this independence that allows the device to boot even if serious problems occur with the operating system. The Fastboot Mode program code is located in a memory area that is protected from reading and writing, which prevents it from being damaged.

In what cases is Fastboot Mode activated?

The Fastboot environment can be launched manually through the standard menu or by simultaneously pressing the power button and the volume down/up key on the switched off device. But in some cases the mode starts on its own, and this is not a very good thing. The reasons for spontaneous loading may be unsuccessful flashing, replacement of the standard recovery environment with a modified one, gaining superuser rights, system failure and damage to Android OS files.

How to exit Fastboot mode

The activation of the mode is indicated by the image of the opened robot and the inscription on the phone screen Fastboot Mode.

If you have not made any changes to the gadget’s configuration before, perhaps the reason for switching to “fast boot” was some kind of temporary glitch. Try restarting your smartphone. If even after a restart the phone says fastboot and does not switch to normal operating mode, this may indicate deeper problems. It is possible that the problem will turn out to be so serious that the gadget will have to be reflashed at a service center, but until it comes to that, you should try to exit the fastboot yourself.

There are two main ways to do this: through the phone itself and using a computer. If a normal reboot does not help, turn off the device, and then simultaneously hold down the power and volume down keys until (about 10 seconds) the Select Boot Mode menu appears on the screen or the phone boots up in normal mode. In this menu, select the Normal Boot option and wait for the gadget to boot in normal mode.

In some cases, removing the battery helps to exit the debugging mode, if it is, of course, removable.

Sometimes users have to deal with loading in fastboot mode after they have picked up the gadget from the service center. This usually happens after. The probable reason is that the fastboot mode function was left enabled in the settings. If this is the case, then to disable Fasboot Mode, go to the settings, and then in the “Display” or “Accessibility” section, find the “Fast boot” item and uncheck it.

How to exit Fastboot Mode using a computer? Install applications on your PC, connect your phone to the computer, activate USB debugging, run the command line as administrator and run the command fastboot reboot. It's simple but very effective method disabling fastboot.

If this does not solve the problem, reset the device to factory settings. After copying all important data, remove the SIM card and memory card from the phone, boot into Recovery mode, find the option in the menu Wipe data/factory reset and perform a rollback using it.

Additionally, you can clear the storage contents by selecting the option Wipe cache partition.

How to put your phone into Fastboot Mode

Fastboot Mode is a service mode that you most often have to resort to if you need to change the device configuration via a PC, for example, install modified firmware or get root rights without using third party programs. Booting in fastmode may also be necessary to provide full access to system Android folders and OS recovery (as an alternative to Recovery mode tools).

How to enter Fastboot Mode on different devices ah may differ. IN Asus smartphones To do this, you need to hold down the power and volume up buttons, in Nexus and HTC - the power and volume down buttons, in Sony, fastboot mode will load if you hold down volume up and connect the gadget to the PC via USB.

But there is also a universal way to load into a fastboot, which works equally on all mobile devices. Android devices. Download and install the program on your computer Adb Run . Next, enable USB debugging in the phone settings, connect the device to the PC and, having launched Adb Run, select from the menu Reboot – Reboot Bootloader.

The gadget will reboot in Fastboot mode.

Android OS like any other software, may occasionally fail. And one of these problems is the display of a black screen on the screen of a smartphone or tablet with the words Fastboot Mode or Select Boot Mode. Many owners of mobile devices, seeing a similar picture, begin to panic and take the device to the nearest workshop. However, you should not take rash actions, since in most cases you can exit Fastboot Mode yourself. Let's look at what causes Fastboot Mode, what it is on Android and how to get rid of it.

Purpose and causes

Fastboot is an effective tool for modifying and customizing the Android operating system, which is included in the software package for developers. Its main task is to install custom firmware. However, this bootloader is also used to install backups, various updates, format a memory card, etc.

Select Boot Mode and Fastboot Mode are not internal or external commands. They start earlier than the operating system itself (like the BIOS on Windows). This allows you to configure the system, as well as fix various problems even if Android has crashed.

Despite its versatility and usefulness, turning on Fastboot on its own may be a sign of a software failure. The main reasons for the appearance of this mode on Android include:

1. Accidental activation by the user. This tool can be launched manually through the gadget menu.
2. Android malfunction. If a smartphone or tablet cannot boot in normal mode, it automatically switches to Fastboot Mode.
3. Unsuccessful firmware via .
4. Manually removing an executable file from the system directory after root unlock access.
5. Exposure to malware. If you have superuser rights on the device, some viruses can be blocked or even removed system files, which leads to a crash of the operating system.

Having figured out what the Fastboot Mode bootloader is and what are the reasons for its appearance, you can begin to consider the question of how to exit boot mode on Xiaomi, Meizu, Lenovo and other models of mobile devices.

Disabling Fastboot Mode on Android

There are two ways to disable the Fastboot bootloader:

• directly from your phone;
• via PC.

The choice of one option or another depends on the reason that led to the launch of this mode. As an example, let's look at how to prevent the Fastboot window from loading on a Xiaomi smartphone.

When faced with this problem, first try holding down the Power key for 20-30 seconds. The device should reboot in standard mode.

Instead of Fastboot, the Select Boot Mode form may appear on the mobile phone screen. Its fields mean the following:

Try choosing the second option. If this does not help, do the following:

If you can go to Xiaomi settings, that is, the OS is working, try to disable the Fastboot mode manually. On this device, go to the “Accessibility” tab and opposite the corresponding item, drag the slider to the Off position.

Disabling Fastboot Mode via Computer

If the operating system crashes, when it is technically impossible to use the smartphone menu, and other methods of disabling Fastboot are ineffective, you can try to solve the problem through a PC and command cmd line. This is done as follows:

The command line is the most effective way to get rid of Fastboot Mode. If this does not solve the problem, then the question is how to enable mobile device in normal mode, is still relevant, all you have to do is change the firmware on the phone or take it to a workshop.

Editor's Choice

Fastboot Mode in Android: we carry out [manipulations with the gadget] at the system level

Sometimes phone or tablet users Android based encounter Fastboot Mode without absolutely understanding what it is?

When they turn on their gadget, they see a screen with animation and some list of data, which is more reminiscent of a system failure.

Usually, A regular reboot won't solve this problem and it’s better to follow the instructions step by step than to try to figure it out on your own. After all, it is one of the system ones, and a user who is poorly versed in such things can accidentally harm his own gadget.

Subsequently, because of this, you will have to contact the service, wasting your time and money. But this can be easily avoided if you figure out the problem without unnecessary haste.

Below you can find out in detail what it is, why the process occurs and how to act when it appears.

Contents:

What it is

On Android operating system it provides full access to a smartphone or tablet to control it via a computer. This approach allows:

• install applications;
• configure various parameters;
• flash the gadget;
• distribute access rights.

Fastboot is not part of one specific OS, but it can often be found in the Android SDK environment, because without it it will not be possible to fully establish communication between the PC and the gadget.

In this case, we mean difficult data transfer, namely setting up the device.

It is worth noting that it starts earlier than the operating system itself. This suggests that the mode can be used even when it is not yet installed on your gadget.

Why does it occur

Having such a mode is very useful, but what to do when you don’t need to configure your smartphone in this way, and a window suddenly appears?

Reasons for its appearance may be different:

• error when flashing the gadget;
• accidental key presses – turning on the smartphone and increasing the volume at the same time;

• obtaining root user rights;
• system failure.

In any of these cases, the Android icon will appear on the device screen, as well as system information for your gadget.

To begin with, if Fastboot occurs, you should check if .

The volume up and down buttons are active - with the first we scroll through the items that are displayed on the screen, and with the second we make a choice (like using a key Enter on PC).

Thus, we reach the inscription "NormalBoot" and select it with the volume down button.

If after that the smartphone turns on quietly, then this, at a minimum, indicates that there are no problems with it and a system failure is also not the cause. Sometimes it occurs due to the connection to the computer.

Synchronization occurs, you do everything necessary actions: you install a new application, upload a photo or download a movie, and then, when you disconnect from your PC, you see that it does not disappear.

This is due to the fact that the service center probably did not disable this function. You can deal with this on your own:

• after the gadget loads normally, go to it "Settings";
• then select the tab "Screen";
• Having found the item in it, uncheck it.

Thus, the fastboot mode will be deactivated, and when turned on, it will no longer disturb the user.

What to do in case of a system failure

If the transition to "Normal Boot" blocked or, even worse, only one message is visible on the screen "Fastboot Mode" and there is no summary of parameters, then for some reason the gadget’s system has failed and there are two options on how to fix everything.

Option 1

You can always try to restore the system and return the smartphone to working condition again.

Important! During recovery, all data stored on the smartphone is formatted, so it is better to protect yourself and first remove the memory card.

First, you need to hold down the power and volume up buttons at the same time. In the menu that appears, find the item – wipe data/factory reset.

And then select it and wait until all settings are rolled back. The process may take from one to several minutes.

The gadget will reboot, and you will again be able to use it for your own purposes.

But installed applications and bookmarks in the browser will have to be restored again, because such a procedure returns it to factory settings.

Option 2

You should resort to this option as a last resort when none of the methods described above definitely work.

If the mode that appears when you turn it on does not contain parameters, if rebooting the gadget does nothing and you can’t even call it up, then you have to do the following:

• remove the battery;
• insert it back;
• Press and hold the power button for at least 30 seconds.

The return of Fastboot Mode will make it clear that it’s time to move on to more drastic actions.

You will have to reboot the device, but through the computer.

Note! To work with a smartphone that has experienced a system failure, you will need suitable drivers.

Not that difficult.

Just use a search engine, and from a series of suggested sites offering to download “firewood”, try to choose official ones in order to eliminate unpleasant incidents associated with the introduction of viruses, etc.

1 Unzip downloaded “firewood”;

2 Data from the archive put it in a folder;

3 After connect the gadget to the PC via USB cable;

4 You will have to spend some time waiting, while the computer recognizes the smartphone, after which he will offer to install drivers to start working with the gadget;

5 Since we have already pre-downloaded them, then select “Install from a specified location”;

6 Select the folder in which you placed them and click Enter.

After the drivers are successfully installed, let's move on to working with the device via the command line.

• go to the menu "Start";
• in the execution line we write "cmd";

This method, which includes the use of a PC, is the most effective. But it’s still best to resort to it when smaller and simpler recovery actions probably won’t work.

How to enter settings

If such a need arises, everything will depend solely on the model of smartphone you use.

But, despite this, you will need a computer and. Be sure to turn off the gadget before starting.

After working with this mode, so that it does not bother you regularly, it is best to disable it again in the settings.

Have you ever wondered how fastboot or ADB work? Or why is it almost impossible to turn a smartphone running Android 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 part of Android or a thing in itself and why to install third party firmware Regular recovery doesn't work? You will find answers to all these and many other questions in this article.

How Android works

Find out about hidden possibilities software systems you can by understanding the principle of their operation. In some cases, this is difficult to do, since the system code may 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 only focus on how the OS starts 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 application storage space, 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 stored in permanent memory devices. It then passes control to the aboot bootloader, which has built-in support for the fastboot protocol, but the manufacturer mobile chip or smartphone/tablet has the right to choose any other bootloader to his taste. For example, Rockchip uses its own bootloader that is not fastboot compatible and requires proprietary tools to flash and manage.

The fastboot protocol, in turn, is a system for managing the bootloader from a PC, which 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 a 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 NAND memory partitions 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 begins loading either Android or the recovery console. NAND memory in Android devices is divided into six conditionally required 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 the size is at least 1 GB;
• cache - designed for storing cached data, also used to save 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 what mode the system should boot in: Android or recovery.

In addition to them, there may also be other sections, but 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 fastboot commands oem format; 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 flashing the bootloader is not necessary to change it.

The misc section is especially interesting. 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 indicate to the bootloader from which partition the system should be loaded - boot or recovery. This feature, in particular, is used by the ROM Manager application to automatically reboot the system into recovery with 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. Erased the misc partition - Android loads, filled it with data - recovery loads... that is, Ubuntu Touch.

Step two. Boot section

If the misc section does not have a recovery boot flag, aboot transfers control to the code located in the boot section. This is nothing more than the Linux kernel; it is located at the beginning of the section, and immediately followed by 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 simply follow each other. The contents of the RAM disk are:

• 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 utility utilities and daemons (adbd, for example);
• sys - sysfs is mounted here;
• system - directory for mounting the system partition;
• charger - application for displaying the charging process;
• build.prop - system settings;
• init - initialization system;
• init.rc - initialization system settings;
• ueventd.rc - settings of 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 the rest of the work of booting the system. The central element here is the init application and its init.rc config, which I will talk about in detail later. In the meantime, I would like 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 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 load, 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 ordinary 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 during system boot. In systems based on the Linux kernel, access to hardware is carried out through special files inside the dev directory, and the ueventd daemon, which is part of init, is responsible for their creation in Android. In a normal situation it works in automatic mode, accepting commands to create files from the kernel, but some files must be created independently. They are listed in ueventd.rc.

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

The proc directory for Linux is standard; in the next boot stages, init will connect procfs, a virtual file system, which provides access to information about all system processes. 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 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 currently inaccessible system/build.prop file.

Takeaways from the text

• Fastboot will remain in place even if, as a result of experiments, you erase the contents of all NAND memory sections from your smartphone
• The recovery section is completely self-sufficient and contains a miniature operating system, which has nothing to do with Android
• By slightly modifying the fstab file, we can force init to boot the system from the memory card

Step two, alternative. Recovery section

If the recovery boot flag in the misc section is set or the user turns on the smartphone with the volume down key held down, 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 unpacked into memory and becomes the root of the file system. However, the contents of the RAM disk are somewhat different here.

Unlike the boot section, which acts as a transition link between different stages of OS loading, recovery section is completely self-contained and contains a miniature operating system that is in no way related to Android. Recovery has its own core, its own set of applications (commands) and its own interface that allows the user to activate service functions.

In a 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 recoveries, such as ClockworkMod and TWRP, have 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 purposes) and include script support, which allows you to automate the firmware process and many other functions.

Using scripts, for example, you can make sure that after booting, recovery is automatically found on the memory card required firmware, installed them and rebooted into Android. This feature is used by the ROM Manager, auto-flasher, and the automatic update CyanogenMod and other firmware.

Custom recovery also supports backup scripts located in the /system/addon.d/ directory. Before firmware recovery checks for scripts and executes them before flashing the firmware. 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 both volume buttons. After this, you should go to the platform-tools subdirectory inside the SDK and run the command

Fastboot devices

The device name will be displayed on the screen. Other available commands:

• fatsboot oem unlock- unlocking the bootloader on nexuses;
• update file.zip- installation of 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, after initializing all its subsystems and drivers, starts the init process, which begins the initialization of Android. As I already 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. However, its format is quite simple and is essentially a set of commands divided into blocks.

Each block defines a loading stage or, in Android developer parlance, an action. Blocks are separated from each other by an on directive followed by the name of the action, 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 activate the early-init, init, early-fs, fs, post-fs, early-boot and boot triggers in turn, thus launching the corresponding command blocks.

If the configuration file pulls along 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 combined 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 creating configuration files for several devices, when the main config contains commands common to all devices, and those specific to each device are written in separate files.

The most notable of the additional configs is named initrc.device_name.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 file systems listed in the file ./fstab.device_name, which has the following structure:

Device_name (partition) mount_point file_system fs_options other options

It usually contains instructions for mounting 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 card. To do this, just divide 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 them with the original device names in the fstab file.

At the end of the boot init block, it 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. The description of services begins with the 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 this.

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 set of commands, many of which are standard Linux commands. The most notable of them:

• exec /path/to/command- run an external command;
• ifup interface- raise the network interface;
• class_start class_name- start services belonging 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 encounter something like this block 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 the config. The app_proccess task is to launch 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.

Once all this is done and Zygote is in control, it begins building the Java application runtime by loading all the framework's Java classes (currently over 2000 of them). 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 this, Zygote opens the socket /dev/socket/zygote and goes to sleep, waiting for data. At this time, the previously launched Activity Manager sends a 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 launches the application on top virtual machine. Voila, we have a desktop on our screen, found 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, Activity Manager will receive it and send a 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 random access memory. Early in the boot process, the kernel extracts the disk contents from the image and mounts it as the root file system (rootfs).

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

In addition to standard triggers, init allows you to define your own triggers, which 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 kills background applications when there is insufficient memory. Free memory threshold values ​​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 it’s hard to figure it out right away. 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.