Android 7.0 Compatibility Document Released with Plenty of Interesting Changes

Android 7.0 Compatibility Document Released with Plenty of Interesting Changes

Earlier today, The updated Android 7.0 Compatibility Document was released. This document gives an outline to OEMs about what they can and should not change when creating android for their devices. It includes guidelines for Android Auto, Android TV, Wear, and for Phones and Tablets proper.

In the latest update, quite a bit has changed, and Reddit user and r/Android moderator IAmAN00bie took the time to comb through and point out all changes that really stuck out. Below is a list of his findings, as well as the ones we have noticed while reading the document:


Something that we’ve suspected before in the past since Snapdragon 800/801 devices were confirmed to not be receiving Android Nougat, but can now confirm is that Android 7.0 does NOT require devices to support the Vulkan graphics API.

  • Graphic Libraries
    • Device implementations, if not including support of the Vulkan APIs:
      • MUST report 0 VkPhysicalDevices through the vkEnumeratePhysicalDevices call.
      • MUST NOT declare any of the Vulkan feature flags

A new section, labeled ‘Android Extensions’ seems to hint at the ability for backporting newer AOSP features to older versions of Android, if what Ron Amadeo of ArsTechnica is speculating turns out to be true.

  • 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.

Android Automotive

Google hasn’t really talked about Android Automotive all that much, but that’s because it’s an unreleased operating system designed for motor vehicles, whereas Android Auto is simply an app suite (that you can now run from your phone). With the latest compatibility document, we now have a glimpse at some of the requirements for Android Automotive:

  • Screen Size
    • 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.
  • 7.3.6 Thermometer
    • For Android Automotive implementations, SENSOR_TYPE_AMBIENT_TEMPERATURE MUST measure the temperature inside the vehicle cabin.

There are some additional sensors outlined in Section 7.3.11, including a Day/Night Mode, Driving Status, and Wheel speed.


Google has been quietly introducing newer guidelines for higher fidelity audio playback, and with Android 7.0 this trend has continued. For starters, there’s now a fairly detailed set of new requirements for an OEM to qualify their device as supporting “Professional Audio” playback.

That’s great news for audiophiles, but the average user will see some added benefits in the near future as well. Google seems to be requiring that OEMs implement in-line headset button support for at least three keys: volume down, volume up, and headsethook. While most OEMs support many headset button features already, it’s nice to know that this will be enforced uniformly across all flavors of Android in the future.

  • 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

An update to the way APK files are signed and verified seems to be in place for Android Nougat, provided that developers make use of the new signature scheme. APK Signature Scheme v2 promises to better detect when certain protected parts of APK files have been tampered with, and to prevent installation of said APKs.

  • 4.0 Application Packaging Compatibility
    • The package manager MUST support verifying “.apk” files using the APK Signature Scheme v2 .


Android Nougat introduced some much-needed usability features with regards to the display. First, there’s the ability to natively modify the DPI without editing build.prop. Next, there’s official support for multi-window. Both of these features are much appreciated by any Android enthusiast, considering the half-baked nature of many unofficial implementations. Still, there was some worry that OEMs might continue using their own implementations of these features, resulting in app developers having to support multiple versions of the same feature. Fortunately, that doesn’t seem to be the case, as OEMs must follow the AOSP implementation.

  • Screen Density
    • 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 as indicated below:
  • 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

Finally, there’s a rather minor change made with regards to the recent app screen. It appears that activities shown in the recents app screen that are affiliated (from the same app, for instance) are no longer required to move together when the user is flinging through the screen. Not a terrible major change, for sure, but it’s there regardless.

  • 3.8.8 Activity Switching
    • MAY display affiliated recents as a group that moves together.

Android TV

Android for televisions has not been forgotten, even though Google hasn’t really given much love to it lately. For starters, Android TV on 7.0 is required to support live pause/play:

  • Time shifting
    • Android Television device implementations MUST support time shifting, which allows the user to pause and resume live content. Device implementations MUST provide the user a way to pause and resume the currently playing program, if time shifting for that program is available.

Finally, it appears that Google is updating requirements for navigating Android TV devices. Whereas in the past, Google only required OEMs to allow the user to somehow access every button via pressing some combination of the D-pad, Back, and Home keys; now, Google has defined explicitly certain functions that must be navigable via controller buttons.

  • Navigation
    • The TV App MUST allow navigation for the following functions via the D-pad, Back, and Home keys on the Android Television device’s input device(s) (i.e. remote control, remote control application, or game controller):
      • Changing TV channels
      • Opening EPG
      • Configuring and tuning to third-party TIF-based inputs
      • Opening Settings menu

Memory and Storage

Next up, there are some interesting changes to the storage requirements for both Android TVs and other devices. It appears that Google is decreasing the storage requirement for Android TVs from 5GBs to 4GBs, whereas they are increasing the storage requirement for other devices from 1.5GBs to 3GBs.

  • 7.6.1 Minimum Memory and Storage
    • Android Television devices MUST have at least 4GB and other device implementations MUST have at least 3GB of non-volatile storage available for application private data. That is, the /data partition
      • MUST be at least 4GB for Android Television devices and at least 3GB for other device implementations. Device implementations that run Android are STRONGLY RECOMMENDED to have at least 4GB of non-volatile storage for application private data so they will be able to upgrade to the future platform releases.

Android Wear

