Gradle-play-publisher: Receive 403 error when trying to publish to other channel

[otnateos]

Hi there,

Thanks for the great plugin beforehand.

We have been using the play publisher plugin and works great deploying to 'alpha' channel on Google Play Store. However we just discover when we try to change to publish certain version to 'beta' channel, we receive 403 error. The error is like below

> com.google.api.client.googleapis.json.GoogleJsonResponseException: 403 Forbidden
  {
    "code" : 403,
    "errors" : [ {
      "domain" : "androidpublisher",
      "message" : "Version ???? of this app can not be downloaded by any devices as 
they will all receive APKs with higher version codes.",
      "reason" : "multiApkShadowedActiveApk"
    } ],
    "message" : "Version ???? of this app can not be downloaded by any devices 
as they will all receive APKs with higher version codes."
  }

Is there any workaround to publish from 'alpha' to 'beta' ?

Thanks

[shiraji]

Your problem is you were trying to upload the same version of apk. Since Play store doesn't let us upload the same version of apk to any of tracks, you got this error message.

If you want to upload a better version of apk, then change version code higher. Then upload it to beta.
If you want to promote alpha track to beta track, you need to wait #108 to merge or do it through the web ui.

[otnateos]

Your problem is you were trying to upload the same version of apk. Since Play store doesn't let us upload the same version of apk to any of tracks, you got this error message.

Do you mean the versionCode ? There is no way that we are deploying the same version. I actually increment the versionCode manually before doing full rebuild and execute the deployment.

[bhurling]

Did you already upload an APK with a higher version code than what you want
to publish to beta? Looks like there is one APK available that will shadow
your beta. Please double check all the version codes that are used in prod,
beta and alpha plus the version codes you are trying to upload.

Do you use APK splits or multi APK?

On Wed, Jan 20, 2016, 11:00 Johanes Soetanto [email protected]
wrote:

Your problem is you were trying to upload the same version of apk. Since
Play store doesn't let us upload the same version of apk to any of tracks,
you got this error message.

Do you mean the versionCode ? There is no way that we are deploying the
same version. I actually increment the versionCode manually before doing
full rebuild and execute the deployment.

—
Reply to this email directly or view it on GitHub
https://github.com/Triple-T/gradle-play-publisher/issues/121#issuecomment-173151408
.

[otnateos]

I don't think we have any version greater than the one we try to upload. Our current production versionCode is 2 digit numbers, and our alpha and beta already 3 digit numbers. e.g.

alpha = 130
beta = 120
new version = 140

I got the same error initially even before I enable the beta channel on Play Console. I could even upload the apk using the web (that beta version above is uploaded through web ui).

Do you use APK splits or multi APK?

We use multidex and multi flavour build

[otnateos]

In the PlayPublishApkTask.groovy line 33 there is an update executed for the track. Could this make an issue if there is another lower channel (e.g. alpha) that need to be updated?

[bhurling]

The problem might be that you already uploaded version 130 to the alpha channel. And now you're trying to upload version 120 to the beta channel. 120 is smaller than 130 thus no one will ever see this version.

Which is still a bit weird. Normally, I'd say that the list of beta users is different from the list of alpha users (there should be more beta users). Do in my opinion there are devices that will see the beta but not the alpha. Maybe you found a bug in the play store console itself. Did you try do upload your beta APK manually?

[otnateos]

Our current beta version are all uploaded manually. The illustration of the version is to demonstrate that the new version (140) fail to be uploaded to beta channel but can be uploaded to alpha without problem. Upload to alpha still works even though after I manually upload to beta.

Currently I still can't check and test since I'm being throttled for uploading the apk by the API.

[otnateos]

I just did another test (version is just an illustration)

initial beta : 150
initial alpha : (disabled after upload beta manually)
upload to beta : 151 (success)
upload to alpha : 152 (success)
upload to beta : 153 (failed with same error like original post)

It seems like changing the track from 'alpha' to 'beta' of the same project won't work nicely.

I'm not sure if that's related to our project settings where we have closed alpha and opened beta, or maybe a bug in the API itself.

[otnateos]

I created PR https://github.com/Triple-T/gradle-play-publisher/pull/122 to fix the issue. This is based on doc https://developers.google.com/android-publisher/tracks around section of rollout that the other tracking need to be removed when releasing.

I'm not sure what kind of standard you have for your PR, feel free to modify it. We will probably use my fork if it won't make to the streamline.

Thanks again for the great plugin

[tasomaniac]

We have the same problem in our app: https://github.com/gdg-x/frisbee

