“Telephony” as used by the Android APIs and this document refers specifically to hardware related to placing voice calls and sending SMS messages via a GSM or CDMA network. While these voice calls may or may not be packet-switched, they are for the purposes of Android considered independent of any data connectivity that may be implemented using the same network. In other words, the Android “telephony” functionality and APIs refer specifically to voice calls and SMS. For instance, device implementations that cannot place calls or send/receive SMS messages are not considered a telephony device, regardless of whether they use a cellular network for data connectivity.
If device implementations include GSM or CDMA telephony, they:
android.hardware.telephony
feature flag and other sub-feature flags according to the technology.If device implementations do not include telephony hardware, they:
If device implementations report the android.hardware.telephony feature
, they:
BlockedNumberContract
and the corresponding API as described in the SDK documentation.TelecomManager.createManageBlockedNumbersIntent()
method.If device implementations report android.hardware.telephony
, they:
KEYCODE_MEDIA_PLAY_PAUSE
and KEYCODE_HEADSETHOOK
events for the android.telecom
APIs as below:Connection.onDisconnect()
when a short press of the key event is detected during an ongoing call.Connection.onAnswer()
when a short press of the key event is detected during an incoming call.Connection.onReject()
when a long press of the key event is detected during an incoming call.CallAudioState
Device implementations:
If device implementations include support for 802.11 and expose the functionality to a third-party application, they:
android.hardware.wifi
.Device implementations:
If device implementations include support for Wi-Fi Direct, they:
android.hardware.wifi.direct
.Device implementations:
If device implementations include support for TDLS and TDLS is enabled by the WiFiManager API, they:
WifiManager.isTdlsSupported
] (https://developer.android.com/reference/android/net/wifi/WifiManager.html#isTdlsSupported%28%29).Device implementations:
If device implementations include support for Wi-Fi Aware and expose the functionality to third-party apps, then they:
WifiAwareManager
APIs as described in the SDK documentation.android.hardware.wifi.aware
feature flag.Device implementations:
If device implementations include support for Wi-Fi Passpoint, they:
WifiManager
APIs as described in the SDK documentation.Conversely if device implementations do not include support for Wi-Fi Passpoint:
WifiManager
APIs MUST throw an UnsupportedOperationException
.If device implementations support Bluetooth Audio profile, they:
If device implementations declare android.hardware.vr.high_performance
feature, they:
Android includes support for Bluetooth and Bluetooth Low Energy.
If device implementations include support for Bluetooth and Bluetooth Low Energy, they:
android.hardware.bluetooth
and android.hardware.bluetooth_le
respectively) and implement the platform APIs.If device implementations include support for Bluetooth Low Energy, they:
[C-3-1] MUST declare the hardware feature android.hardware.bluetooth_le
.
[C-3-2] MUST enable the GATT (generic attribute profile) based Bluetooth APIs as described in the SDK documentation and android.bluetooth.
[C-3-3] MUST report the correct value for BluetoothAdapter.isOffloadedFilteringSupported()
to indicate whether the filtering logic for the ScanFilter API classes is implemented.
[C-3-4] MUST report the correct value for BluetoothAdapter.isMultipleAdvertisementSupported()
to indicate whether Low Energy Advertising is supported.
SHOULD support offloading of the filtering logic to the bluetooth chipset when implementing the ScanFilter API.
SHOULD support offloading of the batched scanning to the bluetooth chipset.
SHOULD support multi advertisement with at least 4 slots.
[SR] STRONGLY RECOMMENDED to implement a Resolvable Private Address (RPA) timeout no longer than 15 minutes and rotate the address at timeout to protect user privacy.
Device implementations:
android.nfc.NdefMessage
and android.nfc.NdefRecord
APIs even if they do not include support for NFC or declare the android.hardware.nfc
feature as the classes represent a protocol-independent data representation format.If device implementations include NFC hardware and plan to make it available to third-party apps, they:
[C-1-1] MUST report the android.hardware.nfc
feature from the android.content.pm.PackageManager.hasSystemFeature()
method.
MUST be capable of reading and writing NDEF messages via the following NFC standards as below:
[C-1-2] MUST be capable of acting as an NFC Forum reader/writer (as defined by the NFC Forum technical specification NFCForum-TS-DigitalProtocol-1.0) via the following NFC standards:
[SR] STRONGLY RECOMMENDED to be capable of reading and writing NDEF messages as well as raw data via the following NFC standards. Note that while the NFC standards are stated as STRONGLY RECOMMENDED, the Compatibility Definition for a future version is planned to change these to MUST. These standards are optional in this version but will be required in future versions. Existing and new devices that run this version of Android are very strongly encouraged to meet these requirements now so they will be able to upgrade to the future platform releases.
[C-1-3] MUST be capable of transmitting and receiving data via the following peer-to-peer standards and protocols:
[C-1-4] MUST include support for Android Beam and SHOULD enable Android Beam by default.
[C-1-5] MUST be able to send and receive using Android Beam, when Android Beam is enabled or another proprietary NFC P2p mode is turned on.
[C-1-6] MUST implement the SNEP default server. Valid NDEF messages received by the default SNEP server MUST be dispatched to applications using the android.nfc.ACTION_NDEF_DISCOVERED
intent. Disabling Android Beam in settings MUST NOT disable dispatch of incoming NDEF message.
[C-1-7] MUST honor the android.settings.NFCSHARING_SETTINGS
intent to show NFC sharing settings.
[C-1-8] MUST implement the NPP server. Messages received by the NPP server MUST be processed the same way as the SNEP default server.
[C-1-9] MUST implement a SNEP client and attempt to send outbound P2P NDEF to the default SNEP server when Android Beam is enabled. If no default SNEP server is found then the client MUST attempt to send to an NPP server.
[C-1-10] MUST allow foreground activities to set the outbound P2P NDEF message using android.nfc.NfcAdapter.setNdefPushMessage
, and android.nfc.NfcAdapter.setNdefPushMessageCallback
, and android.nfc.NfcAdapter.enableForegroundNdefPush
.
SHOULD use a gesture or on-screen confirmation, such as 'Touch to Beam', before sending outbound P2P NDEF messages.
[C-1-11] MUST support NFC Connection handover to Bluetooth when the device supports Bluetooth Object Push Profile.
[C-1-12] MUST support connection handover to Bluetooth when using android.nfc.NfcAdapter.setBeamPushUris
, by implementing the “Connection Handover version 1.2” and “Bluetooth Secure Simple Pairing Using NFC version 1.0” specs from the NFC Forum. Such an implementation MUST implement the handover LLCP service with service name “urn:nfc:sn:handover” for exchanging the handover request/select records over NFC, and it MUST use the Bluetooth Object Push Profile for the actual Bluetooth data transfer. For legacy reasons (to remain compatible with Android 4.1 devices), the implementation SHOULD still accept SNEP GET requests for exchanging the handover request/select records over NFC. However an implementation itself SHOULD NOT send SNEP GET requests for performing connection handover.
[C-1-13] MUST poll for all supported technologies while in NFC discovery mode.
SHOULD be in NFC discovery mode while the device is awake with the screen active and the lock-screen unlocked.
SHOULD be capable of reading the barcode and URL (if encoded) of Thinfilm NFC Barcode products.
(Note that publicly available links are not available for the JIS, ISO, and NFC Forum specifications cited above.)
Android includes support for NFC Host Card Emulation (HCE) mode.
If device implementations include an NFC controller chipset capable of HCE (for NfcA and/or NfcB) and support Application ID (AID) routing, they:
android.hardware.nfc.hce
feature constant.If device implementations include an NFC controller chipset capable of HCE for NfcF, and implement the feature for third-party applications, they:
android.hardware.nfc.hcef
feature constant.If device implementations include general NFC support as described in this section and support MIFARE technologies (MIFARE Classic, MIFARE Ultralight, NDEF on MIFARE Classic) in the reader/writer role, they:
com.nxp.mifare
from the android.content.pm.PackageManager.hasSystemFeature
() method. Note that this is not a standard Android feature and as such does not appear as a constant in the android.content.pm.PackageManager
class.Device implementations:
java.net.Socket
and java.net.URLConnection
, as well as the native APIs, such as AF_INET6
sockets.The required level of IPv6 support depends on the network type, as follows:
If devices implementations support Wi-Fi networks, they:
If device impelementations support Ethernet networks, they:
If device implementations support cellular data, they:
Device implementations:
getMasterSyncAutomatically()
returns “true”.If device implementations include a metered connection, they are:
If device implementations provide the data saver mode, they:
ConnectivityManager
class as described in the SDK documentationSettings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
intent, allowing users to add applications to or remove applications from the whitelist.If device implementations do not provide the data saver mode, they:
RESTRICT_BACKGROUND_STATUS_DISABLED
for ConnectivityManager.getRestrictBackgroundStatus()
ConnectivityManager.ACTION_RESTRICT_BACKGROUND_CHANGED
.Settings.ACTION_IGNORE_BACKGROUND_DATA_RESTRICTIONS_SETTINGS
intent but MAY implement it as a no-op.