To run system Command like "ping" in android device , we can use Process to execute them.
I have difficulty in accessing that data which is replied by system for systme commands.
how to set that data in proper format? how to access it and store in different type of variables?
You might want to look at Root Tools - they make it dead simple.
Edit: Ofcourse this works also for non-root commands on non-root devices ... look at getShell(boolean wantRoot)
I assume you executed your command by getting the DataOutputStream for the process. The same way, you can get the command's output by getting the DataInputStream for the same process. However, this will show you all the output. You will have to implement separate logic to parse through this output, make some sense of it and further process it. I suggest you first get the DataInputStream and print out the output, so you get a better idea. There is no easy way to do this, except probably the answer from Eugen Rieck.
Related
In my app, I have an Activity, which is basically a form for the user to enter data which is then inserted into a database table via a ContentResolver. How do I test this Activity?
My first attempt was to use ActivityInstrumentationTestCase2 which gives me full instrumentation to simulate entering data. However, the underlying ContentProvider is not closed and destroyed between each test, which leaves the database in an unknown state at the beginning of subsequent tests.
My second attempt was to use ActivityUnitTestCase and inject a mock context that can clean up the database for each test. However, this doesn't allow me to enter text or click on buttons in the activity as it is never actually drawn on the test device.
Does anyone have any suggestions about what else I can try?
it seems that what you've been using is intended for library development
You should look at the monkey binary here , which works great for me.
If you're not satisfied with it you could use monkeyRunner which provides more control over the tests you're running.
Edit :
As far as the database testing goes , cant you use the sqlite3 binary for a simple query after each test?
Edit2:
I am thinking of a .sh script that does the following :
Runs monkey for a while - you can specify the number of events for the monkey to send
Invoke sqlite3 with a query that would check the database integrity into a log file (sqlite3 command can take sql query as a second parameter, and you can use ">" to write the output into some file)
Repeat.
There are tons of examples for .sh scripting on the net so you shouldn't have problem with that.
I am assuming you're doing all this in adb shell, but if you're not, make sure to set all your environment variables correctly. Particularly ANDROID_ROOT, ANDROID_ASSETS and ANDROID_DATA should be set to "/system","/system/app" and "/data" accordingly . Also don't forget to "chmod" the .sh file to be executable ( chmod 777 file.sh ).
Another suggestion is to generate and keep track of the monkey random seeds so you can repeat certain inputs that are causing you problems. You can specify a seed with -s parameter.
I have a Python script running that checks to see if slots have opened up for a
class I want to take next semester, and then it emails me.
Problem
I can't have my laptop in all the time. Is there any resource available to let me house my script and just let it run on some server.
Or better yet, is there anyway to run a script like this on an Android phone.
If you are scraping a web page, you could use scraperwiki. It allows you to run scraper code on their server for free. (lxml is importable there too!) You can set how frequently you want the script to run.
I am using my Android app to launch a native binary. I would like to display the output of that binary in a small window in my application. How would I go about either displaying the output in a TextView or showing the terminal in a small window (preferred)?
Thanks.
The gist of the article that Alex linked to is that Runtime.exec() returns a Process object, which lets you get the process' standard output (and stderr, too) as Java streams via Process.getOutputStream()/getErrorStream(). Get them, read them in a thread (they do properly block - you don't want to block the UI thread), pass the data back to the UI thread. Much, much better. I rescind my previous answer.
The article also recommends wrapping the stream in a BufferedReader so that you can do readLine.
Here's one scheme. NDK is not necessary for this one.
You create a temporary file in your app's data dir. You run the binary, specifying the same file as an output direction in the command line using Runtime.exec(). The command line you'll have to specify would invoke not the binary itself, but sh, and one of the command line parameters would be a redirection: >myfile.txt.
You then start a worker thread that reads the same file. You'll need to carefully implement new data detection - as this is a file, not a pipe, the reading operation will simply terminate once the end of file is reached; it won't block until new data appears.
Then you pass the data from the worker thread using Activity.runOnUiThread() or Handler.post() to the main thread, where it's used to update TextView's content.
A cleaner way would involve creating a pipe pair with mkfifo() and redirecting output in place using dup2() from a pipe handle to the file handle value 1 (stdout). That's how they normally do it in the C/Linux world. There's probably an Android example out there, I've never done that.
Oh, and before you do all that, make sure the binary does not have a more palatable interface. More often than not, Linux binaries are based on a static/dynamic library where all the yummy functionality is, one that can be linked with and called directly.
EDIT: Especially if it's logcat. There are other ways to read a log in Android.
I am doing some ui automation, and I am able to store screen touches using getevent, but when I try to send this using sendevent, it takes a really long time, making it hard to actually replay the inputs.
I have already trying loading the script onto the device and running the script locally on the device (a script with a bunch of sendevent commands). But this only imporved this slightly. Is there some other way to inject these commands in a quicker way?
The handler for touch is implemented differently across devices. You should cat /proc/bus/input/devices to see where the touch handler is implemented.
You can also do adb shell getevent, interact with the device and see the output for the interface name.
The reason why your replay takes a long time is because the sendevent binary opens the interface file, writes data to it and closes it for every call to sendevent. So in theory, if you have a bunch of sendevent commands, the binary is opening the interface file, writing data and closing it for every command.
The way I've solved this issue is by re-writing the sendevent.c file under /system/core/toolbox to open the file only once during replay, writing all the data and closing it at the end of the replay. It works perfectly for me!
OK.
Instead of using the getevent/sendevent you can try direct reading from the event interface
inside adb shell try:
dd if=/dev/input/event6 of=record1 # to record
dd if=./record1 of=/dev/input/event6 #to play
However, this may run too fast...
I'm investigating the possible ways of obtaining superuser privileges in a Java Android application and/or its own JNI. The well-known answer seems to be that it's only possible to run a "su" subshell and command line commands from there, which is neither neat nor very practical. I am willing to accept this resolution but still I'd like to hear an opinion on this "what if" scenario.
Reading through Android sources near java.com.android.server.am.ActivityManagerService, java.android.os.Process and the dalvik_system_Zygote.cpp file, it seems to me that during application launch, the application record is examined for the UID and (a list of) GID(s) and all these values are passed to the Zygote through a socket. Z subsequently picks the data up and passes it, without further checks, to setuid() posterior to a fork() call. Therefore, it seems to me that if the Activity Manager pathway was altered, a simple passing of --setuid=0 and perhaps --setgid=0 to the Zygote socket should result in running my Activity with the root UID.
It all seems almost too simple, I suspect that something would go wrong along the way. Unfortunately, there's too much code and new stuff for an inexperienced programmer like me to actually go and try. Has anyone gone this way, or is there any obvious reason why this would NOT work?
I think I just found the answer to my own question. Credits go to #Chris Stratton who pointed me at using the emulator and also pointed out how ridiculous a situation this would be.
The key was in one place where I did not look, between sending commands through the Zygote socket and the Zygote binary itself. The point where the check takes place is com.android.internal.os.ZygoteConnection, method applyUidSecurityPolicy. If the caller process belongs to root, the UID of the spawn may be indeed requested to be zero (or anything else, for that matter). A regular user may use the socket as well but asking for a new UID or GID results in a ZygoteSecurityException.