Service Crashing And Restarting

There are several questions about it but I always read the same thing: 'the service will be killed if the system need resources' or 'you can't build an service that runs forever be

Solution 1:

I finally found the solution ! I removed the AlarmManager from the Service and the service does not cashed anymore, but I have to use it

The problem is the service crash after the user swype away the app from Recent App, so what I did was prevent the app to appear in that window. Add the following to your AndroidManifest.xml as a child of <activity>

android:excludeFromRecents="true"

Now when the user exit from your app it wil not appear in the recent apps window, what means the system kills the Activity right after you exit it, so it'll not waste any resources.

PS: don't forget to set the service to run in a separate process, add the following to your AndroidManifest.xml, as a child of <service>

android:process=":remote"

EDIT - REAL SOLUTION FOUND

After a lot of research and study (months of study) I took a deep look at android APIs and here is what a found, this is na expected behaviour that occours only at API 16+, a change at android arquiteture changed the way that PendingIntents are broadcasted by the system, so Google added the flag FLAG_RECEIVER_FOREGROUND, you must pass this flag to the intent you are using as a parameter on the PendingIntent.getBroadcast(), here is na example:

if(Build.VERSION.SDK_INT >= 16)     //The flag we used here was only added at API 16    
    myIntent.setFlags(Intent.FLAG_RECEIVER_FOREGROUND);
    //use myIntent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND); if you want to add more than one flag to this intent;



PendingIntent pi = PendingIntent.getBroadcast(context, 1, myIntent, 0); // the requestCode must be different from 0, in this case I used 1;

Android versions older than API 16 will work as expected, the service won't crash if you swype away the app from Recent Apps page.

Solution 2:

As the documentation says, a Service runs in the main thread of its callee, that usually is the UI Thread. So what is happening is that when you kill your application, you kill your application process and thus the service is killed too.

You can workaround this behavior by creating your Service in a different process by using android:process in your <service> tag in the Manifest.xml file.

Usually, though, you start a Service in its own process if the Service needs to be independent from the callee and if it may be used by different application. If your Service is for your own application use only, then stick with the default behavior and simply don't kill you application.

EDIT 1:

The documentation for android:isolatedProcess says:

If set to true, this service will run under a special process that is isolated from the rest of the system and has no permissions of its own. The only communication with it is through the Service API (binding and starting).

Solution 3:

From another SO answer (Link), this is the expected behavior. But surely, someone here will have a workaround or a solution.

Your questions from code:

pi = PendingIntent.getBroadcast(this, 0, new Intent("anyany"); 0) //Why those zeros?

The first zero you see is mentioned as a requesCode and decribed as not being used presently:

requestCode: Private request code for the sender (currently not used).

The second zero should actually be one of the flags given (here).

i = intent.getIntExtra("INTENT1", 0) // I don't understant yet why this zero are here

The getIntExtra(String, int) method of Intent doesn't need to have 0 as its second argument: it can be any integer. getIntExtra(String, int) returns an integer corresponding to the String key you provide. In the event that this key no long exists(or never did), getIntExtra(String, int) returns the integer we pass as the second argument. It is the default value when the key fails.