I don't see the association between getLocation() and the AlarmManager. So while you are performing an AsyncTask the calendar is not synchronized with it. In response to the comment:
alarmMgr.setInexactRepeating
here is where you give the AlarmManager your intent to call your service. Actually it's called, when the user cancels the alarm.
The service itself maybe in running state or not started.
If it is in running state or the AlarmMananger doesn't start the service but sends a broadcast to it, both onCreate and onStartCommand won't be called.
So your AnsychTask wont be restarted and the update process will not be performed.
EDITED: Sorry, my fault. So it's actually not the service which is passing his
pendingintent to the alarm manager, but the intent is supposed to control the broadcast
receiver which then starts the service.
Hm .. I personally would prefer the following setup:
Move the logic for the controlling of the AlarmManager into the AlarmSetter. :
The Service is responsible for getting the current location and updating it.:
The AlertSetter when launched starts the service (and binds to it), passes the PendingIntent to the
AlarmManager, so that he can send his broadcast when the user has canceled the alarm.
The AlertSetter then requests the update operation of the service.
I guess that the passing of the PendingIntent from one class (as source) for broadcasting to another class (the destination) may arise issues.
And you won't spread the logic for scheduling the service in two different classes: the service itself and the AlarmSetter.
Besides I don't see any reason for not using http://developer.android.com/reference/java/util/concurrent/ScheduledExecutorService.html in this requirements definition.