Trying to "gradlew publisReleaseListing" fails repeatedly with GPlay HTTP API Error #500 and no messages pointing to the cause.
com.google.api.client.googleapis.json.GoogleJsonResponseException: 500 Internal Server Error
{
"code" : 500,
"message" : null
}
https://www.googleapis.com/upload/androidpublisher/v3/applications/com.github.catfriend1.syncthingandroid/edits/055435675
51180603900/listings/ca/icon?uploadType=resumable
It didn't go away after clicking "Switch to the new image format" on GPlay console - still error 500.
I also tried to replace the transparent PNG by a PNG with solid background as described in https://developer.android.com/google-play/resources/icon-design-specifications , enforced by GPlay from 24/06/2019 + .
AFTER THAT: A java process is left behind in windows task manager and the lang resource file where the "publishReleaseListing" stopped is still open "in background" with no indication to the user that this is the case. It can be proven by running the following command in a terminal:
rd /s /q F:\GitHub\syncthing-android\app\build\generated\gpp
F:\GitHub\syncthing-android\app\build\generated\gpp\release\res\listings\ar\graphics\icon\5185990009863024024.png - Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird.
publishRelease OR publishReleaseListing
Resource upload takes place and finishes successfully. / I expect to be able to retry with another PNG resource for "icon".
About that #500 error:
What I did:
taskkill /f /im java.exe
rd /s /q F:\GitHub\syncthing-android\app\build\generated\gpp
REM Deleted every ".../play/listings/[lang]/graphics/icon" folder manually in Windows Explorer.
REM Re-ran the publishReleaseListing command.
Related posts:
One more question: Is there any way to set "uploadImages = false" in the v2.2.1 of the plugin?
The file resource leak will be fixed by https://github.com/googleapis/google-api-java-client/pull/1324.
And I don't understand your issue. No, you can't disable image uploading. Simply don't put images in the graphics folder if you don't want them uploaded. If it works after running bootstrap that means your images were bad.
A simple way to check would be: can the image be uploaded through the Play Console. If yes, it should work with GPP, if no, then it's bad.
Can you please clarify exactly what you're trying to do?
A simple way to check would be: can the image be uploaded through the Play Console. If yes, it should work with GPP, if no, then it's bad.
I just tried and I could upload and set the icon in the Play Console, but I get the same error using GPP (./gradlew publishReleaseListing) as Catfriend1 reported. The failing image is in https://github.com/syncthing/syncthing-android/tree/master/app/src/main/play/listings/en-GB/graphics/icon and the full log can be found at https://gist.github.com/imsodin/8a40073de6f3192dd1e7c15842b15b7c
If it works after running bootstrap that means your images were bad.
I just ran bootstrap and it does rename the icon without modifying it's content:
app/src/main/play/listings/en-GB/graphics/icon/{12150231666510658317.png => 9834354722760385987.png} | Bin
I retried publishReleaseListing with the renamed icon, but the error remains.
Thanks, imsodin for joining in. This drove me crazy last night looking for a solution. I was trying to upload a png without transparency which also led to the 500 error. Deleting the icon png made the upload complete successfully.
I've contacted some people at Google who should know more. Unfortunately, there's nothing GPP can really do. I'll update when I get more info.
This reason for this image upload error is described here: https://developer.android.com/google-play/resources/icon-design-specifications#instructions_for_api_users.
As the date mentioned on the page is now passed, you should not get the error anymore. That said the new specification is now automatically applied to all icon upload, so make sure you follow the guidelines.
@gitterandgold Yes it works now :)
Thanks for the info. That was really unfortunate timing, a bit later and we would have never encountered this (and arguably not ideal error reporting by the API, I don't see how I should have found that starting at a generic error 500).