-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gradle clean behavior #166
Comments
Hey, thanks for reaching out. I've found that Android Studio or the emulator can leave background processes running that you may not expect, which could be causing this issue. In addition, I believe that this plugin creates additional clean tasks to delete the SDK as part of cleanup even if you customized the location it installs to in your build config. You can programmatically disable that task if you like in your I'm on vacation at the moment though and may be slow to further respond this week. |
Was that sufficient to resolve your issue? |
@bonitao Bump |
Hi @quittle , Unfortunately the issue persists. I believe the source of the problem is more fundamental, since the sdk is a dependency of the build process, and the gradle-setup-android-sdk sees it as a byproduct of the build process. As something cannot be a dependency and a byproduct at the same time without incurring in a loop, problems arise in some edge cases. The only fix I can see is the one I proposed. Treat the sdk as any other dependency, by installing it with version information (which will even allow transitions when you upgrade it) under the dependency cache: https://docs.gradle.org/current/userguide/dependency_management.html#sec:dependency_cache. Then you can point I understand this is a big change, but wanted to leave the suggestion here anyway in case you find it useful. |
When I run
gradle clean
, I getIn some ways, this is expected. For example, when I have Android Studio open. But even when it is not the case there is often some process with a handle on the directory. I wonder if this is a know problem?
An alternative here would be to keep the sdk outside the build tree, maybe in tmp with hash addressing. That way even with the sdk being used
gradle clean
would succeed.The text was updated successfully, but these errors were encountered: