I've got a partially rooted android device. By partial root, I mean that I can only run root commands through ADB. I've figured out how to run these commands locally from within a terminal emulator on the device itself. My question is, how would I go about writing the code for an Android application that executes an ADB command (or multiple commands) from a button press? I can't find anything that explains how to run direct ADB commands through an app interface. Just to clarify, anything that involves "su" will not work on this device. It only accepts ADB input for root access.
Not sure if it works on Android, but have you tried this:
Runtime rt = Runtime.getRuntime();
Process pr = rt.exec("adb do something as root");
If you provide more info about what exactly you need to use adb for in this manner, there may be a better workaround. It is very unlikely you actually need this behavior in app, and I believe it would be generally frowned upon. It sounds like you want your app to have root, but this seems like a very unportable and unnecessary approach.
Related
I have an app that helps locate your lost android phone and for rooted phones I have a one click convert to system app feature (so it will survive a factory reset).
Now some of my users complains and say it no longer works on devices that uses systemless root. So questions of the day are:
how do I detect if a user has systemless installed programmatically?
how do I use systemless? I guess it is not through the normal SU command
BR. Theis
Well, I had one of my users do some tests on his phone and a simple call like this will tell you if the user has su installed:
which su
Yes, the new systemless root also uses "su" as a command. Details can be found on XDA
I have a question regarding ADB.
I'm sorry about the title of this question as I really don't know how to put a good title to this.
I'm working with many android devices at the moment, and I noticed that on some devices, the following problem occurs.
Say I want to run a shell script (my_script.sh) that is located in the /data/local/tmp/ folder of the phone.
If I do this:
adb shell 'sh /data/local/tmp/my_script.sh &'
nothing happens on the phone.
If I just go into adb shell (by entering adb shell on a terminal) and when I get this prompt:
shell#android:/ $
and then I type in the following:
sh /data/local/tmp/my_script.sh &
everything works just fine.
This happens on only a few of the devices I have. So I'm not able to figure out what exactly I'm doing wrong.
Here is another piece of information that might help someone. If I don't use the "&" at the end (which means I don't run the script in a background process), everything works as well.
The following code gives the correct behavior:
adb shell 'sh /data/local/tmp/my_script.sh'
I'm completely lost, and I'm hoping someone here can help me out.
Thanks in advance!
UPDATE: So this issue has puzzled me for a while, and I spent quite a bit of time investigating this issue. I've noticed another behavior, say I lock the screen (by pressing the power key) and then issue the command:
adb shell 'sh /data/local/tmp/my_script.sh &'
And then unlock the screen, the script will run fine.
This is really the weirdest thing I've encountered in a long time.
I really hope someone can lend a hand here.
I guess you want to daemonize some program to run in the background. But normally the child process will got killed while the parent is gone. In this case, your adb shell is the parent process.
And this behavior is really different from device to device. I just tried it on my phone and found that "&" didn't take any effect, the shell command is still blocked.
I think a better way to handle it is to use standard daemonize approach of linux. Please refer to:
Write a daemonize native program
How to daemonize a script on a generic linux os
I have many questions about Android command. I do not know where I should start But, anyway, I have put all question related Android commands. Here ;
Is subset of Linux commands come in Android by default ? Or, Are we installing something ?
In system/bin, there are lots of commands. Where can I find their meaning ? I have tried man, but man is not built in.
Can I start and stop application via start and stop command ?
Why cannot I run the reboot from terminal emulator ? The error permission is denied.
NOTE : feel free to reedit the question, if you see meaningless part.
Is subset of Linux commands come in Android by default ? Or, Are we installing something ?
A subset exists by default within the system. Things like ls, cd, mkdir, cat etc... are present. You can gain access to a wider range by installing Busy Box on a rooted device, as stated by Zac.
In system/bin, there are lots of commands. Where can I find their meaning ? I have tried man, but man is not built in.
The ADB Page is a good place to start. That covers many of the basic ADB and shell commands. It states near the bottom:
"For a complete list of commands and programs, start an emulator instance and use the adb -help command."
So you can use adb -help on an emualator or device to see a full list of the ADB and shell commands (note I think this list will be android specific commands only, it won't include things like cd,ls and other basic unix commands).
Can I start and stop application via start and stop command ?
No, it states on the ADB dev page:
start ........ Starts (restarts) an emulator/device instance.
stop ........ Stops execution of an emulator/device instance.
To start an application you'll use the am utility iirc it will look something like am start com.your.packagename It's been a while though, I might have syntax wrong. The instructions are listend if you issue the am command by itself with no params in a shell.
Why cannot I run the reboot from terminal emulator ? The error permission is denied.
The system prevents applications from rebooting the device unless they are signed with the same key as the OS. When you use the terminal emulator you are restricted to whatever permissions that application has declared. The reboot permission is not granted to any third party applications, so it won't work correctly from any terminals. You could probably do it if your device was rooted and you used su though
EDIT:
Here is another good resource that lists more of the shell commands
There are not many Linux commands included in android, however if you are rooted you can easily install busybox which has a large range of linux commands.
You need to have root access to reboot your device via the command line (to prevent any old app being able to do it)
I was using earlier adb to debug Android applications over wifi, usb - it was great.
Right now I am wondering if it is possible to connect phone with adb via bluetooth.
I did a quick research but didn't find anything - have you tried it already ?
It is not supported by the current adb software, however you could probably make it possible if you have a rooted device (or possibly even if not - see below) either by modifying adb or by using bluetooth to tunnel a channel it does support, such as tcp.
You would need to obtain the source for the adb program - the same source is used to build both the PC and the device versions. First step is to just build it with unmodified functionality, which may take a fair amount of build system modification unless you do so as a part of a complete android source build (the way it was intended to be done)
Then you would modify it to add a bluetooth channel as an option and install it on the device (why you need root) and in your path on the PC. You'd think you could run it from an alternate location on the PC, and you likely can as long as you use it from the command line, but if your fire up DDMS it may kill off the running adb server and launch a new one using the default in the path, so ultimately you'll have to put your modified version there.
IF you can already get your device to accept adb connections over tcp (possible with root, perhaps possible in some cases without) there is another option, which is to not modify ADB (or at least not modify the device side) and instead come up with something running on the device which accepts bluetooth connections and forwards the traffic via local loopback to the tcp port on which the stock adb is operating. This would save the trouble of having to rebuild adb.
If you have some kind of tethering or similar network-over-bluetooth solution, you might even be able to leverage that to carry adb-over-tcp-over-bluetooth without writing any code.
Finally note that it is not 100% essential that the adb daemon run as a more privileged userid or be installed in place of the official one - you can run an adb daemon as an ordinary application and do many of the expected things with it. However, whichever adb daemon is running first will grab the unix domain java debug socket, and so only that adb daemon will be able to provide the full java debug services. More primitive things like logcat, shell, running process list, push/pull, etc will at least partially work without this, provided that your adb daemon doesn't quit (modification may be required) when it is unable to claim the debug socket. If you can kill the official adb daemon and exploit a race condition, you may be able to get an unofficial one started before it restarts - you would probably need to have a script or program to do this and run it with setsid from the official adb shell, meaning you'd need to connect via USB first. At that point, you'd also be able to start your unofficial adb daemon running as the same userid as the official one.
You may want to spend some time estimating or testing if the performance (speed) will be satisfactory before investing in a lot of time setting this up for real.
I know this is a bit old but I seem to have found a post that does this. All credit goes to the author of fomori.org for finding this and making the information available. Today it helped me, maybe tomorrow I'll help you by making it easier to find.
Source
How do I get root access in order to reboot the emulator? How do I kill all unwanted processes along with the child process?
You have already root access to your emulator. To kill a process and all childs just use the device view in eclipse, select the emulator theere and chose which process you want to kill.
I have no idea on how to restart from code if you are looking for that. Rebooting the device should be easy: just close it and than boot it up again.
(I have the feeling I don't really get what you want...)
Most su binaries for Android depend on SuperUser.apk (available for free through the market). The su binary uses this apk to ask the user if it's ok to do whatever is being requested (and the user can opt to remember the answer). If you're using such a su, you need to also have that apk.
Once the pieces are in place, your application can spawn a process with the right arguments... something like argv[0]="/path/to/su", argv[1]="-c", argv[2]="(whatever command you want to run)", argv[3...n]=arguments to your command.
To kill a process in the command line, simply issue the following command line on the shell:
kill-9 YOUR_PID
If you know the name of the process, but not the pid, use
kill -9 $(pidof NAME_OF_PROCESS)
You can also use it on your code:
Runtime.getRuntime().exec("kill-9 YOUR_PID");
Check the man page for more details: http://unixhelp.ed.ac.uk/CGI/man-cgi?kill
ps-after rebooting i also wanted to kill all unwanted process except my specific app and its child process alone to run in emulator.
If that is really what you want to do - repurpose an android build as a generic embedded linux, then the way to go about it is to regenerate a ramdisk image (which android packs onto the kernel) containing an init.rc which launches your application rather than the android native services and (java-esque dalvik) android runtime. Rebuilding the ramdisk requires a unix-like OS and that arcane cpio command line which you can find in web search. I'd be tempted to leave the startup of ADB in there so you can debug the various things which will go wrong.
For testing purposes simply typing "stop" from the adb shell will shut down the android runtime and give you a UI-less virtual pocket linux box. There will still be some native services running but they may be more help than harm. Ultimately you may need to set OOM killer values on the things you add, though without the runtime up that may not be an issue in the near term if you don't consume much memory.
Or if what you want to do is have a very locked down and limited UI built on top of the android runtime, you would instead develop a custom home screen , test this on an unmodified emulator, and then deploy it on a build customized to lack any means of installing other applications.