Android was initiated by Google, but now some actions of Android can't even be seen by Google.
Google has recently broken up with some Android vendors
Google believes that many OEM Android systems today violate Google's policies, making the app unable to run continuously in the background.
Although most Android applications do not need to keep processes in the background, some categories do have such needs, such as health record app, which needs to continuously record data.
However, some OEM Android systems can not meet such needs. The error tracker of AOSP, an Android open source project, once revealed that some OEM manufacturers abused the Android mechanism, prohibited third-party applications from running in the background, and even killed the accessibility service, a system level barrier free service process.
In fact, Google has formulated rules to kill the background for Android system, but OEM manufacturers are not transparent in this regard. Developers and users cannot know what kind of APP background OEM Android will kill.
Sometimes, OEM Android manufacturers will add some apps to the white list, such as some social and communication software, to ensure the timely push of messages.
However, these mechanisms are equivalent to a black box for users and developers. People can't judge which app can run in the background and which can't. the final experience is not satisfactory.
In recent years, the memory of Android has become larger and larger, and even has been stacked to 16g, which is no less than that of desktop PC. But why does the killing of the backstage become more serious in the Android ecosystem? Let's talk about this briefly.
Why should Android kill the background?
The native Android system supports app background retention process, but traditionally there is also a gradual background exit mechanism. Traditionally, Android system assigns different states to app processes, such as foregroup_ App (foreground application), visible_ App (visible application), secondary_ App (secondary application), hidden_ App (hidden APP), content_ Provider, empty_ App (empty application), etc.
When the memory is insufficient, the system will give priority to terminating empty_ App processes and services to release memory; When the memory is tight again, we begin to control the content_ The provider did something, and so on.
The system will judge the priority of killing processes according to the different states of android app
However, not every app honestly registers a reasonable state for the process. Many Android apps use some means to modify the properties of their processes to stay in the background for a long time.
These actions of apps consume additional resources and have a negative impact on endurance and fluency.
Android 7.0 publicized many apps running in the background in the notice bar. Later, these apps had to change the method of background residence
However, many restrictions and background mechanisms of Android system require apps to use a higher version of targetapi to take effect, and a large number of apps still use old development specifications, but users can't abandon many of them.
Therefore, OEM Android kill the backstage, one by one. In China, some Android ROMs even kill the background by default. Even if ram resources are sufficient, most apps cannot retain the background process. The atmosphere of Android ROM killing the backstage came into being.
Why should app forcibly reside in the background?
Unlike apple, Android did not initially provide a unified push mechanism for apps, which means that if each app needs to accept background messages, it needs to host its own process to receive message push at any time.
However, over the years, Google has also improved this by introducing the GCM / FCM mechanism. App can call Google service framework GMS to realize unified message forwarding through Google's server. App message push can be taken over by the system. App doesn't need to keep the background in the whole process, which is similar to IOS.
The FCM mechanism on Android is similar to the unified messaging push of IOS, but the premise is that the system and app access Google services
However, this mechanism is not mandatory. If the app does not access gms or even Google play, it can be ignored. In the typical domestic application environment, GMS is actually not available, and app hosting process and accepting message push have become necessary options.
Therefore, domestic Android apps use a lot of means to host processes in the Android system, which is actually a last resort to a large extent. Of course, there are also commercial considerations. For various means of domestic app staying in the background, domestic android ROM has to take more one size fits all means to kill the background in order to ensure endurance and fluency, which leads to the current situation.
Why should google punish Android ROM and kill the background?
Developers carry the pot for no reason, and this problem is obviously not something developers can solve. Google had to intervene in person to rectify the phenomenon of Android ROM killing the background.
At present, Google is inviting third-party application developers to provide feedback and want to know which mobile phone brands and models kill the background seriously, so as to conduct more in-depth investigation.
How should Android manufacturers respond?
For well-known reasons, Google does not launch account related services in China, and the domestic android ecosystem is disconnected from Google. Therefore, the relevant rectification of Google should have little impact on domestic android products.
However, many domestic android manufacturers carry out overseas business, and Google has an important voice in the overseas market. Google may exert pressure on Android manufacturers to change the system's killing background strategy. In this context, it is necessary for domestic and foreign models to adopt different background killing strategies. In the international ROM for foreign models, Android manufacturers should pay attention to Google's opinions and modify the background killing strategy to a certain extent.
However, we should also realize that the negative experience caused by Android ROM killing the background also exists in China. However, the current domestic android ecosystem forces Android manufacturers to make such a bad decision. How to change the current situation?
The unified push alliance is expected to solve the contradiction between the system killing the background and the app needing to maintain the push service in the background
In general, the reason why Android ROM is so radical to kill the background is closely related to the behavior of android app, and the root of all this is the Android ecology that lacks unified push service. With the strengthening of Google's control over Android abroad and the popularity of unified push services in China, the situation is expected to change. I hope Android ROM and apps can have a better user experience in the future.
- THE END -Pacific computer network