The problem is that "logically" Alpha version should always be higher than Beta. In normal lifecycle, you first promote the Alpha version of the app to Beta and then you publish something to Beta.

Even when the versionCode is higher Play Store does not let us to upload to Beta if there is something in Alpha.

When there is already something in Alpha, It should first be deactivated or promoted to Beta.

{
    "code" : 403,
    "errors" : [ {
      "domain" : "androidpublisher",
      "message" : "Version 23005 of this app can not be downloaded by any devices as they will all receive APKs with higher version codes.",
      "reason" : "multiApkShadowedActiveApk"
    } ],
    "message" : "Version 23005 of this app can not be downloaded by any devices as they will all receive APKs with higher version codes."
  }

[justintuchek]

This could legitimately be a bug in the Publishing API when using tracks other than production. Testing this out with an application that only utilizes an alpha channel OR only utilizes a beta channel - I'll receive the same 403 response and message even though the versionCode has been incremented to exceed the current APK available in the channel (and all other channels - which are empty.)

[tasomaniac]

@jtuchek the idea is that alpha cannot be smaller than beta, beta cannot be smaller than production.

If you have an APK already in alpha or beta, you cannot use the tool to send an APK to production. But you can send an APK to the same alpha/beta channel.

[bhurling]

I just tried to do the following steps using the web interface:

1. Upload an APK to alpha with version code 42
2. Upload an APK to beta with version code 43

