Impact of sticky service in an application with huge monolith code base in Android?

Question

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?

Answer 1

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.