Failed to delete some children. This might happen because a process has files open or has its working directory set in the target directory - windows

For some unknown reason, whenever I run gradle clean build after I start my notebook it works as expected. When I try for the second time, I always get
Unable to delete directory 'C:\_d\mycompany\WSs\demo\build'
Failed to delete some children. This might happen because a process has files open or has its working directory set in the target directory.
- C:\_d\mycompany\WSs\demo\build\classes\kotlin\main\com\mybank
- C:\_d\mycompany\WSs\demo\build\classes\kotlin\main\com
- C:\_d\mycompany\WSs\demo\build\classes\kotlin\main
- C:\_d\mycompany\WSs\demo\build\classes\kotlin\test\com
- C:\_d\mycompany\WSs\demo\build\classes\kotlin\test
- C:\_d\mycompany\WSs\demo\build\classes\kotlin
- C:\_d\mycompany\WSs\demo\build\classes
- C:\_d\mycompany\WSs\demo\build\generated\source\kapt
- C:\_d\mycompany\WSs\demo\build\generated\source\kaptKotlin\main
- C:\_d\mycompany\WSs\demo\build\generated\source\kaptKotlin\test
- C:\_d\mycompany\WSs\demo\build\generated\source\kaptKotlin
- C:\_d\mycompany\WSs\demo\build\generated\source
- C:\_d\mycompany\WSs\demo\build\generated
- C:\_d\mycompany\WSs\demo\build\kotlin\compileKotlin\caches-jvm\inputs
- C:\_d\mycompany\WSs\demo\build\kotlin\compileKotlin\caches-jvm\jvm\kotlin
- C:\_d\mycompany\WSs\demo\build\kotlin\compileKotlin\caches-jvm\jvm
- and more ...
New files were found. This might happen because a process is still writing to the target directory.
- C:\_d\mycompany\WSs\demo\build\kotlin\compileKotlin
I found someone failing quite similar problem but using Android Studio/Ubuntu (I am using IntelliJ Community/Windows 10): other question
I tried carefully all recommendations and none of them fixed my issue. I only get it working back if I restart my Windows and just work one time.
Some of the recommendations are:
1 - Close the studio and go to the path the issue is located at and delete the folder there.
I tried close IntelliJ and I can't delete the folder straight
2 - File > Settings > Build, Execution, Deployment > Instant Run > Uncheck this Check box (Enable Instant Run to hot swap code)
There is no such optional in my IntelliJ
IntelliJ IDEA 2020.2.3 (Community Edition)
Build #IC-202.7660.26, built on October 6, 2020
Runtime version: 11.0.8+10-b944.34 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 10 10.0
GC: ParNew, ConcurrentMarkSweep
Memory: 1963M
Cores: 8
Non-Bundled Plugins: Lombook Plugin, org.jetbrains.kotlin
3 - gradlew clean
Same issue
4 - right-click on the directory, click properties on the context menu that will appear, then uncheck the "Read Only" attribute. After that, click the "Apply" to apply changes.
I am administrator but I couldn't change such folder attribute.
5 - Running android studio as administrator in windows worked for me.
Same issue
Here are my build.gradle
plugins {
id "org.jetbrains.kotlin.jvm" version "1.4.10"
id "org.jetbrains.kotlin.kapt" version "1.4.10"
id "org.jetbrains.kotlin.plugin.allopen" version "1.4.10"
id "com.github.johnrengelman.shadow" version "6.1.0"
id "io.micronaut.application" version '1.0.5'
id "com.gorylenko.gradle-git-properties" version "2.2.2"
}
version "0.1"
group "com.mybank"
repositories {
mavenCentral()
jcenter()
}
micronaut {
runtime "netty"
testRuntime "junit5"
processing {
incremental true
annotations "com.mybank.*"
}
}
dependencies {
implementation("io.micronaut:micronaut-validation")
implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8:${kotlinVersion}")
implementation("org.jetbrains.kotlin:kotlin-reflect:${kotlinVersion}")
implementation("io.micronaut.kotlin:micronaut-kotlin-runtime")
implementation("io.micronaut:micronaut-runtime")
implementation("javax.annotation:javax.annotation-api")
implementation("io.micronaut:micronaut-http-client")
implementation("io.micronaut:micronaut-management")
implementation("io.micronaut.sql:micronaut-jdbc-hikari")
implementation("io.micronaut.sql:micronaut-hibernate-jpa")
runtimeOnly("com.h2database:h2")
runtimeOnly("ch.qos.logback:logback-classic")
runtimeOnly("com.fasterxml.jackson.module:jackson-module-kotlin")
}
mainClassName = "com.mybank.ApplicationKt"
java {
sourceCompatibility = JavaVersion.toVersion('11')
}
compileKotlin {
kotlinOptions {
jvmTarget = '11'
}
}
compileTestKotlin {
kotlinOptions {
jvmTarget = '11'
}
}
gradle.properties
micronautVersion=2.1.3
kotlinVersion=1.4.10
and the build folder seen in IntelliJ
*** edited
I didn't find how fix it. Now is happening with a project I have just cloned from micronaut
And I can't delete build folder although I am Windows administrator
PS C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin> gradle clean build
> Task :clean FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':clean'.
> java.io.IOException: Unable to delete directory 'C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build'
Failed to delete some children. This might happen because a process has files open or has its working directory set in
the target directory.
- C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build\generated\source\kaptKotlin\main
- C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build\generated\source\kaptKotlin\test
- C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build\generated\source\kaptKotlin
- C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build\generated\source
- C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build\generated
- C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build\tmp\kapt3\incApCache\main
- C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build\tmp\kapt3\incApCache\test
- C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build\tmp\kapt3\incApCache
- C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build\tmp\kapt3\stubs\main
- C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build\tmp\kapt3\stubs\test
- C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build\tmp\kapt3\stubs
- C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build\tmp\kapt3
- C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin\build\tmp
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.7/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 13s
1 actionable task: 1 executed
PS C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin> gradle stop
FAILURE: Build failed with an exception.
* What went wrong:
Task 'stop' not found in root project 'hello-world-kotlin'.
* Try:
Run gradle tasks to get a list of available tasks. Run with --stacktrace option to get the stack trace. Run with --info or
--debug option to get more log output. Run with --scan to get full insights.
* Get more help at https://help.gradle.org
Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.7/userguide/command_line_interface.html#sec:command_line_warnings
BUILD FAILED in 2s
PS C:\_d\toLearn\micronaut-grpc\examples\hello-world-kotlin>

