I have an app that I haven’t built in years. I just successfully built it in the Windows simulator, but I can’t build an Android APK using my keystore or the debug keystore either. With both keystores, I get the same error:
11:50:17.634 Picked up JAVA_TOOL_OPTIONS: -Duser.language=en
11:50:17.634 jarsigner: unable to sign jar: no response from the Timestamping Authority. When connecting from behind a firewall an HTTP or HTTPS proxy may need to be specified. Supply the following options to jarsigner:
11:50:17.634 -J-Dhttp.proxyHost=<hostname>
11:50:17.634 -J-Dhttp.proxyPort=<portnumber>
11:50:17.634 or
11:50:17.634 -J-Dhttps.proxyHost=<hostname>
11:50:17.634 -J-Dhttps.proxyPort=<portnumber>
Does this mean that my firewall is blocking Solar? How can I test that?
I’m able to open www.digicert.com consistently, on multiple different browsers. On the other hand, I can never open timestamp.digicert.com in a browser, but that might not be surprising; maybe it doesn’t serve a webpage, just the certificate timestamp.
It’s not my code, either; I tried to build the sample Hello World app and got the same error.
Do you know what port it tries to use? Maybe I can check if that port is open or something…
It’s possible that would also work for you, in which case it’ll come down to Solar2d’s simulator process.
If it is a firewall restriction on your side then you can disable it during your test build (whether 3rd party or Windows built-in), or you can simply make an exception for anything related to Solar2d’s processes.
EDIT:
I do have a workaround to avoid this issue in general, it’s OK for testing but not for production.
Solar2D will setup everything for you, but I make mention of it because at least on a fresh Solar2D installation the first Android build process requires access to Gradle files on the web and that also takes noticeably longer than subsequent Android builds.
Ideally, you would want your timestamp issue resolved.
While on that journey, if what I mentioned earlier doesn’t help narrow down the problem then you can also test using a different Windows profile.
I have also seen weird network issues in the past that were resolved by resetting TCP/IP via netsh command utility; though not sure if that’s relevant nowadays on >= Windows 10.