The Conscrypt module accelerates security improvements and improves device security without relying on OTA updates. It uses Java code and a native library to provide the Android TLS implementation as well as a large portion of Android cryptographic functionality such as key generators, ciphers, and message digests. Conscrypt is available as an open source library, though it has some specializations when included in the Android platform.

The Conscrypt module uses BoringSSL, a native library that is a Google fork of OpenSSL and which is used in many Google products for cryptography and TLS (most notably Google Chrome), in conjunction with Conscrypt code (both Java and native code). BoringSSL doesn't have official releases (all users build from head) and makes no guarantees around API or ABI stability.

Changes in Android 14

Android 14 introduces an updatable root trust store within Conscrypt. CA certificates (or certs) provide the roots of trust for public keys used within Android and the internet at large. These certificates are routinely checked to ensure proper cryptographic signing, so they must be provided and stored on all devices that rely on them.

Prior to Mainline, Android stored certificates in the system partition (in system/ca-certificates) and updated them with every Android release. Now with Mainline, it's possible to update certificates more frequently using Mainline train updates. This new capability should streamline updating processes, allow us to have faster turnaround times for issues, and help to extend device lifetimes.

Starting in Android 14, root trust certificates are stored in the Conscrypt module APEX and the system partition. Apps can still choose their own certificates and modify certificate behavior using NetworkSecurityConfig.

Android 14 includes these other Conscrypt module changes:

  • Added AES-CMAC MAC implementation.
  • Deprecated and removed `PBEwithHmacSHA2-*` MAC implementations.
  • Added limited support for X25519 keys, key agreements, and signatures.
  • Updated BoringSSL for X.509 correctness.
  • Dropped support for MD5-signed certificates in the public CertPath APIs. Such certificates haven't been accepted for TLS connections since API level 16.

Changes in Android 10

Android 9 doesn't include an Android-specific public API for Conscrypt but instead uses a security provider that implements standard classes for Java Cryptography Architecture (JCA) including Cipher and MessageDigest, and Java Secure Socket Extension (JSSE), including SSLSocket and SSLEngine. Users interact with those classes and some nonpublic Conscrypt APIs are used by libcore or frameworks code.

Android 10 adds a small number of public API methods in to access Conscrypt functionality that isn't exposed by the classes under Android 10 also includes a slimmed copy of Bouncy Castle to provide lower-popularity cryptographic tools as part of Android Runtime (not included in the Conscrypt module).

Format and dependencies

The Conscrypt module ( is distributed as an APEX file that includes the Conscrypt Java code and a Conscrypt native library that dynamically links to Android NDK libraries (such as liblog). The native library also includes a copy of BoringSSL that has has been validated (Certificate #3753) through NIST's Cryptographic Module Validation Program (CMVP).

The Conscrypt module exposes the following APIs:

  • Public APIs are extensions of classes and interfaces in packages under java.* and javax.*, plus classes under*. External app code doesn't call Conscrypt directly. Platform API standards ensure that these APIs remain backward- and forward-compatible.
  • Core platform APIs are hidden APIs used by the framework to access nonpublic functionality. These are relatively limited; the largest user is NetworkSecurityConfig, which extends the Conscrypt trust manager (the component that verifies certificates) to implement the network security configuration feature.
  • Intra-core APIs are limited to zero-argument constructors called reflectively by the JCA and JSEE machinery.