Bound Service Lifecycle with Config Changes & Multiple Clients

WHAT THIS TESTS: This question tests your precise understanding of the Android component lifecycle, specifically the relationship between a bound Service and its clients. Interviewers want to see if you know that a Service's lifecycle is managed by the system based on its binding count, not just explicit start/stop commands. It distinguishes candidates who understand system-managed object lifecycles from those who only think in terms of manual control.

A GOOD ANSWER COVERS: A strong answer addresses both parts of the question sequentially. First, for the configuration change: the Activity is destroyed and a new instance is created, but the bound Service is NOT destroyed. The Android system keeps the Service instance alive because the binding itself persists across the configuration change. The new Activity instance will typically re-bind in its onStart(), and the system will deliver the same IBinder from the existing Service. Second, for multiple clients: the system maintains an internal reference count for the Service. Each call to bindService increments this count. The Service's onDestroy() method is only called when the count reaches zero, after the last client has called unbindService(). A single client unbinding will not destroy the service if others remain bound.

COMMON WRONG ANSWERS: A frequent mistake is stating that the Service is destroyed and recreated along with the Activity during a configuration change. This shows a fundamental misunderstanding of how the system manages process-stable components. Another red flag is saying that onUnbind() always leads to onDestroy(). This is only true if it's the last client unbinding AND the service was not also started via startService(). Confusing the lifecycle of a started service (which requires an explicit stop call) with a purely bound service is a common error.

LIKELY FOLLOW-UPS: How does the behavior change if the Service was also started via startService()? (Answer: The Service runs until BOTH it is explicitly stopped via stopService()/stopSelf() AND all clients have unbound). What is the role of onRebind()? (Answer: It's called if a client binds again after onUnbind() was called, but only if onUnbind() returned true). How would you architect the client to gracefully handle the temporary disconnection during the config change? (Answer: Re-bind in onStart() and handle the binder being null temporarily, or use a ViewModel to retain the binder instance across the Activity recreation).

ONE CONCRETE EXAMPLE: Consider a music player Service. An Activity (the main UI) and a Notification (with media controls) can both bind to it. If the user rotates the phone, the Activity is destroyed and recreated, but the music (managed by the Service) doesn't stop. The new Activity instance just re-binds. If the user closes the Activity, it unbinds, but the music continues because the Notification is still bound. Only when the user dismisses the notification (which would trigger an unbind) would the Service's client count drop to zero, causing the system to call onDestroy().