“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.telephonyfeature flag and other sub-feature flags according to the technology.
If device implementations do not include telephony hardware, they:
If device implementations support eUICCs or eSIMs/embedded SIMs and include a proprietary mechanism to make eSIM functionality available for third-party developers, they:
If device implementations report the
android.hardware.telephony feature, they:
BlockedNumberContractand the corresponding API as described in the SDK documentation.
If device implementations report
[C-1-1] MUST support the
ConnectionService APIs described in the SDK.
[C-1-2] MUST display a new incoming call and provide user affordance to accept or reject the incoming call when the user is on an ongoing call that is made by a third-party app that does not support the hold feature specified via
[C-1-3] MUST have an application that implements InCallService.
[C-SR] Are STRONGLY RECOMMENDED to notify the user that answering an incoming call will drop an ongoing call.
The AOSP implementation meets these requirements by a heads-up notification which indicates to the user that answering an incoming call will cause the other call to be dropped.
[C-SR] Are STRONGLY RECOMMENDED to preload the default dialer app that shows a call log entry and the name of a third-party app in its call log when the third-party app sets the
EXTRA_LOG_SELF_MANAGED_CALLS extras key on its
[C-SR] Are STRONGLY RECOMMENDED to handle the audio headset's
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.
If device implementations include support for 802.11 and expose the functionality to a third-party application, they:
WifiManager.enableNetwork()API method call as a sufficient indication to switch the currently active
Networkthat is used by default for application traffic and is returned by
ConnectivityManagerAPI methods such as
registerDefaultNetworkCallback. In other words, they MAY only disable the Internet access provided by any other network provider (e.g. mobile data) if they successfully validate that the Wi-Fi network is providing Internet access.
ConnectivityManager.reportNetworkConnectivity()API method is called, re-evaluate the Internet access on the
Networkand, once the evaluation determines that the current
Networkno longer provides Internet access, switch to any other available network (e.g. mobile data) that provides Internet access.
If device implementations include support for Wi-Fi power save mode as defined in IEEE 802.11 standard, they:
WifiManager.WifiLock.acquire()APIs and the lock is active.
WIFI_MODE_FULL_LOW_LATENCY) mode MUST be smaller than the latency during a Wi-Fi High Perf Lock (
WIFI_MODE_FULL_LOW_LATENCY) is acquired and takes effect.
If device implementations support Wi-Fi and use Wi-Fi for location scanning, they:
If device implementations include support for Wi-Fi Direct, they:
If device implementations include support for TDLS and TDLS is enabled by the WiFiManager API, they:
If device implementations include support for Wi-Fi Aware and expose the functionality to third-party apps, then they:
WifiAwareManagerAPIs as described in the SDK documentation.
If device implementations include support for Wi-Fi Aware and Wi-Fi Location as described in Section 22.214.171.124 and exposes these functionalities to third-party apps, then they:
If device implementations include support for Wi-Fi Passpoint, they:
WifiManagerAPIs as described in the SDK documentation.
Conversely if device implementations do not include support for Wi-Fi Passpoint:
WifiManagerAPIs MUST throw an
If device implementations include support for Wi-Fi Location and expose the functionality to third-party apps, then they:
WifiRttManagerAPIs as described in the SDK documentation.
If device implementations include support for Wi-Fi keepalive offload and expose the functionality to third-party apps, they:
[C-1-1] MUST support the SocketKeepAlive API.
[C-1-2] MUST support at least three concurrent keepalive slots over Wi-Fi and at least one keepalive slot over cellular.
If device implementations do not include support for Wi-Fi keepalive offload, they:
If device implementations include support for Wi-Fi Easy Connect and expose the functionality to third-party apps, they:
If device implementations support Bluetooth Audio profile, they:
If device implementations support HFP, A2DP and AVRCP, 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_lerespectively) and implement the platform APIs.
If device implementations include support for Bluetooth Low Energy, they:
BluetoothAdapter.isOffloadedFilteringSupported()to indicate whether the filtering logic for the ScanFilter API classes is implemented.
BluetoothAdapter.isMultipleAdvertisementSupported()to indicate whether Low Energy Advertising is supported.
If device implementations support Bluetooth LE and use Bluetooth LE for location scanning, they:
If device implementations include support for Bluetooth LE and Hearing Aids Profile, as described in Hearing Aid Audio Support Using Bluetooth LE, they:
truefor BluetoothAdapter.getProfileProxy(context, listener, BluetoothProfile.HEARING_AID).
android.nfc.NdefRecordAPIs even if they do not include support for NFC or declare the
android.hardware.nfcfeature 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
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-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:
If device implementations include an NFC controller chipset capable of HCE for NfcF, and implement the feature for third-party applications, they:
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:
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
java.net.URLConnection, as well as the native APIs, such as
Socket#getLocalPort) and NDK APIs such as
IPV6_PKTINFOMUST return the IP address and port that is actually used to send and receive packets on the network and is visible as the source ip and port to internet (web) servers.
The required level of IPv6 support depends on the network type, as shown in the following requirements.
If device implementations support Wi-Fi, they:
If device implementations support Ethernet, they:
If device implementations support Cellular data, they:
If device implementations support more than one network type (e.g., Wi-Fi and cellular data), they:
A captive portal refers to a network that requires sign-in in order to obtain internet access.
If device implementations provide a complete implementation of the
android.webkit.Webview API, they:
ACTION_CAPTIVE_PORTAL_SIGN_INand display the captive portal login page, by sending that intent, on call to the System API
android.net.LinkProperties.isPrivateDnsActivefor all network traffic that is not explicitly communicating with the captive portal.
ConnectivityManager.registerDefaultNetworkCallback, and used by default by Java networking APIs such as java.net.Socket, and native APIs such as connect()) is any other available network that provides internet access, if available.
If device implementations include a metered connection, they are:
If device implementations provide the data saver mode, they:
ConnectivityManagerclass as described in the SDK documentation
If device implementations do not provide the data saver mode, they:
If device implementations support Open Mobile API-capable secure elements and make them available to third-party apps, they:
[C-1-1] MUST enumerate the available secure elements readers via
[C-1-2] MUST declare the correct feature flags via
android.hardware.se.omapi.uicc for the device with UICC-based secure elements,
android.hardware.se.omapi.ese for the device with eSE-based secure elements and
android.hardware.se.omapi.sd for the device with SD-based secure elements.