Bound Service Lifecycle: Config Changes and Multiple Clients

What's really being asked

This question probes your understanding of the reference-counted nature of bound services. It separates candidates who know the basic lifecycle from seniors who understand how the Android system manages the service's existence based on the number of active clients. It specifically tests if you can distinguish between an Activity instance's lifecycle and the service's lifecycle, which are related but not identical.

The full answer

An excellent answer addresses both parts of the question distinctly. First, for the configuration change, you should state that the original Activity instance is destroyed, triggering its onDestroy() method. A well-behaved client unbinds from the service here. If it's the only client, the service's onUnbind() and then onDestroy() are called, destroying the service. The new Activity instance created after the configuration change will then call bindService(), which, thanks to BIND_AUTO_CREATE, creates a new instance of the service, calling its onCreate() and onBind().

Second, for multiple clients, you should explain that the service's lifecycle is managed by a connection count. The first client to bind (with BIND_AUTO_CREATE) causes the service to be created. Subsequent clients binding to the same service do not trigger onCreate() or onBind() again; the system just delivers the same IBinder instance. When one of several clients unbinds, the service's onUnbind() is called, but the service is NOT destroyed because other clients are still connected. The service's onDestroy() method is only called when the very last client unbinds.

The mistakes people make

A major red flag is stating that the service "survives" the configuration change because the system knows the Activity is being recreated. This is incorrect; the service is destroyed and recreated through the unbind/rebind process. Another mistake is thinking onBind() is called for every new client; it's only called for the first one to establish the connection. Similarly, incorrectly describing when onRebind() is called is a sign of a weaker understanding.

What usually comes next

Expect questions like: "How would you persist state within the service across that configuration change?" (The service is destroyed, so you can't. State must be managed outside, e.g., in a ViewModel or persisted to storage). Or, "What's the difference between a started and a bound service, and can a service be both?" (Yes, and it's destroyed only when it is both stopped AND all clients have unbound). Another is, "What does returning true from onUnbind() accomplish?" (It allows onRebind() to be called for future clients instead of onBind()).

A concrete example

Imagine a music player Service. An Activity binds to it to display the currently playing track. If the user rotates their phone (a config change), the Activity unbinds, destroying the service. The new Activity instance re-binds, creating a new service. If state wasn't saved externally, the music would restart. However, if a media notification was ALSO a client bound to that service, rotating the phone would cause the Activity to unbind, but the service would NOT be destroyed because it still has one client (the notification).