“Android Extensions” could be Google’s plan to make Android updates suck less

Finally, a whopping two-and-a-half months after the release of Android 7.0 Nougat, the Android 7.0 Compatibility Definition Document (CDD) has been published. The CDD is Google’s list of rules for Android OEMs that want to ship devices with the Google Play Store and other Google apps. While Android is open source, most of Google’s apps are not, and licensing Google’s apps means agreeing to a contract called the Mobile Application Distribution Agreement (MADA) and passing Google’s “compatibility” tests, which ensure the device can properly run Android apps.

The updates to the 85-page Compatibility Definition Document are mostly about codifying the new 7.0 features so OEMs don’t break anything, but there are a few interesting tidbits. The one we’re going to focus on now is the mysterious mention of “Android Extensions.” There’s a whole new section, which reads:

3.1.1. Android Extensions

Android includes the support of extending the managed APIs while keeping the same API level version. Android device implementations MUST preload the AOSP implementation of both the shared library ExtShared and services ExtServices with versions higher than or equal to the minimum versions allowed per each API level. For example, Android 7.0 device implementations, running API level 24 MUST include at least version 1.

“Extending the managed APIs while keeping the same API level version” sounds a whole lot like what Google Play Services does today. You have the base Android operating system, and Google Play Services is a layer that sits on top of the OS. Play Services provides a bunch of Google APIs, giving developers access to various Google Services. Because Play Services is just an APK (an Android app file), it can be easily updated via the Play Store. This means that regardless of how indifferent your OEM is to updates, Play Services can always be updated directly by Google.

Today on a production Android device there are two main API sources for developers: the AOSP (Android Open Source Project) APIs included in the base OS, and the proprietary Google APIs included in Google Play Services. Play Services is an easily updatable APK, while the AOSP APIs require a full OS update, which for non-Google phones can be a nightmare of roadblocks and approvals.

The current “layout” of Android, to the best of our knowledge. We might soon have to add a new column to this called “Android Extensions.”

We have a theory: “Android Extensions” is a plan to bring the easily updatable app model to the AOSP APIs. Like Google Play Services, we think this app will be a bundle of API shims that Google can update whenever it wants. The difference is that everything in Play Services is a closed-source Google API, while “Android Extensions” would be collections of fresh AOSP code delivered directly to your device via the Play Store. The CDD’s stipulation that OEMs “MUST preload the AOSP implementation” is telling. It says that 1) this is AOSP code, and 2) OEMs aren’t allowed to “customize” it.

The CDD even helpfully calls out the specific files. It references “shared library ExtShared and services ExtServices,” and sure enough, there are two new APKs on Android 7.0 devices called “GoogleExtShared.apk” and “GoogleExtServices.apk.” After taking a look at the two files on the Google Pixel and LG V20, we can say that today they are…mostly empty.

Specifically, GoogleExtShared.apk is almost totally empty. It has no UI, no permissions, no images, boilerplate Java code, and a single string that identifies the app as the “Android Shared Library.” GoogleExtServices has an app name of “Android Services Library” and does actually contain something: an “Android Notification Ranking Service.” A “Notification Ranking Service” was added in Lollipop, and it sorts notifications by “importance” based on things like freshness, app type (IM apps come first), and by contact. This seems to be an extension to the system that includes support for Nougat’s “notification bundling” feature. This is a really minor feature, and with only this single chunk of code, GoogleExtServices weighs in at a microscopic 10KB.

The shape of things to come

So if these two files are pretty much empty, why does the CDD demand that both files be preloaded in all 7.0 devices? The answer is probably because we’ll eventually see these “apps” show up in the Play Store. Being preloaded means if updated versions did come to the Play Store, the Play Store client would find them and automatically install the updated versions. Preloading placeholder apps basically ensures Google can “install” these at a later date, when they’re ready. Being empty fits with our theory that these files will be for backporting future AOSP features—they’re empty now because fresh versions of the OS just shipped, and Google hasn’t yet developed any out-of-cycle features to backport.