Error:Failed to capture snapshot of output files for task 'transformClassesWithDexForDebug' property 'streamOutputFolder' during up-to-date check.
Failed to create MD5 hash for file 'C:\Users\GauravZone\AndroidStudioProjects\ZopporoStore\app\build\intermediates\transforms\dex\debug\folders\1000\10000\instant-run_83dbc65f4e3a4cd278807c089695c6b352698791\classes.dex'.
I am getting these errors don't know why, all application working fine earlier but suddenly getting this error in my all applications when try to run projects
Disable your antivirus, and it will work.
This is a Gradle issue and you can find it here.
So as of now just disable Instant Run.
It worked for me.
In android studio,
Open the Settings or Preferences dialog: On Windows or Linux, select File >
Settings from the menu bar. On Mac OSX, select Android Studio > Preferences from the menu bar.
Navigate to Build, Execution, Deployment > Instant Run.
Uncheck The box next to Restart activity on code changes.
I Solved this issue in my react-native project by removing all npm cache
1.npm cache clean --force
2.react-native run-android
Set multiDexEnabled true in your buildType release class in your build.gradle file
Error:Failed to capture snapshot of output files for task 'transformClassesWithDexForDebug' property 'streamOutputFolder' during up-to-date check ::
Solution: Just rebuild the project and then sync the project with Gradle files, as mention below.
1. Click on Build -> Rebuild Project
2. Click on Tools -> Android -> Sync Project with Gradle Files
I was also getting the same error.
But when i disabled Instant Run, Gradle started building.
But i agree with those who think this is a Gradle issue.
And until it gets resolve, disable Instant Run.
follows steps: instant run(file->setting->build,execution,deployment->uncheck instant run) then compile it work properly.
I've run into this issue after updating Android Plugin for Gradle to version 2.3.1. Rollback to version 2.3.0 helped for me, try setting
classpath 'com.android.tools.build:gradle:2.3.0' in your top level gradle.build file.
For me i had this error when i use my device as emulator . I did like that and it works :
1.adb reverse tcp:8081 tcp:8081
2.react-native start --reset-cache
3.react-native run-android
I faced the same issue and by disabling the QuickHeal Antivirus's virus protection, it worked for me fine.
Problem is gradle version. Update the gradle version to latest to resolve this kind of issues.
I have tried 'com.android.tools.build:gradle:3.3.2' is working for me. previously it was '3.1.0'
This issue comes when there are more than one process which is doing something with a file in your disk (whether it's your Jenkins job's workspace or Gradle's cache path or Gradle build folder that it creates) where these processes are trying to do something with a file and holds a lock.
If you have anti-virus, you may see this. Un-installing may resolve the issue but then you don't have anti-virus (it's better if you can set something in anti-virus to scan files periodically).
In my case, this issue only comes when I have a Jenkinsfile pipeline, where I'm running Gradle task for 3-5 projects in parallel (let's say Gradle is running an rpm task or build task) and when I'm running concurrent runs of this pipeline.
As you can see my pipeline code (Jenkinsfile Pipeline DSL: How to Show Multi-Columns in Jobs dashboard GUI - For all Dynamically created stages - When within PIPELINE section) is creating dynamic stage(s) and when I call it within pipeline section, I use parallel to run N no. of projects (that I can define in a hash/array) gradle tasks in parallel.
What I noticed is, all these runs (running in parallel) is running using my user-id (or some service account) and they are all using same Gradle version (4.3.1 in my case) and thus, they are using the same cache.
Running them in parallel alone --OR-- more realistic case would be running multiple pipeline runs of this pipeline job (running 5 project's gradle task in parallel) would probably land into this LOCK file condition.
You can probably solve this by setting a unique GRADLE_USER_HOME="~${WORKSPACE}/.cache"
(i.e. use Jenkins job's workspace which is dynamically created and is unique) or even better by setting Gradle user home as:
dt_stamp=`date +%s`; ## set and pass this dt_stamp variable for Gradle user home before calling Gradle.
GRADLE_USER_HOME="~${WORKSPACE}/${dt}/.cache"`
This way, at least in Gradle's cache, you won't see any issues due to lock files (NOTE: You'll not be able to efficiently use Gradle's cache concept of being lazy (or not fetching artifacts/library dependencies from a binary repository like Artifactory each time) while using Gradle among many projects if you set GRADLE_USER_HOME to a dynamic folder value as it'd be like running gradle after clearing it's cache each time (for some it's OK if your build doesn't take much time and it's more cleaner way to build as well)).
When I tried to run just one pipeline run (which runs all 5 project's gradle task in paralle), the pipeline succeeds all the time.
Running multiple instances of the pipeline job (running 5 parallel builds in each run) lands into this file LOCK issue.
Error mesg when I ran many concurrent pipeline runs (each pipeline run - runs Gradle tasks in parallel on 5 different projects).
FAILURE: Build failed with an exception.
* What went wrong:
Failed to capture snapshot of output files for task ':rpm' property 'archivePath' during up-to-date check.
> Timeout waiting to lock file hash cache (/view/user123456_Team_Tools/vobs/space/test/folder1/Project1of5/.gradle/4.3.1/fileHashes). It is currently in use by another Gradle instance.
Owner PID: 29003
Our PID: 903
Owner Operation:
Our operation:
Lock file: /view/user123456_Team_Tools/vobs/space/test/folder1/Project1of5/.gradle/4.3.1/fileHashes/fileHashes.lock
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
-- OR --
You may also get this kind of error where a process is not able to delete a directory (while Gradle is in progress as the target folder/file may be in use by some other process)
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':clean'.
> Unable to delete directory: /view/user123456_Team_Tools/vobs/space/test/folder1/project2of5/build/classes/java/main/org/syntax/jedit
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
* Get more help at https://help.gradle.org
If you are really lucky (like me), then you'll probably hit this error as well:
Jenkins - java.lang.IllegalArgumentException: Last unit does not have enough valid bits &
Gradle error: Task 'null' not found in root project
See here for more details: Jenkins - java.lang.IllegalArgumentException: Last unit does not have enough valid bits & Gradle error: Task 'null' not found in root project
Clearing the cache does fix it. But only once, if you stop the project and re run it, you ll end up with same error again.
Doing following fixes it for me,
cd android
./gradlew clean
react-native start --reset-cache
npm clean cache --force
Next, open two different terminals,
Run react-native start
in one terminal and in second,
Run react-native run-android
Hope it'll work for you as well.
Related
(using android,
openjdk-11.0.13_8
node v16.13.2
react-native 0.67.0)
i created a barebone react-native project with
npx react-native init testapp
then signed it according to official react-native documentation
then tried to create the release-variant with npx react-native run-android --variant=release
now i get BUILD SUCCESSFUL message and got apk, and it installs and works in my physical device...
BUT, i got a lot of gradle problem-warning ...here is one sample..
Task :app:processReleaseManifestForPackage Execution optimizations have been disabled for task ':app:processReleaseManifestForPackage' to
ensure correctness due to the following reasons:
Gradle detected a problem with the following location: 'D:\testapp\android\app\build\intermediates\merged_manifests\release'.
Reason: Task ':app:processReleaseManifestForPackage' uses this output
of task ':app:copyReleaseBundledJs' without declaring an explicit or
implicit dependency. This can lead to incorrect results being
produced, depending on what order the tasks are executed. Please refer
to
https://docs.gradle.org/7.2/userguide/validation_problems.html#implicit_dependency
for more details about this problem.
this same problem-warning is repeated for many other tasks!!...
NB i havent added any packages or changed any source code.. its the barebone app coming with react-native!... so how do i solve this issue?.. how to fix my settings so that this warning can be removed...
(i copied one of these tasks-names and did a text-search inside all files in my project directory to find out where its mentioned...but shockingly, its not mentioned anywhere!!!...so where are all these problem-warnings coming from? and how can we get a neat gradle build?)
this same warning is repeated in lots of lines in gradle output for other tasks too, such as:
Task :app:compressReleaseAssets
Task :app:processReleaseManifestForPackage
etc.. etc..
My setup:
Android Gradle Plugin 3.5.0
Gradle to 5.5.1
100+ Gradle modules
lot of generated code (mostly Dagger + data binding)
When I checkout a branch which causes changes in generated code then usually I have to wipe out whole .gradle/caches directory to make the build succeed. Otherwise gradle build system tries to resolve some old generated code.
clean and cleanBuildCache don't help. Also a side note: so far I've been a happy user but since we updated tools to these versions then build caching stopped working properly. Any tips?
EDIT: Please note that not every change in generated code breaks the cache. It's nondeterministic for me so far.
Disclaimer: I'm a java developer and am not familiar with the Android plugin
The clean task won't remove entries from the build cache. The cache key is derived from the task inputs and outputs. If you haven't declared all of the task inputs correctly then the cache key won't be correct
If (for example) your "generate" task needs a template, some xml and a system property to generate the sources you will need to declare all three (template, xml and syspop) as task inputs to the "generate" task. Any output directory(s) will obviously need to be declared as a task output.
The last thing to consider is that the "generate" task is correctly wired into Gradle's DAG. Eg the "compileJava" task should "dependsOn" your "generate" task (or whatever the android equivalent task is)
I profile my build follwings instruction in Android:
gradlew --profile --recompile-scripts --offline --rerun-tasks assembleFlavorDebug
I found "UI:platformAttrExtractor" takes a long time, please see the screenshot.
I don't understand what "platformAttrExtractor" is and how can I remove it to save build time?
I have the sample "problem". What I noticed is that by specifying the --offline command line option for gradle, build time (and specifically the time taken by the platformAttrExtractor) task is reduced considerably
I have an Android Studio App that now has close to 100 "productFlavors" associated with it, of course all defined in the build.gradle. I would like to build them from command line since building them one at a time in the IDE would be a nightmare. My issue arises when I run into an error in the middle of building them using the command line gradlew.bat assembleRelease. Once I fix the error I would like to start building at the point of failure (maybe 50 flavors into the build) rather than at the beginning. Is there a way to do that with Gradle? With Ant I was forced to comment them out, I am hoping there is a better way with Gradle since the structure is much more complicated in the file.
UPDATE
I finally went with a solution that encompassed Gradle and Ant (yucky but it works). Basically I wanted to build on of my 100 White Label flavors, with a prefix of the version, and then copy it to the deliver APK without the version. To do this my ANT script looks like:
#!/bin/sh
DEPLOY_DIR=C:/AndroidBuilds/MyCompany.Build
VERSION="63"
NAME="WhiteLabel1"
DEPLOY_FOLDER="whitelabel1"
APK_NAME=$NAME$".apk"
gradlew assemble$NAME
cp $DEPLOY_DIR/$DEPLOY_FOLDER/$VERSION"-"$APK_NAME $DEPLOY_DIR/$DEPLOY_FOLDER/$APK_NAME
NAME="WhiteLabel2"
DEPLOY_FOLDER="whitelabel2"
APK_NAME=$NAME$".apk"
gradlew assemble$NAME
cp $DEPLOY_DIR/$DEPLOY_FOLDER/$VERSION"-"$APK_NAME $DEPLOY_DIR/$DEPLOY_FOLDER/$APK_NAME
This results in 2 APKs being generated, 63-WhiteLabel1.APK and 63-WhiteLabel2.APK, which are then copied to their respective deploy directories as WhiteLabel1.APK and WhiteLabel2.APK
I suppose if you are clever you could make this take parameters to run just the one you want, but Android Studio does a pretty decent job of that.
You can't specifically do that, but you can work around the issue and fix it with some script-magic.
If you have a build type called Release, and a flavor called Iron, you could run:
gradlew.bat assembleIronRelease
So you could write a script that would run through a loop of all flavors, and if it fails, it would tell you which one failed. You can then fix the error, and start the script again, telling it to start at X flavor (you would have to write the logic to tell it where to start though).
Just updated to Android Studio 0.8.2 and I'm suddenly getting ClassNotFoundException on launch for the main activity when one of my apps is built with 0.8.2.
The app is in version control (Git) so I've checked out old builds and they are now exhibiting the same symptom upon execution and they were definitely working just fine when built with 0.8.1.
I've tried clean rebuilds, gradle syncing, manually deleting build/ and, .gradle/ dirs, closing & reopening Android Studio etc. - I've checked out various old builds of my project and tested the APK on several Android devices, the issue is 100% reproducible with both Debug and Release builds.
Strangely, although this is 100% reproducible for this particular project, I have another project which is building and executing just fine.
I've pulled apart the APK that is output from Android Studio 0.8.2 with apktool, and the class is definitely there.
$ pwd
/Users/ben/Development/go-android/Go/build/outputs/apk/Go-debug/smali/au/com/glassechidna/go/content
$ ls
AddTripFragment$1.smali CreateTripFragment$OnQueryTextListener$1.smali CreateTripFragment.smali MainActivity.smali
AddTripFragment.smali CreateTripFragment$OnQueryTextListener.smali GoActivity.smali TrainTimeFragment$1.smali
CreateTripActivity.smali CreateTripFragment$OnSuggestionListener.smali GoApplication.smali TrainTimeFragment.smali
CreateTripFragment$1.smali CreateTripFragment$StopCursor.smali MainActivity$PagerAdapter.smali TripFragment.smali
Stacktrace: https://gist.github.com/Benjamin-Dobell/a77bd8fffb03ddb37ff1
Manifest: https://gist.github.com/Benjamin-Dobell/ca7ee54d7562a0feab0c
Go/build.gradle[1]: https://gist.github.com/Benjamin-Dobell/f9a3a39d6f141e412dac
build.gradle[1]: https://gist.github.com/Benjamin-Dobell/2db744dd89e487325b65
MainActivity.java[2]: https://gist.github.com/Benjamin-Dobell/11a6335f56b6ababeeb4
Any ideas?
[1] Taken from one of the oldest commits, as it has less dependencies etc. cluttering stuff up. However, the issue is still 100% reproducible for this commit.
[2] Just the declaration.
Cleaning from CLI seems to have resolved the issue.
Props to #yogurtearl for pointing me in the right direction.
$ ./gradlew clean
Relying on packaging to define the extension of the main artifact has been deprecated and is scheduled to be removed in Gradle 2.0
:Go:clean
BUILD SUCCESSFUL
Total time: 3.906 secs
$ ./gradlew assembleDebug
Relying on packaging to define the extension of the main artifact has been deprecated and is scheduled to be removed in Gradle 2.0
:Go:preBuild
:Go:compileDebugNdk
:Go:preDebugBuild
:Go:checkDebugManifest
:Go:preReleaseBuild
:Go:prepareComAndroidSupportSupportV42000Library UP-TO-DATE
:Go:prepareDebugDependencies
:Go:compileDebugAidl
:Go:compileDebugRenderscript
:Go:generateDebugBuildConfig
:Go:generateDebugAssets UP-TO-DATE
:Go:mergeDebugAssets
:Go:generateDebugResValues UP-TO-DATE
:Go:generateDebugResources
:Go:mergeDebugResources
:Go:processDebugManifest
:Go:processDebugResources
:Go:generateDebugSources
:Go:compileDebugJava
:Go:preDexDebug
:Go:dexDebug
:Go:processDebugJavaRes UP-TO-DATE
:Go:validateDebugSigning
:Go:packageDebug
:Go:zipalignDebug
:Go:assembleDebug
BUILD SUCCESSFUL
Total time: 10.64 secs
$ adb uninstall au.com.glassechidna.go.debug
Success
$ adb install Go/build/outputs/apk/Go-debug.apk
8553 KB/s (323343 bytes in 0.036s)
pkg: /data/local/tmp/Go-debug.apk
Success
Update
Since running the gradlew commands above I can now clean and build just fine in Android Studio. Consequently, it would seem that Android Studio wasn't cleaning properly and that manually deleting build/ and .gradle/ directories wasn't sufficient either.
Now, I just need to understand why this worked and why cleaning and building in Android Studio didn't...
If you know about any additional state gradle/gradlew stores elsewhere that could be the culprit, I'd love to hear about it via a comment.
Update 2
This issue has kept occurring for me on my Mac. I've noticed that when I build in Android Studio the "preDexDebug" task generated several warnings as follows:
objc[49452]: Class JavaLaunchHelper is implemented in both /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/bin/java and /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home/jre/lib/libinstrument.dylib. One of the two will be used. Which one is undefined.
Comparing a good APK and a bad one I could see that some of the generated DEX'd classes vary quite significantly between the two APKs. Unfortunately I don't yet know a solution to the problem (I'm stuck building with the Gradle Wrapper from CLI).