Android remote service in app versus standalone app

I'm trying to figure out the pros and cons of writing a remote Android service as part of my client application (using android: process = ": remote"), which makes it a standalone service application.

In both cases, the service will work in its own separate process and have its own heap, etc. However, when creating a separate application, there should be some differences, since it will have a separate application sandbox. I have found many examples of their use and preferred approaches according to the scenarios, but I am trying to understand the internal technical details.

What is a good source of information about this?

Edit: What will be the impact on the application object / context if the services and client processes are running in the same application. Will it be overwritten by one of the processes? or for each process there will be two application objects that do not seem to be correct, are part of one application.

+7
android android-service android-service-binding
source share
1 answer

Your question has been partially addressed before. Check here:

  • using android: process = ": remote" recreates android Application object

But if you still think that something is working in the background, you can look in this link:

Having things working in the background is clearly not a good option. If for any reason you really need it. Therefore, be careful not to annoy the user with unnecessary background services that were not knowingly activated by the user's own will. In this case, creating a separate application or a kind of function that will be activated by the user is a more reasonable and safe way.

If you need to write a service that can perform complex communications with clients in remote processes (besides just using the .startService context 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 .

+6
source share

All Articles