Mobile Phone Management application Research "3"--Mobile phone acceleration Chapter

Welcome reprint, Reprint please specify: HTTP://BLOG.CSDN.NET/ZHGXHUAA

Description

In the previous article described "Garbage cleanup", in the system optimization has a function is often not with the garbage cleanup, that is, "mobile phone acceleration." There is no clear definition of what "garbage cleanup" is called "mobile acceleration" in popular management software and on the Web. In conjunction with the previous article "Garbage cleanup" Here is a unified definition of this article in this series:

n Garbage Cleanup: In this series of articles, it is considered that static content is scanned and cleaned, including file caches, thumbnails, logs, and other systems or files created by applications that do not have a run-time feature.

N Mobile Acceleration: In this series of articles, it is considered that the cleanup is dynamic content , including killing the runtime process, restricting boot-start, restricting background self-booting, and the memory used by the app when it runs, all of which are process-dependent and have a run-time feature.

After making a simple distinction between garbage cleanup and mobile acceleration, this article will look at the related content of mobile acceleration.

Clean up the run-time process

Clean up the runtime process is to clean up the background process, some mobile phone management software is also called "one-click acceleration" or "one-click Cleanup", in fact, refers to this function.

Before the formal introduction of the process cleanup, let's briefly describe some of the memory management strategies for processes in Android.

Android Memory Management Policy

In Android, the lifecycle of a process is controlled by the system, and even if the user shuts down the program, the process remains in memory. The purpose of this design is to be able to start quickly next time. Of course, as the system runs, memory gets smaller. Android Kernel will perform a check periodically, kill some processes, and release memory.

The Android-to-memory management introduces a mechanism used in Linux that is called Oom (out of memory, not enough) to accomplish this task, which will select a process and kill it if the system is out of memory. In Android, the native oom mechanism of Linux has been modified according to the characteristics of the embedded device, so there is a low Memory Killer.

Memory management is not the focus of this article, want to know low memory killer friends can check the relevant data or view the source code, here do not do a detailed introduction. The position of low Memory killer in the source code is: @/kernel/goldfish/drivers/staging/android/lowmemorykiller.c. Here are the questions to be clarified by two points:

A. Low memory killer specifies a set of memory thresholds in the user space that will be killed when one of the values is in the same range as the Oom_adj value in the process description.

B. The oom-related parameters in Android are initialized in Init.rc and are dynamically adjusted by Activitymanagerservice when the system is running.

Android Process Priority

Depending on the oom_adj,android, the process is divided into 6 levels, which are ranked from highest to lowest in order of precedence:

1) foreground process (Foreground_app)

2) Visual process (Visible_app)

3) Secondary service process (Secondary_server)

4) Background process (Hidden_app)

5) Content Supply node (content_provider)

6) empty process (Empty_app)

The value of the Oom_adj for these six types of processes may vary in different phones. Here are the parameters on my Xiaomi 2S phone:

Note the larger the value, the less important the process is.

On my Xiaomi 2S, these processes will be killed in the following time:

Note that the units for these numbers are page. 1 page = 4 KB.

For the value of Oom_adj for a single process, you can view the value of/proc/pid/oom_adj as follows:

Clean up the run-time process

After a simple understanding of Android's management strategy for processes and memory, we find that the low memory killer strategy in Android scans regularly and kills processes based on their policies. What reference would that give us to clean up the run-time process?

One of the possible scenarios in which we kill the runtime process: You can set a threshold based on the value of the Oom_adj, and when the user triggers (and, of course, timing triggers), it kills if the Oom_adj value of the process is greater than the threshold. There are two ways to kill a process, as described below:

Choose to kill the process at the Linux level

You can choose to read the value of/proc/pid/oom_adj according to the method in 1.2, and then kill the process through the KILL function in Linux.

At the Android level, the system defines the importance of the process through the following attributes:

@/frameworks/base/core/java/android/app/activitymanager$runningappprocessinfo

Where the value of importance is as follows, the meaning of each value is in the following comment:

