# Conscrypt for Android and OpenJDK TLS

> Conscrypt supplies a BoringSSL-backed Java security provider for TLS and selected cryptography APIs on Android and OpenJDK. Its current development model favors Google's internal work and platform delivery over outside pull requests.

**google/conscrypt** — Conscrypt is a Java Security Provider that implements parts of the Java Cryptography Extension and Java Secure Socket Extension.

- Repository: https://github.com/google/conscrypt
- Stars: 1,413 · Forks: 330
- Language: Java
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/google-conscrypt

## Conscrypt's role in Android and OpenJDK security

Conscrypt addresses applications that need TLS and cryptographic primitives through Java APIs such as SSLContext, Cipher, and MessageDigest. It is a Java Security Provider implementing parts of the Java Cryptography Extension and Java Secure Socket Extension. Its native foundation is BoringSSL, which supplies cryptographic primitives and TLS behavior for Java applications on Android and OpenJDK.

The intended audience differs by platform. Most Android developers should use the Conscrypt copy included in Android rather than manage a separate dependency. The platform version is normally selected through Java Cryptography Architecture provider ordering when application code requests an algorithm without naming a provider. The README says this platform version receives updates through Project Mainline, including current features and security patches, even on devices running older Android releases.

OpenJDK developers use Conscrypt as an explicit platform-dependent dependency. The supported baseline stated in the README is Java 8 or later. On Android, the stated baseline is Lollipop, API Level 21. The repository also points readers to CAPABILITIES.md for the algorithms and capabilities provided, making that file more useful for adoption decisions than the broad JCE and JSSE description alone.

## BoringSSL, JSSE, and Java provider selection

Conscrypt connects a native TLS and cryptography implementation to Java's standard provider interfaces. Application code requests an object through APIs such as SSLContext.getInstance("TLS"). Java then chooses among installed security providers according to provider priority and algorithm availability. This creates two distinct integration paths: implicit use of the Android platform provider and explicit selection of a Maven or Gradle dependency on OpenJDK.

For Android, omitting the provider name is significant. The README states that Android selects the highest-priority provider offering the requested algorithm, which is typically its built-in Conscrypt. This arrangement reduces application-level dependency management and allows security updates to arrive through the Android system update mechanism. It also means that inspecting an application that omits provider names requires understanding the device's provider configuration, not merely its declared dependencies.

On OpenJDK, Conscrypt remains available as the `conscrypt-openjdk` artifact. Its binaries are platform-dependent because each embeds a native library for a particular operating system and architecture. The documented classifiers cover Linux and macOS on x86_64 and aarch_64, plus Windows on x86_64. This native packaging boundary is the main architectural constraint on an explicit installation.

## OpenJDK 2.7.0 installation with Gradle

For an OpenJDK project, the README directs developers to Maven Central and uses `osdetector-gradle-plugin` to select the native classifier for the build host. The following configuration is the documented Gradle setup for Conscrypt 2.7.0. The plugin resolves `osdetector.classifier`, which must match the target platform.

```gradle
buildscript {
  repositories {
    mavenCentral()
  }
  dependencies {
    classpath 'com.google.gradle:osdetector-gradle-plugin:1.4.0'
  }
}

// Use the osdetector-gradle-plugin
apply plugin: "com.google.osdetector"

dependencies {
  compile 'org.conscrypt:conscrypt-openjdk:2.7.0:' + osdetector.classifier
}
```

After the configuration resolves successfully, the Conscrypt JAR selected for the host is available to the project. The README also provides a Maven configuration based on `os-maven-plugin` version `1.4.1.Final`, using the same `org.conscrypt:conscrypt-openjdk` coordinates and `${os.detected.classifier}`.

The repository contains a `gradlew` script, but the README does not document a complete build command or a first-use verification procedure. Accordingly, there is no confirmed Gradle invocation to add to this tutorial. A first practical check is to request a Java security algorithm and inspect the selected provider in the target environment. The README documents the provider-listing API, but it does not promise a particular provider selection result for every OpenJDK setup.

## A first TLS request on Android

Android applications normally need no special Conscrypt setup. The following README example requests a TLS `SSLContext` without naming a provider. On a typical Android device, this allows the platform's provider order to select the built-in Conscrypt implementation.

