I have set up a Jenkins job for building my android project in the following steps:
SSHing to a ubuntu machine. I set it up with the SDK, java, gradle, etc.
Cloning my source code
Building the apk using "./gradlew assembleRelease"
Deploying it or emailing to me (A step after apk building, customizable)
However, the SSH tunnel closes to my remote machine during some steps in the android building process, like when the following module builds:
:app:transformClassesWithDexForDevRelease
I am looking for a way to keep the SSH tunnel ON so that the building command does not exist. I tried to run the command using nohup but still does the same.
Any help or suggestions will be greatly appreciated.
EDIT:
I was able to go pass the ssh issue by making a small login machine changes as well, by adding
Host*
ServerAliveInterval 600
However, following that I added --stacktrace flag and that would give me the following response:
org.gradle.launcher.daemon.client.DaemonDisappearedException: Gradle build daemon disappeared unexpectedly (it may have been killed or may have crashed) at
org.gradle.launcher.daemon.client.DaemonClient.handleDaemonDisappearance(DaemonClient.java:222)
It seems very odd because this error never appears when I build by directly logging onto the remote machine. It only happens when the build is triggered using Jenkins. Something seems to be killing the Gradle daemon because the JVM settings seem fine. Maybe the ssh detachment is still happening but at a different point in the process than the one I was earlier seeing.
Try opening ssh connection to your ubuntu slave manually, then try increasing the connection timeout for the ssh server configurations ( /etc/ssh/ssh_config ) by configuring the keep alive parameters as shown in example bellow:
# activates the keep alive verification (default is Yes)
# you could just set this to No but it would risk keeping ghost ssh sessions
TCPKeepAlive Yes
# sets the keep alive interval (in seconds) - this will send one keep alive per minute
ClientAliveInterval 60
# Sets the number of client alive messages which may be sent without sshd receiving any messages back
ClientAliveCountMax 10
This means that sshd will send one client alive per minute and will wait 10 minutes for a client response before closing ssh session.
Assuming that your whole jenkins build (checkout + installing stuff + gradle build) takes less then 10 minutes it should work fine.
Related
When I run my ionic app in android device, it shows an error
Application Error
The connection to the server was unsuccesful.(http://localhost:8101)
I run with the command
ionic cordova run android -lc
How i can fix this error? why this error occur?
One option in this scenario is to not pass the -l which is for livereload functionality. So just run:
ionic cordova run android
This will then compile the apk and deploy it to your phone, but won't run a web server to watch for changes.
You can still debug with Chrome in this scenario, but if you make a change to the markup and press save it won't automatically reload the app with that change. You would need to run ionic cordova run android again to rebuild and deploy it to your phone.
On the plus side 1: after the first deploy, subsequent builds are much faster, as a gradle server is started.
On the plus side 2: if you disconnect your USB then you can still use your app. With a livereload deployed app it breaks once you disconnect.
I would actually really like to solve your problem as well. As I move around coworking spaces sometimes it seems that the network is locked down somehow and just is blocking certain ports. I haven't figured out exactly why or if there is a workaround for this.
Whenever I open or create a project in Android Studio, and it starts to do its background build or whatever, it gets to "Starting Gradle daemon", but gets in a loop and never stops repeating that step. As a result, the build never finishes and it keeps creating Gradle daemon processes until the system runs out of memory and freezes.
This is in Ubuntu. It did work previously, and I don't know what could have changed to make it start happening. Has anyone else run into this problem and been able to fix it?
TL;DR: Turn off Windows Mobile Hotspot (aka, adHoc Adapter or Wi-Fi Direct Virtual Adapter) before your first build.
For some reason, while the hotspot is on, gradle server cannot accept incoming connections from /127.0.0.1 according to the log file in %userProfile%\.gradle\daemon\<version>\. And so, it keeps spawning new daemons thinking the old ones (sleeping in wait for connections) are dead.
Every time you need a new gradle daemon (eg. open a new project), you have to turn the hotspot off, wait for AS to connect to the daemon (eg. start building, sync gradle files, etc.), then re-enable it.
Notice that if you forget to disable the hotspot and start a build/sync process, your RAM will be filled with waiting gradle daemons. Kill them all before you try again or you will have an "Insufficient Memory" error.
I use this nice command in a shortcut file to kill all deamons with one click:
C:\Windows\System32\taskkill.exe /F /IM java.exe /T. Of course this is assuming you have no java processes other than gradle daemons (which is mostly the case when I'm working on AS), and you don't mind working daemons be restarted (which isn't a big deal imo).
This problem started only after upgrading from AS 4.0 to 4.1 and stayed for the next upgrades too.
I had the same problem on Linux.
I traced it down to a firewall misconfiguration. It prevented Android Studio from communicating with Gradle daemon using IP over loopback interface.
I have same Error on Win 10, I searched a lot but nothing helped me.
I off/on window firewall, defender, edit rules ...etc. no result
Solution is (may be)
restore all firewall settings.
old style Control Panel → System & Safety → Windows Defender → Restore Defaults
Note: options/words may not very similar, because it translated.
Update 1:
Other solution
is run Build before connect PC to internet, then after Daemon started connect to network, and builds will work fine.
or you can try disabling Daemon, or let it work offline.
I hope this could help someone.
for me:
disconnected the real device attached for testing,
which, i use for testing apps as well as for internet connection through tethering.
and hurray.
on more study,
found that the loose usb cable was culprit.
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?
I have this application which I'm testing. I use a script which automatically installs the app but I also want to restart the device. This is important as after the installation I run a monkey-test on the device and all kind of quirks and bugs may arise. To get rid of these I want to restart the phone to get it into some kind of "known state". (These bugs are not only in the app as the phone has been known to suddenly shutdown during the tests)
My installation script is run with jython and I know of the device.reboot() command but this takes almost no time at all (which makes me suspicious) and doesn't work very well. I know there's three arguments: "bootloader", "recovery" and "None" but I can't find the impact these would have on the device.
So my question is, is device.reboot() the right command to use? If yes, what happens when I don't use any arguments with the device.reboot() command and what is the effects of the arguments.
It may be worth mentioning that I run the jython script from a batch command prompt in jenkins. So any batch commands using adb or similar would work just as fine.
device.reboot("None") works on my device
I get the message
Launch error: Failed to connect to remote VM. Connection timed out.
each time i debug my application on read device. I added to the AndroidManifest the:
<uses-permission android:name="android.permission.SET_DEBUG_APP"/>
and
android:debuggable="true"
But still this is not helping. When i reset the Eclipse ( close it and open it again ) this problem sometimes solved. Its really hard to work in this way - How can i solve this problem?
I sometimes have this problem after I disconnect phone from the computer and reconnect again.
I do CTRL + ALT + DELETE and kill all adb.exe processes and it fixes it for me.
Please try if this also works for you.
Note: I find this faster than restarting adb from command line/eclipse
Just had this bug, tried several things, finally, changing the port worked. I was at port 8600, changed to 8601 and connects instantly! You can find this setting in Windows->Preferences->Android->DDMS. Change default port, apply, and restart Eclipse.
Just uninstall the app from your device and run the debug again.
I don't know why, but this works for me: First Run(or Debug) your application in an emulator and then Debug the application on the device (without closing the emulator).
I know it is not a good solution though, but it's easy.
Another thing to try:
In my case I had 2 instances of eclipse running
To solve:
Close eclipse
Use task manager to kill any additional eclipse processes that are running
Restart eclipse
When running my APP as an Android Application on a Galaxy SII, all worked fine.
When debugging the same app, I got the error:
Launch error: Failed to connect to remote VM. Connection timed out.
On my Windows XP there was installed JRE 1.7. After uninstalling Java 1.7 completely, and installing JDK 1.6u26, I was able to debug my app.
In Eclipse...
Window --> Preferences --> General --> Network connections, choose 'Native' as Acrive Provider.
I had this problem and I became crazy.
Now I've resolved.
I had the AVG 2013 on my system, I uninstalled it and everything is working fine. I guess AVG was not allowing the emulator to open the port for debugger.
Yeah, I've been having this problem a lot these last few weeks.
StackOverflow does not lack in offered solutions, but most involved restarting or killing something.
I noticed the error message included the phrase, 'Connection timed out.', and so I hoped that there was some setting to extend that time and so the attachment wouldn't time out.
There is!
What worked for me was to increase the 'timeout' time.
I'm currently on Eclipse Kepler (Build id: 3.0.3-20140327-1716-Typesafe)
Under the Windows menuu -> Perferences -> Java -> Debug
Near the bottom of the window you will see the following field: Debugger timeout(ms): 3000
I just added another zero, 30000, and my troubles were no more.
You may find that your breakpoints continue to be skipped initially, but wait!
With this long timeout time now, just keep running past those breakpoints until the debugger successfully attaches and boom! You're stopping at breakpoints.
Better still, start up your app in 'debug mode', fold your arms, wait 30 secs or more...then have at her!
It was the following link that lead to this revelation:
getting Launch error: Failed to connect to remote VM. Connection timed out. which trying to debug my app on my device in android