This article is from http://blog.csdn.net/liuxian13183/ , and the reference must be indicated!
Under normal circumstances, the application keep-alive scenarios are: the background needs to continuously locate and describe a clear trajectory, and IM communication needs to receive message reminders in time.
The so-called keep-alive is to avoid being killed by the application. Of course, the foreground application is naturally the background application. We know that Android's application priority is -16 to 15. System processes generally have a priority of -16 to -1, while ordinary applications only have a priority of 0-15; the lower the level, the higher the priority.
First of all, the application that enters the background cannot be a rogue process, such as frequency positioning, sending network requests, not allowing the screen to be turned off, etc.; if doing heartbeat, you need to choose a suitable period, such as once every 2 minutes, for a long socket connection ; you can design a foreground process and a Background processes, monitor each other and restart each other; keep at least 1 pixel in the foreground.
Secondly, if it is forced to keep alive, 90% of the processes may be killed; before 4.4, you can use the setRepeating method of AlarmManager to keep alive regularly, and then you can use the setAndAllWhileIdle method to wake up collectively for a period of time;
In addition, you can register notifications, such as booting, time change, screen lock and screen, network switch, receiving text messages, incoming calls, etc.; after 5.0, you can use JobSchedule's Api for round-robin operations, and automatically register for network switching. Broadcast to listen (the configuration file registration method has been disabled)
If it is a Service, you can also use the startForeGround method to keep the service in the foreground to avoid killing, and use stopForeGround to remove it when it is closed. In addition, rewrite onStartCommand and return to START_STICKY to automatically restart the service after it is killed.
public int onStartCommand(Intent intent, int flags, int startId) {
return START_STICKY;
}
And through WakeLock, you need to apply for permission
Acquire the lock:
- WakeLock mWakeLock= null ;
- PowerManager pm = (PowerManager) getSystemService(Context.POWER_SERVICE);
- /**
- * PowerManager.PARTIAL_WAKE_LOCK: keep CPU running, screen and keyboard lights may be off
- * PowerManager.SCREEN_DIM_WAKE_LOCK: keep the CPU running, the running screen is displayed but the screen may be gray, allowing the keyboard light to be turned off
- * PowerManager.SCREEN_BRIGHT_WAKE_LOCK: keep the CPU running, the screen is highlighted, allows to turn off the keyboard light
- * PowerManager.FULL_WAKE_LOCK: keep the CPU running, the screen is highlighted, and the keyboard lights are highlighted
- * PowerManager.ON_AFTER_RELEASE: keep the screen on for a while when the lock is released
- * PowerManager.ACQUIRE_CAUSES_WAKEUP: Force the screen to light up
- */
- mWakeLock = pm.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "SoundRecorder");
- mKeyguardManager = (KeyguardManager) getSystemService(Context.KEYGUARD_SERVICE);
- mWakeLock.acquire();
- if (mWakeLock.isHeld()) {
- mWakeLock.release();
- }
After all, this method is very rogue, just like Zhang Xiaolong's expectation for WeChat: I hope it is a tool that people need to use and let go of when they are done.
Set the following label for the Activity. When the user clicks on the recent task, the App will not be displayed, so as to achieve the purpose of hiding
android:excludeFromRecents="true"
Attached to Zebra's requirements for user permissions (mainly setting a whitelist)
Congratulations, you finally found a new world! In any case, when keeping alive, consider the user's feelings and keep alive rationally!
Others, such as starting a 1-pixel activity, keeping the native process alive, notifying the save service, listening to the public broadcast of the third party and the system