AndroidX Security in 2026: Security-crypto status & setup

That gap causes real build warnings and, worse, silent key-scheme mismatches in production. This guide confirms what's current, what's deprecated but still functional, and gives you a MasterKey.Builder-based EncryptedSharedPreferences and EncryptedFile pattern that compiles clean today.

Is security-crypto deprecated? Current status

Yes, but not because it stalled in alpha. security-crypto shipped a stable 1.1.0 release on July 30, 2025, jumping from 1.1.0-alpha06 (April 2023) to 1.1.0-alpha07 in April 2025 and on through beta and rc within months.

Alpha07 is where Google deprecated every API in the artifact in favor of existing platform APIs and direct Android Keystore use, per the Android Developers Jetpack security release notes, and that deprecation notice carried straight through to the 1.1.0 stable release. The library is stable and deprecated at the same time.

In our work migrating Android codebases off MasterKeys to MasterKey.Builder, we've logged the APK size deltas and code-review issues that came with it. Teams building on security-crypto regularly hit the same wall: the class they relied on for key generation, MasterKeys, is gone from current builds, replaced by MasterKey.Builder with an explicit KeyScheme enum, itself now deprecated in favor of calling Android Keystore directly.

Google's actual direction is fragmentation, not a straight sunset. Instead of one monolithic artifact, AndroidKeystore-backed functionality is splitting into Security-State, Security-App-Authenticator, and Security-Identity-Credential, each versioned and released independently. EncryptedSharedPreferences and EncryptedFile still work today, and Google ships no official migration guide off them, but plan any new app around the split rather than around security-crypto.

The androidx.security artifact family beyond security-crypto

Jetpack ships three newer androidx.security artifacts that Google built as separate libraries instead of folding them into security-crypto, and most teams evaluating the family miss them because they aren't bundled in the same dependency.

For broader context on the tools and libraries these artifacts belong to, this essential Android libraries roundup covers the wider set of tools most teams rely on.

Security-State targets compliance and risk-scoring use cases: a banking app can query whether a device meets a minimum patch level before allowing a transaction.

Security-App-Authenticator matters for apps exposing content providers or bound services to other apps on the same device, closing a class of confused-deputy attacks OWASP MASVS flags under platform interaction.

Security-Identity-Credential is the one to watch if your app touches digital ID or wallet use cases, it's the API path Google is standardizing on instead of custom Tink-based schemes.

Beyond these specific libraries, teams should also weigh broader mobile app security practices when deciding how to handle compliance, authentication, and identity use cases.

Two of the three are already stable: security-app-authenticator shipped 1.0.0 in July 2025, and security-state shipped 1.1.0 in September 2026. Only security-identity-credential remains alpha, so it's the one to treat as a roadmap item rather than a production-ready replacement for security-crypto.

Gradle setup: Version catalog and Kotlin DSL

Add security-crypto through a Gradle version catalog (libs.versions.toml) instead of hardcoding the version string in build.gradle.kts. That keeps one version pinned across every module in a multi-module Android app, which matters once you're also pulling in security-crypto-ktx or security-app-authenticator for the same project.

# Libs.versions.toml
[versions]
androidxSecurityCrypto = "1.1.0"

[libraries]
androidx-security-crypto = { module = "androidx.security:security-crypto", version.ref = "androidxSecurityCrypto" }

// build.gradle.kts
dependencies {
 implementation(libs.androidx.security.crypto)
}

In our work with Android teams, security-crypto pulls in Tink's Java classes as a transitive dependency, and we've measured a small but non-zero APK size increase once R8 shrinking runs, not a blocker, but worth a size-report diff during code review before you ship.

Building a MasterKey with MasterKey.Builder

MasterKey.Builder replaces the deprecated MasterKeys helper class as the entry point for generating or retrieving the key that backs EncryptedSharedPreferences and EncryptedFile in the AndroidX Security library. Instead of the old static MasterKeys.getOrCreate(spec) call, you now build an explicit key with a declared KeyScheme.

val masterKey = MasterKey.Builder(context).setKeyScheme(MasterKey.KeyScheme.AES256_GCM).build()

KeyScheme.AES256_GCM is currently the only scheme exposed by the builder, backed by the AndroidKeystore, so there's no tradeoff decision to make at this call site, the choice was made for you when Google folded the old KeyGenParameterSpec boilerplate into a single enum value.

The practical migration work is elsewhere: MasterKeys returned a raw key alias string, while MasterKey.Builder returns a MasterKey object that EncryptedSharedPreferences.create and EncryptedFile.Builder both expect directly. In our work with Android teams, the build fails loudly at compile time once the deprecated class is removed, which is the safest kind of breakage.

Budget for updating every call site that touched the old alias-based API, not just the key generation line. If this migration work feels like a heavy lift, partnering with an experienced Android development team can help you handle the transition without disrupting your release schedule.

EncryptedSharedPreferences: What it's for and how to build it

EncryptedSharedPreferences wraps the standard SharedPreferences interface and encrypts both keys and values before they touch disk, so an app can keep using getString and putBoolean calls while the underlying content stays unreadable outside the app's sandbox. It is the right tool for auth tokens, feature flags, and small user preferences, not for large blobs, which belong in EncryptedFile instead.

Creating an instance requires a MasterKey.Builder output plus explicit key and value schemes:

