Falmarri's answer is the correct one, and I do not understand your concerns.
In onPostExecute(), when you determine that things went awry:
- Call
getSystemService(ALARM_SERVICE) to get the AlarmManager
- Call
set() on the AlarmManager to trigger you in 5 minutes
If needed, use extras on the Intent in the PendingIntent to give you information about what to retry, or use a custom action string to distinguish retries from the scheduled alarm, or something. Note that if you use Intent extras, you will need to choose an appropriate flag with PendingIntent (e.g., FLAG_UPDATE_CURRENT).
The problem is the AlarmManager is started from one class but the AsyncTask is in another class, therefore
the class that starts the AlarmManager doesn't know whether it has failed or not.
So? Multiple classes can talk to the AlarmManager. Also, feel free to pass data to your AsyncTask subclass via its constructor.
Also, you might want to consider using an IntentService rather than a Service and AsyncTask. IntentService gives you a background thread automatically. Plus, it shuts down when there is no more work to be done, which is also important, so you don't get a bunch of one-star ratings on the Market complaining about the service you keep running all of the time.
I don't want to start an AlarmManager from the onPostExecute() of my Service class.
Why not?
If I start an AlarmManager from within the Service then I'm sort of creating a recurring function where
I'm calling the Service from itself.
Of course. That's what you want. It matters not a whit whether the Service or the AsyncTask or the MyOtherReallyCoolClass is the one actually talking to AlarmManager -- the component that is rescheduling the Service is the Service itself.