There was an update yesterday from Thiel Terminal LABS, which read as follows:

PingWest reported on June 3 that According to the information released by Tyre Terminal Laboratory under the Ministry of Industry and Information Technology, At present, Theil Terminal Lab has worked with huawei, OPPO, Vivo, Xiaomi, Samsung, Meizu, Gionee, Nubia, Google (Weibo), Baidu, Alibaba, Tencent, Getui, Aurora and other major foreign and domestic relevant enterprises to jointly develop the Technical standard of Android Unified Push Service (UPS). It aims to establish a unified standard for notification push service in China, provide better mobile phone use experience for end users, and better solve the demand of notification push for application developers, and has achieved phased results. Specifically, terminal manufacturers will provide system-level push service (similar to the unique push channel of APNS) in the future to ensure that App push messages are received. Accordingly, apps are no longer allowed to keep constant connections in the background to reduce terminal energy consumption and improve user experience. At the same time, all terminal manufacturers unify the interface and function of push channel to facilitate developers’ access. In addition, the third-party push service providers also follow the standard of unified push in principle to ensure service consistency and reduce the learning cost of developers. According to the new features in the Preview version of Android 8.0, background activity in Android apps will be more tightly controlled in the future, and notifications will only be sent through system-level push channels. At present, major mobile phone manufacturers have also provided or are developing system push service solutions based on their own system platforms. If the unified Android push service becomes an industry standard in the future, it will undoubtedly be a great benefit for Android phone users.

If this standard is implemented successfully, it will be great news not only for Android developers, but also for ordinary users. Everyone knows that the biggest difference between An Android and an iPhone is that Android is harder to use than an iPhone. One of the reasons for this is the push mechanism, so I’m going to take a quick look at what the platforms are doing to protect push.

Keep alive means

Currently, the industry’s Android process survival means are mainly divided into black, white, gray three, its general implementation ideas are as follows:

Black preservation: Different APP processes wake each other up with broadcast (including the broadcast provided by the system). The so-called black preservation refers to the use of different APP processes to wake each other up with broadcast. Three common scenarios are as follows: – Scenario 1: Wake up the APP using the broadcast generated by the system during startup, network switching, photo taking, and video shooting

  • Scenario 2: Accessing a third-party SDK will also wake up the corresponding APP process. For example, the wechat SDK will wake up wechat, and the Alipay SDK will wake up Alipay. It spreads out, and it triggers the next one

  • Scenario 3: If you have Alipay, Taobao, Tmall, UC and other Alibaba apps installed in your mobile phone, you may wake up other Alibaba apps after opening any of them. (Just take Ali as an example, in fact, BAT is similar)

That’s right, our Android phones are being towed step by step by step.

For scenario 1, Google is probably starting to realize these issues, so in the latest Android N, ACTION_NEW_PICTURE, ACTION_NEW_VIDEO, CONNECTIVITY_ACTION (network switching) and other three broadcasts, undoubtedly gave a lot of apps a heavy blow.

And boot broadcast, remember some custom ROM manufacturers have already removed it.

For scenario 2 and scenario 3, invoking the SDK to wake up the APP process is a normal behavior and is not discussed here. However, when analyzing the wake path between apps with the help of LBE, two problems were found:

  1. Many push SDKS also have the ability to wake up the app
  2. The wake up paths between apps are numerous and complex

I will show you the test results of my mobile phone (my mobile phone is mi 4C, which is running the native Android5.1 system, and I have obtained Root permission to view these wake paths).

15 groups wake up each other

Full wake up path

Let’s go straight to the wake up path of the brief book

You can see the above three wake up paths, but the total number of wake up apps covered is 23+43+28, which is amazing. Please note that this is just the wake up path of an app on my phone.

Of course, there is still a question, is the LBE analysis of the application of these wake paths and mutual wake, we do not know the thinking. Therefore, we are not sure whether the analysis results are accurate. If some LBE children read this article, could you please tell us your thoughts? However, opening an app on the phone awakens a large number of people. I personally experienced this kind of sour cool……

White keep alive: Starts the foreground Service

Prints Ser for all processes with the specified package name

Vice. Let’s see if we have anyisForeground=trueKey information. If the Notification bar does not see the Notification belonging to the app and sees it againisForeground=trueIt shows that this APP makes use of this grey means to keep alive.

Below are the test results of wechat, QQ, Alipay and Momo on my mobile phone. If you are interested, you can verify it yourself.



WeChat

The white preservation method is very simple. It is to call the system API to start a foreground Service process, which will generate a Notification in the Notification bar of the system to let users know that such an app is running, even if the current APP has retreated to the background. LBE and QQ Music are as follows:



Gray keep alive:Vulnerabilities in the systemStart foreground Service

Gray preservation, this means of preservation is the most widely used. It takes advantage of system vulnerabilities to start a foreground Service process. The difference with the common startup mode is that it does not show a Notification in the system Notification bar, and looks like running a background Service process. The advantage of this is that the user will not know that you are running a foreground process (because the Notification cannot be seen), but your process has a higher priority than a normal background process. Then how to use the system vulnerabilities, the general implementation ideas and codes are as follows:

New Notification() is passed to the foreground Service when API < 18.

