With every major release of Android, Google releases an Android Compatibility Definition Document which lays out Google’s rules for Android OEMs in order for those devices to be approved to ship with Google’s services, including the Play Store. With Android Nougat the company waited a couple of months to release that document and today, it’s finally here. The 85-page document spells out Google’s plans for Android OEMs, and while most of the document is relatively unimportant for most people, there are some points worth talking about…
“Android Extensions”
The first big talking point, unearthed by Ars Technica, is “Android Extensions.” While we don’t fully know what Google has in store for this, it seems like it could be used by Google to bypass manufacturers and carriers to push AOSP API updates to the entire Android ecosystem at once. Currently, the APKs that power “Android Extensions” on the Google Pixel and LG V20 are mostly blank slates, but over time Google could use this to push more updates to Android’s core without requiring full system updates.
With that said, 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.
And here’s the text straight from the CDD:
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.
Google May Force OEMs To Stop Using Proprietary Charging Standards
Another important change is this document is Google attempting to push OEMs away from proprietary charging standards. If you ask me, this is the most important consumer-facing aspect of this document. Right now there are several different fast charging “standards” on the market ─ Qualcomm Quick Charge, OnePlus Dash Charge, Motorola Turbo Charging, Huawei SuperCharge, MediaTek Pump Express, and OPPO VOOC just to name a few. Even though Quick Charge is the most widely used standard out today, it doesn’t work on every phone, and Google wants to change that.
On the Pixel and last year’s Nexus devices, Google uses USB Power Delivery for fast charging. Not only does this allow fasting charging, but it’s also compatible with all chipsets. That means that, in a perfect world, everyone could use the same fast chargers on all smartphones. In the current Android CDD, Google is “strongly recommending” that OEMs adopt USB PD, Google may later force this functionality as Android Police pointed out:
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
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. It was rumored earlier in the year that this was Google’s primary reason for dropping devices like the Nexus 5 as well as OEMs for dropping devices running on older Qualcomm chipsets, but clearly, that isn’t the issue we once thought it was.
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.
Multi-Window Support Must Follow AOSP
A feature that OEMs have long had, but Google waited on implementing is multi-window. It wasn’t until Nougat that Google added this feature as a part of the OS, but there was still concern that OEMs would try to make the feature “their own.” Thankfully, they won’t have the chance. A portion of the CDD strictly states the OEMs cannot implement any multi-window form aside from what is found in AOSP. We can already see this in action on Nougat-powered devices like Huawei Mate 9 and LG V20.
Also worth noting, OEMs do have the option of not implementing multi-window if they choose to do so. For the most part, it’s unlikely that OEMs might skip this feature, but I could absolutely see it happening on devices with small screens oinadequatete performance.
3.8.14. 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
The last big thing we’ll point out regards call blocking. In Nougat, OEMs must support number blocking for calls and messages. 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.
7.4.1.1. 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.
These are just a few of the big changes from Nougat’s CDD ─ there are undoubtedly many more. Just from these, however, we can see that Google is working step-by-step to take back portions of Android, and we can see those results in Nougat. We’ve listed a few other changes below.
Android Auto
The Nougat CDD reveals updated specs on hardware requirements for Android Auto stereos including the size and resolution. It also shows that temperature sensors used with Android Auto must measure the cabin of the vehicle.
- Android Automotive devices MUST have a screen with the physical diagonal size greater than or equal to 6 inches.
- Android Automotive devices MUST have a screen size of at least 750 dp x 480 dp.
- For Android Automotive implementations, SENSOR_TYPE_AMBIENT_TEMPERATURE MUST measure the temperature inside the vehicle cabin.
Audio
The document also lays out information on how Android devices should handle remote controls on headphones connected via a 3.5mm headphone jack.
7.8.2.1 Analog Audio Ports
In order to be compatible with the headsets and other audio accessories using the 3.5mm audio plug across the Android ecosystem, if a device implementation includes one or more analog audio ports, at least one of the audio port(s) SHOULD be a 4 conductor 3.5mm audio jack. If a device implementation has a 4 conductor 3.5mm audio jack, it:
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
Package Manager
Nougat also adds a requirement for installing APKs. More details on that can be found here.
The package manager MUST support verifying “.apk” files using the APK Signature Scheme v2.
Display
Settings that change Display Density/Size must follow AOSP’s implementation:
Device implementations are STRONGLY RECOMMENDED to provide users a setting to change the display size. If there is an implementation to change the display size of the device, it MUST align with the AOSP implementation
FTC: We use income earning auto affiliate links. More.
Comments