SHA-1 key problem in apk release and debug

Asked

Viewed 4,841 times

4

I finally got a version alpha from my Android app and decided to send it to the Play Store for the first time. As I’ve never done this before( I’m new in the world of Android development), I read some tutorials and was able to generate an app signed in my Android Studio and get it ready for the Play Store. As it is an alpha version, I created a group of alpha test on my Play Store console and added half a dozen friends. Everything works perfectly well. Testers can download the app, install and use.

The problem starts when I need to add new features to the app. Obviously the flow for this is to program new features in android studio and as soon as they are ready to generate again the .apk signed and do the upload to the Play Store, so he can distribute it to my alpha testers. Again, I’m following this flow and it’s all working.

But my app uses some Google Cards, like Sign In, Google Play Games, and Google Maps. And some of these require the Oauth 2.0 client credential created in the Google Developer Console (which has already been created by min and is working properly) to work. As many of you may know, this particular credential requires the signed apk SHA-1 key to function properly. Here comes the problem. Every time I’m programming new features for the .apk, I have to go to the Oauth 2.0 client credential (on google dev console) and change the SHA-1 key to the .apk of debug. Which obviously causes my alpha testers who are using the release .apk no longer have access to the Google Cards implemented in app. For example, the user can no longer log into the app via Google Sign In. And again, when I just uploaded the update to the Play Store, I return the SHA-1 key to the release .apk and everything goes back to working for my alpha testers.

I know there must be a way around this problem, but being new to Android I’m not sure how to do. I would like some light from the most experienced galley. Thanks =)

  • Thiago, if I’m not mistaken, you can register more than one sha1 key on project console no? I don’t even know if it is necessary to configure something extra in the app, I need to check. I think only registering your sha1 debug key and your release key on the console should solve the problem.

  • I’m not sure, but I might. So, assuming you can, I think your line of reasoning would be to create a new Oauth 2.0 client credential and configure it with the SHA-1 key generated by Android Studio for the apk debug. I’m sure?

  • 1

    So, if you only register the key API, you don’t need to make any changes to the app. Just generate the two SHA-1 based on the two build types and register there. Regarding the Oauth 2.0 Client Ids, it is the same situation. I believe you need to register the 3 artifacts created in your google-services.json (the Key API and the 2 Client IDS).

  • I think I did. Just one thing, when you say generate the two SHA-1 based on the two build types, that means build>generate Signed APK and change the build type to debug, right?

  • Wakin, thank you very much. I followed your line of reasoning and it worked.

1 answer

4

When I go to work with some signed Api I usually generate the .apk signed debug, so I will only have one SHA-1.

For that, put your .keystore at the root in your Project (at the same level as the app folder).

In his build.gradle (module) add the following:

android {
    signingConfigs {
        deployer{
            keyAlias KEY_ALIAS
            keyPassword KEY_PASSWORD
            storeFile file(STORE_FILE)
            storePassword STORE_PASSWORD
        }

    }
    buildTypes {
        release {
            …
            signingConfig signingConfigs.deployer
        }
        debug {
            signingConfig signingConfigs.deployer
        }
   }
 …
}

In the file Gradle.properties add:

    STORE_FILE=../nomeDoArquivo.keystore
    STORE_PASSWORD=senhaDoStore
    KEY_ALIAS=seuAlias
    KEY_PASSWORD=suaSenhadoAlias

With this, your .apk for debug will always be signed!

To learn more follows the documentation!

  • Hmm, I like your approach. I’ll try it this way =)

  • Thiago, I was left with some doubts. o . Keystore that you talk to copy the project root is the debug.Keystore that is in the . android folder? storeFile is the path of the debug.Keystore or the path of my generated . jks when I sign my apk? Valew

  • 1

    Dude, now intendi. The constants in the.properties grid are referenced in the build.grade.

  • is the debug path.Keystore! and STORE_FILE is the way for it! So if you put in the root in the project the way is: ../filename.Keystore.

  • Exactly! You can leave it on Radle even!!! But by putting it on . properties it doesn’t stand so in the face!

Browser other questions tagged

You are not signed in. Login or sign up in order to post.