Unable to install version 0.10.0 as update of 0.9.3

[Lineflyer]

While testing the nightlies based on master I was unable to install the nightly version as of today on top of the already installed 0.9.3 (latest Playstore version).

Not sure why it fails.
As far as I can see the version code is untouched

WhereYouGo/build.gradle

Line 43 in f08ac2d

versionCode 45

which should be perfectly fine to install it as an update.

Could either be a problem with the signing key(?) or do we alter the version code during build on the CI for the whereyougo nightlies?

[kumy]

New key was deployed recently and is used for signing the nightlies since. The build process is as simple a running the gradle script. I did not see anything special last time I checked it the gradle build file.

Isn't there some restriction in android which prevent overwrite apk installed originally from PlayStore by a version downloaded manually as apk?

[Lineflyer]

Isn't there some restriction in android which prevent overwrite apk installed originally from PlayStore by a version downloaded manually as apk?

Not that I know of. I perform this regularly while testing the upgrade path of c:geo RC versions.
The only restriction is, that the new version code needs to be >= the installed version code.
I would need to have a ADB log, which I do not have during the week to see the fail reason.

[kumy]

I do not use GPlay, cannot help further, sorry.

[bekuno]

from https://developer.android.com/studio/publish/versioning :

versionCode — A positive integer used as an internal version number. 
This number is used only to determine whether one version is more recent than another, 
with higher numbers indicating more recent versions. This is not the version number shown to users; 
that number is set by the versionName setting, below. The Android system uses the versionCode 
value to protect against downgrades by preventing users from installing an APK with a lower 
versionCode than the version currently installed on their device.

The value is a positive integer so that other apps can programmatically evaluate it, for example to 
check an upgrade or downgrade relationship. You can set the value to any positive integer you want,
 however you should make sure that each successive release of your app uses a greater value. You 
cannot upload an APK to the Play Store with a versionCode you have already used for a previous 
version.

We have to increase the versionCode, I would say.

[Lineflyer]

As to my experience installation should work with the same versioncode as well. It must not be lower.

Of course when it comes to publishing on Google Play you need to use a higher version.
Lets test if this solves the manual installation problem as well.

[bekuno]

Maybe the signing key is not the same as on the latest version.
I tried to install the latest nightly on top of the 0.9.3 version:

>adb install -r "C:\whereyougo-2020.03.03-NB-f08ac2d.apk"
Performing Streamed Install
adb: failed to install C:\whereyougo-2020.03.03-NB-f08ac2d.apk: Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE: Package menion.android.whereyougo signatures do
not match the previously installed version; ignoring!]

[Lineflyer]

If the CI really uses the correct keys (those I provided to @mucek4 recently) they seem to be different than those used by @biylda. But that seems strange as those keys I received are the keys from @menion originally used for publishing the app. As the package name is the same since beginning @biylda would have had the same problem as we experience now.

[kumy]

The signing key on CI server seems really fresh. It was generated on Mon Jan 06 22:14:36 CET 2020.

@Lineflyer @mucek4 do we own the "officials" keys?

$ unzip whereyougo-2020.03.03-NB-f08ac2d.apk
$ keytool -printcert -file META-INF/CERT.RSA
Owner: CN=WhereYouGo team
Issuer: CN=WhereYouGo team
Serial number: 906c1a5
Valid from: Mon Jan 06 22:14:36 CET 2020 until: Fri Dec 30 22:14:36 CET 2044
Certificate fingerprints:
	 SHA1: 44:44:9E:BF:FC:22:A4:88:6A:E4:FE:B3:29:D1:E3:C1:31:0B:C3:32
	 SHA256: F6:4C:57:D5:6B:38:AB:98:BF:1C:4A:23:02:7C:CA:C6:DF:74:CC:BD:0C:38:CF:7C:28:4A:AE:5E:D1:DB:74:1F
Signature algorithm name: SHA256withRSA
Subject Public Key Algorithm: 2048-bit RSA key
Version: 3

