Fixed
Status Update
No update yet.
Comments
uc...@google.com
Thank you for your feedback. Team may reach out for more feedback in reproducing or triaging this issue.
ra...@google.com
xa...@google.com
Indeed I can reproduce with 3.5 canary13.
We need to check if we miss the exception or if the tooling API is not actually throwing it.
If the former, let's fix it, if the former, let's file a bug on Gradle.
We need to check if we miss the exception or if the tooling API is not actually throwing it.
If the former, let's fix it, if the former, let's file a bug on Gradle.
xa...@google.com
We should also probably either remove the distributionSha256Sum parameters (or comment it) or notify the user that this is going to prevent sync from working until it's updated. I don't think we can safely go get that information and auto-update.
ch...@google.com
Gradle Tooling API doesn't throw any exception nor terminate when this happens, so the freeze occurred inside of Gradle.
Will file a bug to Gradle.
And at the meantime, Studio will comment out distributionSha256Sum parameter and show a warning about "this parameter is not supported" if it's defined.
Will file a bug to Gradle.
And at the meantime, Studio will comment out distributionSha256Sum parameter and show a warning about "this parameter is not supported" if it's defined.
ch...@google.com
[Deleted User] <[Deleted User]>
> And at the meantime, Studio will comment out distributionSha256Sum parameter and show a warning about "this parameter is not supported" if it's defined.
As the attachment shows, this is an ERROR not a WARNING! This seems overkill to me, as I still want to ensure integrity of the wrapper download, and I am ok with it hard failing if the checksum is incorrect, better than succeeding when the checksum is incorrect which could lead to a huge global exploitation.
As the attachment shows, this is an ERROR not a WARNING! This seems overkill to me, as I still want to ensure integrity of the wrapper download, and I am ok with it hard failing if the checksum is incorrect, better than succeeding when the checksum is incorrect which could lead to a huge global exploitation.
an...@gmail.com
I share the same concerns as #7. Maybe someone has found an easy solution to have `distributionSha256Sum` at least only for CI builds?
ch...@google.com
Thank you for your feedback!
It was made an error instead of warning to ensure that user is aware of this issue.
The problem is that, if checksum doesn't match, Gradle freezes without giving any feedback, and it is hard for Android Studio to guess the reason and terminate Gradle process since there are some valid long-running Gradle tasks.
But I agree that it is important to be able to do integrity check. We will think about a better way to handle this, and please expect it in the next 3.6 canaries.
It was made an error instead of warning to ensure that user is aware of this issue.
The problem is that, if checksum doesn't match, Gradle freezes without giving any feedback, and it is hard for Android Studio to guess the reason and terminate Gradle process since there are some valid long-running Gradle tasks.
But I agree that it is important to be able to do integrity check. We will think about a better way to handle this, and please expect it in the next 3.6 canaries.
sr...@google.com
ha...@guardianproject.info
For auto-updating, Gradle does publish the list of checksums for all their releases here: https://gradle.org/release-checksums/ . If they made that page also include a JSON version, then it would be really easy to fetch and use.
But really, it seems to me that these checksums should just be built into the ./gradlew wrapper script.
But really, it seems to me that these checksums should just be built into the ./gradlew wrapper script.
sr...@google.com
On the next release (3.6 beta 1) there will be an additional option in the message to use the checksum, if this option is selected, sync will be run again and any subsequent sync that uses the same checksum for the same distribution url will continue without a similar warning.
sr...@google.com
This change was also cherry picked for 3.5.1.
Description
I sometimes use the `distributionSha256Sum` parameter in gradle-wrapper.properties file.
If Android Studio and gradle version is updated -- and you have not
updated this checksum beforehand it will get stuck at the "Android syncing..." build
step and you have to kill Android Studio to get out of that. I realize I have to update the new sha256 sum each time manually, but the fact it freezes up and locks could be handled a bit more gracefully, and also let the user know the checksum mismatches.
It should be noted that this might be gradles fault, I am not sure.
Build: AI-191.6014.8.35.5375575, 201903141247, AI-191.6014.8.35.5375575, JRE 1.8.0_152-release-1343-b16-5323222x64 JetBrains s.r.o, OS Linux(amd64) v4.18.0-16-generic, screens 1920x1080, 1080x1920AS: 3.5 Canary 8; Android Gradle Plugin: 3.5.0-alpha08; Gradle: 5.3; NDK: from local.properties: (not specified), latest from SDK: (not found); LLDB: pinned revision 3.1 not found, latest from SDK: (package not found); CMake: from local.properties: (not specified), latest from SDK: (not found), from PATH: 3.12.1 IMPORTANT: Please read