What is the difference between symmetric and asymmetric encryption?

Symmetric encryption uses one key for both directions, the same key encrypts and decrypts. Asymmetric encryption uses a mathematically linked key pair, and the pair works two ways, the public key encrypts and the private key decrypts for confidentiality, the private key signs and the public key verifies for authenticity.

• Symmetric, algorithms like AES. Fast and cheap enough to run on large amounts of data, which is why it's what actually encrypts the bulk of your traffic or a file on disk. The catch is key distribution. Both sides need the same secret, and getting it to the other party without it leaking is the whole problem.
• Asymmetric, algorithms like RSA, and increasingly elliptic curve ones, ECDSA and Ed25519 for signing, ECDH for key agreement, which get the same strength from far smaller keys. You can hand the public key out to anyone, and the reason it's safe is that there's no practical way to work back from the public key to the private one. That solves the distribution problem, at the cost of being much slower, so you never point it at bulk data.

Signing is the direction people forget, and on Android it's the more common one of the two. You sign a payload with the private key, and anyone holding the public key can check that it came from you and hasn't been altered on the way. Same pair, opposite roles.

Because of the speed gap, real systems don't pick one, they combine both. In TLS 1.3, the version securing the HTTPS calls your app makes now, the two sides run an ephemeral Diffie Hellman exchange, so each derives the same shared secret without either one ever putting it on the wire. The certificate's key isn't used to encrypt that secret, it's used to sign the handshake, which is how the server proves it's who the certificate says. The older design, where the client encrypted a secret to the server's RSA public key, was removed from the protocol in 2018. Once the shared secret exists, everything after it is fast symmetric AES.

On Android, the Android Keystore is the practical entry point for all of this. It generates and holds symmetric keys, for encrypting local files or database fields, and asymmetric key pairs, for signing a request or attesting the device. The key material stays in a system process and never enters your app's memory, so a heap dump gets an attacker nothing. It's backed by the trusted execution environment on most devices, or by a separate tamper resistant chip if you ask for StrongBox, and you can bind a key to the user with setUserAuthenticationRequired so it won't work at all until they've unlocked with a biometric or the device credential.