Develop Reference

How to execute shell commands from Ruby in their own shell?

I'm writing a small Ruby script that performs some adb shell commands. The problem happens when I attempt to run a screen record on the android device and then send some swipe and touch events.
If I run adb shell screenrecord without an "&" at the end the touch and swipe, events only happen when the screenrecord times out:
adb shell screenrecord --time-limit 10 /sdcard/dumper.mp4
If I run it with an "&" at the end, the screenrecord cuts immediately when a touch or swipe event is carried out despite passing a high --time-limit option to screenrecord.
adb shell screenrecord --time-limit 10 /sdcard/dumper.mp4&
Is there a way I can just create a child process have it run the screenrecord and just dies when the screenrecord is finished and in parallel execute the touches and swipes?
I tried using fork but the parent ends up dying and if I re-exexcute the program the touches and swipes are carried out.
This is the code I used to fork:
def adb(arg)
fork do
exec("adb -s #{ARGV[0]} #{arg}")
exit
end
end
I tried looking at spawn as an alternative but it just wouldn't work:
if line.include? "<record>"
puts "comes here"
duration=line.scan(/\d+/).first.to_i
adb_sep("shell screenrecord --time-limit #{duration} /sdcard/demo.mp4")
It basically parses an XML file with tags to trigger a record process. I'm confident the exec isn't failing because I tried simulating the steps in IRB.
Running
irb>>exec(<adb screenrecord command>)
kills the Ruby shell after it is done as expected however.
irb>>system(<adb screenrecord command>&)
irb>>system(<adb tap or swipe command>)
works like a dream! It does exactly what I want it to do. Pulling the recorded video from the device shows exactly what I want.
I think I've figured out what's going on. Running adb with & sent the adb process to the background and recording stopped. Running adb tap brought it back to the foreground. consequently I'm getting chopped up videos.
I guess I would have to trigger the adb screenrecord in its own shell.
A bash analogy with a human would be to open one terminal, start recording the screeen. Open another terminal, start sending taps and swipes.

As it turns out this was an Android shell screen record problem and not a Ruby problem.
Android is carrying out optimizations of recorded video length that skew my output video. It only records the video from the first UI change to the last UI change.

Passing adb shell commands into IntelliJ Android Launcher

I am building an Android application that is designed to help with load testing. When the app launches we are sending extra values to the main activity so that we can control what kind of load each app executes. Currently, we are doing this, scripted, via the terminal using adb directly which is pretty straight forward:
adb shell am start -e key1 value1 -e key2 value2 -n bla.bla/bla.MainActivity
For debugging purposes, I'd like to be able to do this from IntelliJ but I don't see anything in my run configuration screen that let's me pass anything to adb. Is this possible?

Might be waaaaaay late on this one, but you can always try the BashSupport plugin on the IntelliJ Repo.

What does 'adb shell start/stop' do?

Question
What do adb shell start and adb shell stop actually do?
Description
I think they call /system/bin/start and /system/bin/stop. But these two executables don't give any clue about what they do. When tested on a real device, I found the zygote process is started and stopped. So these two commands seem to control the Android runtime (which corresponds to the yellow and blue parts in the figure below).
But what exact processes/services are started/stopped with these two commands?

Basically, all your Android services are restarted; those that are created and registered in SystemServer.java. This is called within the "Context of Zygote". So yes, Zygote is stopped.
All your services registered with ServiceManager in Android will get removed within ServiceManager. To restart them, do adb shell start.
Also note that SystemServer is started by Zygote, so init.rc tells that if Zygote is stopped, then even SystemServer must be stopped. Even SurfaceFlinger dies, since it's started from SystemServer but natively.

Run this on your device
grep ^service /init*rc

I have been wondering what "stop" does on Android too. Learned from someone that "stop" stops AP being rendered by SurfaceFlinger.
Had a try with the command like below. Execute the command, wait for a few seconds and then execute "stop" on Android. The command keeps printing increased number and creating .txt files. So maybe it only stops the Android part while the Linux part remains active. Just FYI.
busybox sh -c 'i=0;while [ $i -ne 100 ]; do echo $i >> count.txt; sleep 1; i=$(($i + 1)); echo $i; touch "$i.txt"; done;'

adb shell "start --help"
usage: start [SERVICE...]
Starts the given system service, or netd/surfaceflinger/zygotes.
adb shell "stop --help"
usage: stop [SERVICE...]
Stops the given system service, or netd/surfaceflinger/zygotes.

