Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I did lot of trial and error programming and found a solution for this. So, I answer my own question.</p> <p><strong>Android Behaviour on Service Restarts:</strong> It is well known that an Android service can be force-stopped by the system in case there is a resource crunch. Android will automatically restart this service. This is unavoidable and you need to program your service to gracefully handle this scenario. Please note that there is a delay between service force-stop and restart. This delay is seemingly random and can be in hours. I discovered that there is pattern to this delay. After the very first force-stop, Android restarts the application in 5000ms (5 seconds). Further to this, if the service is force-stopped again (second time) within 60 seconds of first restart, Android updates the delay for next restart by 4 times (ie., 5000 x 4 = 20000ms = 20 seconds). After 20 seconds, Android restarts the service again (third time). If the service is again force-stopped (third time) within 60 seconds, after the third restart, the delay is updated to 4 times 20000 ms = 80000 ms = 80 seconds and so on. Consequently, if your service is getting force-killed within 60 seconds of automatic restart, the delay is increasing exponentially (5s, 20s, 80s, 320s, 1280s, ..........). If you service is not force-killed again within 60 seconds, the delay timer resets to 5 seconds for next force-stop and restart. In my opinion, having a restart timer of anything beyond 20 seconds is unreasonable, how are programmers supposed to write reliable apps with services if you are not even sure you service is running or not ? </p> <p><strong>Known Solutions &amp; workarounds:</strong> There are several answers already in stack overflow which focus on how to ensure your service is not killed in the first place. Prime among them is to have the service start in foreground. See here to see how to do this. This causes a notification when the service is started. Starting a service in foreGround ensures that it is almost never killed. There were other suggested means like having a continuously running thread spawned from your service (this thread does not have to do anything). This is supposed to bump up the “importance” of the thread and service is not frequently killed. However, I suspect this may drain the battery.</p> <p><strong>New solution I discovered:</strong> I discovered another method of circumventing this issue, which does not need a foreGround service or a battery draining thread. You justed need to call startService() in your service in your onStartCommand when intent is null (ie., it is a system restart of the service, assuming the service create returned START_STICKY earlier). When you call startService(), the restart timer delay resets to 5 seconds always. Sample below</p> <pre><code>public class MyService extends Service { @Override public int onStartCommand(Intent intent, int flags, int startId) { if( null == intent ) { Log.d( "MyServiceTag", "This is a System Restart"); /* restart the service with startService(). * This will ensure that the delay between system force-stop and restart * is always 5 seconds */ startService( new Intent( getBaseContext(), MyService.class)); } return START_STICKY; } @Override public void onDestroy() { Log.d( "MyServiceTag", "In onDestroy"); } @Override public IBinder onBind(Intent intent) { // TODO Auto-generated method stub return null; } } </code></pre> <p>If you have a more complicated scenario where you are passing parameters to your service via an intent and you are using START_REDELIVER_INTENT, you may need to use the “flags” to discover a restart and re-create the additional parameters in your intent before calling startService().</p> <p>Worked for me. Hope this helps.</p>
    singulars
    1. This table or related slice is empty.
    1. POBroadcastReceiver in a Service : Design Issues
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USSudhee
    1. USSudhee
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POBroadcastReceiver in a Service : Design Issues
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload