Hello, what's the best option to store and secure your API keys ?

I was looking into AccountManager these days for exactly the same use case. I’m curios what you came up with too. https://developer.android.com/reference/android/accounts/AccountManager

You could use EncryptedSharedPref -> https://developer.android.com/reference/androidx/security/crypto/EncryptedSharedPreferences

Plus one to encrypted shares preferences, very quick to setup and secure enough for most people

EncryptedFile is probably a better choice. SharedPreferences itself is broken by design and we may or may not let EncryptedSharedPreferences ever leave alpha because it implies that people should continue using it :)

Wouldn’t encrypted shares preferences only work if you’re retrieving keys at runtime?

They were just talking about Encrypted Shared Prefs at Dev summit. Talking with security folks during sandbox hours they also had no objection to using it

security-wise yes, it's secure. It just might fail to save your data and you will never know about it, or ANR your app between activities 🙂

Oh I gotcha, that makes more sense. 😬

also note that androidx.security has minimum SDK 23

Eh 21 is overrated anyway 😉 but that’s a good point. Our lowest version is thankfully 23

Java bytecode is weakest point of secure API keys

@Adam Powell Why are

SharedPreferences

doing an

fsync

in

onStop

and blocking the main thread?? And how come this is not documented? And finally, why isn't there recommendation from the javadoc to use something else if it's broken by design (for error handling mainly)?

For the fsync, the original intent was to ensure the write completed before potential process death. For the rest, longer story. 🙂 Historically things in Android have lasted for quite a while until a complete replacement can be presented.

Why the

fsync

thing hasn't been removed in recent Android versions? A lot of Android apps are still using

SharedPreferences

and this is not changing anytime soon given the friction plus the fact that the doc doesn't even mention it. End users would still benefit if a change is added into Android 11 to not do it on the main UI thread.

kind of an ongoing debate over how much value the documented "guarantee" it provides is actually adding, plus the associated work involved in changing the contract between ActivityManagerService and apps to make activity stop partially async to finish pending work like that. Since most people who care about this stopped using SharedPreferences a long time ago and enforce their own guarantees it hasn't gotten a lot of traction.

BTW,

SharedPreferences

is an interface that can be implemented by anything that would not bring this performance issue to the users (let's be honest, the users pay the cost, the devs don't bother much…)

it's not a very good interface. 🙂

That's right, but implementing it with a better thing than what's currently available allows to easily migrate old code.

sure, in an academic sense, but it's also just a map. Migrating old code even to something significantly different isn't a large task.

I completely agree with you that it's better to use something else with another API, but I've yet to see an alternative that is a good example for the same use cases like storing simple user preferences, and there's ton of code using it, that is making many/all phones slower with that

fsync

happening at the wrong time.

that's up to you then ¯\_(ツ)_/¯

How would you design a SharedPreferences replacement that is reliable and never does I/O on the main thread? Because for now, I understood you'd not use

SharedPreferences

, but what you would do exactly instead is not clear to me.

if you can assume kotlin it's a lot easier, imo 🙂 for my own usage I generally lean on data classes, moshi's codegen plugin, and serializing to/from files, then a conflated

Flow<T>

to reflect changes to other interested parties only after they're written.

Using

writeText()

or

writeBytes()

is not a good idea for this?

probably fine, the question is what do you do to prevent half-written files and other similar edge cases

So if I think about that (all linked to process death), I can make my own AtomicFile analogue with the Kotlin API I want safely?

Not even just linked to process death; unexpected shutdowns, errors in your app code during the write itself, plenty of reasons. 🙂 But yes, you can do a write to temp file and rename or any other atomic file techniques too

Are you aware of the following? https://android-review.googlesource.com/c/platform/frameworks/support/+/1169184

Yes

It’d be worth calling this out more deliberately I’m documentation, folks on Reddit are very confused about what is writing with it. https://kotlinlang.slack.com/archives/C0B8M7BUY/p1574250911017900