Finally after a whopping 2 and a half months after release, Android 7.0 made a debut on Android distribution charts and now the Android Compatibility Definition Document has been published too. The CDD is a list of rules set out by Google, for OEMs to follow if they wish to include some Google love on the Android devices they sell, most importantly, the Google Playstore and Google Play services. Android may ne open source, but Google Apps are not and as such, Google can set terms and conditions for licensing them to OEMs. Only devices that pass Google’s compatibility tests are allowed to have Google apps on them.
Android’s increasing dependence on these Google Apps or Gapps, as the modders among you know them, irks many in the open source community but this dependence is how Google looks to have and gain more control over its own platform.
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.
USB Type C Requirements
We all want our smartphones to charge up faster. However, it looks like Google might want to put the brakes on some methods that promise those kinds of fast charging times, but don’t use standard hardware.
From the Android 7.0 CDD:
Type-C devices are STRONGLY RECOMMENDED to not support proprietary charging methods that modify Vbus voltage beyond default levels, or alter sink/source roles as such may result in interoperability issues with the chargers or devices that support the standard USB Power Delivery methods. While this is called out as “STRONGLY RECOMMENDED”, in future Android versions we might REQUIRE all type-C devices to support full interoperability with standard type-C chargers.
Between Qualcomm Quick Charge, MediaTek Pump Express, Oppo VOOC, OnePlus Dash Charge, Huawei SuperCharge, Samsung Adaptive Fast Charging and Motorola Turbo Charge, fast charging methods on Android phones are kind of a mess. And this move by Google is intended to nudge phone makers away from nonstandard USB-C charging methods like Qualcomm QuickCharge. The references, first spotted by Android Police, suggest such changes may come into force in future Android versions.
Headphone Inline controls
In the CDD Google also mentions that in order to pass Google’s compatibility tests, any device which has a 3.5mm audio port that has 4 conductors, is required to support both detection and mapping for various keycodes. Those keycodes are listed as KEYCODE_HEADSETHOOK, KEYCODE_VOLUME-UP, AND KEYCODE_VOLUME-DOWN, which have impedance ranges of 70 Omh or less, 210-290 Ohm or less, and 360-680 Ohm or less respectively.
MUST support the detection and mapping to the keycodes for the following 3 ranges of equivalent impedance between the microphone and ground conductors on the audio plug:
- 70 ohm or less : KEYCODE_HEADSETHOOK
- 210-290 Ohm : KEYCODE_VOLUME_UP
- 360-680 Ohm : KEYCODE_VOLUME_DOWN
What this is basically doing is setting it up so that manufacturers aren’t able to change up the action of these keycodes, and like the USB Type-C regulations they’re trying to put in place, they want things to be standardized. Inline headphone controls are a rather… analog method of device control, but they do have the benefit of generally being widely compatible with most phones these days.
Android’s biggest problem has always been and always will be fragmentation, though it’s nothing you can really fault Google for. Their updates come in fast, furious, and regularly, but their business model of licensing Android out to any interested manufacturer creates a default bottleneck for getting all Android users on the latest and greatest software.
In this updated CDD Google seemingly talks about a new system that could “extend” Android’s functionality using shared libraries that OEMs would be forced to include in their Android installations.
Ron Amadeo from Ars Technica explains this better than I can:
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.
Of course, with that only being speculation and there not being enough information, it’s not worth letting your excitement get the best of you. Here’s the original text from the CDD :
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.
Vulkan APIs not required for running Nougat
One other thing discovered in the CDD is confirmation that Nougat doesn’t require a chipset capable of using Vulkan APIs in order to run. Earlier it was rumoured that the reason why the Nexus 5 or the Sony Xperia Z3 won’t get Nougat updates was because they lacked the hardware for running Vulkan APIs. That doesn’t seem to be the case thoughas there are some steps mentioned for such devices.
Device implementations, if not including support of the Vulkan APIs:
- MUST report 0 VkPhysicalDevices through the vkEnumeratePhysicalDevices call.
- MUST NOT delare any of the Vulkan feature flags PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL and PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.
All Android smartphones running on Android Nougat must support call blocking. This includes adding a UI to manage blocked numbers. We can also see this in action on the Huawei Mate 9 which is running Nougat.
Android Telephony device implementations MUST include number blocking support and:
- MUST fully implement BlockedNumberContract and the corresponding API as described in the SDK documentation.
- MUST block all calls and messages from a phone number in ‘BlockedNumberProvider’ without any interaction with apps. The only exception is when number blocking is temporarily lifted as described in the SDK documentation.
- MUST NOT write to the platform call log provider for a blocked call.
- MUST NOT write to the telephony provider for a blocked message.
- MUST implement a blocked numbers management UI, which is opened with the intent returned by TelecomManager.createManageBlockedNumbersIntent() method.
- MUST NOT allow secondary users to view or edit the blocked numbers on the device as the Android platform assumes the primary user to have full control of the telephony Page 59 of 85 services, a single instance, on the device. All blocking related UI MUST be hidden for secondary users and the blocked list MUST still be respected.
- SHOULD migrate the blocked numbers into the provider when a device updates to Android 7.0.
There are even more such mentions in the CDD regarding displays and Android Auto amog others but these were some of the biggest changes that I felt you should know about.
Perhaps Google’s take on Fast charging might not impress you much. I certainly don’t feel good about it. OnePlus’s Dash charging is awesome. What do you think?