After the App process is killed, let the App start by itself again. Similar App: Alarm clock on time (after the process is killed by force, it starts by itself again)
----Updated on 2016-12-14 ----- In addition to the forced killing of apps, there is a new feature after Android M that will affect third-party push, that is Doze mode. Now using 7.+ System, WeChat's message push is often blocked, and you often have to wake up the screen to receive messages. This situation should be caused by the Doze mode of Android M.
Zhihu: Can third-party push services still work in Doze mode of Android M?
This is not possible unless you use Google's gcm, which is similar to Apple's apns push, but it will probably hit a wall in China. So if you kill the process, you won't be able to receive it. But the closed push can be received when the app is opened again.
qq will be started by the system when the network status changes. It can also be started by a clock scheduled task. It can also start a daemon process like WeChat
Before Android 5.0, there were various ways to improve the survival rate of the service, but after Android 5.0, the push arrival rate was very low. The permissions of the background process were given to the user, and trust in the application needed to be manually set. In this way, The service can continue to survive after the APP is killed. I have probably seen applications from major manufacturers such as QQ. They are automatically trusted after installation. They must have an agreement with the hardware manufacturer, and the hardware manufacturer has a whitelist or something. I can only guess. Regarding not being able to receive the previously pushed messages when opening the APP again, I don’t know much about Jiguang. The general idea is that the pushed messages have arrival statistics and use monitoring devices that have not arrived. When the device starts the APP, there will be verification of Jiguang. , which means that the device is online, and the unarrived notification is sent again at this time.
![[Web front-end] Node.js quick start](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
After the App process is killed, let the App start by itself again. Similar App: Alarm clock on time (after the process is killed by force, it starts by itself again)
----Updated on 2016-12-14 -----
In addition to the forced killing of apps, there is a new feature after Android M that will affect third-party push, that is Doze mode.
Now using 7.+ System, WeChat's message push is often blocked, and you often have to wake up the screen to receive messages. This situation should be caused by the Doze mode of Android M.
Zhihu: Can third-party push services still work in Doze mode of Android M?
Service
This is not possible unless you use Google's gcm, which is similar to Apple's apns push, but it will probably hit a wall in China. So if you kill the process, you won't be able to receive it. But the closed push can be received when the app is opened again.
qq will be started by the system when the network status changes. It can also be started by a clock scheduled task. It can also start a daemon process like WeChat
Before Android 5.0, there were various ways to improve the survival rate of the service, but after Android 5.0, the push arrival rate was very low. The permissions of the background process were given to the user, and trust in the application needed to be manually set. In this way, The service can continue to survive after the APP is killed. I have probably seen applications from major manufacturers such as QQ. They are automatically trusted after installation. They must have an agreement with the hardware manufacturer, and the hardware manufacturer has a whitelist or something. I can only guess.
Regarding not being able to receive the previously pushed messages when opening the APP again, I don’t know much about Jiguang. The general idea is that the pushed messages have arrival statistics and use monitoring devices that have not arrived. When the device starts the APP, there will be verification of Jiguang. , which means that the device is online, and the unarrived notification is sent again at this time.
There is a post on Github discussing this issue. It is recommended to read it: https://github.com/android-cn...