Some sample code to kill the process in this way is as follows:

In the example code above, we kill the process through the Killbackgroundprocesses interface in the Activitymanager class, and here's a look at killbackgroundprocesses:

Here are a few points to note:

A. However, this method only kills processes with a process priority lower than SERVICE_ADJ.

B. Using this method requires declaring Kill_background_processes permissions

C. This interface is a public interface in Activitymanager and does not require any permissions.

For the most part, it is enough to kill the background process by invoking the interface, but sometimes we have to execute a more rigorous process cleanup strategy to kill the higher-priority processes. The following section provides an introduction.

A more rigorous process-killing scenario

Follow the last question in the previous section to continue the analysis and see how the system chooses to kill processes that are below the specified priority level. Although there is no interface for us to use on Android, we can be sure that Android itself will have our similar needs. Finally I found the system implementation of this function in Activitymanagerservice (hereinafter referred to as "Ams"), as follows:

@/frameworks/base/services/java/com/android/server/am/activitymanagerservice.java

@/frameworks/base/core/java/android/os/process.java

As can be seen from the above procedure, AMS actually invokes the Killprocessquiet method in android.os.Process when it kills the process. This is very clear, we can only achieve this process when the killing process.

Through the implementation of Killprocessquiet we can see that this method is a hidden method that cannot be called directly in the application. Looking closely at the process class, we found a similar implementation, the KillProcess method, as follows:

Here the killprocess and Killprocessquiet are the same, the only difference is that there will be "sendingsignal" when the process is killed by killprocess. PID:%d SIG:%d "" To print out the log. So, we can use the KillProcess method directly when we implement our own kill process logic.

A scenario that prevents the kill process from restarting

The three sections above in this section describe the feasibility of three kill processes, and it is also possible to verify that they are valid. However, a careful friend may encounter some of the following issues when validating the above scenario: the direct kill process

A. Some processes cannot be killed or restarted after being killed (mainly system applications and service).

B. An abnormal condition may occur when killing a process that is currently running.

So how do you solve this situation? By looking at Activitymanager's code, I found a way to do the following:

Take a closer look at the description of the Forcestoppackage method, oops, just beyond our expectations. By using the Forcestoppackage method, not only can you force the application process to stop, you can even forcibly stop some other related content related to the current process, such as:

• Other processes that share the UID with the current app.
• Service for all licensed operations
• All the activity
• Notice
• Timer

Further study of the implementation of Forcestoppackage found that the system will set the current package state to stopped state when calling Forcestoppackage. After the Android2.3 version, applications marked as STOPPED state cannot accept broadcasts unless the FLAG_EXCLUDE_STOPPED_PACKAGES flag is specified when the broadcast is sent, but the system broadcast is not considered to be the specified change flag bit.

The following is an internal implementation of the Forcestoppackage method:

@/frameworks/base/services/java/com/android/server/am/activitymanagerservice.java

Through the study of this method we can draw the following conclusions:

A. You need to declare force_stop_packages permissions when using the Forcestoppackage interface.

B. Forcestoppackage is a hidden interface that needs to be invoked by means of reflection.

C. A system signature is required to use the Forcestoppackage interface.

D. Forcestoppackage interface can be used to kill the process, but also to prohibit boot and background self-booting.

E. When using the Forcestoppackage interface, there may be unwanted side effects (emptying the timer, etc.), use caution.

F. The stopped status of the package is increased after Android4.0, that is, the version forcestoppackage prior to 2.3 does not disable power-on broadcasts.

An accelerated shortcut animation effect implementation

About UI-related content is not the end of this article, interested friends can refer to an article on the Internet:

http://blog.csdn.net/ruils/article/details/16922557

Post-boot management

We always know what we do, and then we can do it before. Therefore, before you know how to disable start-up, you need to come to know the principle of boot-up and the timing of the system issuing boot_completed broadcasts.

The principle of start-up self-booting

