Diving in

Currently, some of the most seen ways to handle the storage of data are:

Keeping them in a Constant class:

public static final class Constants {

public static final String MY_TOKEN = "???";

}

Keeping them in a resource file strings.xml or alike:

<resources>

<string name="my_token">???</string>

</resources>

These most usual ways are terribly awful, just by simply using an APK analizer and doing a grep we can find them! Definetily not what we want.

Adding proguard and storing them in a class (since proguard doesnt encrypt resources)

This gets far better, but the developer needs to proguard his whole application delicately (which is not something done in an hour).

We can still reverse engineer it and debug the APK checking for known places of initialization or high entropy (one example is the Application class declared in the manifest)

Storing them inside a native library.

Better than proguard + constants! Still, with a simple command like strings libwithconstants.so and some hours filtering all the symbols we dont want, we will obtain it. Also, they can still debug! So by debugging the output of your JNI method that returns the value, they will obtain it :(

Using SharedPreferences / AccountManager / etceteras.

This is useless, since you need to previously declare the constant somewhere to store it. Just by looking at how you obtain it, we grep the classes for the places where you store that key and we found it.

Keeping encrypted values and decrypting them before using them

This will make it harder since the attacker needs to know how you decrypt it.. But remember that its there in the code! He will need some more hours to find it but its still easily done.