What cryptography should solve in an Android app
Open-source cryptography for Android development is not simply a matter of adding an encryption dependency. Your design should answer four separate questions:
- Confidentiality: Can an attacker who obtains a database, backup, or intercepted payload read it?
- Integrity: Can an attacker modify data without detection?
- Authentication: Can the app verify a server, user, device, or message origin?
- Key protection: Where are secrets generated, stored, rotated, revoked, and deleted?
Start with a threat model. A consumer app handling profile data has different requirements from a payments app, a health application, or an offline-first field tool used on shared devices in India. Identify assets, attackers, trust boundaries, offline behaviour, backups, rooted-device exposure, and what happens if a user loses access to a device.
Cryptography cannot repair insecure authentication, a compromised server, leaked logs, or an API that accepts unauthorised requests. Treat it as one layer in a broader security programme, alongside building high-performance AI applications with open-source tools when your Android product also processes sensitive model inputs or outputs.
Prefer safe constructions over algorithm shopping
For most application code, use authenticated encryption with associated data (AEAD) rather than combining encryption and hashing yourself. AES-GCM and ChaCha20-Poly1305 are common choices. AEAD protects confidentiality and detects tampering, provided that nonces are generated correctly and never reused with the same key.
Use established primitives for specific jobs:
- Password protection: Argon2id, scrypt, or an appropriately configured PBKDF2 implementation. Passwords should be salted and stored as verifiers, never encrypted for later recovery.
- Message authentication: HMAC when both parties share a secret and need integrity and authentication.
- Digital signatures: Ed25519 or ECDSA where a private key signs and a public key verifies.
- Key agreement: X25519 or a platform-supported elliptic-curve mechanism.
- Hashing: SHA-256 or SHA-512 for general integrity and identifiers; do not treat an ordinary hash as password storage.
Do not implement these primitives yourself, copy cryptographic code from a blog, or use obsolete constructions such as ECB mode, unauthenticated CBC, MD5, or SHA-1 for new security designs. Avoid choosing a library solely because it offers the largest algorithm catalogue.
Library choices for Android in 2026
Google Tink
Tink is often the strongest default for application-level cryptography. Its high-level APIs and keyset model reduce opportunities to misuse primitives, while support for common AEAD, MAC, signature, and hybrid-encryption patterns makes it suitable for many Android products. Review its Android support and release notes before adoption, and keep keysets out of source control.
Android platform APIs and Keystore
The Android SDK should be your first stop for platform-backed key generation and storage. Android Keystore can generate non-exportable keys and, where hardware support exists, protect operations using a secure hardware-backed environment. It does not automatically secure every secret: the key remains vulnerable to misuse by an app process that is already authorised to use it, and device capability varies by version and manufacturer.
Use Keystore for wrapping or directly using keys, with explicit purposes, block modes, paddings, and user-authentication requirements. Test behaviour across API levels, emulators, and representative Indian-market devices rather than assuming uniform hardware support.
Bouncy Castle and Spongy Castle
Bouncy Castle provides broad low-level algorithm and protocol coverage, but that flexibility increases the chance of incorrect configuration. Use it when you have a clear interoperability requirement, such as a protocol or encoding unavailable through Android APIs or Tink. Spongy Castle is largely a legacy reference for older Android projects; new applications should assess current provider compatibility and maintenance before selecting it.
SQLCipher
For encrypted SQLite databases, SQLCipher can be appropriate when the threat model includes offline database extraction. It protects the database at rest, not the keys, queries, network traffic, or data displayed in memory. Store or unwrap the database key through a sound Keystore-backed design, handle migrations carefully, and verify that exported backups and debugging builds do not expose plaintext copies.
Native libraries and bindings
Libraries based on libsodium or other native implementations can provide well-designed primitives, but JNI and native memory introduce build, packaging, and maintenance complexity. Pin versions, verify provenance, review Android ABI coverage, and ensure that sensitive buffers are not unnecessarily copied into immutable Kotlin or Java strings.
A practical implementation pattern
1. Define the data classification. Separate public, internal, sensitive, and regulated data. Decide whether encryption is needed in transit, at rest, or end to end.
2. Generate keys inside a trusted boundary. Prefer random keys from a platform-approved secure random source or a vetted library. Never derive an encryption key from a username, device ID, or hardcoded constant.
3. Use Keystore deliberately. Generate a wrapping key or operation key with narrow purposes. Require device authentication for especially sensitive actions where the user experience permits it.
4. Use a versioned envelope format. Store the algorithm identifier, key identifier, nonce, ciphertext, and format version alongside the ciphertext. Authenticate metadata as associated data so it cannot be changed silently.
5. Plan rotation and recovery. Support key versions, re-encryption, revocation, and account/device replacement. Decide what happens when a user uninstalls the app, clears storage, loses a phone, or restores a backup.
6. Minimise exposure. Do not log plaintext, keys, tokens, or full encrypted payloads. Clear sensitive temporary data where practical, and avoid placing secrets in URLs, analytics events, screenshots, or crash reports.
For teams learning through public code, reviewing open-source AI projects for student developers can be useful for repository hygiene, but security-sensitive Android code still needs focused review by someone experienced in mobile cryptography.
Network security is more than TLS
Use HTTPS with modern platform defaults and certificate validation. Do not disable hostname verification or trust all certificates to “fix” development problems. For high-risk applications, consider certificate or public-key pinning only with a carefully tested rotation and recovery strategy; a broken pin can cut off every installed client.
Authenticate the server, authenticate users with a suitable session design, and authorise every sensitive operation server-side. If you need end-to-end encryption, define identity verification, device enrolment, multi-device support, message ordering, metadata leakage, and key recovery before writing code. Encryption between the app and your own server is not automatically end to end.
Testing, review, and supply-chain controls
Cryptographic tests should cover both expected and hostile inputs:
- Test round trips, tampered ciphertext, altered nonces, wrong keys, truncated payloads, and unsupported versions.
- Use known-answer and interoperability tests when implementing a protocol shared with a backend or another client.
- Test backup, restore, migration, logout, reinstall, screen capture, offline mode, and device-lock scenarios.
- Run static analysis, dependency vulnerability scanning, secret scanning, and release-build checks.
- Review transitive dependencies, licences, release activity, security advisories, and repository provenance before shipping.
- Have an independent reviewer examine key lifecycle, error handling, randomness, authentication, and downgrade resistance.
For projects combining Android clients with AI services, apply the same discipline to prompts, uploaded documents, and model responses; the guidance on deploying open-source AI agents in production is relevant to service-side access controls and operational monitoring.
A concise decision guide
Choose Android Keystore plus platform APIs for straightforward local key protection. Choose Tink for high-level application encryption and keyset management. Choose SQLCipher when the SQLite database itself must be encrypted. Choose Bouncy Castle or a native library only when a documented compatibility or protocol requirement justifies the added surface area.
Before release, document the threat model, algorithms, key ownership, rotation plan, failure behaviour, and recovery limits. Open source improves inspectability and reuse, but it is not a security guarantee. A small, well-understood design with maintained dependencies is safer than a complex collection of powerful primitives.