public class GrayService extends Service { private final static int GRAY_SERVICE_ID = 1001; @Override public int onStartCommand(Intent intent, int flags, int startId) { if (Build.VERSION.SDK_INT < 18) { startForeground(GRAY_SERVICE_ID, new Notification()); Else {Intent innerIntent = new Intent(this, grayinnerservice.class); startService(innerIntent); startForeground(GRAY_SERVICE_ID, new Notification()); } return super.onStartCommand(intent, flags, startId); }Copy the code

API >= 18, start two foreground services with the same ID, and then stop the last Service.

GrayInnerService extends Service {@override public int GrayInnerService extends Service {@override public int GrayInnerService extends Service {@override public int onStartCommand(Intent intent, int flags, int startId) { startForeground(GRAY_SERVICE_ID, new Notification()); stopForeground(true); stopSelf(); return super.onStartCommand(intent, flags, startId); }}}Copy the code

This is basically the code that allows you to start a foreground Service without anyone noticing. In fact, many apps in the market use this kind of grey survival method. What? You don’t believe? All right, let’s test that. The process is simple. Open an app and check whether there is a Notification in the system Notification bar. If not, enter the ADB shell mode of the phone and enter the following shell command

dumpsys activity services PackageName
Copy the code

Hand Q

Alipay

Momo

In fact, Google is aware of the existence of this vulnerability, and gradually closed. This is why there are two cases of API >= 18 and API < 18. From the postNotification function source code of the ServiceRecord class on Android5.0, you can see this line of comment

One day when API >= 18 doesn’t work, we have to find another way out. Note that using grey save does not mean your Service is immortal, only that it increases the priority of the process. If your app process consumes a lot of memory, reclaiming the process will also kill your app. Keep alive is interested in gray not showing how to use the system vulnerabilities Notification of children’s shoes, you can study the system’s ServiceRecord, NotificationManagerService related source code, because is not the focus of this article, so do not elaborate.

Here is basically the introduction of black, white, gray three implementation methods, only from the code level to talk about the survival is not enough, I hope to understand the survival through the system process recycling mechanism, so that we can better avoid stepping on the pit of process killing.

If you are familiar with the Android system, you will know that the system does not actually kill the process when the app goes back to the background, but cache it for the sake of experience and performance. The more applications open, the more processes are cached in the background. When the system memory is insufficient, the system starts to determine which processes to kill according to its own process reclaiming mechanism, so as to free up memory for the needed app. This mechanism is called Low Memory Killer, which is based on OOM Killer (out-of-memory Killer) mechanism Of Linux kernel.

Low Memory Killer Low Memory Killer What is oom_adj? It is a value assigned by the Linux kernel to each system process. It represents the priority of the process, and the process reclamation mechanism determines whether to recycle based on this priority. Here’s what you need to remember about what oOM_adj does:

  • The larger the oOM_adj value is, the lower the priority is and the easier the process is to be killed and reclaimed. The smaller the value is, the higher the process priority is and the harder it is to kill and recycle
  • If the oOM_adj of a common APP process is 0, the oOM_adj of a system process can be <0

How do we check the oOM_adj value of a process using the following two shell commands

Ps | grep PackageName / / for you specify the process of informationCopy the code

Here is the demo code I wrote as an example, the middle of the red circle are the ids of the following three processes

UI process: com.clock.daemon Common background process: com.clock.daemon:bg Grey preservation process: com.clock.daemon:gray

Of course, the ids of these processes are also available from AndroidStudio

Then we get the oOM_adj of the three processes

Cat /proc/process ID/oom_adjCopy the code

As you can see from the figure above, the OOM_adj of the UI process and the grey preservation Service process is 0, while the oom_adj of the normal background process is 15. You can see why background processes are easier to recycle than foreground processes. But that’s not enough. Look at the picture below

If I switch the app to the background and check oOM_adj again, you can see that the UI process has changed from 0 to 6, and the grey Service process has changed from 0 to 1. Here you can see that when the app goes back into the background, all of its processes take a lower priority. But the UI process is the most obvious reduction, because it occupies the most memory resources, when the system is running out of memory must be prioritized to kill these processes to free up resources. Therefore, in order to avoid killing the background UI process, it is necessary to release some unused resources as much as possible, especially images, audio and video.

From the Official Android documentation, we can also see the different types of processes listed in order of priority: Foreground Process, Visible Process, Service Process, Background process, Empty process. What are the oOM_adj of these processes and how are they linked? I recommend reading the following article:

www.cnblogs.com/angeldevil/…

conclusion

Just a little summary. After all, the fundamental solution to process survival comes back to performance optimization, and process immortality is a completely false proposition after all! However, each platform to ensure timely and accurate push efforts, which also leads to Android phones heavy battery consumption, lag and other phenomena.

If the Ministry of Industry and Information Technology can unify the Push channel of Android smoothly this time, it will be a great benefit for Android developers and Android system users.

The author:Rance935Source:The Ministry of Industry and Information Technology requires a unified notification push standard for Android in ChinaPlease indicate the author’s details and the source of this article at the beginning of the reprint

Welcome to follow my wechat official account and QQ group to share Android development and Internet content

Android technology share: group number 534813930

Wechat id: AndroidParks

Public id: AndroidParks