81

I have a BroadcastReceiver which is called every so often, and I have noticed many people use 

android: process =":remote"

in their receiver. Mine is used to check a few things and if the conditions match then activate an alarm. My question is should I use the line I had posted above in my manifest? And if so what are the benefits of doing so?

Jason
  • 4,034
  • 4
  • 40
  • 62

1 Answers1

177

By defining your receiver with android:process=":remote" you basically run your receiver in a different process (= VM). For typical use-cases, you don't need to run this in a different process, and whatever you want to do can probably run just fine locally (in your APK process).

The drawback of using android:process=":remote" is that you need additional resources for it to run (in this case a separate process). When doing so, you're basically dealing with 2 VMs, and some patterns like singletons, static fields can no longer be shared between your app and your remote service.

The benefit of using android:process=":remote" is that for some use-cases, it might be handy to start a service that will keep on running (in its own process) after you've shutdown your application, or if you want remote clients to be able to bind to your service. Your broadcast receiver will not block your applications main thread when running in a separate process upon calling the onReceive() method (however, there are other ways of implementing this).

I've found that most of the time, for most common use-cases, you can get away without using android:process=":remote".

mixel
  • 25,177
  • 13
  • 126
  • 165
ddewaele
  • 22,363
  • 10
  • 69
  • 82
  • might I ask what the other ways of implementing a non-blocking onreceive() method you are mentioning wpuld be ? I actually have exactly that scenario going on, a onReceive method that actually does quite some work and I am suspecting that might be causing some issues in my software... – TiGer Jul 11 '14 at 13:59
  • There is another implicit benefit that is not mentioned: when running a component on a separate process, you have a fresh new VM heap to use. So in case your application is performing memory intense operations, a separate process may be a solution to avoid Out Of Memory errors. – Rodrigo Dias Jul 21 '14 at 21:28
  • 3
    How does one communicate with such a reciever ,I tried communcating via Sharedpreferences but that doesn't work as the remote recieve has the first copy and none that succeeds the initial data – humblerookie Apr 11 '15 at 10:51