Bound Service Lifecycle with Config Changes & Multiple Clients
Tests your grasp of bound Service lifecycles. Explain that with BIND_AUTO_CREATE, the Service survives an Activity's config change recreation. It's only destroyed after the *last* client unbinds. A red flag is assuming the Service dies with the first client.
What's really being asked
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.
The full answer
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.
The mistakes people make
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.
What usually comes next
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).
A 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().
Interview question
Two distinct clients are bound to a Service using BIND_AUTO_CREATE. If one client calls unbindService(), what is the immediate impact on the Service?
- a.The Service continues to run because at least one client remains bound to it.Correct
- b.The Service's onUnbind() method is called, followed immediately by onDestroy().
- c.The Service enters a 'pending destruction' state until the second client unbinds.
- d.The Service is destroyed as the system detects a change in its client count.
Why? this is the answer
The system maintains a reference count for bound services. onDestroy() is only called when the count drops to zero. Option B is a common misconception; onDestroy() is not called until the *last* client unbinds.
Just read this? Test yourself on what you have been reading.
Read the original → developer.android.com
- #android
- #service
- #lifecycle
- #architecture
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on android — each one lists the topics its interview covers.
See open roles