How to store Android tokens?

Question

Java

We need a way to properly store tokens in the application.
There is a client application that accepts a login password and sends it to the server.
The server checks the data and issues a token to the application.
However, the token must be stored somehow in order to initialize the user using it later.
The question is how to do it? Shared Preferences? Is it safe?
You just need to shove a ready-made token somewhere and then get it if necessary.
If possible, a small example, thanks.

Answer 1

According to Android, it is safe to store in Shared Preferences with private mode. This is not safe on rooted devices, because there you can access the Shared Preferences file (without root, the android does not let you into the application folder).
So if something is serious, it is better to encrypt. How to encrypt? I'd like to see a professional answer myself.
I did this for myself: I generate an AES session key, take the information, encrypt it with the session key, save the result to a private file. Next, I encrypt the session key with a permanent RSA key and save the result to a file. The RSA key itself is stored in the KeyStore. Why is a session key needed? Because RSA can only encrypt a small amount of information (245 bytes, like on a 2048-bit key).
It turns out that infa is encrypted with a session key, which in turn is encrypted with a key that is stored in the KeyStore. The KeyStore itself, as I understand it, is a hardware storage (at least in modern devices) and you can trust it. Access to the saved key is available only to your application instance, and even then not the key itself, but only the ability to operate on it. That is, it’s impossible to steal information just like that, without modifying your application.
But now I'm thinking if I didn't freeze the garbage, because the same AES session key could be stored in the KeyStore. Well, RSA seems superfluous - it's public key encryption. At first I thought to store part of the key on the device, part on the server with access by pincode and deletion after a couple of incorrect entries, but then I decided that this was unnecessary ...
In the end, even the developers of state applications stupidly shove confidential information into private files and don’t bother with encryption, and nothing, they pass the FSB certification.