How does Android ensure that the service is not killed in the background? androidkill

How does Android ensure that the service is not killed in the background? androidkill
In fact, Android cannot do more without being killed in the background. We can only try to use some operations to improve the chances of not being killed in the background. 1. The onStartCommand method returns START_STICKY. After the service process is killed after onStartCommand is run, the service process will remain in the starting state, but the imported intent will not be retained. Soon after, the service will try again, because it is retained in the starting state. After the service is created, the onstartCommand will be called. If no start command is passed to the service, the null intent is obtained. START_NOT_STICKY after running onStartCommand, the service process is killed and no new intent is passed to it. The Service will be removed from the starting State and will not be re-created until the new obvious method (startService) is called. If no unknown intent is passed, the service will not start, that is, the onstartCommand will not receive any null intent during this period. After START_REDELIVER_INTENT runs onStartCommand and the service process is killed, the system starts the service again and passes in the last intent to onstartCommand. Intent delivery is stopped until stopSelf (int) is called. If an unprocessed intent still exists after being killed, the service will start automatically after being killed. Therefore, onstartCommand does not receive any null intent. 2. Improve service priority in AndroidManifest. in the xml file, you can set the highest priority for intent-filter through the android: priority = "1000" attribute. 1000 is the highest value. If the number is smaller, the higher the priority is, and the broadcast is applicable. 3. Processes in Android are hosted to improve the service process priority. When the system process space is insufficient, the process will be automatically recycled according to the priority. Android divides processes into six levels. The order of priority is from high to low: 1. foreground process (FOREGROUND_APP) 2. visualized process (VISIBLE_APP) 3. secondary service process (SECONDARY_SERVER) 4. background process (HIDDEN_APP) 5. content supply node (CONTENT_PROVIDER) 6. empty processes (EMPTY_APP) kill some existing processes when the service runs in a low-memory environment. Therefore, the priority of the process will be very important. You can use startForeground to put the service in the foreground state. In this way, the probability of being killed at a low memory will be lower. 4. Sending broadcast in onDestory and restarting service + broadcast means sending a custom broadcast when the service goes through ondestory. Restart the service when receiving the broadcast; 5. Add Persistent attribute 6. Listen to the system broadcast to determine the Service status through some broadcasts of the system, such as restarting the mobile phone, waking up the interface, and changing the Application status, then determine whether our Service is still alive. Do not forget to add permissions. 7. Dual-process Service protects two processes from each other. After one of the services is cleared, other processes that are not cleared can immediately restart the process. 8. Contact the vendor and add them to the whitelist.