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.
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.
If our theory is right, the real question going forward is how extensively these two APKs will be used by Google. Google Play Services 1.0 didn't do much when it launched in September 2012, just rolling out support for OAuth 2.0 and a few Google+ APIs. However, over the following years it grew lots of other APIs.
Here is our best guess at what these two files will eventually do once the updates come out: "GoogleExtServices" sounds like the AOSP counterpart to Google Play Services. It will bring new APIs to developers, with proprietary Google APIs living in Play Services and AOSP APIs living in "Extended" Services. "GoogleExtShared" is identified as a "Shared Library," a feature that lets programs share common bits of code, usually from a third party. For instance, nearly every Android app today includes the Android Support Library—another collection of shims that allows newer Android features to work on older operating systems. Android doesn't support shared libraries today, so the Android Support Library is bundled with most apps—it wouldn't be crazy to have 50 copies of it on your phone, all at various versions. Shared Libraries would allow for a single instance of the Android Support Library on a device, which every app could access.
There will always be a gap between what a full OS update can do and what updating a set of APKs can do. Right now, though, with Google Play Services as the only "API shim" app, Google's update setup has the odd stipulation that easily updatable code must also be proprietary Google code. There's no reason Google can't use this "app-style distribution" to ship open source code just as easily, and so far the evidence suggests these two "Android Extension" APKs could be a path toward that.
Listing image by Dsimic
reader comments
72