Android: Emulator frequently disconnected (offline)!

Sometime just after I launched a new emulator, for very first time I was trying to upload my apk, however I got "emulator: ERROR: the user data image is used by another emulator. aborting".
I launched a new emulator, and left it alone, several minutes later, DDMS showed "device offline".
I had to restart a new one, you know, minutes wasted.
It's really bothering that I keep getting this error and slowed down debugging.
How do I fix it?

If the emulator is still alive, you can tell adb to connect to it via tcp (which is I believe what it does anyway, only it normally uses an 'emulator' class of name and would now get a ip:port one)
It's been a while since I've had to do that, but I think that if you were using emulator-5554 you would connect to your development machine's loopback one port higher, ie:
adb connect localhost:5555
If it works adb devices will show it an eclipse should see it as a deployment option
The 'in use' problem sounds like a stale lockfile perhaps left behind in a crash

I have another solution. try this
Run configurations > Target > Wipe user data > Run

In my case it happens when I have another process listening on emulator port.
e.g. if I see:
emulator-5554 offline
it means that something is using port 5554

Manually delete these following folders:
C:\Users\%UserName%.android\avd\AVD2.1.avd\cache.img.lock
C:\Users\%UserName%.android\avd\AVD2.1.avd\userdata-qemu.img.lock
this always works for me. :3

On Arch Linux x64, I had this similar problem which led me to this question. Using Eclipse, the emulator-5554 window would freeze, and Eclipse prompted me to start a new one. In the following dialog, emulator-5554 was reported to be offline, with an unknown target. If I started a new instance, it would be emulator-5556. This problem persisted through Eclipse restarts and log-off-on cycles too! Further, killx would close the window, but the process was still running.
So, find the emulator64-arm process id (not emulator-arm!):
ps ax | grep "emulator64-arm"
...and then just kill -9 it:
sudo kill -9 6728
...where 6728 was its PID. This completely disconnects the emulator so Eclipse can try to run it again.

Open android debug monitor window by
typing "monitor" command in cmd,
then select device in the monitor window,
click on down arrow as shown in the figure then just click on reset tab thats all you will get internet connection.

It was some strange
I had that problem, automatically stopped the emulator localhost:5554 after to launch the application.
I didn't know why it happens but intil today I did something different at I could launch as normality.
What I did as different was to change the prespective of Eclipse ADT. I was executing the application from Debug and now I executed from Java Prespective, it worked, I don't know the reason, I had to share it, sound some .. this answer but I resolved doing that without deleting and creating again my android virtual device.

Android Adb error

Please guide me about this error
2011-05-02 18:37:20 - SimpleOptionMenu] The connection to adb is down, and a severe error has occured.
[2011-05-02 18:37:20 - SimpleOptionMenu] You must restart adb and Eclipse.
[2011-05-02 18:37:20 - SimpleOptionMenu] Please ensure that adb is correctly located at 'F:\android-sdk-windows\platform-tools\adb.exe' and can be executed.
It was working fine and now i am getting this error . I have restarted eclipse but nothing happed . Thanks

When I faced with this problem, resetting adb is usually the solution.
If this not solves, unplugging-replugging the device works. I never have had to restart Eclipse.
By the way, Reset adb option can be found in DDMS(Dalvik Debug Monitor Server)'s Devices tab.

I have had this error from time to time too, and restarting Eclipse has fixed it. My best guess is that you had the misfortune of getting the error twice in a row. Try restarting again and see if it goes away.
Writing this post has had the unfortunate effect of making me realize that the Android SDK bears a striking resemblance to Windows.

I do not know the reason but restating up my system worked for me :) !!!

I just posted the response below here:
adb kill-server not responding?.
I am duplicating it here too as Google considers this thread as one of
the top hits.
If zombie adb process is not the issue i.e. there's no adb.exe in the task-manager list, the problem is usually adb ports e.g. 5555, 5554, 5037 etc., being taken by other applications.
Solutions:
On all Windows: find the process taking one of those ports using netstat -bn and kill it from task-manager Ctrl+Shift+Esc is the shortcut.
On Windows 7 and 8: there's this new tool called Resource Monitor. It'll also allow you to find out the blocked port and blocking process under the network tab.
On Linux: the similar is done with netstat -pn. Feel free to use your grep foo as needed and kill the blocking process with kill or pkill.
Change Default ADB Port: Apparently default ADB port can be changed as described here by setting up an environmental variable before launching ADB. Give it shot. It'll allow more flexibility if you don't want to kill the blocking processes.