Whereas the one downloaded from apkcombo (sha1: 91217683814ff0d2e935bae528afdd0f08e8bc5b)

$ unzip WhereYouGo_v0.9.3_apkpure.com.apk 
$ keytool -printcert -file META-INF/MENION.RSA 
Owner: CN=Menion Asamm, L=Prague, ST=Czech Republic, C=CS
Issuer: CN=Menion Asamm, L=Prague, ST=Czech Republic, C=CS
Serial number: 4ae46b76
Valid from: Sun Oct 25 16:15:02 CET 2009 until: Thu Oct 19 17:15:02 CEST 2034
Certificate fingerprints:
	 SHA1: 1D:45:82:81:D6:0D:C1:32:23:AA:C0:F2:96:2E:57:3D:53:CD:7C:77
	 SHA256: D6:29:8F:36:BE:D2:56:32:DD:C3:1B:FB:9B:8A:BA:32:A0:F3:FF:C2:ED:FE:CE:4F:D5:D7:CF:6C:18:40:A5:BC
Signature algorithm name: SHA1withRSA
Subject Public Key Algorithm: 1024-bit RSA key
Version: 3

[Lineflyer]

I forwarded this question to menion (see CC to cgeo-dev)

[menion]

Hi guys,
explanation is simple here.

What I send you is not original release key used for signing app on the Google Play, and as I see,
I did not mention this correctly to @Lineflyer during our email communication, sorry.

I do not know, how you generate and publish c:geo app, but this key is "Upload key" for AppSigning system on Google Play. The original "Release" signing key is already uploaded on Google Play and will be used for the final singing of APK files before uploading to users by Google itself.

So to test if all works ok, best is to enable some Alpha/Beta channel on the WhereYouGo page and upload signed APK/AAB there.

The main reason for this is that the original key used for singing WhereYouGo is the same, as I use for the Locus Map app. And I do not want to share it, believe you understand.

All clear?

[Lineflyer]

Thanks @menion for this logical explanation. We do not use this mechanism with c:geo so at least I was not aware of it.
I doublechecked the play console and it should match:

Upload certificate fingerprint: SHA1: 44:44:9E:BF:FC:22:A4:88:6A:E4:FE:B3:29:D1:E3:C1:31:0B:C3:32

Automatic app signing fingerprint: SHA1: 1D:45:82:81:D6:0D:C1:32:23:AA:C0:F2:96:2E:57:3D:53:CD:7C:77

LGTM

We have the beta channel enabled, so it we can test it with that.

BTW: @menion Any idea why there are so many active versions out there, see #13 ?

[kumy]

One downside is that direct downloads from jenkins/download.cgeo.org/fdroid users will have apk signed by a different key. It should be acceptable 👍

[menion]

Perfect, glad to help.
Versions ... I never used this system, but based on the age of these versions, it does not make too much sense now I think. Anyway, this, as well as whole WhereYouGo, was 100% under control of Matejčík. I only made a manual sign of APK he sends me over email ... (crazy I know).

@kumy I was worried you will have this use-case. Anyway as long, as you will keep the same certificate for public APK's, it should be ok (except the first update of course). Sorry for this small complication.

[Lineflyer]

@menion
Maybe a bit later we could replace the certificate by a new one on Google Play. AFAICS the certificates are handled on app base rather than on account base. So it should be possible to change the signing key for one app while keeping it for another app on the same Google Play account. Or will it then still break the upgrade path?!

[kumy]

Changing signing certificate will always break the upgrade path. That's the purpose of the certificate signing.

[menion]

Right, currently always.
Anyway because these older certificates (like mine generated in 2010) have it's validity time-limited, I read that in preparation is a system for the proper switch without breaking updates. Not sure about status of this "feature" now, but in the future, it will be (have to) possible.

[Lineflyer]

I documented the steps needed for releasing (including the two step signing) in a first wiki entry. Feel free to add/correct:
https://github.com/cgeo/WhereYouGo/wiki/Release-preparation

IMHO we can close this issue. I will open an issue regarding the key migration (once this is possible) as a reminder.