Should I Use Android: Process =":Remote" in My Receiver

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

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

AlarmReceiver not getting called with android:process=:remote

When you configure your service to run in remote mode (android:process=":remote"), you will have to debug the process :remote instead as usual .

Personal bug:
So I was having an exception when trying to access FirebaseUser on the service. When in remote mode, you can't access the FirebaseUser, since your process runs on another context.
I had to pass the user through intent extras when initializing the service.
That was all!

Implication of android:process when defining services or receivers

will this have an impact on the behaviour of the receiver and SyncService?

Not directly.

Can this impact the applications' behaviour when running

Thread safety becomes a bit more of an issue with everything in one process. OTOH, that can be a lot easier than coordinating work in 2+ processes such that one process does not stomp on the work of the other process.

I am aware than a service will be run on the main thread

The lifecycle methods of a service (e.g., onStartCommand()) will run on the main application thread; your business logic should run on background threads. You have to do that regardless of whether everything is in one process or split between processes.

will something stall or only delay when code is scheduled to run on the main thread?

If your service runs code on the main application thread, it will block everything else on that thread while that code runs. That is why services always use background threads.

Depending on how you are synchronizing access to shared objects, service code running on a background thread could lock access to those shared objects and therefore stall UI code that tries accessing those objects. That's why we try to organize our code to avoid blocking calls from the UI on such objects, such as by using reactive options (LiveData, RxJava, etc.).

android remote process(receiver) dies quickly

Got the answer myself finally,

A BroadcastReceiver object is only
valid for the duration of the call to
onReceive(Context, Intent). Once your
code returns from this function, the
system considers the object to be
finished and no longer active.

source: click here

---

Related Topics