Question

I'm trying to figure out the pros and cons of writing an android remote service as a part of my client app (using android:process=":remote") vs making it a separate service app.

In both the cases, the service would be running in its own separate process and having its own heap etc. However, there have to be some differences when we make it a separate app since it will have its own application sandbox. I found many examples of their usage and preferred approaches as per the scenarios but I'm trying to understand the internal technical details of it.

Any good source of information on this?

Edit: What will be the impact on the application object/context in case the service and client processes are running in the same app. Will it get overwritten by one of the processes? or there will be two application objects for each process which doesn't sound correct being the part of one app.

Was it helpful?

Solution

Your question has been partially answered before. Check here:

But if you still think about the idea of having something running on background, you can have a look in this reference:

Having things running on background is clearly not a good option. Unless you for any reason really need it. So, take care to not annoy the user with unnecessary background services that was not consciously activated by the user´s own will. In such case, making a separate App, or kind of a feature that will bee activated by the user is a smarter and safer road to take.

If you need to be able to write a Service that can perform complicated communication with clients in remote processes (beyond simply the use of Context.startService to send commands to it), then you can use the Messenger class instead of writing full AIDL files. If you only need a remote service, you should follow this tutorial.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top