Exploring the Android 7.0 CDD for TVs

The Android Compatibility Definition Document (CDD) is an important document for OEMs. It is a document, written by engineers at Google, that stipulates what is required in an Android device. This may differ based on form factor (TV, phone, watch), but overall states what is recommended and required for products before they’re certified. This certification allows the device to come preloaded with Google Play and Google apps, giving consumers a healthy ecosystem of software to use right out of the box.

With each major revision of the operating system is a revision of the CDD. In the document for Android 7, there were several notable changes for Android TV. How will these permeate to other devices? We’ll explore the changes to the CDD below.

3.12. TV Input Framework

The TV Input Framework is the set of APIs on Android TV that allow third-party apps to build their own channels and interface with the Live Channels app. In Android 7, TV recording was added. However, it seems like OEMs won’t have to support it.

Android Television device implementations are STRONGLY RECOMMENDED to support TV recording. If the TV input supports recording, the EPG MAY provide a way to record a program if the recording of such a program is not prohibited. Device implementations SHOULD provide a user interface to play recorded programs.

Sony’s custom TV app, for instance, does not have to support recording to fit within Google’s specifications. Even if it does, this may not appear in the guide or include a DVR interface.

This may change in the future, moving from “strongly recommended” to “required”. Other TIF features such as TV input app linking and time shifting “must” be implemented.

3.8.14. Multi-Windows

Android TV apps can now enter picture-in-picture (PiP), allowing two apps to be displayed and running at the same time. You could watch video while browsing other videos or even while ordering a pizza.

Android Television device implementations MUST support picture-in-picture (PIP) mode multi-window and place the PIP multi-window in the top right corner when PIP is ON.

Picture-in-picture must be implemented by the OEM. It shouldn’t be difficult given that code exists within the platform. On the Nexus Player, you can enter this mode by holding down the home button. For other devices, there may have to be separate implementations. Regardless, any Android TV should be able to access this mode through a particular key.

If the PIP multi-window mode is supported the KeyEvent.KEYCODE_WINDOW key MUST be used to control the PIP window; otherwise, the key MUST be available to the foreground activity

This WINDOW key was first added to Google TV in API level 11. Now, it can be used to enter the PiP mode.

5.3. Video Decoding

Android TV is a device that puts a big focus on video playback, so it makes sense there are a number of requirements around media playback. Android TVs are specifically required to support the H.264 codec, including HD 1080p60, H.265, VP8, and VP9.

VP9 is a recent codec, developed in part by Google, to minimize data usage in high resolution videos. Although not required, it is recommended for Android TV to support UHD decoding in VP9 videos.

SHOULD support the UHD decoding profile. If the UHD video decoding profile is supported, it MUST support 8-bit color depth and SHOULD support VP9 Profile 2 (10-bit).

7.2.6, 7.2.7. TV Input Devices

Android TVs can be controlled through different means and all of these types are expected to be supported. Android TVs “must support button mappings for game controllers”. The document provides a table which lists all of the required inputs, which are all what is expected.

TVs “should” provide a remote control for users. They don’t have to, such as set-top boxes which are primarily for gaming. Remotes may be a physical piece of hardware or just be a phone app. If a remote is provided, it must support voice search capability and include buttons for navigation.

5.8. Secure Media

Services like Netflix rely on paying subscribers to continue operating. Piracy can have an impact on their subscriber count and ability to succeed. There are different ways to keep content secure, even when its being streamed to different devices.

Android Television device implementations MUST support HDCP 2.2 for devices supporting 4K resolution and HDCP 1.4 or above for lower resolutions

3.3.1.1. Graphic Libraries

Vulkan is a new graphics library which is cross-platform and uses parallelization to make graphics run better than before. It has plenty of value on newer devices which can take advantage of smoother graphics.

It makes sense for Android TVs, since they have enough power to run games and since gaming is a big focus. Android devices do not have to support Vulkan, but if they do:

Device implementations, if including support of the Vulkan APIs:

  • MUST report, one or more VkPhysicalDevices through the vkEnumeratePhysicalDevices
    call.
  • Each enumerated VkPhysicalDevices MUST fully implement the Vulkan 1.0 API.
  • MUST report the correct PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL
    and PackageManager#FEATURE_VULKAN_HARDWARE_VERSION feature flags.
    MUST enumerate layers, contained in native libraries named libVkLayer*.so in the
    application package’s native library directory, through the vkEnumerateInstanceLayerProperties and vkEnumerateDeviceLayerProperties functions in libvulkan.so
  • MUST NOT enumerate layers provided by libraries outside of the application package, or provide other ways of tracing or intercepting the Vulkan API, unless the application has the android:debuggable=”true” attribute

Conclusion

As Android TV continues to become more mainstream, and picked up by various OEMs, these documents provide a great insight into what kind of experience users will have at the bare minimum. By looking at these changes over time, it can also highlight what Google expects from devices in the next year.

We’ll continue to look at CDDs with each major revision and continue to report how the platform changes over time.

Nick Felker

Nick Felker

Nick Felker is a student Electrical & Computer Engineering student at Rowan University (C/O 2017) and the student IEEE webmaster. When he's not studying, he is a software developer for the web and Android (Felker Tech). He has several open source projects on GitHub (http://github.com/fleker) Devices: Moto G-2013 Moto G-2015, Moto 360, Google ADT-1, Nexus 7-2013 (x2), Lenovo Laptop, Custom Desktop. Although he was an intern at Google, the content of this blog is entirely independent and his own thoughts.

More Posts - Website

Follow Me:
TwitterLinkedInGoogle PlusReddit