0

So I'm working on an app that uses the AlarmManager to broadcast an intent for my receiver to do a simple task and finish quickly. I want my receiver to run every few minutes so I use setRepeating to ensure this. I don't want to have to worry about the main activity of my app running or being visible when the alarm triggers. In order for my receiver to run separately from the main activity like that, do I need to add android:process=":remote" to the receiver in the manifest? or are they already inherently separate things? The two do not need to communicate. I'm trying my best to kill the activity without canceling any alarms and the receiver seems to be running properly for now, but I'm wondering if it'll continue to work for a few hours or days.

Mr_and_Mrs_D
  • 32,208
  • 39
  • 178
  • 361
Corey Ogburn
  • 24,072
  • 31
  • 113
  • 188

2 Answers2

1

Yes, they're separate. No need to use that attribute.

By the way, how much work do you do in that BroadcastReceiver? Normally, you can't do very much inside the BroadcastReceiver itself, you use it to trigger other things.

Also, I'm wondering how you're doing the following:

"I'm trying my best to kill the activity..."

I'm wondering what problem you were trying to solve here by trying to kill the activity?

Stephan Branczyk
  • 9,363
  • 2
  • 33
  • 49
  • The `onReceive` starts a thread that makes a web request and store the results in a sqlite database. I had to do it in a thread because sometimes I force a broadcast from an activity and it was throwing an exception for accessing the network on the ui thread. – Corey Ogburn Apr 25 '13 at 02:54
  • You can't start a thread from your BroadcastReceiver, you have to do a startService an IntentService from your onReceive instead: http://developer.android.com/reference/android/app/IntentService.html – Stephan Branczyk Apr 25 '13 at 02:59
  • I'm killing the process before the next AlarmManager event is fired so that I know the event is happening even when the activity isn't running. As for the "you can't start a thread..." I am and it's working. Why can't I? – Corey Ogburn Apr 25 '13 at 14:09
  • Maybe what I should have said is that my onReceive is explicitly starting a new thread. I'm not expecting onReceive to be it's own thread already. – Corey Ogburn Apr 25 '13 at 14:14
  • That thread will get a lower priority and could get killed earlier than an IntentService (or even earlier than just a Service). There could also be some other reasons in addition to that one. I'll have to research that topic a little more. – Stephan Branczyk Apr 25 '13 at 20:04
  • I think I'll try moving to IntentService. I didn't think about short running threads being killed. But I've noticed today that it does seem to be happening. – Corey Ogburn Apr 25 '13 at 22:04
0

To your immediate question - certainly not - it will be a performance killer and is unneeded anyway.

To your design - flawed. You should :

  1. Register an alarm (also take care to re-register it on boot) - see wakeLock does not wait for network connectivity for the code registering the alarm
  2. When the AlarmaManager wakes your receiver up delegate to a WakefulIntentService. The intent service is NOT guaranteed to run when the device is asleep (see Android deep sleep and wake locks).

See also:

Community
  • 1
  • 1
Mr_and_Mrs_D
  • 32,208
  • 39
  • 178
  • 361