I have a m1 macbook air, when I try compile the app for android a Gradle daemon tries to start, however sometimes (very often) it will hang:
If I quit the process (via Cmd + C) and try to build the app again, then I get a message one gradle daemon cannot be re-used because it's busy and another one tries to start, which also hangs...
It's super annoying, anyone else facing this problem? I'm using azul JDK (because it runs native on arm), but I don't think this is a problem with java
When I run ./gradlew --status that also hangs, the only solution seems to restart my machine a bunch of times
As it turns out the issue was Raycast, I started vscode from a script run by it (and ran the build command from the integrated vscode terminal), it seems gradle pipes the output of the daemons through the parent process and raycast doesn't play nicely with this model.
There 2 workarounds:
Don't call gradle/android build from any subprocess (in my case raycast -> vscode), just a plain terminal will work
Kill the parent process (again in my case raycast) before running the build command
Related
Android Studio can't start the debugger if I use C code though JNI.
Running it normally works well, but the debugger doesn't even start, regardless if I'm debugging Kotlin or C code.
It throws a message Debugger process finished with exit code 127. Rerun 'app'
And the only detail it gave me is com.intellij.execution.ExecutionFinishedException: Execution finished.
Here I set up a simple github repository to replicate the error: https://github.com/perojas3/Android-JNI-debug-bug-example. It simply calls C code to get a string and then displays it in a toast.
And here I set up an small youtube video displaying the bug the way it is happening: https://youtu.be/8jIL5yqP7m8
I'm using Manjaro Linux right now.
I had the same issue and installing libncurses5 package solved it.
If using Ubuntu: sudo apt install libncurses5 and launch the debugger again (no android studio restart required).
I also had this issue.
I was able to run and debug my code normally, but for some reason I started to get this crash while running on debugging mode:
Debugger process finished with exit code 127
After playing a lot with Android Studio's settings and Edit Configurations, clearing caches, restarting both Android Studio and the computer and many other things, nothing was helpful.
I struggled with it a lot and the fact that there're no discussions anywhere about it annoyed me a lot, so having no information online together with the previous feeling about it happening after upgrading to Android Studio 4.2, made me think maybe it's a new issue raised in Android Studio's new 4.2 version.
So, I decided to download Android Studio 4.1.3 and give it a try. It worked like a magic and I can finally debug my code :)
When running a unit test from within Android Studio on a mac, I can manually run it 1 time, then it fails with the error "Could not execute build using Gradle distribution 'https://services.gadles.org/distributions/gradle-4.10-all.zip'".
I can run it again by deleting my .gradle folder and restarting Android Studio, but this isn't sustainable for testing.
When running the unit test manually with ./gradlew, it works every time but that doesn't lend itself well to debugging.
This applies to even the most simple of tests.
Wanted to add specific error message from the Build tab. This happens on a simple test, with the first time running it working, and the second time running it not working:
#Test
fun testTrue(){
assertTrue(true)
}
FAILURE: Build failed with an exception.
* What went wrong:
java.lang.NullPointerException (no error message)
So, I have a suspect that could be the cause, and a hack that makes it work in the short term.
First, the hack. As many other people have answered, deleting the .gradle folder resolves the issue for me temporarily. However, that is a bit over overkill and forces a complete build every time you run it.
You can get around this partially by deleting just the fileHashes.bin and fileHashes.lock file in .gradle/4.7/fileHashes folder. I wrote a quick script to delete those two files and edited the "Android JUnit" Template in "Run/Debug Configurations" to run that script before every junit run. See screenshot for details, but you'll need to make sure it is the first thing that runs. (Drag it to the first)
The .bsh file is an executable which just deletes those two files.
#!/bin/bash
echo This script deletes the .gradle files necessary for my android studio to work
cd wealth-android/.gradle/4.7/fileHashes
rm fileHashes.*
Now, the real problem may be that I could have multiple implementations of gradle on my machine. I'll look into that more and update the answer.
Android Studio 2.2.2. Did a build of my project and after several minutes I noticed that it still hadn't completed and at the bottom of my screen Android Studio said I had a process running. When I clicked on it it said it was the Gradle Build so I clicked to stop it. The display changed to
Stopping - Gradle Build Running
But it never seems to stop. If I restart the build that whole sequence repeats itself so now I have TWO
Stopping - Gradle Build Running
dialogs. But they never actually stop, even after 15+ minutes! If I try to shut down Android Studio it puts up an "Are You Sure?" dialog warning me I have background tasks running.
What's the right way to shut these down cleanly and how do I prevent this from happening?
Run the following in a terminal:
./gradlew --stop
It kills all the gradle processes.
Sometime it happens, Due to many reasons like your system Ram or memory. Just try to close everything and restart it again. It happened with me somedays back. I did the same process and after this, it works fine in my system.
On Mac, it returned to normal only after restarting the machine.
Some of the cached temporary files seem to have caused the problem.
I have created a blank activity project in Android Studio on Ubuntu 14.04. I can do a gradle build and install it to my device in one step using the installDebug target.
I wanted to work with the Nest API though, and I can't get the installDebug target to work. As a start, I downloaded their sample project and tried to build and install it in one go. I get this:
:testapp:installDebug FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':testapp:installDebug'.
> com.android.builder.testing.api.DeviceException:com.android.ddmlib.InstallException: Unable to upload some APKs
I created an app largely based off of this sample which also isn't working. Does anyone know how to fix this? What's weird is - it used to work at some point!!
I tried blowing away my Android SDK and re-installing everything, and also re-cloning the project from Nest's git repo and starting over. It's not working anymore.
I am extremely pleased I have figured out a solution to this problem.
I started to notice something was more seriously up with my adb connection because adb shell for example would just hang.
I neglected to mention it, but I was using Ubuntu 14.04 in Oracle Virtualbox as the guest to a Windows 10 host. I think that may have something to do with it.
In VirtualBox, I went to Devices > USB > USB Settings and under Enable USB Controller I enabled USB 2.0 (EHCI) Controller. Previously this was set to 1.1.
My guess is if the application is large enough, USB 1.1 is too slow to transfer all of the data in a timely manner.
I hope this helps someone in the future.
it could be because of three things:
If you are using a device, your device is not plugged in correctly. Make sure you can see it when you run adb devices on the commandline.
If you are using an emulator,the emulator is not running or it has not booted up yet.
Your app is configured to use a buggy version of gradle. Version 1.3.1 is well known to cause this problem.
The most likely cause of this problem will gradle version 1.3.1.
In my experience, upgrading gradle did not fix the problem. To fix it, I had to downgrade it to a rather memorable version of 1.2.3.
Look for com.android.tools.build:gradle:1.3.1 in the android/build.gradle, and update it to com.android.tools.build:gradle:1.2.3.
I had another program that was using the adb and was interfering with the build.
I have an unused mac mini, so I installed Jenkins on it, and I'm trying to configure it so that it is always running monkey tests on our latest Android build. I can't find a way to do that though. I've found the Android Emulator Plugin which allows for the booting of an emulator and then running a Monkey Test on the build, but it only seems to be configurable for a certain number of events, not time based.
The ideal Jenkins configuration would poll a git server. When it sees a new commit on a specific branch, it would build the APK, run the emulator, and then start the monkey test. I'm sure crashes would happen, and every time a crash happens the test should restart. It should continue running like this indefinitely. Then when a new commit is detected, it would shut down the emulator, and start the build all over again.
Are there any creative ways that a Jenkins build could be configured to continually run monkey tests?