val prefs = EncryptedSharedPreferences.create(
 context,
 "secure_prefs",
 masterKey,
 EncryptedSharedPreferences.PrefKeyEncryptionScheme.AES256_SIV,
 EncryptedSharedPreferences.PrefValueEncryptionScheme.AES256_GCM
)

Keys use AES256_SIV because preference keys need deterministic encryption to remain look-up-able; values use AES256_GCM for authenticated, non-deterministic encryption (Encrypting, Testing SharedPreferences - Learn Tink &). Swapping these two schemes is a mistake we still see in code review. It compiles, but it defeats the point of encrypting keys at all.

One caveat worth flagging early: EncryptedSharedPreferences has no migration path for existing plaintext SharedPreferences files. Teams moving legacy prefs over need to read the old file, write into the encrypted one, then delete the original, there is no built-in converter in the androidx.security API.

EncryptedFile: Encrypting files on disk

EncryptedFile encrypts individual files on disk using a streaming cipher, so an app can write or read large content, photos, PDFs, exported logs, without loading the whole payload into memory first. It pairs with EncryptedFile.Builder, backed by the same MasterKey.Builder and AndroidKeystore-derived key used for EncryptedSharedPreferences, but defaults to KeyScheme.AES256_GCM_HKDF_4KB instead of the single-shot AES256_GCM scheme.

That 4KB-segmented scheme is the real tradeoff: streaming encryption processes content in fixed-size chunks, so seek and random access cost more, but memory stays flat regardless of file size. Whole-file AES256_GCM, the scheme EncryptedSharedPreferences uses, is faster for small values but unsuitable for anything you can't fully buffer.

Teams migrating off the deprecated MasterKeys helper class run into this class distinction often, MasterKeys.getOrCreate returned a key alias string, while MasterKey.Builder returns a MasterKey object accepted directly by both EncryptedFile and EncryptedSharedPreferences APIs. In our migration work, that signature change was the most common code-review finding, not a crypto bug.

According to Jetpack security release notes, security-crypto spent several years in alpha before reaching a 1.1.0 stable release, which is worth checking before pinning a version in production Java or Kotlin code.

EncryptedSharedPreferences vs DataStore vs Android keystore

EncryptedSharedPreferences, DataStore, and raw AndroidKeystore access solve different layers of the same problem, and picking the wrong one is the most common code-review finding we see on Android security audits.

EncryptedSharedPreferences wraps key-value storage with Tink-backed AES256_GCM under the hood. DataStore (Proto or Preferences) has no built-in encryption and needs a manual Tink AeadConfig cipher wrapped around it. AndroidKeystore is the primitive underneath both, exposed directly when you need custom key material rather than a storage format.

In our work with Android teams, the mistake is treating EncryptedSharedPreferences as a general-purpose vault instead of a small-secrets store, it degrades once entries or file size grow. Teams migrating off MasterKeys should benchmark write latency on both APIs before committing to one.

Device attestation: Security-state and security-app-authenticator

Security-State and Security-App-Authenticator answer a question EncryptedSharedPreferences and MasterKey.Builder never touch: can you trust the device and the caller, not just the ciphertext.

Security-State exposes the device security patch level and lets an app check it against a vendor-published baseline before releasing sensitive content, instead of trusting whatever Build.VERSION reports.

Security-App-Authenticator does the caller side: it verifies the package signature and certificate chain of another app on the device before you hand it a token or shared file, which matters for SDK integrations and inter-app auth flows where a spoofed package name is a real attack path.

Both libraries are separate androidx artifacts from security-crypto, and both are now stable, security-app-authenticator since July 2025, security-state since September 2026, per the Android Developers Jetpack security release notes.

Security-State's earlier 1.0.x line did carry a breaking change (the Component enum was replaced with string constants for extensibility), so if you're upgrading from a pre-1.1 integration, re-check the changelog on that bump specifically rather than assuming a drop-in update.

Use them together on Android builds where regulatory posture (MASVS-RESILIENCE controls) requires proof of patch currency, not just encryption at rest.

Mobile driver's licenses with security-identity-credential

Security-Identity-Credential is the androidx security artifact almost no team touches until a state government contract lands on the roadmap. It builds the ISO/IEC 18013-5 mobile driver's license (mDL) standard, handling the device-retrieval and reader-authentication flow so an app never has to hand-roll the underlying crypto.

Instead of storing a credential as an encrypted blob in EncryptedSharedPreferences or an EncryptedFile, this class models it as structured identity data with its own access-control and usage-tracking API, backed by AndroidKeystore where hardware support exists.

Building this correctly under a tight compliance deadline is a strong reason to bring in an experienced Android development team rather than hand-rolling the mDL flow in-house.

We've seen teams reach for this library only after a compliance review flagged a homegrown mDL implementation as unauditable against MASVS. The API surface is small and still evolving between alpha versions, so pin a specific release and re-test reader interop before shipping an app update, particularly around the ResponseGenerator and CredentialDataRequest classes.

API reference: Classes, enums, and tink under the hood

The security-crypto artifact is a thin Java wrapper around Tink, Google's cryptography library, so almost every class you touch maps to a Tink primitive underneath. AndroidKeystore still holds the key material; androidx just standardizes the API surface app teams write against.

Use AES256_GCM by default; reach for AES256_SIV only when a file needs random-access reads instead of pure streaming.

FAQ: Androidx security-crypto questions