0

As we all know,Java memory model consists of data (or code), stack and heap segments. I presume that the same is the case with Android. I have a single monolith application (let's consider the code base of this application to be too huge). When I start the application the activities and fragments within the application gets loaded into Dalvik JVM and offloaded. When this is the case, how this works with Service? Let's say I have a STICKY_SERVICE like,

public class CountingNumberService extends Service {
    @Override
    public int onStartCommand(Intent intent, int flags, int startId) {
        for(int i=0; i<100; i++) {
            //Do something
        }
        return Service.START_STICKY;
    }
    @Override
    public IBinder onBind(Intent intent) {
        /**
         * This has to do with some inter process communication
         */
        return null;
    }
}

Since the service is STICKY it makes the process behave like a persistent process and it is always running. Now consider I stopped using my application and as a user I believed that application is closed (I'm closing it or clearing it from recents) but since my service is STICKY it would always be running and I assume I would have the following impact,

  1. I would eat user's battery.
  2. Some additional code (other than service) will be running along with the application (?) not sure though. If it's the entire application sitting within data segment then it will not allow other application to run smoothly.

I'm kinda confused on STICKY service on a process (a huge monolith code) and it's impact. Can someone clarify me on this please?

Tom Taylor
  • 3,344
  • 2
  • 38
  • 63

1 Answers1

0

Since the service is STICKY it makes the process behave like a persistent process and it is always running.

No, it does not.

but since my service is STICKY it would always be running

No, it will not.

Quoting the documentation for START_STICKY:

if this service's process is killed while it is started (after returning from onStartCommand(Intent, int, int)), then leave it in the started state but don't retain this delivered intent. Later the system will try to re-create the service.

Android is still welcome to terminate your process as it sees fit. All START_STICKY does is encourage Android to restart your service (forking a fresh process along the way) when conditions allow.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • Since the service is STICKY it makes the process behave like a persistent process and it is always running. >> No It is. I've verified by creating a sample program. It makes the process always running even i killed it explicitly via adb shell kill pid. – Tom Taylor May 09 '19 at 20:00
  • @rm-rfstar: If you check your PID, it should be a separate process. – CommonsWare May 09 '19 at 20:01
  • Are you saying that my application and service would be a separate process? – Tom Taylor May 09 '19 at 20:02
  • @rm-rfstar: No. I am saying that you killed your first process. At that point, Android sees that you have requested `START_STICKY` and starts a new process for you. After all, *Android* did not need for your process to be terminated, and it is unlikely to have a reason not to restart it. In the real world, users are not killing processes using `adb shell` -- Android is killing processes due to actual conditions, such as low memory. In that case, there may be a time gap between when Android kills the process and starts a fresh one for you. – CommonsWare May 09 '19 at 20:12
  • Yes, this makes sense @CommonsWare. My worry is if android recreates the process will it recreate all the components in the application or only the service? Since the service by itself asked/requested the Android by mentioning itself as `STICKY`? – Tom Taylor May 10 '19 at 06:57
  • @rm-rfstar: "My worry is if android recreates the process will it recreate all the components in the application or only the service?" -- every time your process starts, the framework will create your `Application` and any `ContentProvider` that you have registered in the manifest. After that, it is based solely on what was requested. So, in the case of `START_STICKY`, the only additional component that will be created automatically is the service. – CommonsWare May 10 '19 at 10:29
  • This is really helpful ! Thanks for being so clear. I have one more doubt now. When the application recreates I'm expecting only the service to run but the receivers which are registered in the manifest are getting invoked as part of it? Is there any way to control them? – Tom Taylor May 10 '19 at 11:22
  • After process recreation (we can expect something like the user quit the app or android killed the app due to some memory pressure) - I'm expecting the receivers in the application code to react only when the user brings the app to foreground. Since I'm making a single service as `STICKY` what are all the receivers that are in AndroidManifest.xml is invoked and executing. Is there any way to control them? – Tom Taylor May 10 '19 at 11:23
  • @rm-rfstar: "but the receivers which are registered in the manifest are getting invoked as part of it?" -- I do not know what you mean, sorry. You might consider asking a separate Stack Overflow question, where you provide a [mcve] showing what you are trying and explain, in detail, what you are getting as results. – CommonsWare May 10 '19 at 11:34