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)
Related
I am setting up a CI server which creates Android AVDs on the fly to run automated UI tests. This works great, but since the CI gets brand new emulators with brand new images each time a job is run, I get all of the Android welcome and first run and do you agree prompts. These break my tests.
Is there anyway to have the emulator auto-accept or dismiss all of these prompts?
Here are some examples:
After much digging and experimentation, I've figured out a way to work around both of the prompts mentioned above. There isn't a catch-all solution, but here it goes, piece by piece.
Chrome
Before starting up Chrome for the first time, run this command with adb:
./adb shell 'echo "chrome --disable-fre --no-default-browser-check --no-first-run" > /data/local/tmp/chrome-command-line'
Basically, this writes out a file to a known location which Chrome will check on boot. All of the flags specified in the command are obeyed, and those inheriently disable all of the first run prompts. This link was very helpful.
Keyboard (Gboard)
The Android shell has a tool called ime to manage the input methods available on the device. By default, on newer devices in English, the input method is LatinIME. This is the Latin implementation of Gboard, which provided the legal prompt shown above.
The easiest solution is to select another keyboard which doesn't have this prompt. I used the old SoftKeyboard:
./adb shell 'ime set com.example.android.softkeyboard/.SoftKeyboard'
You may obtain a list of available keyboards, like so:
./adb shell 'ime list -a -s'
Final Result
I am working flashing a custom ROM on a new device. Through a bit of research, I've found that I am able to completely circumvent the need to port Clockworkmod by simply using UniFlash on my Windows based laptop. From there, I am left with needing to port the ROM I desire, Cyanogenmod 12, to my device.
I've come to learn that I do not need to build from source, rather I can tailor an existing recovery to fit my device. I am unsure if that is true, so that may need to be cleared up. I went ahead and installed ADB and found a porting guide on the Cyanogenmod Wiki. This is where I am running into problems. I do not seem to have ADB permissions for my device.
When attempting to grab my build.prop, I get this return:
user#mypc:~$ adb pull /system/build.prop
* daemon not running. starting it now on port 5037 *
* daemon started successfully *
error: insufficient permissions for device
After realizing my computer may not see the device, I tried to see which were connected:
user#mypc:~$ adb devices
List of devices attached
???????????? no permissions
It seems I do not have any access to the device at all. USB Debugging is connected, it is a rooted device, and it is set show as a USB Storage. I'm sure if I can at least get this fixed, I should be able to find my way through the rest of the guide myself.
Thank you for any help I can receive!
EDIT 01-
So, I decided to do more digging, and I guess I needed to START the server as super user, and not just run commands in super user.
After running this command, I was able to use my others with permission:
user#mypc:~$ sudo adb start-server
Now, I am running into a problem in which my device is offline:
user#mypc:~$ adb pull /system/build.prop
error: device offline
After referring to this (set up device for development (?????? no permissions)) thread, I seem to get a new response:
user#mypc:~$ adb pull /system/build.prop
error: device not found
I feel it's safe to say I should remove 51-android.rules from my ~/rules.d/.
Edit 02:
It seems I have answered my own question with research. I guess I just needed to update to the newest version because Android 4.2+ requires bridge authorization to complete tasks, and my version did not know to do that! I was successfully able to pull my build.prop!
The reason is that when you connect the USB device it shows a popup asking if you want to allow your pc access the device. You have to accept that manually from the device.
Something like this
http://www.gihosoft.com/android-recovery/img/allow-usb-debugging.png
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.
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.