Android will send a standard broadcast, called "Android.intent.action.BOOT_COMPLETED" when the system is booted, when it is powered on. The so-called "boot self-start" is to register to receive boot_completed static broadcast, when the broadcast will be aroused.

Here is a short sample program:

To register a static boot_completed broadcast in Androidmanifest:

To make boot_completed broadcast effective, you need to declare receive_boot_completed permissions.

It's very simple here, we've basically used it, there's nothing to talk about. Here are a few points to be aware of:

A. When using boot_completed broadcasts, remember to declare receive_boot_completed permissions.

B. At the beginning of Android4.0, Android has added the package stopped status, and applications in that state are not receiving a boot broadcast. Applications in the stopped state include:

N calls the application that is stopped by the Forcestoppackage interface described in 1.3.4.

n Click the "Deactivate" button in the "Settings--apps---app Details page" to deactivate the app.

n New installations complete, apps that have never been opened and run.

C. In the previous version of Android2.3, there was no previous restriction that could receive a boot broadcast.

D. In later versions of Android4.0, if you want to enable applications in the STOPPED state to receive broadcasts, you need to add the flag flag_exclude_stopped_packages to intent. However, it is important to note that system broadcasts make it impossible for users to customize.

E. Boot_completed is a standard broadcast that, when developing an application, will sometimes want its application to specify "Android:priority" when it receives a boot-up broadcast earlier than other applications that receive a start-up broadcast. The value of the property is the largest integer (priority is shaping and the value range is 1000 to 1000).

Boot from the time in 2.1 we learned that the boot is through the acceptance of the system broadcast "boot_completed" implementation, that "boot_completed" is the system when issued? For the Android system boot process, not the content of this article, do not introduce, here only to talk about the power-on broadcast "boot_completed" related parts, as shown in:

You can see that the power-on broadcast is issued when the first application process (desktop) is started after the system starts.

Enable no boot from boot

Understand the principle of boot-up, and then introduce the development of mobile phone management software, how to implement the Prohibit application boot. From the previous analysis, let's think about the possible implementations of disabling the boot broadcast. The entire process of receiving and processing broadcasts from an application is in fact no different from the following possibilities:

A. Prevent the system from issuing A boot_completed boot complete broadcast.

B. Does not prevent the system from broadcasting, but prevents the app from receiving the boot_completed boot complete broadcast.

C. The app can receive boot_completed broadcasts, but blocks the app from responding.

D. The running app receives boot_completed broadcasts and responds, but prevents them from running after the response is applied.

Next, we will analyze the feasibility of these cases in turn:

A. The first option is difficult to implement at the level of application, and it is not feasible to be reasonable.

B. The second option is theoretically feasible, at least as far as the forcestoppackage described above can be done.

C. The third option, theoretically feasible, may be somewhat difficult (process injection).

D. The fourth option is also feasible and is relatively easy to do according to previous analyses.

The following is an analysis of specific implementation scenarios:

Disable power-on self-booting by stopping application implementation

For the second scenario above, "do not prevent the system from broadcasting, but prevent the application from receiving the boot_completed power-on complete broadcast" idea, I believe you will soon think of the 1.3.4 introduced in the Forcestoppackage this interface, this interface in addition to kill the running process, there are some "side effects", where the application status is set to "stopped" and emptying the timer. These are exactly what we need when implementing a no boot boot.

As a result of the use of the previous pair of forcestoppackage and the need to pay attention to the issue of a more detailed explanation, here no longer repeat, unclear friends can refer to 1.3.4.

Disable power-on startup by disabling broadcast receivers

Forcestoppackage interface can fully meet our needs, even more than our needs, not only disable the boot start, even the background from the start and so on are disabled. These side effects are often not what we want, is there a "side effect" of a relatively small implementation way? This leads to the implementation of this section.

This scenario is also based on the idea that the second scenario "does not prevent the system from broadcasting, but prevents the application from receiving the boot_completed boot completion broadcast."

