Android 7.0 Compatibility Document Released, Plenty of Changes in Tow

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:

APIs

• Confirmed: Android 7.0 does not require use of Vulkan APIs.
  • 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
      PackageManager#FEATURE_VULKAN_HARDWARE_LEVEL and PackageManager#FEATURE_VULKAN_HARDWARE_VERSION.
• 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 Auto

• Screen requirements for Android Auto:
  • 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.
• Android Auto temperature sensors must measure the cabin temperature:
  • For Android Automotive implementations, SENSOR_TYPE_AMBIENT_TEMPERATURE MUST measure the temperature inside the vehicle cabin.

Audio

• Under “Professional Audio” in CDD, there’s a new set of requirements:
  • Latencies and USB audio requirements MUST be met using the OpenSL ES PCM buffer queue API.
• 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

• Here’s something interesting I found that hasn’t yet been covered yet:
  • The package manager MUST support verifying “.apk” files using the APK Signature Scheme v2 .
  • Here’s the documentation for this change.

Display

• OEM settings that change Display Density/Size must follow AOSP 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 as indicated below:
• Multi-window support must follow AOSP implementation:
  • 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
• Seemingly very minor change:
  • MAY display affiliated recents as a group that moves together.

Android TV

• Android TV on 7.0 is required to support live pause/play:
  • 3.12.1.4. 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.
• Interesting changes to data storage requirements, tl;dr Android TV now requires minimum of 4GB while other devices must have at least 3GB
  • 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.
• New requirements with regards to TV controllers for Android TV:
  • 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

Android Wear

• Interesting thing about navigation keys with regards to Android Wear:
  • 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.
• Regarding Accessibility: Android Wear devices are recommended (but not required) to implement a talkback-like feature if they support audio output:
  • 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 (http://ift.tt/1G4KDcv).

Telephony

• Call blocking is now required to be implemented for 7.0 devices with telephony capabilities:
  • 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.

Security/Kernel

• New kernel security requirements:
  • 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.
• Safe Boot is outlined in the CDD, but is not required to be implemented:
  • 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.
• Under “Managed Profile Support”, something new regarding lock screens:
  • 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 Page 24 of 85
    • The DPC password policies MUST apply to only the managed profile’s lock screen credentials unless called upon the DevicePolicyManager instance returned by getParentProfileInstance

Data/Storage

• Data Saver feature is not required for OEMs to implement:
  • 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.

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!