The problem is that you have multiple Gradle processes that are still holding locks to your files.
You can try running gradle --stop when this happens to stop any daemons that are running in the backgorund (this usually helps).
You can also check the state of your daemons by running gradle --status. For me this outputs:
No Gradle daemons are running.
Only Daemons for the current Gradle version are displayed.
See https://docs.gradle.org/6.5/userguide/gradle_daemon.html#sec:status
If you see something there it might be a problem.
Using --no-daemon and --no-parallel might help, but they would just hide the underlying problem.
In my case when this happened I realized that I had processes running in the background because of tests never finishing. Check all your threading and/or coroutine usage for unclosed / unfinished processes.
One other case when this happened to me is when I was using ProcessBuilder to start another Java process and it didn't exit.

Just rename the " build " folder.

In my case, I experienced this error after I ran a Gradle command as the root user in Linux.
After switching back to a regular user, Gradle gave me the above error. When I tried to remove the build directory using rm -rf build/, I received a "Permission denied" error. You can solve this problem by removing the build directory as the root user.

For me the files where under a different user and the group and the permissions were not sufficient to write to the files of the directory in question.
Try checking who the user of the project files are with ls -al
If the project and the sub directories and files are under a different user. You can run sudo chown -R [new_owner] [project_folder_name] The flag -R here recursively changes owner for the sub files and sub dirs.
You can also add additional permissions to the group (if the user belongs to the group) or even change the group (if the user does not belong to the group). The basic idea is giving the user enough permission (rwx) to use files.

