I am looking for the best practice for dealing with this problem.
If the API you are trying to use offers transient tokens (e.g., AWS's Token Vending Machine), use it, so that you do not bake long-lived keys into the app in the first place. Or, as hexafraction suggest, cook up your own scheme for this, where the API keys are on your server, and your app uses your server to perform operations on the app's behalf.
If the API you are using has a way to tie your use of the API to the signing key of your app (e.g., Play Services), your API key cannot be used without your signing key, and so the fact that it can be found is a non-issue.
You're welcome to spring for DexGuard, which will encrypt data in your app. This does not stop a determined hacker, but it does at least slow one down. Casual hackers may well just bypass your app and go with weaker prey.
And if none of those are an option, don't worry about it. For example, if you are solo developer, and stolen API keys are in your top 100 concerns, you are worrying far too much. Just plan to rotate the keys periodically (e.g., every app update), eventually retiring older keys when they are no longer being used, to minimize the risk of damage if some attacker does get your keys. You have bigger fish to fry, like how you are going to market the app.
In particular, rolling your own crypto, instead of just buying DexGuard, is a waste of time. If you cannot afford the DexGuard license fee, you can't afford to be fussing around rolling your own crypto either. And the odds are modest that your own crypto will be worth the time it took to write it, in terms of defending your keys.