Android Wear 2.0 has already been outlined in the past, but while it has been delayed, the CDD provides some new details about the upcoming software update. First up, Android Wear will allow the system to react to long-presses on the back key. OEMs may use this to potentially introduce a quick shortcut to some key feature of some kind, but we’ll have to wait and see what’s in store with the release of the first Wear 2.0 devices.

  • 7.2.3 Navigation Keys
    • Android Watch device implementations, and no other Android device types, MAY consume the long press event on the key event KEYCODE_BACK and omit it from being sent to the foreground application.

Next, Google has outlined a guideline for Android Wear devices with speaker output. Said devices are expected, but not required, to be accessible to users with disabilities by offering some kind of TalkBack-like feature.

  • 3.10 Accessibility
    • Android Watch devices with audio output SHOULD provide implementations of an accessibility service on the device comparable in or exceeding functionality of the TalkBack accessibility service (


One of the most common features related to making phone calls, call blocking, is finally now being made a requirement for any device running Android 7.0 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.

Security Features

Android security holes have been documented and patched for many years now, but one of the most well-known and pervasive security holes was related to libstagefright. Google has been diligently working to separate the media framework into different processes each with their own set of permissions so any attack on the media framework will not have access to such a wide range of permissions.

  • 9.7 Kernel Security Features
    • MUST split the media framework into multiple processes so that it is possible to more narrowly grant access for each process as described in the Android Open Source Project site.

A feature commonly found on desktop and laptop computers, safe mode has been commonly thought to be a native feature of Android for some time. Not so, because only now with the 7.0 CDD has Google outlined the requirements for a safe booting mode. And furthermore, implementation of such a safe boot mode is NOT mandatory.

  • 9.13. Safe Boot Mode
    • Android provides a mode enabling users to boot up into a mode where only preinstalled system apps are allowed to run and all third-party apps are disabled. This mode, known as “Safe Boot Mode”, provides the user the capability to uninstall potentially harmful third-party apps. Android device implementations are STRONGLY RECOMENDED to implement Safe Boot Mode and meet following requirements:
      • Device implementations SHOULD provide the user an option to enter Safe Boot Mode from the boot menu which is reachable through a workflow that is different from that of normal boot.
      • Device implementations MUST provide the user an option to enter Safe Boot Mode in such a way that is uninterruptible from third-party apps installed on the device, except for when the third party app is a Device Policy Controller and has set the UserManager.DISALLOW_SAFE_BOOT flag as true.
      • Device implementations MUST provide the user the capability to uninstall any third-party apps within Safe Mode.

Users who own a separate Android device for their work may now be met with a separate lock screen to grant access to certain apps, an attempt by Google to allow for enterprises to sandbox critical apps separately in case clumsy workers allow a third-party access to their device.

  • 3.9.2 Managed Profile Support
    • Support the ability to specify a separate lock screen meeting the following requirements to grant access to apps running in a managed profile.
      • Device implementations MUST honor the DevicePolicyManager.ACTION_SET_NEW_PASSWORD intent and show an interface to configure a separate lock screen credential for the managed profile.
      • The lock screen credentials of the managed profile MUST use the same credential storage and management mechanisms as the parent profile, as documented on the Android Open Source Project Site
      • The DPC password policies MUST apply to only the managed profile’s lock screen credentials unless called upon the DevicePolicyManager instance returned by getParentProfileInstance

USB Connections

If you’re familiar with the work done by Nathan K. and Benson Leung with regards to USB Type-C cables, then you might be somewhat aware of the issues regarding USB Type-C interoperability and safety. Many third-party fast-charging methods modify the voltage levels and other parts to provide faster charging at the expense of the device losing compatibility with USB Power Delivery (USB PD) methods. Google is now strongly recommended that OEMs stop modifying their charging methods in this manner, with the possibility of revoking CTS in the future for devices that fail to meet these guidelines.

  • 7.7.1 USB Peripheral Mode
    • 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

Mobile Data Management

Data Saver is one of the low-key features introduced in Nougat. The feature allows users to restrict background data access only to those apps that are white-listed. This is especially useful to users who are on plans with low data limits. Unfortunately, this feature is not required to be implemented by OEMs.

  • 7.4.7. Data Saver
    • Device implementations with a metered connection are STRONGLY RECOMMENDED to provide the data saver mode. If a device implementation provides the data saver mode, it:
      • MUST support all the APIs in the ConnectivityManager class as described in the SDK documentation.
      • MUST provide a user interface in the settings, allowing users to add applications to or remove applications from the whitelist.
    • Conversely if a device implementation does not provide the data saver mode, it:
      • MUST return the value RESTRICT_BACKGROUND_STATUS_DISABLED for ConnectivityManager.getRestrictBackgroundStatus
      • MUST not broadcast ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
      • MUST have an activity that handles the Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS intent but MAY implement it as a no-op.

Miscellaneous Features

The 85 page CDD is chock full of details regarding Android features, some of them describing Nougat features we are already intimately familiar with. For starters, there’s a section on Quick Settings (3.13) that outlines how the feature must be implemented. OEMs must allow users to add third-party tiles to Quick Settings and must not automatically add third-party tiles to Quick Settings. Finally, regarding virtual performance, Google has outlined some requirements for meeting VR’s high performance needs in Sections 7.9.2 (Virtual Reality High Performance) and 8.5 (Sustained Performance). You can read the technical details for yourself, but just know that these requirements are unlikely to make a significant difference to the end user.

This is just a selection of the full document. To read the full document for yourself, visit this link. We will be updating this page with more interesting changes as we find them. Let us know in the comments what you think about the new document and changes!

About author

Jake Westall
Jake Westall

I'm a senior mechanical engineering major, a dad, a star wars fanatic, and I play drums and a bit of bass. If you would like to know more about me feel free to ask.