The web interface does not let me apply that configuration with basically the same message (version 42 can't be downloaded by any device). So as I see it, the 403 response is more or less the expected behaviour for a configuration like that. I don't agree with that behaviour but Google obviously assumes that Alpha Testers are a subset of Beta Testers.

There are three things we can do to tackle that issue:

1. Wrap that error message into something more useful like "Did you forget to deactivate your APK in the alpha/beta/rollout track?"
2. Provide dedicated tasks to deactivate the APK on alpha/beta/rollout track. I'd rather not automatically deactivate other tracks because that might break other people's tests.
3. File an issue to explains that Alpha Testers are not necessarily a subset of Beta Testers and thus their assumption "App cannot be downloaded by any device" is not entirely true

[tasomaniac]

Good summary of the problem. Thank you.

I would say the 3rd option is impossible. Even though some people would not prefer Alpha Testers are a subset of Beta, most projects would prefer that I think. At least Google thinks that way. And changing it at that point may not be possible at all.

I would go for the 2nd option. Automatically doing it is I think too much. But it can be provided as an option. And a task to deactivate an APK in the track would be really helpful.

[justintuchek]

@bhurling @tasomaniac I think that the 2nd option is the optimal way to go.

At least there would be an option to compose replacing APKs inline by unpublishing that track before uploading a new APK.

Is this something that we would want to pull into the project if it was developed? (I just got some time allocated in our backlog coming up to spend some time on getting our continuous deployment mechanism working for beta and alpha users - otherwise we'll probably just maintain a fork)

[tasomaniac]

Our continuous delivery implementation pushes apk to alpha once we merge something to master. We never get this error with alpha because alpha accept APKs even there are APKs in release or beta.
Whenever, I do a real release I go ahead manually and disable the alpha version.

2nd option indeed sounds good.

I didn't understand your last paragraph @jtuchek

[otnateos]

Provide dedicated tasks to deactivate the APK on alpha/beta/rollout track. I'd rather not automatically deactivate other tracks because that might break other people's tests.

I created PR #146 for that preferred solution

[bhurling]

As of version 1.2.0-beta2 you can set untrackOld true in your gradle file. With that flag enabled, the plugin will automatically deactivate all versions in the alpha channel that would block a new APK from being uploaded to beta.

[p-schneider]

Currently our app has only one version active for all users (1700), we have been using the alpha and beta channels before but we uploaded the (final) "1700" directly to production and therefore disabled the beta channel. (We did the same to beta/alpha earlier when we pushed "1645" directly to beta instead of pushing it to alpha first, which is why our alpha version is even older than the beta version.)

In the "Play Console" Android App by Google it currently looks like this:

The "Google Play Developer Console" (website) looks like this (section ~"manage versions")

Until now we always uploaded APKs manually but we now want to start using gradle-play-publisher.
I am now testing version 1.2.0-beta2 with this settings trying to upload version "1702" to alpha:

play {
    track = 'alpha'
    untrackOld = true
    jsonFile = file('keys.json')
}

_Edit: Initially I only had jsonFile definded and the error occured, so I added track and untrackOld for testing but it still doesn't work (same error)._
... but we currently get this error:

{
  "code" : 403,
  "errors" : [ {
    "domain" : "androidpublisher",
    "message" : "Version 1645 of this app can not be downloaded by any devices as they will all receive APKs with higher version codes.",
    "reason" : "multiApkShadowedActiveApk"
  } ],
  "message" : "Version 1645 of this app can not be downloaded by any devices as they will all receive APKs with higher version codes."
}

I don't know why google's api is complaining about the outdated beta channel apk (1645) which already is inactive.
Is there a proper way to work around this or do i have to manually upload a "1701" to beta in order to make gradle-play-publisher able to upload the "1702" version to alpha?

Also: the readme states we can use untrackOld = true, your comment said untrackOld true. Do both ways work? Which one is preferred?

[bhurling]

Probably you need to manually deactivate the outdated APKs in the web interface. I don't understand why they are still there at all. By uploading 1700 to prod through the browser they should have been deactivated automatically.

The only way to do it with the plugin might be too upload a 1701 to prod with untrackOld set to true.

[p-schneider]

Thank you for your fast reply.
We managed to get it to work without the need to publish a new version (causing updates for the users) to production or beta.
Here our solution just in case someone else runs into the same issue.

There was a way in the webinterface to update the beta channel from the outdated 1645 to 1700, so it would equalize with production where we were already using 1700:
"Manage Beta Version" -> "Create Version" -> "add APK from library" _(translated from German "Beta-Version Verwalten" -> "Version erstellen" -> "APK aus der Bibliothek hinzufügen")_

So we got into this state:

After that we were able to use gradle-play-publisher to update the alpha channel directly from the outdated 1610 to the latest 1702 (newer than beta/production)

End result:

The Android Play Developer app now shows it like this: (After the inactive beta 1645 was updated to the 1700 from prodution the beta channel disappered from this view.)

[hram]

@p-schneider Thank you!!! You save my day.
"Manage Beta Version" -> "Create Version" -> "add APK from library" fixed 403 error

[AnthonyNahas]

Hi, i had the same problem and i solve it like below:

call Edits.tracks: update twice:

For example, suppose the current production version is 999, and the current rollout version is 1100. To promote the rollout version to production, call Edits.tracks: update. Call it once to assign version 1100 to the "production" track, passing this JSON object:
{
"track": "production",
"versionCodes": [1100]
}
And call the method a second time to clear out the "rollout" track, passing this JSON object:
{
"track": "rollout",
"versionCodes": []
}

was mentioned here in the documentation, in the last scope
--> https://developers.google.com/android-publisher/tracks

` // Assign apk to alpha track.
List apkVersionCodes = new ArrayList<>();
apkVersionCodes.add(apk.getVersionCode());

        Update updateTrackRequest = edits
            .tracks()
            .update(ApplicationConfig.PACKAGE_NAME,
                editId,
                TRACK_ALPHA,
                new Track().setVersionCodes(apkVersionCodes));

        Track updatedTrack = updateTrackRequest.execute();
        log.info(String.format("Track %s has been updated.", updatedTrack.getTrack()));

I added this part to google sample code

        Update updateTrackRequest2 = edits
            .tracks()
            .update(ApplicationConfig.PACKAGE_NAME,
                editId,
                TRACK_BETA,
                new Track().setVersionCodes(new ArrayList<>()));

        updateTrackRequest2.execute();

end

        // Commit changes for edit.
        Commit commitRequest = edits.commit(ApplicationConfig.PACKAGE_NAME, editId);
        AppEdit appEdit = commitRequest.execute();
        log.info(String.format("App edit with id %s has been comitted", appEdit.getId()));`

Result 👍

• Mai 19, 2017 12:49:45 PM com.google.play.developerapi.samples.BasicUploadApk execute INFORMATION: Created edit with id: 07475336680662904134

• Mai 19, 2017 12:49:51 PM com.google.play.developerapi.samples.BasicUploadApk execute INFORMATION: Version code 503 has been uploaded

• Mai 19, 2017 12:49:52 PM com.google.play.developerapi.samples.BasicUploadApk execute INFORMATION: Track alpha has been updated.

• Mai 19, 2017 12:49:56 PM com.google.play.developerapi.samples.BasicUploadApk execute INFORMATION: App edit with id 07475336680662904134 has been comitted

• Mai 19, 2017 12:49:56 PM com.google.play.developerapi.samples.AndroidPublisherHelper authorizeWithServiceAccount

The modified JAVA code can be found under https://github.com/googlesamples/android-play-publisher-api/blob/master/v2/java/src/com/google/play/developerapi/samples/BasicUploadApk.java

Summary: the plugin should track update two times !!

[paulo-coutinho]

I think the plugin need an update. I have the same problem.