In Windows 10 Kill all Java TM instances by running this command on command prompt :
TASKKILL /F /IM java.exe

Or you delete your app installed on your phone and reinstall it again.This solved my problem

As I have faced similar kinds of errors during the flutter app development, I have figured out which process is blocking the running app. So I have just ended Open JDK from the Process list and then retried running the app without debug mode and it's working. The thing I learned here is that we have multiple development environments running in the background so we have to determine which process is blocking others.

Delete build folder in this path : your project\app . Then rebuild project.

If you are running windows 10, Go to task manager and end the following task
.......................
Java Platform SE binary
There might be more than one above mentioned task just end all of them and rebuild works

I went to my file system and deleted the file manually. Restarted my android

Related

Unable to delete build dir after running Sonar

I am using the SonarQube Gradle plugin version 3.0 with Gradle 6.7.1 for analysis of my Java code. This works fine and the results are uploaded to Sonar. When I do gradlew clean test sonarqube initially I have no problem. But when I run it subsequently I get the following:
java.io.IOException: Unable to delete directory 'C:\xxx\build'
Failed to delete some children. This might happen because a process has
files open or has its working directory set in the target directory.
- C:\xxx\build\sonar\findbugs\findsecbugs-plugin.jar
- C:\xxx\build\sonar\findbugs
- C:\xxx\build\sonar
This keep on failing until I kill the Gradle daemon after which I can successfully run sonarqube again.
Is there a way to get around this?

Could not create service of type ChecksumService using BuildSessionScopeServices.createChecksumService()

I am new in gradle and when I try to simple check gradle built in tasks, I get Build Failed error.
Can anybody explain what is wrong?
I only run 'gradle tasks' on cmd and get next error:
FAILURE: Build failed with an exception.
* What went wrong:
Gradle could not start your build.
> Could not create service of type ChecksumService using BuildSessionScopeServices.createChecksumService().
> Timeout waiting to lock checksums cache (M:\.gradle\checksums). It is currently in use by another Gradle instance.
Owner PID: unknown
Our PID: 14372
Owner Operation: unknown
Our operation:
Lock file: M:\.gradle\checksums\checksums.lock
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with
--scan to get full insights.
* Get more help at https://help.gradle.org
BUILD FAILED in 1m 1s
./gradlew --stop as the error happens when gradle didn't close cleanly. Such as in: Cannot lock checksums cache (/Users/.../StudioProjects/android/.gradle/7.4.2/checksums) as it has already been locked by this process.
This was a permissions issue for me.
I tried running a project on my Mac from my mounted Google Drive directory and got this error.
Moving the project to Documents worked.
FWIW, I forgot to stop the server in IntelliJ and once I did the problem went away.
For Flutter users
I faced this problem on Mac OS Monterey (M1 processor)
I solved it in the following way
Browse android/buil.gradle add or update gradle version to 7.1.2
dependencies {
classpath 'com.android.tools.build:gradle:7.1.2'. //---this
classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
}
Update distributionUrl in android/gradle/wrapper/gradle-wrapper.properties to 7.4
distributionUrl=https\://services.gradle.org/distributions/gradle-7.4-all.zip
Navigate in the terminal to the android folder and run
cd android
despues
./gradlew --stop
4.Run flutter clean and flutter pub get
flutter clean
flutter pub get
Then run flutter run
flutter run
This work for me:
Close my IDE
Go to my project directory
Search and delete all .lock files
Open the IDE, and try again
Just restart your machine. it's a cache related error

IntelliJ IDEA (2020.2): Gradle: Lock file: repository/caches/journal-1/journal-1.lock

