Google Play App Signing

hi,

google have this new option to upload apks. 

https://support.google.com/googleplay/android-developer/answer/7384423

is there a tutorial out there so i can use it with corona?

what do i need to change in my builds, what should i upload? etc.

by mistake i activated this feature, now i can’t go back.

regards,

Carlos.

It looks to me like they want you to upload your current release keystore to them and they will sign your app with it. Then you create a new keystore called the upload keystore and actually sign your app with it before uploading. There isn’t anything magic about how Corona signs apps that’s any different than any other native built app.

After reading the documentation, I’m not 100% sure about what all is needed to take your current release keystore and get it uploaded. They talk about needing a certificate and public key, which means you probably need to use the keytool program and export the various parts they need. I’m sure there are some tutorials out there since this is a generic Android process.

Rob

usually i use same key to all my apps.

i tried to upload a new app with this program. it said that the key is already used i can’t used anymore.

if i need to create a new key for each build is 10x worst than what i’m using right now.

i posted here about corona and this new method because in the documents says we need to make some changes on the apk:

Modifications to your APK Apps that are signed by Google will have a 'derived APK ID' written into their AndroidManifest.xml file. You'll see a meta-data element added under the application tag that references \<meta-data android:name="com.android.vending.derived.apk.id" android:value="[ID]" /\>.

so i don’t know if we need to make changes on build.settings or in config.lua, or is just what you said.

usually i use same key to all my apps.

Huh?  How did that work for you before?  You should be signing each unique app with a unique keystore made for that app only.

Even if this worked for you before it is wrong.  So, like it or not you need to start doing this the right way.

(This is not the same as a new keystore for every version of the app.  Each app should have a single unique keystore that is used for the original submission and all  updates.  i.e. You should have a 1-to-1 ratio of apps and keystores.)

( UPDATE: I am partly wrong about the 1-to-1 ratio business.  See Rob Miracles post next. )

Note: It sounds like you will need to release new copies of your old apps (with new ids) as if your key was ‘lost or compromised’.  With or without this program you would  might have had to do that.

PS - I hope you only have a few apps in the store or this may be a long process.  Once you work this out, please share your findings and resolution steps here as this will likely be very helpful to one or more future readers.

@roaminggamer, you’re 100% right every developer should use a per-app signing key. But trying to understand keystores, aliases, the complex keytool command (in particular on windows since it’s never in the path) is problematic enough that many people get one working and never want to touch keytool ever again.  

A keystore file can hold multiple aliases. This means developers have three choices

  1. one keystore file, one key alias used for everything. This is a bad practice and should be avoided, but as mentioned above, key stuff is scary.

  2. multiple keystores, one key alias per keystore file, unique per app. This is probably the next step up since you only have to change one thing on the command line, the name of the keystore file. But you end up with multiple files to keep track of. 

  3. one keystore file, multiple key aliases per keystore file, unique alias per app. This is probably the most practical way if your comfortable with keytool. You change the keyalias value instead of the filename. You only have to keep track of one file.

Rob

@Rob - Thanks for clarifying.  I hope I didn’t come across to @carlcosta as a jerk, but it sounded like he has unfortunately painted himself into a corner on this via a bad practice.  (I may have misunderstood what he was describing though.)

I currently use technique #2, but #3 is intriguing.  As with @carlcosta I too do not like maintaining a bunch of keystores.  I just never realized I could do otherwise.

Sweet!  I learned something new.

@carlcosta - If you’re reading this and you use technique #3, then I misunderstood you.  Apologies.  I do however ask again that when you work this out, please… share your steps here so future readers don’t have to struggle with this or at least we can refer them to this thread as a solution if they should post independently about the same issue.

@roaminggamer,

i use same key for all apps built for our company.

when i make apps for other clients that can buy the rights of the app, i created a new key for each client. but usually its all created and updated in our place so 1 key is enough.

even google says you should use same keystore:

https://developer.android.com/studio/publish/app-signing.html#considerations

