Can this be achieved with Keystore?
I don't think that fits your use case. Keystore is designed to store cryptographic keys that will be used for encryption, decryption and signing. The idea is that these keys will be out of reach of the application using them, so basically, if you need something signed or encrypted, you call a system function that has access to the keya, but you can't get the keys themselves. This protects them from compromised applications. This doesn't work for you, since you need access to the access token itself.
If you used Keystore to encrypt and decrypt the access token, this would protect the access token from other processes (or from being extracted by forensic software from the filesystem - but see about access token expiry further down...). So that would definitely enhance security. But if your app was compromised, an attacker would still get access to the decrypted access token.
Is there a more secure way than using localstorage?
I'd say that if you want to protect against someone with root access and/or a compromised application, then no. You can't protect a secret from root, no matter where you store it on the device, except maybe in trusted computing platform hardware (this isn't exactly true - linux systems support security capabilities which root has by default, but may be denied by the kernel if so configured - but I think that's not very relevant for this discussion)
The problem with protecting from root is that root has access to everything your app can access, so even if you encrypt your access token, root would have access to the encryption key and could decrypt it. The same holds when your application is compromised.
One way to add a bit of security might be to have a service which is housed outside the device do an additonal layer of encryption and decryption of the access token based on a revokable key, so if the device was lost, you could revoke the associated key and then the encrypted access token on the device would be useless. But for this solution, you'd need to have two layers of encryption, one on the device (otherwise, you'd open up a new vulnerability by sending plaintext access tokens over the network to another service) and one on the service.
However, this strikes me as a ludicrous amount of work to protect an access token (it might make a bit more sense for a long-lived renewal token). Access tokens are generally short-lived and if you deleted an access token as soon as you no longer needed it, that would also increase security.
Storing the access token somewhere other than localstorage might, however, be more secure than localstorage because localstorage is accessible using javascript, so if your webview was infected with malicious javascript, it could steal the access token. But since your own code in the webview probably needs access to it, you're out of luck.
BTW: I'm assuming you're talking about a oauth access token. oath was originally designed to solve authorization for server-side applications which are used by user agents (browsers). oauth 2 then extended this to include authorization and authentication flows for other scenarios, such as for javascript apps running in the browser or apps sitting on devices controlled by the users themselves, but there are a few people (the original editor of the oauth 2 spec among them) who complain that oauth 2 support for these alternative scenarios isn't very good/secure.