I am working with Intellij Idea (CE)
2020.2.3
And using Gradle 6.7
Path Variables
Where in the OS exists configured, the following about Path Variables in the bash profile:
GRADLE_HOME = /Users/username/.../gradle/6.7
GRADLE_USER_HOME = /Volumes/FP27072011/gradle/repository
How you can see, customized locations
The /Users/username/.gradle directory is empty.
About Intellij Idea, its configuration for Gradle is as follows:
Same paths as the bash profile.
Note
The following figures that represents the interaction with the IDE, are based on:
/Users/username/.gradle directory empty
/Volumes/FP27072011/gradle/repository directory empty
Working with spring-framework project based on Gradle
It to have a quick discard something around there.
Ok, startup process:
Starts to Sync
A Gradle's daemon is started
After of some seconds fails with:
The error message is:
Gradle could not start your build.
> Could not create service of type FileAccessTimeJournal using GradleUserHomeScopeServices.createFileAccessTimeJournal().
> Timeout waiting to lock journal cache (/Volumes/FP27072011/gradle/repository/caches/journal-1). It is currently in use by another Gradle instance.
Owner PID: unknown
Our PID: 713
Owner Operation: unknown
Our operation:
Lock file: /Volumes/FP27072011/gradle/repository/caches/journal-1/journal-1.lock
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.
The repository directory shows the following
The /Users/username/.gradle directory shows
Observation: Until this point observe in the two previous Figures that the daemon/6.7 path/directory appears twice in the repository and .gradle directories respectively
Note: When the IDE is closed, just in that moment, in the /Users/username/.gradle directory appears this new file (registry.bin.lock) as follows:
I got this behavior even if I delete the idea-directory-installation/.gradle directory (not /Users/username/.gradle directory) and even with Invalidating Caches/Restart
What is missing, what to do?

gradle-wrapper.properties not found after clean install intellij idea 2020.1.2 community edition on windows 10

Installed clean windows10(1607) and intellij idea(2020.1.2 community edition). When i create new gradle project
Invalid Gradle JDK configuration found. Open Gradle Settings
"gradle-wrapper.properties not found".
How can I fix it?
Install gradle 6.7
sdk install gradle 6.7
brew install gradle
Go to IntelliJ and set gradle version:
On File >> Settings >> Build, Execution , Deployment >> Gradle
or
Preferences >> Gradle
In Use Gradke from specific the correct location
If IDEA is set to use the Gradle wrapper (as it is in your screenshot: "Use Gradle from:" is set to "gradle-wrapper.properties"), IDEA expects the following file structure:
Gradle wrapper JAR: [project root]/gradle/wrapper/gradle-wrapper.jar
Gradle wrapper properties: [project root]/gradle/wrapper/gradle-wrapper.properties
Gradle wrapper script: [project root]/gradlew.bat
If you are missing one of these three elements, IDEA will attempt to generate the wrapper by calling the gradle wrapper task. It will do this using the Gradle JDK, which may or may not be the project SDK (File > Settings > Build, Execution, Deployment > Build Tools > Gradle > Gradle JVM).
I'm not sure how it selects the version of Gradle it uses - I only have 6.8.3 installed on my machine, and I had my wrapper properties set to 7.0-rc-1, yet somehow it used 6.7.0 when generating the wrapper.
I tried various options for clearing the cache, but did not get the result.
Openjdk-14 installed by default and does not work. From site adoptopenjdk.net install OpenJDK 11 (LTS). When creating the project, I chose 11 version. Then the program suggested updating gradle to version 6 and it worked.
I ran into this problem a while ago when I upgraded to intellij 2020.* The first time I created a new project there was no problem: gradle daemon did its work and the project was created with no problems.
In my case, the project would start a new gradle daemon, and attempt to build the project, would get rejected by windows Security, and nothing would happen, so intellij goes ahead and starts another (unsuccessful) daemon. Soon, I had 20+ gradle daemon processes running on my system, all of them doing nothing.
So, it looks like intellij has messed in enabling that it places the appropriate permissions it requires for these folders that it depends on to run properly. So, you need to manually give these permissions, and then things (should) work.
The real issue here is security on your machine: either a virus checker or the security software, Windows Security on Windows 10, for example. The first time you make a project, Intellij goes and produces a number of folders that they need access to.
However, once these folders are available, for whatever, intellij doesn't make sure to give itself access.
On windows 10, in AppData, you'll find several folders required by Intellij to produce, in my case, produce gradle projects.
Try finding the various folders that Intellij has produced on your system, and give them exceptions on your virus checker and on whatever firewall/security software programs that may block access.