At the beginning of the idea, there may be some kind of start-up feeling, no matter since the core of this program is "block broadcast reception", let's first look at how the static broadcast receiver in Android is defined, the following is the official Android document about receiver:

Citation: http://developer.android.com/intl/zh-cn/guide/topics/manifest/receiver-element.html

I do not know if you see the "android:enable" this property when there is not like me as the light of the feeling. As far as I am concerned, there is little focus on this attribute when developing common applications, because there is little need for this. Well, let's take a look at the "android:enable" attribute, as follows:

After reading this paragraph of the description, is not the feeling not only meet our needs, but also a small surprise? Yes, that's the phrase, "the<application> element has its own enabled attribute, applies to allapplication, includ ing broadcast receivers." This means that other application components other than receiver have the "android:enable" attribute. Oh, here is not for us to prohibit the background self-launched application also found a solution?

After understanding the "android:enable" attribute, take a look at its use:

@/frameworks/base/core/java/android/content/pm/packagemanager.java

In addition to setcomponentenabledsetting in Packagemanager, another interface setapplicationenabledsetting is provided, With setapplicationenabledsetting, you can deactivate all the components in your app, with the following code:

Here are a few things to keep in mind:

A. By calling Setapplicationenabledsetting, you can place all the components in your app in the disable state.

B. This interface does not empty the timer when compared to the Forcestoppackage interface, so if the application sends a custom broadcast via a timer, and the flag_exclude_stopped_packages is specified in the broadcast, it can be awakened.

C. Using the Setcomponentenabledsetting interface must be a system program and have a system signature.

D. Use this interface to declare change_component_enabled_state.

E. When the interface is applied to the entry activity in Androidmanifest (Intent-filter specifies an action of "Android.intent.category.LAUNCHER"), the You can also reach the effect of hiding the app shortcut icon.

Here is a snippet of code that uses the interface:

Deactivation of broadcast receiver scenario Research start-up management there is a small and beautiful software autostart believe that a lot of friends have heard, as follows: This software is the use of 2.3.2 introduced in the principle of implementation, the following is a small piece of anti-compiled code snippet:

A lot of friends will be here. There is a question: In the previous section, it is not said that the use of the Setcomponentenabledsetting interface requires system permissions (is the system program and has a system signature)? Autostart is not the system, how does it do it? A colleague told me that Autostart was reminded of me by "PM" commands, and look at the PM command:

Execute PM Required shell permissions, in the case of root access can be directly executed using. It also reminds us to be a little divergent and listen to other people's advice when it comes to analyzing a problem that is hindered.

Disable the broadcast receiver scenario and continue to explore

Friends who have used Windows systems know that there is something in Windows called a registry that maintains information about installed apps on Windows systems. There is no such thing as a registry in the strict sense of Android, but there is a similar file "/data/system/packages.xml" in Android for maintaining the installation package information, such as:

After the setcomponentenabledsetting is set, the following data is eventually generated in the Packages.xml:

That in the case of root access, directly modify Packages.xml can not achieve the effect of stopping self-priming? You might as well verify yourself that this should not be possible. Because Packages.xml is resolved at the time of Packagemanagerservice service initialization, the data stored in the memory data structure is later used, and the direct modification of the Packages.xml file cannot achieve the purpose of modifying the in-memory data. This should be in effect when restarting the phone next time (no verification).

Disable boot from boot by killing process

This scenario is an analysis and discussion of the fourth scenario, "Running an application that receives boot_completed broadcasts and responds, but prevents them from running after the application responds." The idea of this scenario is this:

If we can receive "boot_completed" as soon as possible after the system boot, and then monitor other application processes, we will force kill if we find that other applications are being started. This also achieves the purpose of prohibiting the application from booting. Several key points in this scenario are analyzed in turn:

A. How can I start early?

Combining the principles described in 2.1 and 2.2, here we can take two steps:

1) The priority of the specified receiver is the maximum integer

2) The category "Android.intent.category.HOME" is specified for receiver

B How to monitor the current process?

