The service of your own app is always easy to be recovered by the system, and the following are some basic solutions: 1. Writing service to system service will never be recycled (not practiced): Setting the Persistent property to true in the Manifest.xml file allows the service to be protected from out-of-memory killer. However, this approach must be cautious, too much system service will seriously affect the overall operational efficiency of the system. 2. Improve service priority (not practiced): set android:priority= "1000"
<!--to eliminate the warning message that appears after adding android:priority= "1000", you can set the Android:exported property to indicate whether the service can be called by other application components or interact with it- < Service android:name= "Com.example.helloandroid.weatherforecast.service.UpdateWidgetService" android:exported= " False "> <!--to prevent service from being reclaimed by the system, by increasing priority resolution, 1000 is the highest priority, the smaller the number, the lower the priority-- <intent-filter android: priority= "></intent-filter> </service>"
3. Writing services to the front desk foreground service (has been practiced to a large extent, but not guaranteed to be killed): override the Onstartcommand method, use Startforeground (int, Notification) method to start the service. Note: The front desk service will display a notification in the status bar, the most typical application is the music player, as long as the playback state, even if the hibernation will not be killed, if you do not want to display the notification, as long as the parameters in the int set to 0.
Notification Notification = new Notification (R.drawable.logo, "WF update Service is running", System.currenttimemillis ());p Intent=pendingintent.getservice (this, 0, intent, 0); Notification.setlatesteventinfo ( This, "WF update Service", "WF update Service is running! ", pintent);//Let the service foreground run, to avoid the system automatically kill when the phone hibernation//If the ID is 0, then the status bar notification will not be displayed. Startforeground (startid, notification);
At the same time, the foreground run state needs to be canceled by Stopforeground (true) for the Service,ondestory method initiated through Startforeground.
PS: If the service is killed after the next restart error, it may be that the re-send intent is NULL, you can modify the return value of the Onstartcommand method to resolve: start_sticky : If the service process is killed, the status of the reserved service is the start state, but the delivery intent object is not preserved. The system then tries to recreate the service, and since the service status is started, the Onstartcommand (Intent,int,int) method must be called after the services are created. If no startup commands are passed to the service during this time, then the parameter intent will be null. start_not_sticky: "Non-sticky". When this return value is used, the service is not automatically restarted if the service is killed by an exception after Onstartcommand is executed. start_redeliver_intent: Retransmission INTENT. With this return value, if the service is killed by an exception after Onstartcommand is executed, the service is automatically restarted and the value of intent is passed in. start_sticky_compatibility: Start_sticky compatible version, but does not guarantee that the service will be restarted after kill.
If this service's process is killed, then it'll be scheduled for a restart and the last delivered Intent re-delivered To it again return service.start_redeliver_intent;
Reprint Note Address: http://www.chengxuyuans.com/Android/65105.html
Workaround for Android service being reclaimed by system