i know there is pros and cons about using same key,

you can read all of them here:

https://stackoverflow.com/questions/7685458/can-i-use-the-same-keystore-file-to-sign-two-different-applications

there are good replays there that you can learn from.

what you said it’s a way of doing things but it’s not better from what i’m doing.

*edit* -  i notice there are more 2 replies from you and rob while i was writing my post. i will read more about, but still you both says its a bad practice but don’t say why…

@carlcosta,

Cool!

First, I totally misunderstood the technique you were describing.  I thought you meant same keystore, same alias. 

(This is what I meant when I said bad practice, but it sounds like you’re actually using technique #3 which I do not use, but am now definitely considering.  Multiple keystore maintenance does suck.)

Second, this has been a learning experience for me and I’m looking forward to digging into it more.  Thanks so much for the description in last post and links.

Third, I hope you get this worked out.  I’ll leave it to the staff (and others with more key/signing expertise) from here, but I’ll be reading this as I’m very interested in the solution.  

Total bummer you got bitten by this.

Final note.  

If you didn’t notice.  I tend to post, read my post, correct typos, amend, etc.  Its anal, but I like the posts to be legible and I often make small mistakes in the first writing.  

So, be sure to wait a sec if you see a post from me.  I’m almost sure to amend in a moment later with fixes and clarifications.

@roaminggamer,

i’m still learning about this new process also. now only monday i will pick up this problem again. It’s time to go for weekend :slight_smile:

if all goes bad, i will delete the app and start from scratch and use old method.

the app is new so there is really no problem here.

i never thought for 1 second that your comments were negative. i really appreciate all the help you guys are giving. i also tend to write in a “rough tone” that usually is confused with aggressive attitude (words missing here, english is not my native language)  so i never judge a person or comment for the cover :wink:

regards,

carlos

I created a new key;

created a build with that key;

uploaded to google store;

completed process like any other app;

all went fine, it’s already on store live.

so i guess this new feature for corona users is same as before. i didnt had to upload any key. but i could not use the same key as before. for people that already create new keys for every app this is nothing new to them. 

I downloaded a certificate provided on the new section “Google Play App Signing” and installed on my windows machine (but don’t know if this done anything to the key I created after).

The  app I used this new method can be found in google play or apple store with the name “Tea Timer Gorreana”. It’s just a simple app for timing the tea, so you can have a perfect tea every time, using the app client tea (the largest tea maker company in Europe). I used material design guide lines from google website. all functions were done by me. already using them on another project.

It looks to me like they want you to upload your current release keystore to them and they will sign your app with it. Then you create a new keystore called the upload keystore and actually sign your app with it before uploading. There isn’t anything magic about how Corona signs apps that’s any different than any other native built app.

After reading the documentation, I’m not 100% sure about what all is needed to take your current release keystore and get it uploaded. They talk about needing a certificate and public key, which means you probably need to use the keytool program and export the various parts they need. I’m sure there are some tutorials out there since this is a generic Android process.

Rob

usually i use same key to all my apps.

i tried to upload a new app with this program. it said that the key is already used i can’t used anymore.

if i need to create a new key for each build is 10x worst than what i’m using right now.

i posted here about corona and this new method because in the documents says we need to make some changes on the apk:

Modifications to your APK Apps that are signed by Google will have a 'derived APK ID' written into their AndroidManifest.xml file. You'll see a meta-data element added under the application tag that references \<meta-data android:name="com.android.vending.derived.apk.id" android:value="[ID]" /\>.

so i don’t know if we need to make changes on build.settings or in config.lua, or is just what you said.

usually i use same key to all my apps.

Huh?  How did that work for you before?  You should be signing each unique app with a unique keystore made for that app only.

Even if this worked for you before it is wrong.  So, like it or not you need to start doing this the right way.

(This is not the same as a new keystore for every version of the app.  Each app should have a single unique keystore that is used for the original submission and all  updates.  i.e. You should have a 1-to-1 ratio of apps and keystores.)

( UPDATE: I am partly wrong about the 1-to-1 ratio business.  See Rob Miracles post next. )

Note: It sounds like you will need to release new copies of your old apps (with new ids) as if your key was ‘lost or compromised’.  With or without this program you would  might have had to do that.

PS - I hope you only have a few apps in the store or this may be a long process.  Once you work this out, please share your findings and resolution steps here as this will likely be very helpful to one or more future readers.

@roaminggamer, you’re 100% right every developer should use a per-app signing key. But trying to understand keystores, aliases, the complex keytool command (in particular on windows since it’s never in the path) is problematic enough that many people get one working and never want to touch keytool ever again.  

A keystore file can hold multiple aliases. This means developers have three choices

  1. one keystore file, one key alias used for everything. This is a bad practice and should be avoided, but as mentioned above, key stuff is scary.

  2. multiple keystores, one key alias per keystore file, unique per app. This is probably the next step up since you only have to change one thing on the command line, the name of the keystore file. But you end up with multiple files to keep track of. 

  3. one keystore file, multiple key aliases per keystore file, unique alias per app. This is probably the most practical way if your comfortable with keytool. You change the keyalias value instead of the filename. You only have to keep track of one file.

Rob

@Rob - Thanks for clarifying.  I hope I didn’t come across to @carlcosta as a jerk, but it sounded like he has unfortunately painted himself into a corner on this via a bad practice.  (I may have misunderstood what he was describing though.)

I currently use technique #2, but #3 is intriguing.  As with @carlcosta I too do not like maintaining a bunch of keystores.  I just never realized I could do otherwise.

Sweet!  I learned something new.

@carlcosta - If you’re reading this and you use technique #3, then I misunderstood you.  Apologies.  I do however ask again that when you work this out, please… share your steps here so future readers don’t have to struggle with this or at least we can refer them to this thread as a solution if they should post independently about the same issue.

@roaminggamer,

i use same key for all apps built for our company.

when i make apps for other clients that can buy the rights of the app, i created a new key for each client. but usually its all created and updated in our place so 1 key is enough.

even google says you should use same keystore:

https://developer.android.com/studio/publish/app-signing.html#considerations

i know there is pros and cons about using same key,

you can read all of them here:

https://stackoverflow.com/questions/7685458/can-i-use-the-same-keystore-file-to-sign-two-different-applications

there are good replays there that you can learn from.

what you said it’s a way of doing things but it’s not better from what i’m doing.

*edit* -  i notice there are more 2 replies from you and rob while i was writing my post. i will read more about, but still you both says its a bad practice but don’t say why…

@carlcosta,

Cool!

First, I totally misunderstood the technique you were describing.  I thought you meant same keystore, same alias. 

(This is what I meant when I said bad practice, but it sounds like you’re actually using technique #3 which I do not use, but am now definitely considering.  Multiple keystore maintenance does suck.)

Second, this has been a learning experience for me and I’m looking forward to digging into it more.  Thanks so much for the description in last post and links.

Third, I hope you get this worked out.  I’ll leave it to the staff (and others with more key/signing expertise) from here, but I’ll be reading this as I’m very interested in the solution.  

Total bummer you got bitten by this.

Final note.  

If you didn’t notice.  I tend to post, read my post, correct typos, amend, etc.  Its anal, but I like the posts to be legible and I often make small mistakes in the first writing.  

So, be sure to wait a sec if you see a post from me.  I’m almost sure to amend in a moment later with fixes and clarifications.

@roaminggamer,

i’m still learning about this new process also. now only monday i will pick up this problem again. It’s time to go for weekend :slight_smile:

if all goes bad, i will delete the app and start from scratch and use old method.

the app is new so there is really no problem here.

i never thought for 1 second that your comments were negative. i really appreciate all the help you guys are giving. i also tend to write in a “rough tone” that usually is confused with aggressive attitude (words missing here, english is not my native language)  so i never judge a person or comment for the cover :wink:

regards,

carlos