How to perform network activity from Android AlarmManager callback

Question

I'd like to set up a network task in an Android app using AlarmManager.setInexactRepeating(...).

I have registered my BroadcastReceiver in AndroidManifest.xml with the following entry:

    <receiver
        android:name="com.vandenmars.colortrek.analytics.CTAUploadService"
        android:process=":sync"/>

Now, if I simply run my network request with a blocking HttpURLConnection from onReceive(), I get a NetworkOnMainThreadException!?!?

Weird... I thought the whole point of the AlarmManager was to call onReceive on a background-thread...

Which leads me to question 1:

Is it possible to force AlarmManager to call onReceive on a background thread rather than a Main thread? Do I need to declare something differently in AndroidManifest.xml?

I've tried to just work around this issue by setting up an AsyncTask for my network request inside onReceive and the exception goes away. The problem I'm having now is that some Android devices take forever to time out a network request that should fail because of an intermittent network issue or server problem. So, now (if I set the repeat-interval to something tiny) I have a bunch of AsyncTasks piling up in a queue that are trying to complete the same request and hang, waiting for the first request to fail. And when the network issue is resolved, all pending AsyncTasks break loose one after the other in a gigantic deluge of network requests.

To solve this, I tried simply keeping a flag in an instance variable around in my code that prevents another AsyncTask from being scheduled before the previous one completes. Unfortunately, this didn't work as expected, as every invocation from the AlarmManager created a fresh instance of my BroadcastReceiver, resetting the flag...

It does work if I make this flag static to attach it to the class itself rather than an instance of it, but this leads me to question 2:

Can I rely on this approach or is it ever possible that a BroadcastReceiver is called in such a way that there are two processes (?) or so of it active that have different "instances" of static variables?

And finally question 3:

If I can't rely on this approach, is there a good alternative?

I'd rather not have to hit the disk with this flag since I don't want to use up flash-write-cycles if I don't have to...

PS: I realize that there are other ways to do networking in the background, like GCM, JobScheduler, SyncAdapters, ... that may fix this issue for me or be otherwise considered "the right way to do it". Unfortunately they all have some form of issue (sketchy permissions, weird system changes, API level requirements, ...) that make them useless to me. So, I do need to use AlarmManager for this.

Answer 1

One of your questions have been answered already: https://stackoverflow.com/a/9687668/1738090

However, you've asked several questions, so maybe I can help out here a little since I've had some recent experience with AlarmManager.

Is it possible to force AlarmManager to call onReceive on a background thread rather than a Main thread? Do I need to declare something differently in AndroidManifest.xml?

Yes, you can create a Service which implements a custom Handler. The Handler can be used to fire off an AlarmManager PendingIntent. The Broadcast Receiver that you use for this intent (for catching the AlarmService trigger) can then either receive and execute logic in the background within the handler or it can notify the UI of the trigger event. If you need more help on this part, let me know.

Can I rely on this approach or is it ever possible that a BroadcastReceiver is called in such a way that there are two processes (?) or so of it active that have different "instances" of static variables?

If you're worried about there being multiple instances of an alarm intent running behind the scenes, then I would highly advise making sure that you retain the instance of your PendingIntent which is used in the AlarmManager .set() method call. Although I haven't used setInexactRepeating() before, I know that if you're making multiple calls to the .set() method call with the same retained intent, then it will just reset the Alarm Service. The service knows to keep track of the intent instance and reset the alarm rather than creating multiple alarm processes. I would also recommend looking into the newer APIs which help with stricter delivery guarantees: setWindow(int, long, long, PendingIntent) and setExact(int, long, PendingIntent)

If I can't rely on this approach, is there a good alternative?

From what it sounds like, you are trying to send/receive data in the background of your application. And with your questions, it sounds like you are trying to manually handle scheduling when your app updates it's data behind the scenes.

I HIGHLY HIGHLY recommend using a SyncAdapter in this case. Aside from an easier development approach, there are lots of benefits to using SyncAdapters instead of your IntentService + BroadcastReceiver approach: http://developer.android.com/training/sync-adapters/index.html (including improved battery life, in general)

Hope this helps!