Let’s start by examining the design goals of Play Services in contrast with the platform code. At a high level, the relevant architectural issues at hand are:

Play Services is built into an application package (APK), rather than the framework core. This application is updated automatically by the Play Store, outside of platform releases. Client applications (to some extent) dictate the version of Play Services on the device.

In the Android framework, system services are registered at boot time with a registry component known as service manager, which tracks all services available to other applications. There is a strong assumption that framework services will always be available and the processes containing them will always be running. Even if they die, Android ensures they get restarted as quickly as possible. The framework, therefore, has very limited checks around service availability. Services are never unregistered, removed, or replaced at runtime.

Google Play Services, on the other hand, exposes services directly to client applications to be bound using intents. There’s nothing terribly magical about this process. The same general capability is available to any application in the SDK using AIDL. At any moment, the APK containing Play Services may be updated. This can happen when a scheduled version upgrade rollout occurs, or even when a client application simply requests a higher version than is currently installed on the device. When this happens, all the existing services are replaced with a different instance.

In short, the core framework is quite static at runtime, while Play Services is designed to be very dynamic.