As per the subject, either the file upload itself (from a Jenkins slave) or the preceding fetch of the channels etc. fails with the system not even trying to use the proxy (which is properly specified not only in Jenkins GUI, but also via JAVA_OPTs, although the latter should not be necessary - meaning he plugin's code is very old and obsolete). The OAuth goes through, but nothing else. We cannot say where the error occurs, because the plugin "conveniently" inhibits the stack trace (why?? - we checked the code, it is deliberately inhibited), printing only the useless "Network is unreachable" message. Still, here it is in all its glory (redacted):

Authenticating to Google Play API...

• Credential: 12345678-1234-1234-1234-1234567890ab
• Application ID: com.example.app

Upload failed: Unknown error: java.net.SocketException: Network is unreachable
No changes have been applied to the Google Play account

Network is unreachable, because neither the Jenkins master not the Jenkins slave have a default route; they do have a route to a local outbound proxy with proper AAA in place, though.

Traffic dump on the Jenkins slave clearly shows that it makes a DNS query for googleapis.com just before the failure - a clear sign that it does not use the proxy at al, otherwise it should have made a CONNECT request to the proxy instead; on top, the log on the HTTPS proxy shows no connection attempt at all.

Again:

• The proxy is configured in Jenkins master's GUI - this is the only place that should be needed and works for all other plugins we have (the -D... thing is old and obsolete, as well as the Plugin -> Advanced place you advertise in your docs)
• It is also added also in master's JAVA_OPTS (otherwise the OAuth fails on this plugin, although many other plugins work happily, e.g. Notifications plugin).
• It is automatically pushed to the slaves by Jenkins in some JAVA_WHATEVER_OPTS env var, even though this is clearly wrong, as a slave may well need different proxy settings form its master (still, Maven picks it up and works).
• It is added to the env on the slave in the form of the HTTP_PROXY, HTTPS_PROXY and NO_PROXY vars (for anything else that may just need it, like libcurl et al).
• It is added to the env of the slave as JAVA_OPTS var, similar to the master (-D...)

How do we troubleshoot which component fails and how do we fix it?

All in all, running a 4-year-old code based on 11-yeatr old code that uses 5 year-old Google lib (which now has a new major version) and that lags 300+ minors behind current Jenkins stable does not look encouraging.