Auri's Blog

I recently ran into an issue with Amazon’s “Login with Alexa” – aka LWA – SDK in our Android app. Before releasing to Google Play, I fully tested the app. Logging in with Alexa worked flawlessly, and I was able to register my Amazon Alexa device.

Everything was looking good in the app, so I uploaded it to Google Play and released it to Production. A few hours later, the app was approved, and available for download to Android apps around the world. w00t!

A week or so later, a partner was testing the app and said “Hey, Amazon login doesn’t work!” Considering I had tested this 7 ways to Sunday, I found that hard to believe. But still, I had to test it.

Sure enough, I downloaded the app from Google Play, went to login with Alexa, and received an error: “Cannot connect to Amazon Alexa.”

WHAT?!?! It worked with the exact same APK I had uploaded. What the heck changed? Certainly, Google doesn’t change the code upon uploading, do they? How could they? Conspiracy theories aside, my team started looking into it.

When we’d logcat the PROD version, we’d see these telling entries:

2021-07-08 10:01:58.966 17695-6047/? I/com.amazon.identity.auth.device.api.authorization.AuthorizationManager: com.our.appname calling authorize

2021-07-08 10:01:58.972 17695-6047/? W/com.amazon.identity.auth.device.appid.APIKeyDecoder: Failed to decode: Decoding failed: certificate fingerprint can't be verified! pkg=com.our.appname

2021-07-08 10:01:58.972 17695-6047/? W/com.amazon.identity.auth.device.appid.APIKeyDecoder: Unable to decode APIKey for pkg=com.our.appname

It turns out, our signing process was the culprit. Our production LWA API key was generated in the Amazon developer portal using our original keystore’s thumbprint and SHA-256 hash. However, we use Google’s managed key service, which maintains the app signing key in Google Play. This is important, just in case you ever lose your keystore. Old timer Android devs know this nightmare…

So how do we fix this? How do we use a different LWA API key when releasing to Google Play, yet still enable our beta testers to use our sideloaded Dev builds? We definitely don’t want to lose our CI/CD pipeline to a manual process!!

Android build variants to the rescue.

The LWA API key is generally stored under assets/api_key.txt. However, that one was only the debug key. We needed one for both our debug and release build configurations. Luckily, you can simply add build folders for this and Android’s build system will take care of the rest! You don’t need to work with Gradle source sets!

To fix this, under the src/ folder, we added two new folders:

• src/debug/java
• src/debug/assets
• src/release/java
• src/release/assets

These are in addition to the typical:

• src/main/java
• src/main/assets

As long as “replacement” entries exist in the build configuration-specific folders, the Android compiler will choose those assets over those under main/.

There’s more information about how to do this via the Android Studio UI here. Just keep in mind the UI approach is a slow process. Sometimes menu options you’re expecting don’t appear until gradle has finished doing its job.

Alright, to solve this problem, we need a new LWA API key based on our Google Play signing key. Thankfully, Google makes this easy to obtain.

We retrieved our Google Play thumbprint and hash from the Google Play Developer Console and going to <AppName> > Setup > App Integrity, and found our MD5 certificate fingerprint and SHA-256 certificate fingerprint:

Then we moseyed on over to the Login with Alexa Console, chose Kindle/Android Settings for our security profile, and added a second key:

Once we had the new API key – which you can retrieve by clicking Show – we added a new api_key.txt file under src/release/assets and inserted the new key there.

We then moved the non-Production API key from src/main/assets/api_key.txt to src/debug/assets. It no longer needed to be located under src/main/assets because we only want the configs for debug and release. If you have other build configs, you may need to create additional folders.

This enabled our CI/CD pipeline to continue to distribute DEV builds that work, and to also generate PROD builds we could successfully distribute via Google Play.

I hope this helps anyone else having the same issue!