```java
import javax.net.ssl.SSLContext;
try {
    SSLContext sslContext = SSLContext.getInstance("TLS");
} catch (NoSuchAlgorithmException e) {
    e.printStackTrace();
}
```

The call creates a Java `SSLContext`; initialization and use remain separate steps. Initialization and application use remain the responsibility of the surrounding application; the README comment marks those steps but does not supply a complete TLS handshake example.

The README also shows how to list installed providers through `Security.getProviders()`. That can confirm whether Conscrypt is present, but provider presence does not by itself document which provider will win every algorithm request. For Android evaluation, the documented behavior is to omit the provider name and inspect the actual device. Explicit provider selection is not necessary for the recommended platform path.

## External contribution and platform upgrade boundaries

Conscrypt is not archived, and its last push was on 2026-10-15. That recency alone does not mean the public repository follows the earlier community contribution model. The README states that primary development has moved inside Google and external pull requests will no longer be accepted on GitHub. Internal changes are to be mirrored to the public repository, although mirroring may pause during the transition.

This changes the maintenance cost for adopters and contributors. Public users may still receive mirrored fixes and new releases, but they cannot influence the primary codebase through pull requests. Bug reports remain available through GitHub Issues, while Android-specific bugs should go to the Android Issue Tracker.

The release list provides recent versions `2.7.0`, `2.7-alpha`, and `2.6.3`. The README does not document a compatibility matrix between those versions, nor does it explain the API or behavior changes between them. It also does not provide a migration procedure or rollback instructions. An OpenJDK adopter must therefore treat version selection as a separate compatibility check rather than assume that the newest release can replace every deployed configuration.

The repository identifies Apache-2.0 as its license and includes `LICENSE`, `NOTICE`, and license-related build files. The README does not state how notices must be reproduced in downstream distributions, so it cannot support a more specific compliance conclusion.

## Conscrypt versus the default OpenJDK JSSE path

The practical alternative is to use the OpenJDK security provider selected by the JVM instead of adding `conscrypt-openjdk`. Conscrypt replaces that selection path with its own Java Security Provider implementation backed by BoringSSL. This is an architectural difference, not merely a version update: one path depends on the JVM's installed providers, while the other adds a platform-specific artifact containing a native library.

Conscrypt is the more specific choice when an application deliberately requires its BoringSSL-backed TLS and cryptography behavior. The default provider path avoids an explicit native dependency and its operating-system classifier selection. Android developers have an additional reason to prefer platform delivery because Project Mainline supplies updates to the built-in version.

The trade-off is platform control. Explicit OpenJDK installation gives the application a named Conscrypt dependency, but it also requires the correct classifier and compatible build configuration. Implicit provider selection has less dependency management, although it introduces dependence on the environment's provider ordering. The README says little about cipher-suite differences, handshake behavior, performance measurements, or migration risks between these paths. CAPABILITIES.md is the documented starting point for algorithm coverage, while the repository's implementation notes may be needed for lower-level behavior.

## Conclusion

Android applications should normally use Conscrypt through the platform provider, while OpenJDK applications may adopt version 2.7.0 when they need Conscrypt's BoringSSL-backed implementation. Do not adopt it merely to replace the default provider without checking platform compatibility, native classifier support, and capability requirements. First verify that the required TLS and cryptography algorithms appear in CAPABILITIES.md for the intended platform.

## FAQ

### How do Android applications use Conscrypt?

Most Android applications need no explicit setup. Request the algorithm without a provider name, and the platform normally selects its built-in Conscrypt through provider priority.

### How is Conscrypt installed on OpenJDK?

Add the `org.conscrypt:conscrypt-openjdk` artifact from Maven Central with a classifier matching the target operating system and architecture. The README documents both Maven and Gradle configurations.

### Can external developers still submit pull requests to Conscrypt?

No. The README states that external pull requests on GitHub will no longer be accepted because primary development has moved inside Google. Internal changes are intended to continue being mirrored.

## Sources

- [google/conscrypt on GitHub](https://github.com/google/conscrypt)
- [Issues](https://github.com/google/conscrypt/issues)
- [License: Apache-2.0](https://github.com/google/conscrypt/blob/master/LICENSE)
- [README](https://github.com/google/conscrypt/blob/master/README.md)
- [Releases](https://github.com/google/conscrypt/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/google-conscrypt