Should I use android: process =":remote" in my receiver?

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?

Here is Solutions:

We have many solutions to this problem, But we recommend you to use the first solution because it is tested & true solution that will 100% work for you.

Solution 1

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".

Note: Use and implement solution 1 because this method fully tested our system.
Thank you 🙂

All methods was sourced from stackoverflow.com or stackexchange.com, is licensed under cc by-sa 2.5, cc by-sa 3.0 and cc by-sa 4.0

Leave a Reply