8

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.

pree
  • 2,297
  • 6
  • 37
  • 55
  • Deployment is one of the biggest benefits of keeping in one app with two processes. If deploying to an app store, I wouldn't do it any other way. Why do you need a remote service? – Mike dg Jan 17 '14 at 13:46
  • @Mikedg Yes, deployment is one of the reasons you would want to keep both processes in one app but it's not about why I need the remote vs local service, rather I'm trying to understand the overall internal behavior as I mentioned in the below response's comments. – pree Jan 17 '14 at 17:38
  • Edited my question as well. – pree Jan 17 '14 at 18:16
  • Does android:process=": remote will work if background data is OFF or Battery Saver is ON? – Rajesh N Sep 30 '17 at 06:41

1 Answers1

6

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.

Community
  • 1
  • 1
Avanz
  • 7,466
  • 23
  • 54
  • So if an app has a remote service, an application object will be created when the app gets launched and when the service is started, it recreates the application object? Is so, we have a Dalvik VM running one application with two processes and one application object which can change over time depending on a process start up, right? Isn't it little weird and unexpected because we originally start the remote service from an activity using application object (getApplicationObject().startService()). If the application objects gets overwritten, won't it mess up the whole application environment? – pree Jan 17 '14 at 05:46
  • I already looked at that link earlier and played with local/remote all types of services. What I'm trying to understand is the behavior of Context/application object in case of remote service as a part of the client app itself as I just explained above. – pree Jan 17 '14 at 17:35
  • Actually your first link clarified it, each process will get its own application object so they won't mess with each other. one application object per process, not per app/APK. – pree Jan 17 '14 at 19:00