Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

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? 
                the Receiver is defined in the manifest, It is called from android's AlarmManager utility.
– Jason
                Dec 1, 2010 at 5:32
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".
                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, 2014 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, 2014 at 21:28
                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, 2015 at 10:51
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.