1## 7.4\. Data Connectivity 2 3### 7.4.1\. Telephony 4 5“Telephony” as used by the Android APIs and this document refers specifically 6to hardware related to placing voice calls and sending SMS messages via a GSM 7or CDMA network. While these voice calls may or may not be packet-switched, 8they are for the purposes of Android considered independent of any data 9connectivity that may be implemented using the same network. In other words, 10the Android “telephony” functionality and APIs refer specifically to voice 11calls and SMS. For instance, device implementations that cannot place calls or 12send/receive SMS messages are not considered a telephony device, regardless of 13whether they use a cellular network for data connectivity. 14 15* Android MAY be used on devices that do not include telephony hardware. That 16is, Android is compatible with devices that are not phones. 17 18If device implementations include GSM or CDMA telephony, they: 19 20* [C-1-1] MUST declare the `android.hardware.telephony` feature flag and 21other sub-feature flags according to the technology. 22* [C-1-2] MUST implement full support for the API for that technology. 23 24If device implementations do not include telephony hardware, they: 25 26* [C-2-1] MUST implement the full APIs as no-ops. 27 28#### 7.4.1.1\. Number Blocking Compatibility 29 30If device implementations report the `android.hardware.telephony feature`, they: 31 32* [C-1-1] MUST include number blocking support 33* [C-1-2] MUST fully implement [`BlockedNumberContract`]( 34http://developer.android.com/reference/android/provider/BlockedNumberContract.html) 35and the corresponding API as described in the SDK documentation. 36* [C-1-3] MUST block all calls and messages from a phone number in 37'BlockedNumberProvider' without any interaction with apps. The only exception 38is when number blocking is temporarily lifted as described in the SDK 39documentation. 40* [C-1-4] MUST NOT write to the [platform call log provider]( 41http://developer.android.com/reference/android/provider/CallLog.html) 42for a blocked call. 43* [C-1-5] MUST NOT write to the [Telephony provider]( 44http://developer.android.com/reference/android/provider/Telephony.html) 45for a blocked message. 46* [C-1-6] MUST implement a blocked numbers management UI, which is opened 47with the intent returned by `TelecomManager.createManageBlockedNumbersIntent()` 48method. 49* [C-1-7] MUST NOT allow secondary users to view or edit the blocked numbers 50on the device as the Android platform assumes the primary user to have full 51control of the telephony services, a single instance, on the device. All 52blocking related UI MUST be hidden for secondary users and the blocked list MUST 53still be respected. 54* SHOULD migrate the blocked numbers into the provider when a device updates 55to Android 7.0. 56 57#### 7.4.1.2\. Telecom API 58 59If device implementations report `android.hardware.telephony`, they: 60 61* [C-SR] Are STRONGLY RECOMMENDED to handle the the audio headset's 62 `KEYCODE_MEDIA_PLAY_PAUSE` and `KEYCODE_HEADSETHOOK` events for the 63 [`android.telecom`](https://developer.android.com/reference/android/telecom/package-summary.html) 64 APIs as below: 65 * Call [`Connection.onDisconnect()`](https://developer.android.com/reference/android/telecom/Connection.html#onDisconnect%28%29) 66 when a short press of the key event is detected during an ongoing call. 67 * Call [`Connection.onAnswer()`](https://developer.android.com/reference/android/telecom/Connection.html#onAnswer%28%29) 68 when a short press of the key event is detected during an incoming call. 69 * Call [`Connection.onReject()`](https://developer.android.com/reference/android/telecom/Connection.html#onReject%28%29) 70 when a long press of the key event is detected during an incoming call. 71 * Toggle the mute status of the [`CallAudioState`](https://developer.android.com/reference/android/telecom/CallAudioState.html) 72 73### 7.4.2\. IEEE 802.11 (Wi-Fi) 74 75Device implementations: 76 77* SHOULD include support for one or more forms of 802.11\. 78 79If device implementations include support for 802.11 and expose the 80functionality to a third-party application, they: 81 82* [C-1-1] MUST implement the corresponding Andr:oid API. 83* [C-1-2] MUST report the hardware feature flag `android.hardware.wifi`. 84* [C-1-3] MUST implement the [multicast API]( 85http://developer.android.com/reference/android/net/wifi/WifiManager.MulticastLock.html) 86as described in the SDK documentation. 87* [C-1-4] MUST support multicast DNS (mDNS) and MUST NOT filter mDNS packets 88(224.0.0.251) at any time of operation including: 89 * Even when the screen is not in an active state. 90 * For Android Television device implementations, even when in standby 91power states. 92* SHOULD randomize the source MAC address and sequence number of probe 93request frames, once at the beginning of each scan, while STA is disconnected. 94 * Each group of probe request frames comprising one scan should use one 95 consistent MAC address (SHOULD NOT randomize MAC address halfway through a 96 scan). 97 * Probe request sequence number should iterate as normal (sequentially) 98 between the probe requests in a scan 99 * Probe request sequence number should randomize between the last probe 100 request of a scan and the first probe request of the next scan 101* SHOULD only allow the following information elements in probe request 102frames, while STA is disconnected: 103 * SSID Parameter Set (0) 104 * DS Parameter Set (3) 105 106#### 7.4.2.1\. Wi-Fi Direct 107 108Device implementations: 109 110* SHOULD include support for Wi-Fi Direct (Wi-Fi peer-to-peer). 111 112If device implementations include support for Wi-Fi Direct, they: 113 114* [C-1-1] MUST implement the [corresponding Android API]( 115 http://developer.android.com/reference/android/net/wifi/p2p/WifiP2pManager.html) 116 as described in the SDK documentation. 117* [C-1-2] MUST report the hardware feature `android.hardware.wifi.direct`. 118* [C-1-3] MUST support regular Wi-Fi operation. 119* SHOULD support Wi-Fi and Wi-Fi Direct operations concurrently. 120 121#### 7.4.2.2\. Wi-Fi Tunneled Direct Link Setup 122 123Device implementations: 124 125* SHOULD include support for 126 [Wi-Fi Tunneled Direct Link Setup (TDLS)]( 127 http://developer.android.com/reference/android/net/wifi/WifiManager.html) 128 as described in the Android SDK Documentation. 129 130If device implementations include support for TDLS and TDLS is enabled by the 131WiFiManager API, they: 132 133* [C-1-1] MUST declare support for TDLS through [`WifiManager.isTdlsSupported`] 134(https://developer.android.com/reference/android/net/wifi/WifiManager.html#isTdlsSupported%28%29). 135* SHOULD use TDLS only when it is possible AND beneficial. 136* SHOULD have some heuristic and NOT use TDLS when its performance might be 137 worse than going through the Wi-Fi access point. 138 139#### 7.4.2.3\. Wi-Fi Aware 140 141Device implementations: 142 143* SHOULD include support for [Wi-Fi Aware]( 144 http://www.wi-fi.org/discover-wi-fi/wi-fi-aware). 145 146If device implementations include support for Wi-Fi Aware and expose the 147functionality to third-party apps, then they: 148 149* [C-1-1] MUST implement the `WifiAwareManager` APIs as described in the 150[SDK documentation]( 151http://developer.android.com/reference/android/net/wifi/aware/WifiAwareManager.html). 152* [C-1-2] MUST declare the `android.hardware.wifi.aware` feature flag. 153* [C-1-3] MUST support Wi-Fi and Wi-Fi Aware operations concurrently. 154* [C-1-4] MUST randomize the Wi-Fi Aware management interface address at intervals 155 no longer then 30 minutes and whenever Wi-Fi Aware is enabled. 156 157#### 7.4.2.4\. Wi-Fi Passpoint 158 159Device implementations: 160 161* SHOULD include support for [Wi-Fi Passpoint]( 162 http://www.wi-fi.org/discover-wi-fi/wi-fi-certified-passpoint). 163 164If device implementations include support for Wi-Fi Passpoint, they: 165 166* [C-1-1] MUST implement the Passpoint related `WifiManager` APIs as 167described in the [SDK documentation]( 168http://developer.android.com/reference/android/net/wifi/WifiManager.html). 169* [C-1-2] MUST support IEEE 802.11u standard, specifically related 170 to Network Discovery and Selection, such as Generic Advertisement 171 Service (GAS) and Access Network Query Protocol (ANQP). 172 173Conversely if device implementations do not include support for Wi-Fi 174Passpoint: 175 176* [C-2-1] The implementation of the Passpoint related `WifiManager` 177APIs MUST throw an `UnsupportedOperationException`. 178 179### 7.4.3\. Bluetooth 180 181If device implementations support Bluetooth Audio profile, they: 182 183* SHOULD support Advanced Audio Codecs and Bluetooth Audio Codecs 184(e.g. LDAC). 185 186If device implementations declare `android.hardware.vr.high_performance` 187feature, they: 188 189* [C-1-1] MUST support Bluetooth 4.2 and Bluetooth LE Data Length Extension. 190 191Android includes support for [Bluetooth and Bluetooth Low Energy]( 192http://developer.android.com/reference/android/bluetooth/package-summary.html). 193 194If device implementations include support for Bluetooth and Bluetooth 195Low Energy, they: 196 197* [C-2-1] MUST declare the relevant platform features 198(`android.hardware.bluetooth` and `android.hardware.bluetooth_le` 199respectively) and implement the platform APIs. 200* SHOULD implement relevant Bluetooth profiles such as 201 A2DP, AVCP, OBEX, etc. as appropriate for the device. 202 203 204If device implementations include support for Bluetooth Low Energy, they: 205 206* [C-3-1] MUST declare the hardware feature `android.hardware.bluetooth_le`. 207* [C-3-2] MUST enable the GATT (generic attribute profile) based Bluetooth 208APIs as described in the SDK documentation and 209[android.bluetooth]( 210http://developer.android.com/reference/android/bluetooth/package-summary.html). 211* [C-3-3] MUST report the correct value for 212`BluetoothAdapter.isOffloadedFilteringSupported()` to indicate whether the 213filtering logic for the [ScanFilter]( 214https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html) 215API classes is implemented. 216* [C-3-4] MUST report the correct value for 217`BluetoothAdapter.isMultipleAdvertisementSupported()` to indicate 218whether Low Energy Advertising is supported. 219* SHOULD support offloading of the filtering logic to the bluetooth chipset 220when implementing the [ScanFilter API]( 221https://developer.android.com/reference/android/bluetooth/le/ScanFilter.html). 222* SHOULD support offloading of the batched scanning to the bluetooth chipset. 223* SHOULD support multi advertisement with at least 4 slots. 224 225 226* [SR] STRONGLY RECOMMENDED to implement a Resolvable Private Address (RPA) 227timeout no longer than 15 minutes and rotate the address at timeout to protect 228user privacy. 229 230### 7.4.4\. Near-Field Communications 231 232Device implementations: 233 234* SHOULD include a transceiver and related hardware for Near-Field 235Communications (NFC). 236* [C-0-1] MUST implement `android.nfc.NdefMessage` and 237`android.nfc.NdefRecord` APIs even if they do not include support for NFC or 238declare the `android.hardware.nfc` feature as the classes represent a 239protocol-independent data representation format. 240 241 242If device implementations include NFC hardware and plan to make it available to 243third-party apps, they: 244 245* [C-1-1] MUST report the `android.hardware.nfc` feature from the 246[`android.content.pm.PackageManager.hasSystemFeature()` method]( 247http://developer.android.com/reference/android/content/pm/PackageManager.html). 248* MUST be capable of reading and writing NDEF messages via the following NFC 249standards as below: 250* [C-1-2] MUST be capable of acting as an NFC Forum reader/writer 251(as defined by the NFC Forum technical specification 252NFCForum-TS-DigitalProtocol-1.0) via the following NFC standards: 253 * NfcA (ISO14443-3A) 254 * NfcB (ISO14443-3B) 255 * NfcF (JIS X 6319-4) 256 * IsoDep (ISO 14443-4) 257 * NFC Forum Tag Types 1, 2, 3, 4, 5 (defined by the NFC Forum) 258* [SR] STRONGLY RECOMMENDED to be capable of reading and writing NDEF 259 messages as well as raw data via the following NFC standards. Note that 260 while the NFC standards are stated as STRONGLY RECOMMENDED, the 261 Compatibility Definition for a future version is planned to change these 262 to MUST. These standards are optional in this version but will be required 263 in future versions. Existing and new devices that run this version of 264 Android are very strongly encouraged to meet these requirements now so 265 they will be able to upgrade to the future platform releases. 266 267* [C-1-3] MUST be capable of transmitting and receiving data via the 268 following peer-to-peer standards and protocols: 269 * ISO 18092 270 * LLCP 1.2 (defined by the NFC Forum) 271 * SDP 1.0 (defined by the NFC Forum) 272 * [NDEF Push Protocol]( 273 http://static.googleusercontent.com/media/source.android.com/en/us/compatibility/ndef-push-protocol.pdf) 274 * SNEP 1.0 (defined by the NFC Forum) 275* [C-1-4] MUST include support for [Android Beam]( 276 http://developer.android.com/guide/topics/connectivity/nfc/nfc.html) and 277 SHOULD enable Android Beam by default. 278* [C-1-5] MUST be able to send and receive using Android Beam, 279 when Android Beam is enabled or another proprietary NFC P2p mode is 280 turned on. 281* [C-1-6] MUST implement the SNEP default server. Valid NDEF messages 282received by the default SNEP server MUST be dispatched to applications using 283the `android.nfc.ACTION_NDEF_DISCOVERED` intent. Disabling Android Beam in 284settings MUST NOT disable dispatch of incoming NDEF message. 285* [C-1-7] MUST honor the `android.settings.NFCSHARING_SETTINGS` intent to 286 show [NFC sharing settings]( 287 http://developer.android.com/reference/android/provider/Settings.html#ACTION_NFCSHARING_SETTINGS). 288* [C-1-8] MUST implement the NPP server. Messages received by the NPP 289 server MUST be processed the same way as the SNEP default server. 290* [C-1-9] MUST implement a SNEP client and attempt to send outbound P2P 291 NDEF to the default SNEP server when Android Beam is enabled. If no default 292 SNEP server is found then the client MUST attempt to send to an NPP server. 293* [C-1-10] MUST allow foreground activities to set the outbound P2P NDEF 294message using `android.nfc.NfcAdapter.setNdefPushMessage`, and 295`android.nfc.NfcAdapter.setNdefPushMessageCallback`, and 296`android.nfc.NfcAdapter.enableForegroundNdefPush`. 297* SHOULD use a gesture or on-screen confirmation, such as 'Touch to 298Beam', before sending outbound P2P NDEF messages. 299* [C-1-11] MUST support NFC Connection handover to Bluetooth when the 300 device supports Bluetooth Object Push Profile. 301* [C-1-12] MUST support connection handover to Bluetooth when using 302 `android.nfc.NfcAdapter.setBeamPushUris`, by implementing the 303 “[Connection Handover version 1.2]( 304 http://members.nfc-forum.org/specs/spec_list/#conn_handover)” and 305 “[Bluetooth Secure Simple Pairing Using NFC version 1.0]( 306 http://members.nfc-forum.org/apps/group_public/download.php/18688/NFCForum-AD-BTSSP_1_1.pdf)” 307 specs from the NFC Forum. Such an implementation MUST implement the handover 308 LLCP service with service name “urn:nfc:sn:handover” for exchanging the 309 handover request/select records over NFC, and it MUST use the Bluetooth Object 310 Push Profile for the actual Bluetooth data transfer. For legacy reasons (to 311 remain compatible with Android 4.1 devices), the implementation SHOULD still 312 accept SNEP GET requests for exchanging the handover request/select records 313 over NFC. However an implementation itself SHOULD NOT send SNEP GET requests 314 for performing connection handover. 315* [C-1-13] MUST poll for all supported technologies while in NFC discovery 316 mode. 317* SHOULD be in NFC discovery mode while the device is awake with the 318screen active and the lock-screen unlocked. 319* SHOULD be capable of reading the barcode and URL (if encoded) of 320 [Thinfilm NFC Barcode]( 321 http://developer.android.com/reference/android/nfc/tech/NfcBarcode.html) 322 products. 323 324(Note that publicly available links are not available for the JIS, ISO, and NFC 325Forum specifications cited above.) 326 327Android includes support for NFC Host Card Emulation (HCE) mode. 328 329If device implementations include an NFC controller chipset capable of HCE (for 330NfcA and/or NfcB) and support Application ID (AID) routing, they: 331 332* [C-2-1] MUST report the `android.hardware.nfc.hce` feature constant. 333* [C-2-2] MUST support [NFC HCE APIs]( 334http://developer.android.com/guide/topics/connectivity/nfc/hce.html) as 335defined in the Android SDK. 336 337If device implementations include an NFC controller chipset capable of HCE 338for NfcF, and implement the feature for third-party applications, they: 339 340* [C-3-1] MUST report the `android.hardware.nfc.hcef` feature constant. 341* [C-3-2] MUST implement the [NfcF Card Emulation APIs]( 342https://developer.android.com/reference/android/nfc/cardemulation/NfcFCardEmulation.html) 343as defined in the Android SDK. 344 345 346If device implementations include general NFC support as described in this 347section and support MIFARE technologies (MIFARE Classic, 348MIFARE Ultralight, NDEF on MIFARE Classic) in the reader/writer role, they: 349 350* [C-4-1] MUST implement the corresponding Android APIs as documented by 351the Android SDK. 352* [C-4-2] MUST report the feature `com.nxp.mifare` from the 353[`android.content.pm.PackageManager.hasSystemFeature`()]( 354http://developer.android.com/reference/android/content/pm/PackageManager.html) 355method. Note that this is not a standard Android feature and as such does not 356appear as a constant in the `android.content.pm.PackageManager` class. 357 358### 7.4.5\. Minimum Network Capability 359 360Device implementations: 361 362* [C-0-1] MUST include support for one or more forms of 363data networking. Specifically, device implementations MUST include support for 364at least one data standard capable of 200Kbit/sec or greater. Examples of 365 technologies that satisfy this requirement include EDGE, HSPA, EV-DO, 366 802.11g, Ethernet, Bluetooth PAN, etc. 367* SHOULD also include support for at least one common wireless data 368standard, such as 802.11 (Wi-Fi) when a physical networking standard (such as 369Ethernet) is the primary data connection 370* MAY implement more than one form of data connectivity. 371* [C-0-2] MUST include an IPv6 networking stack and support IPv6 372communication using the managed APIs, such as `java.net.Socket` and 373`java.net.URLConnection`, as well as the native APIs, such as `AF_INET6` 374sockets. 375* [C-0-3] MUST enable IPv6 by default. 376 * MUST ensure that IPv6 communication is as reliable as IPv4, for example. 377 * [C-0-4] MUST maintain IPv6 connectivity in doze mode. 378 * [C-0-5] Rate-limiting MUST NOT cause the device to lose IPv6 379 connectivity on any IPv6-compliant network that uses RA lifetimes of 380 at least 180 seconds. 381 382When connected to an IPv6-capable network: 383 384* [C-1-1] devices MUST provide applications with direct IPv6 connectivity to 385the network, without any form 386of address or port translation happening locally on the device. Both managed 387APIs such as 388[`Socket#getLocalAddress`](https://developer.android.com/reference/java/net/Socket.html#getLocalAddress%28%29) 389or 390[`Socket#getLocalPort`](https://developer.android.com/reference/java/net/Socket.html#getLocalPort%28%29)) 391and NDK APIs such as `getsockname()` or `IPV6_PKTINFO` MUST return the IP 392address and port that is actually used to send and receive packets on the 393network. 394 395 396The required level of IPv6 support depends on the network type, as follows: 397 398If devices implementations support Wi-Fi networks, they: 399 400* [C-2-1] MUST support dual-stack and IPv6-only operation on Wi-Fi. 401 402If device implementations support Ethernet networks, they: 403 404* [C-3-1] MUST support dual-stack operation on Ethernet. 405 406If device implementations support cellular data, they: 407 408* [C-4-1] SHOULD support IPv6 operation (IPv6-only and possibly dual-stack) on 409cellular data. 410 411When devices are simultaneously connected to more than one network, (e.g., Wi-Fi 412and cellular data), they: 413* [C-5-1] MUST simultaneously meet these requirements on each network to which 414they are connected. 415 416 417### 7.4.6\. Sync Settings 418 419Device implementations: 420 421* [C-0-1] MUST have the master auto-sync setting on by default so that 422the method [`getMasterSyncAutomatically()`]( 423 http://developer.android.com/reference/android/content/ContentResolver.html) 424 returns “true”. 425 426### 7.4.7\. Data Saver 427 428If device implementations include a metered connection, they are: 429 430* [SR] STRONGLY RECOMMENDED to provide the data saver mode. 431 432If device implementations provide the data saver mode, they: 433 434* [C-1-1] MUST support all the APIs in the `ConnectivityManager` 435class as described in the [SDK documentation]( 436https://developer.android.com/training/basics/network-ops/data-saver.html) 437* [C-1-2] MUST provide a user interface in the settings, that handles the 438 [`Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS`]( 439 https://developer.android.com/reference/android/provider/Settings.html#ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS) 440 intent, allowing users to add applications to or remove applications 441 from the whitelist. 442 443If device implementations do not provide the data saver mode, they: 444 445* [C-2-1] MUST return the value `RESTRICT_BACKGROUND_STATUS_DISABLED` for 446 [`ConnectivityManager.getRestrictBackgroundStatus()`]( 447 https://developer.android.com/reference/android/net/ConnectivityManager.html#getRestrictBackgroundStatus%28%29) 448* [C-2-2] MUST NOT broadcast 449`ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED`. 450* [C-2-3] MUST have an activity that handles the 451`Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS` 452 intent but MAY implement it as a no-op. 453