Running into the Timeout waiting to lock journal cache error when building a Flutter application on Android is a frustrating roadblock. It typically appears right after you hit the Run button in Android Studio, halting the Gradle build before your emulator or physical device even boots the app.

In this guide, we'll explain why this lock contention happens, how to identify and kill the orphaned process holding the lock on Windows, and whether it's safe to manually delete the lock file.

Understanding the Error

The core message inside your stack trace states:

Could not create service of type FileAccessTimeJournal using GradleUserHomeScopeServices.createFileAccessTimeJournal().
> Timeout waiting to lock journal cache (C:\Users\<User>\.gradle\caches\journal-1).
  It is currently in use by another Gradle instance.
  Owner PID: 19508
  Our PID: 23252

Gradle uses file locks in the .gradle/caches directory to prevent multiple daemon instances from writing to cache metadata at the same time. The journal-1 directory specifically tracks file access timestamps for cache cleanup.

When you run .\gradlew --status, it only displays Gradle daemons matching the exact Gradle version configured in your current project wrapper. If an older daemon, a lingering Kotlin daemon, an Android Studio background sync worker, or a crashed JVM process holds the lock, Gradle will wait until it times out.

Step 1: Identify and Terminate the Blocking Process

The error message handily gives you the exact process identifier (PID) holding the lock: Owner PID: 19508 (replace this with the PID from your specific error output).

Check the PID on Windows

Open PowerShell or Command Prompt as Administrator and run the following command to check if that process is still alive:

tasklist /FI "PID eq 19508"

If the command returns a process (often a lingering java.exe or jbr.exe), terminate it directly:

taskkill /PID 19508 /F

Kill All Lingering Java / Gradle Processes

Often, stopping just one daemon leaves another hanging in the background. You can stop all Gradle daemons across all versions using:

# Stop via Gradle wrapper
.\gradlew --stop

# Or kill all Java processes (Warning: will close Android Studio and other Java apps)
taskkill /F /IM java.exe
taskkill /F /IM jbr.exe

Step 2: Is It Safe to Delete journal-1.lock?

Yes, absolutely.

The files inside ~/.gradle/caches/journal-1 contain cache metadata (specifically access journal entries used by Gradle's garbage collection to know when cache files were last read). Deleting lock files or the entire journal-1 directory will not corrupt your project or dependencies. Gradle will simply recreate them on the next run.

Before deleting, ensure no active builds or IDE background syncs are running. Then execute:

# Remove the lock file directly
Remove-Item "$HOME\.gradle\caches\journal-1\journal-1.lock" -Force

# Alternatively, remove the entire journal directory
Remove-Item "$HOME\.gradle\caches\journal-1" -Recurse -Force

If Windows reports that the file is in use and refuses deletion, a background Java process is still holding it. Use the taskkill commands above or restart your machine.

Step 3: Clean Flutter & Rebuild

Once the orphaned process is killed and the stale lock file is cleared, reset your Flutter build environment from your project root:

flutter clean
flutter pub get

Now restart Android Studio, launch your emulator, and click the Run button again. The build should initialize a fresh daemon and proceed smoothly without cache lock conflicts.

How to Prevent This Issue in the Future

  • Avoid abrupt IDE closures: Force closing Android Studio or terminating terminals during a build can cause the Gradle daemon to orphan its file locks.
  • Adjust Gradle Daemon Settings: If you frequently encounter memory pressure or runaway daemons on Windows, consider adding org.gradle.daemon.idletimeout=60000 to your global C:\Users\<User>\.gradle\gradle.properties file to prune idle daemons after 1 minute.
  • Exclude .gradle from Anti-Virus Real-Time Scanning: On Windows, aggressive antivirus scanners (including Windows Defender) can hold transient locks on files in ~/.gradle/caches, causing Gradle to falsely believe another instance is using them. Add an exclusion for the %USERPROFILE%\.gradle folder to improve build speeds and reduce lock issues.