2

I can instantiate an AsyncTask from WakefulBroadcastReceiver (see my motivation for favouring AsyncTask over Service), e.g., 

public abstract class AlarmReceiver extends WakefulBroadcastReceiver {

    @Override
    public void onReceive(Context context, Intent intent) {   
        new AsyncTask<Void,Void,Void>(){
            @Override
            protected Void doInBackground(Void... v) {
                while (true) {
                    SystemClock.sleep(7000);
                    Log.w("", "alive");
                }
            }
        }.execute();
    }

}

But is this recommendable? In particular, are there life cycle issues associated with instantiating an AsyncTask from a WakefulBroadcastReceiver? For instance, can my AsyncTask be killed prematurely?

(I know I can wrap the AsyncTask inside a service, but this seems like overkill?)

Answer

Instantiating an AsyncTask from a WakefulBroadcastReceiver is ill-advised, since anything instantiated by a BroadcastReceiver will be considered killable by the system once the onReceive() method returns, i.e., the system may kill AsyncTask. Thanks to corsair992.

See process lifecycle for further details about killable processes.

Community
  • 1
  • 1
user2768
  • 794
  • 8
  • 31
  • I initialised the above code using `AlarmManager` and it has been running (i.e., outputting "alive") for an hour. Of course, this does not answer any of the questions I have posed... – user2768 Aug 07 '14 at 05:16
  • 1
    "A `BroadcastReceiver` object is only valid for the duration of the call to `onReceive()`. Once your code returns from this function, the system considers the object to be finished and no longer active. This has important repercussions to what you can do in an `onReceive()` implementation: anything that requires asynchronous operation is not available, because you will need to return from the function to handle the asynchronous operation, but at that point the `BroadcastReceiver` is no longer active and thus the system is free to kill its process before the asynchronous operation completes." – corsair992 Aug 11 '14 at 02:04
  • @corsair992, thanks for your comment. The API description seems unclear! In particular, I presume the final sentence should be read as follows: "_anything that requires asynchronous operation_ [to return] _is not available, because you will need to return from the_ [`onReceive()`] _function to handle the asynchronous operation, but at that point the `BroadcastReceiver` is no longer active and thus the system is free to kill its_ [`AlarmReceiver`] _process before the asynchronous operation completes_." Since my asynchronous operation doesn't return to [`onReceive()`], is there a problem? – user2768 Aug 11 '14 at 06:09
  • 1
    As mentioned in the API reference, no asynchronous operations can be executed in the context of a `BroadcastReceiver`, because as soon as the `onReceive()` method returns after invoking it, the `BroadcastReceiver` will be inactive, and the process would be considered to be killable by the system if there is no other active component (e.g. a `Service`). – corsair992 Aug 11 '14 at 06:55
  • @corsair992, I assume `BroadcastReceiver` being killable implies my `AsyncTask` is also killable? Moreover, I assume that this cannot be detected by testing, because the system may not kill anything? (Thinking out loud: can `emulator -shell` force a kill?) Is the solution to wrap my `AsyncTask` inside a `Service`? Or is there a better solution? – user2768 Aug 12 '14 at 02:00
  • 1
    The whole _process_ that the application is running under is considered to be killable after all the components are inactive, so yes the `AyncTask` would also be killed as part of the process. You are correct that process killing is at the discretion of the system, which will do so when it needs to clear up memory for other processes. You can force stop your process for testing using ADB via the `adb shell am force-stop ` command, or from the Devices section in the Device Monitor. The only way to start an asynchronous task from a `BroadcastReceiver` is by starting a `Service`. – corsair992 Aug 12 '14 at 06:04

0 Answers0