Gradle Could not create service of type InitScriptHandler using BuildScopeServices.createInitScriptHandler()

I used gradle build command in Centos 7 terminal and I got output:
FAILURE: Build failed with an exception.
* What went wrong:
Could not create service of type InitScriptHandler using BuildScopeServices.createInitScriptHandler().
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
For me, killing the Gradle daemon (gradle --stop) really helped and fixed the issue.
Try setting your GRADLE_USER_HOME variable to a folder where you have valid access. Then this error will go away.
For ex: I faced the same issue today while I was running gradle clean command on a new slave machine.
My Gradle version was 2.3.
With --stacktrace, I came to know it was trying to create .gradle folder for storing Gradle's cache data (while I invoked Gradle to run clean task on the slave) and it was trying to create that folder under /some/location/where/gradle/exists OR some /path/location/xxx/yyy where the user which was running Gradle on the slave machine didn't have valid access to write (create folder/files).
i.e. the user which I used to connect from Jenkins machine to the slave didn't have write access to touch/mkdir anything in the default location (where Gradle thought, OK I should create .gradle folder here).
To fix it, I added the above GRADLE_USER_HOME variable in the slave's ENVIRONMENT Variable section. Now, as I have valid access in my home directory, I was OK.
Setting:
GRADLE_USER_HOME=~/gradle_2_3_cache/.gradle
resolved the issue.
You can set it to ~/.gradle as well. But I set it under a custom folder inside my ~ home directory (gradle_2_3_cache). This will help me in case I have another job/build run running on the same Slave machine but with a different Gradle version for ex: 2.5 etc version and if I want the .gradle cache for 2.3 and 2.5/x version in separate folders.
NOTE: When using parallel section within Jenkinsfile, it's best to avoid Gradle greatness (i.e. using same Gradle's cache i.e. using same GRADLE_USER_HOME) as otherwise, you'll land into a mine of interesting issues as listed here: Jenkins - java.lang.IllegalArgumentException: Last unit does not have enough valid bits & Gradle error: Task 'null' not found in root project
The Problem solved by simply using "sudo" and giving access to gradle to create a folder and write cache. use:
sudo ./gradlew
If you using wrapper gradlew, in root make directory .gradle_new
mkdir .gradle_new
chmod -R 777 .gradle_new
and run gradlew with arguments:
--project-cache-dir .gradle_new
Restarting the machine solved the issue.
I had the same problem.
For me it worked after I exclude the .gradle folder if you can not delete try to rename.
If you have just updated your JDK version and you have set up a Gradle wrapper in your project, you may want to double-check the wrapper version supports your new JDK. If not, consider removing wrapper-related files from the project (gradlew, gradlew.bat and gradle/wrapper/*) and re-generating them with the Gradle CLI, like so:
gradle wrapper --gradle-version <new-version-number>
e.g. gradle wrapper --gradle-version 4.10.2
This of course assumes your Gradle installation is up-to-date. If not, you will want to update that first.
I got the same error, got rid of it by using the correct version of Java / JDK. I was trying to build a Java 8 project with the Java 11 JDK. Check which version of Java JDK you are using.
To develop projects with different Java versions in parallel I now use jEnv to manage the different JDK versions: http://www.jenv.be/
This is a permission issue.
do a
gradle wrapper --stacktrace
you should see something like this
Failed to create parent directory '/home/cloud_user/my-project/gradle' when creating directory '/home/cloud_user/my-project/gradle/wrapper'
the user, cloud_user, has no permission to the directory
make cloud_user owner of the folder
sudo chown -R cloud_user:cloud_user /home/cloud_user/my-project/
I got this error when running code in IntelliJ Idea, and
gradle --stop
really not helped, as it said that "No Gradle daemons are running."
But simple kill of all gradle processes helped:
ps aux | grep gradle
kill -9 $PID
Permission issue. This fixed the issue for me:
sudo chown -R $USER dir
For me this was to do with Java versions. I have Java 10 installed and as the default Java on my system. Setting a JAVA_HOME pointing at Java 8 was sufficient for the project (graphql-spring-boot) to build.
If using the "Invoke Gradle script" build step, click on Advanced to reveal additional options. Locate "Force GRADLE_USER_HOME to use workspace" and check it.
If anyone is still struggling with this, my issue was caused by Microsoft preventing Java from running due to Controlled Folder Access security restrictions.
I didn't get the popup notification since my computer is set to Do Not Disturb Mode. Once I allowed access, Gradle ran fine.
For future reference.
I had the same problem, the issue was that the antivirus was blocking OpenJdk platform binary and java.exe which prevented android studio from being able to modify the files
I ran into this exception when trying to build a project that was mounted as read-only filesystem in a VM. The project set its own gradle cache so changing GRADLE_USER_HOME did not work. I had to change the filesystem to be read/write.
You Just Have to Run it under the super user (sudo ....) it works for me
If you run Docker-in-Docker and mount the project directory from docker host directly to docker container:
-v ${PWD}:/path_to_project -w /path_to_project
the owners are different and docker container user (either gradle or root) can't override/delete ./buildSrc/build or ./build/
One of the fixes - copy the sources inside the container to temporary directory and build there.
Smth like this (first mounted to project, but then copied to project-copy to "decouple" with the host system real files and run the build in the copy):
docker run -v "${PWD}":/home/gradle/project -w /home/gradle/project-copy \
--rm \
--entrypoint sh \
gradle:5.5.1-jdk11 \
-- -c "cp -r -T /home/gradle/project ./ && ./gradlew build"
In my case I had bad credentials to private Maven repository. JIdea does not show the inner exception but running gradle build reveals the problem immediately.
I used a Gradle project in Eclipse, Eclipse's Gradle was giving that error. When I installed NetBeans and its Gradle Plugin, the problem has gone, project was building okay. Another way to circumvent this error was using commandline ./gradlew , project also built successfully.
It seems that Eclipse's era is over, they appear to be unable to follow the progress.
This can happen if you run Gradle commands from separate terminals at the same time - I assume Gradle somehow locks ~/.gradle when it is running to prevent any problems.
I had that same error, while running gradle with java 14 (openjdk) as my default java implementation. Setting default java back to java 8 solved the issue
sudo update-alternatives --auto java
just run (taskkill /im java.exe /f) in command
In my case the error was different but I landed here, my error was:
Could not create service of type ExecutionHistoryStore using ExecutionGradleServices.createExecutionHistoryStore().
> Timeout waiting to lock execution history cache (/Volumes/Extreme SSD/FlutterProject/test/android/.gradle/6.7/executionHistory). It is currently in use by another Gradle instance.
Owner PID: unknown
Our PID: 94001
Owner Operation: unknown
Our operation:
Lock file: /Volumes/Extreme SSD/FlutterProject/test/android/.gradle/6.7/executionHistory/executionHistory.lock
It happens when you try to run flutter run from two separate terminals.
So I solved it by executing cd <projectPath> && flutter run from the active terminal which I was using first.
Basically, while executing some Gradle command, in this case building an android file, the terminal locks down some Gradle PID, so either you stop them or just simply use that terminal.
in my case manual removing the .gradle and .idea folders helped me
you can find them in the Android Studio if Project view selected
after this just clean and rebuild app
kill -9 'pid' solved the issue. pid can be found in the error log
To fix this issue, restarting your PC is the main solution
I got the same issue and for me worked below command.
./gradlew --stop
After that restart my system and wipe data of simulator and run again everything works fine.

Resources