Self-initiates a timer, periodically polls the running service, and performs cleanup work.

Applications that query the boot start can be implemented via the following interface provided in Packagemanager:

In addition to killing the boot-up application process, the background-initiated process can also be killed on timed wakeup. The methods for obtaining running services and application are provided in Activitymanager, as follows:

C How to kill the process?

You can use the android.os.killProcess described earlier, or you can use the Killbackgroundprocesses interface in the Activitymanager. The Restartpackage interface in the Activitymanager can also achieve the same purpose, but it is deprecated.

The problem with this scenario:

A. The use of timed polling to achieve, their own comparison of power consumption.

B. In addition to restricting boot-up, you can also use it to restrict background self-booting.

C. You can determine if you have the "Android.permission.RECEIVE_BOOT_COMPLETED" permission when you get the start list.

Kill process Scenario Case study There is also a well-known application "Autorunmanager" in applications that use the kill process scheme, as follows:

Autorunstartupintentreceiver after receiving the open broadcast, start the Autorunservice service:

After the Autorunservice service starts, start a timer to perform the H task:

H Task reader power on from startup settings, if the program does not allow booting, then kill the program process:

Note: The Content section of this section is referenced from http://blog.csdn.net/androidsecurity/article/details/8623264

Background self-start management

The so-called name is not right, in the analysis of the background since the start, here first on the boot and background from the start to make a conceptual distinction. The definitions are not found on the web, and are mainly based on your own understanding of the definitions in this series of articles.

• Boot from:

1) from the start time: Occurs when the start is complete.

2) from the starting principle: Start the broadcast "boot_completed" triggered by the boot.

• Background self-booting

1) from the start-up time: Occurs when the startup is complete when it is running normally.

2) from the start principle: from the "boot_completed" broadcast other than the scene triggered, common common are: Lock screen unlock, network status changes, timers and so on.

There is no real difference between boot and background self-booting, and the method described in the 2nd Chapter is also applicable to background self-booting. Here are just a few things to note:

A. When using the Forcestoppackage interface, there is a situation that is more difficult to avoid, that is, the application before the mutual aroused problems.

B. You need to be aware of the handling of user-defined broadcasts when using the Setcomponentenabledsetting interface.

C. When using killprcocess mode, care should be taken to deal with the manslaughter situation.

Summarize

The function of garbage cleaning and mobile acceleration is now almost finished, here to say some personal thoughts, hoping to arouse some of the readers of this series of ideas.

The "Junk cleanup" and "phone acceleration" in Android are a paradox in itself. What you think is rubbish, it may be the software that produces rubbish want to keep; you think that through the mobile phone acceleration for the user to clean up the memory space, but the full use of memory is the Linux memory management mechanism, does not provide the application of direct kill process, the process is unified by the system to create and recycle, It is also an optimization of Android for fast process creation. I never thought that the developers of Linux kernels or the developers of Android frameworks would be more idiotic (ignorant) than us, and in the early days of system design and system evolution, there had been countless discussions and tradeoffs, Demonstrated that the programme currently in use is a relatively good approach that balances the needs of all parties.

See the various types of mobile phone management software on the market, the electronic market recount "user experience" under the guise, in order to meet the user psychological kind of "cool" demand, provide even automatic to clean up garbage and mobile phone acceleration. In order to collect user information and push and so on to monitor various broadcast and timer to ensure that their application resides. The mutual game of the two makes the overall situation of the application even worse. Seeing the various random images of Android apps, as an Android developer, really hurts.

Not all friends can agree with my point of view, and even many people think it is these non-standard created the Android ecosystem Prosperity, also created a group of similar to 360 mobile security companies. However, I'm still all developers who want to be able to specify an " appropriate strategy " in the process of developing an application because we have been messed up by you as a user.

Here, the mobile phone acceleration is finished, welcome to exchange discussions. The next article will introduce the "application of miscellaneous articles", that is not a few of the previous several application management functions, such as application lock, cottage application identification, application installation location judgment, application intelligent recommendation.