04 December 2016
Google releases Android Compatibility Definition Document with every major release of Android. This document enlists the rules that every Android OEMs have to follow in order to avoid any interoperability issues. Google waited a couple of months to release the Android Nougat CDD. The document consists of 85-pages revealing what the OEMs have to follow. Some of the rules are meant for the Android OEMs but there are some of the rules that will not be embraced by consumers. We are talking about the ban on the OEMs to stop using their own quick charging technologies for the USB Type-C devices.
This part is unclear, however, this could be used by Google to bypass manufacturers and carriers to push AOSP API updates to the entire Android ecosystem at once. According to Ars Technica, “Android Extensions would be collections of fresh AOSP code delivered directly to your device via the Play Store.”
According to 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.
Google could force OEMs to stop using proprietary charging standards
Today almost every Android OEM brings their own charging tech, be it the OnePlus Dash Charge, Motorola’s Turbo Charging, Huawei’s Super Charge, Oppo’s VOOC, or even chipset makers’, Qualcomm’s Quick Charge, and MediaTek’s Pump Express. Maximum of the Android devices use the Quick Charge today, however, it doesn’t work with every phone. So, Google wants to make a standard that could be implemented or compatible by every device.
Google uses USP Power Delivery on Nexus and Pixel devices for fast charging. This tech is compatible with the chipsets and also allows fast charging. In the current Android CDD, Google is “strongly recommending” that OEMs should adopt USB PD. Google may later force this functionality as according to Android Police,
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.
Nougat doesn’t require Vulkan APIs
It was rumored earlier that Google’s primary reason for dropping devices like the Nexus 5 was the device’s incompatibility with Vulkan APIs. Today, CDD confirms that Nougat doesn’t require a chipset capable of using Vulkan APIs in order to run.
The second standard described in the CDD that can affect the consumers is the multi-window support. The document strictly states that the OEMs can’t implement any multi-window form aside from what is found in AOSP. This can already be seen in action on Nougat-powered devices like Huawei Mate 9 and LG V20.
Here’s what the document write for the multi-windows –
A device implementation MAY choose not to implement any multi-window modes, but if it has the capability to display multiple activities at the same time it MUST implement such multi-window mode(s) in accordance with the application behaviors and APIs described in the Android SDK multi-window mode support documentation and meet the following requirements.
All Android smartphones must support call blocking –
Google defines through this document that the OEMs must support number blocking for calls and messages. This will include adding a UI to manage blocked numbers. We can see this in action on the Huawei Mate 9 which is running on Nougat –
Number Blocking Compatibility 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.
The 85-pages document includes many more changes as well. For instance, the document writes for Android Auto, Audio, Package Manager, and Display as well. You can head to the source to know more about this document.