[Android] Fix for wrong Development Key Hash creation command

[ErykDarnowski]

Problem

When I tried to use this package in my Android app, I've encountered an issue while configuring it to work with my Facebook app. To be more specific, the Key Hash generation command in the Running Sample Apps part of Facebook's Getting Started Guide linked under Installation -> 3. Configure projects -> 3.1 Android in the project's README.

I've encountered this error after using the command from Facebook's guide:

SERVER_ERROR: [code] 1349195 [message]: The key hash does not match any stored key hashes. Go to https://developers.facebook.com/docs/facebook-login/android for more information. [extra]

Solution

Well, this is caused by the fact that the RN app, doesn't get it's debug.keystore from ~/.android/debug.keystore (where Facebook's command puts it). Facebook's command is simply not correct for a RN project (both Expo and React Native CLI). This is of course the case because Facebook's guide was written with native Android development in mind.

Nonetheless I've figured out that using the debug.keystore inside ./android/app (from the root of a RN app), resolves the problem. Therefore I've though up this process:

1. Get in to the root dir of your app:

cd my-app

2. If you're using Expo, you'll of course need to run npx expo prebuild first.
3. Generate the Development Key Hash with the fixed command (Linux / MacOS):

keytool -exportcert -alias androiddebugkey -keystore android/app/debug.keystore | openssl sha1 -binary | openssl base64

4. Enter android or the password you've changed it to (if it doesn't ask you for a password, you either don't have all the needed utilities installed / the path is wrong / there's something wrong with the command).
5. Copy & paste the Development Key Hash in to your Facebook app.
6. Update algorithm as SHA1 is a security risk (Linux / MacOS):

keytool -importkeystore -srckeystore android/app/debug.keystore -destkeystore android/app/debug.keystore -deststoretype pkcs12

From my testing it looks like the app (both Expo and React Native CLI) doesn't even need to be reloaded, let alone rebuilt after running the Key Hash generation command.

P.S.

I think this (with some polish - like adding equivalent Windows commands and so on) would be a worthy addition to the project's README!

[mikehardy]

Keystore location is variable. My keystores are not where you say they are, for instance. I'm not against including something like this in the manual but I think it would be best to:

a) avoid specific commands, they go stale quickly, and just invite more support burden b) reference how to locate the keystore ("find the 'storeFile' line in your app's build.gradle to determine it's location")

So something less specific and more referential, ideally to the android developer documentation for the storeFile build.gradle element, and to their documentation to get the hash

[ErykDarnowski]

Those are great points and I completely agree with you.

I blindly created my solution based on the default location of the keystore file in RN projects but my main point was simply the fact that a different debug.keystore file (than the one in Facebook's guide) needs to be used.

I'm still a new to RN and mobile dev in general so to be honest I didn't know you can get the storeFile from build.gradle thank you for sharing that! 😄

---

These are a couple resources related to storeFile I found that might be usefull:

• https://developer.android.com/studio/build/gradle-tips#sign-your-app
• https://developer.android.com/reference/tools/gradle-api/4.2/com/android/build/api/dsl/SigningConfig#storeFile:java.io.File

I also think it'd be good to mention the 2 build.gradle files (the one in /android and /android/app) as newer devs may get confused.

• https://stackoverflow.com/a/23241888/11749019

[mikehardy]

It is possible that "android" and "android/app" aren't the actual paths either, those are variable, even if they are the default and are the most commonly used (https://github.com/react-native-community/cli/blob/main/docs/platforms.md#projectconfig - you can change it if you want)

The same point as the original one, in other words - documentation changes should always keep in mind

• what the maintenance-cost-over-time is (and thus prefer referring to upstream documentation where possible, with search terms plus the link, to guard against link rot - as opposed to specific concrete examples of the usage of other tools, since those are brittle)

• whether anything documented is actually variable (location of store file, location of gradle files that even define the store files) vs default assumptions. It's okay to include the default assumptions to make the docs more useful but they should be clearly labeled as defaults with links to documentation on how they are variable / how to determine concrete value

Documentation is frequently harder than code

[ErykDarnowski]

That's very true!

I agree, it'd be good to include these paths as the default locations with a strong ephasis that they're default and can vary + links to some android docs.

In other cases a dev can resort to: ag 'storeFile' 😅!

[ErykDarnowski]

So, what do you think about something along the lines of this:

"Keep in mind you have to point this command at your app's debug.keystore file instead. You can find it's location by checking storeFile in one of the build.gradle files (it's default path is android/app/build.gradle however this can vary from project to project)."

[mikehardy]

That seems to allow for all the flexibility the build system allows, while still most likely resulting in a developer finding it immediately. Looks good to me

[ErykDarnowski]

Fantastic!

In that case I'll create a PR soon, so we can polish the changes.

[github-actions[bot]]

:tada: This issue has been resolved in version 11.0.1 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: