I've looked into other questions relating to grade issues and I cannot find anything that relates to the cause I am seeing.
I am learning to develop android applications as part of my independent study programming course. Because this is being done on a school computer, I have been dealing with some odd behavior from android studio.
Most of the issues I was able to fix, but there is one that I cannot find a solution to, and it is locking me out of any debugging tools and the Android Device Manager.
Almost immediately after loading a project, I get an error saying "grade sync failed" and am pointed towards a massive stack dump. Gradle attempts to create a file lock on some file that I cannot identify. An UnsupportedOperationException is thrown with the message "File locking is not supported".
So I came up with a possible solution. This is almost certainly being caused by the VM nature of the environment I'm using, so would moving the android SDK and gradle tools to my flash drive fix the problem? (64G, file size isn't an issue). Where are those grade files stored and how can I instruct Android studio to their new location?
Side note that I do not have any administrative permissions.
Related
So basically I haven't opened my Android Studio project for almost a year and this time was the time for it to be opened and built. After updating Android Studio and all of the project's plugins, I finally reach this error:
Execution failed for task ':app:processDebugResources'.
> Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
> Failed to transform play-services-base-17.1.0.aar (com.google.android.gms:play-services-base:17.1.0) to match attributes {artifactType=android-compiled-dependencies-resources, org.gradle.status=release}.
> Execution failed for AarResourcesCompilerTransform: C:\Users\Me\.gradle\caches\transforms-2\files-2.1\d92a27efcac738b4f280b9ad0c07bda7\jetified-play-services-base-17.1.0.
> AAPT2 aapt2-4.1.1-6503028-windows Daemon #0: Unexpected error during compile 'C:\Users\Me\.gradle\caches\transforms-2\files-2.1\d92a27efcac738b4f280b9ad0c07bda7\jetified-play-services-base-17.1.0\res\drawable-xhdpi-v4\common_google_signin_btn_text_dark_normal_background.9.png', attempting to stop daemon.
This should not happen under normal circumstances, please file an issue if it does.
I hope someone could help me resolve this issue. Thanks in advance.
update 07 May 2021
With Android Studio 4.2 and the corresponding android gradle plugin v4.2.0 (which requires gradle 6.7.1) the build now works for me also on my older AMD.
So I guess the problem has been fixed :)
(would be great if someone else can confirm via comment)
original answer
Hi have exactly the same issue.
The project builds on 2 of 3 tested PCs. The only difference I see is, that is not working on an older AMD processor. The PCs its working with have both Intel CPUs (an older i7, 2. Gen, and a new i7). All three PCs are running with Windows 10 Pro.
My dev environment is set up equally on all 3 PCs.
I hope this information helps to find a maybe better solution.
The only solution I found is to go back to a previous version of the Gradle plugin and Gradle itself.
In gradle-wrapper properties I defined Gradle version 6.1.1
distributionUrl=https://services.gradle.org/distributions/gradle-6.1.1-all.zip
And in the project build.gradle I set version 4.0.2
classpath 'com.android.tools.build:gradle:4.0.2'
Try:
Invalidate Cache / Restart
Clean Project
Rebuild Project
Along same lines: I too am getting this same error but oddly, my project is stored on OneDrive so I can access it/modify it from different locations. The SAME project builds, installs and runs with no issue at one location (with my phone connected to computer), but the error shown above takes place when accessing the same files from the other location (with the same phone connected).
The same version of Android Studio is being used at both locations as well. This was not an issue with this same project a few days ago (i.e. - it ran properly from both locations until recently)
The solution offered previously here does not fix the issue.
Would not normally put this response here but thought perhaps my experience with the same error message could help shed some light on what is happening.
the same topic is discussed here. I have the same behavior the same project builds without a problem on i7. But produces an error on an old AMD processor.
I have read a question/answer which states Flutter Web is a fork of Flutter and so one Android Studio (or VScode) project can't be built to handle both.
I'm not an expert on either (obviously) but I don't understand why the fact the libraries are forked implicitly precludes one from using the same source code for the different destinations.
Has anyone done so? And, if so, is there a skeletal project anyone would care to share?
So I'm pretty sure this question will get closed, but I just want to see if anyone else is experiencing this issue. I'm trying to migrate over to Android Studio, as it just came out of beta and Google announced that they essentially won't be supporting ADT for Eclipse from now on. So far, I'm noticing that the application as a whole is extremely slow and bordering on unresponsive. With every click, I have to deal with extreme latency, which is really making this tool hard to use. After doing a quick check, I've noticed that this one application is using nearly 1GB of memory and I haven't even begun to migrate my project to it! Is anyone else experiencing something like this and does anyone have an idea of what I can do to speed this up? If this doesn't improve then I'll be forced to stop migrating and continue using the Eclipse ADT until something has been done. I'm running Windows 7x64
Did you notice if the IDE is stuck doing something by looking at bottom right status?
Make sure you are using bundled Gradle, also Do you have have many dependencies? You might want to check if its getting stuck because it is constantly looking for those dependencies.
I'm using TypeScript in Visual Studio 2012 and when I have to refactor my code and must temporarily introduce a lot of errors visual studio become unresponsive for up to a minute, very often, making it impossible to refactor efficiently.
How can I turn this off temporarily until I feel like I've patched the majority of errors?
It shouldn't be that bad, else it's a bug. Unfortunately with the latest release there is an issue being investigated. See https://typescript.codeplex.com/workitem/779 . If it's not this issue, then please log another describing how to reproduce the issue you are seeing reliably, and it will get investigated.
There is a fix checked in for the above issue that is being tested currently (see https://typescript.codeplex.com/SourceControl/changeset/e44dbae94e04 ). If you are feeling lucky and don't want to wait for the next update, you could always replace this line of code yourself in the typescriptServices.js file and see if it resolves your issue.
See http://blogs.msdn.com/b/typescript/archive/2013/01/29/trying-the-latest-typescript-build.aspx for details on the location of the file to update.
I am working on a program which I suspect to have one or more memory leaks. Some other answer on Stack Overflow told me to try DevPartner BoundsChecker (one of many others I tried).
Now when I run my program with BoundsChecker running, it will break. At some point, a Windows file open dialog will get initiated and right before that actually happens, a non-continuable breakpoint gets triggered. This only happens with BoundsChecker running.
According to the Console Output, the last thing that the program is trying to do is to load C:\Windows\SysWOW64\slc.dll which DevPartner recognizes as the "Microsoft Software Licensing Client Dll". Since we do not use any software licensing in that particular program, this must somehow be related to the dialog window that is supposed to be opened.
Anyway, I really want to find those memory leaks and for that, I need to open that file. Is there a possibility to tell BoundsChecker not to break my program because of this issue (whatever that issue might be)?
Basti, there was known bug in the 9.x versions of BoundsChecker with the MFC file open prompt. If you post your DPS and Visual Studio versions I might be able to tell you which patch or update you need to get around this. On the other hand if you really are tripping up in a licensing guard DLL, BoundsChecker may be exciting some anti-tamper logic in it. I have seen DPS raise the anti-tamper logic in other Micro Focus products. If it is the latter you would need to raise a case with Micro Focus customer care and provide a repro test sample. Shameless plug: I work on the DevPartner team. We are releasing DPS 10.5 with BoundsChecker for x64 application support on February 4, 2011. Please see if this version corrects your issue once the download eval is posted.