Database Develop

adb shell and arrow keys

is it just me, or when you "adb shell" into the device and then use a program that uses the arrow keys everything goes berserk?
it seems like it's overlaying the command history into the on-screen buffer and all future interactions are corrupted beyond repair.
for example, run vi and use arrow keys to navigate around (yes, i know there are other methods for this, just using this to illustrate) and it pulls info from some sort of history buffer on to the screen.
another example is the ash shell. up and down arrows behave nicely at first allowing you to scroll through your command history. but, it degrades fairly rapidly into being unusable
this does not seem to be an issue using scroll ball in terminal on the device.
I can't find anything in the Android Issues Page.
I've reproduced this in multiple builds on multiple OS's on multiple machines (but I've only got one G1, hence this thread)
Does anyone have any insight?

What OS? Mine behaves this way too, and I think the root problem is the Windows command prompt. Read a comment somewhere on here that makes sense - something along the lines of cmd.exe not properly interpretting ANSI control codes? Need to hit up Google, maybe there's an alternative command shell that would solve this for Windows users.
EDIT: Ok, really need to work on reading comprehension - you tried multiple OSes? I was all set to blame MS. Anyway, I tested in Cygwin, Command2, Command2 wrapped around bash.exe .. No luck. Problem has to be in ADB itself somewhere, either the daemon on the phone or in all the clients.

Saiboogu said:
What OS? Mine behaves this way too, and I think the root problem is the Windows command prompt. Read a comment somewhere on here that makes sense - something along the lines of cmd.exe not properly interpretting ANSI control codes? Need to hit up Google, maybe there's an alternative command shell that would solve this for Windows users.
Click to expand...
Click to collapse
Thx for the reply.
I use a Mac mostly, but have similar response in Linux and Windows.
I've tried Terminal.app as well as iTerm on the Mac.
I tried cmd.exe, powershell, & cygwin / bash in Windows.
I agree it almost has to do have something to do with the way the adb daemon handles ANSI codes.

Maybe this will help...
Hi All,
I don't reckon there isn't an actual problem.
The "DOS" console is not a terminal program and thus doesn't behave proper, and the DOS telnet program is just as bad!
In linux, the console is a terminal program, but is also very generic.
The adb shell is not a very good telnet server either in terms of terminal handling; which all really boils down to the sh being to limited as a login shell.
The following may help a little.
Have PuTTY or the like handy.
For windows, copy paste the following or something like it into a bat file (dlink.bat I called it):
The important bit is the forwarding...
Code:
@echo off
:init
::REM //-----------------------------------------------------------------------
set prog=%~f0&&REM This
set progDir=%~dp0&&REM This location
set workdir=%cd%&&REM Current locataion
set ADB=%progDir%adb
echo --Droid Link--
echo current settings:
echo -----------------
echo prog=%prog%
echo progDir=%progDir%
echo workdir=%workdir%
echo -----------------
::REM //-----------------------------------------------------------------------
::REM //ensure a clean house
%ADB% kill-server&&echo adb server clean: Ok.||echo adb server clean: Problem...
::REM //start fresh server instance, use its own shell as it will not detach from the shell until it ends elsewise due to it running in daemon mode
%SystemRoot%\system32\cmd.exe /e:on/v:on/f:on /c "%ADB% root>nul:"
::REM //get id of the Android (will need to be adjusted for more than one)
for /f %%a in ('"%ADB% devices|find "HT""') do set adev=%%a
::REM //see if we found our device
if .%adev%.==.. (
echo Android not detected...
goto :done
) else (
echo Android detected as:%adev%
)
::REM /if
set DROID=%ADB% -s %adev%
::REM //-----------------------------------------------------------------------
:begin
::REM //-----------------------------------------------------------------------
::REM //forward telnet port
%DROID% forward tcp:18023 tcp:23
::REM //forward ssh port
%DROID% forward tcp:18022 tcp:22
echo This terminal is now held by --Droid Link--
echo You can now connect to Android:%adev% via telnet host:127.0.0.1 port:18023
echo And if you start a ssh server...
echo You can connect to Android:%adev% via ssh host:127.0.0.1 port:18022
echo For best results, use a program like PuTTY or something (dos telnet is lacking).
%DROID% shell telnetd
echo --Droid Link: Closed---
::REM //-----------------------------------------------------------------------
:done
::REM //-----------------------------------------------------------------------
%ADB% kill-server&&echo adb server off-line.||echo adb server dropped: off-line.
::REM //cleanup
set DROID=
set ADB=
set adev=
::REM //-----------------------------------------------------------------------
:xit
echo End of line.
::REM //-----------------------------------------------------------------------
For Mac, I'm afraid I rely on my linux syntax and pray it works the same in OSX:
adb -s {device ID} forward tcp:18023 tcp:23
note the adb -d forward tcp:18023 tcp:23 may do the trick also.
I use PuTTY and have a profile called Android-Telnet, which can be called from the console as putty.exe -load Android-Telnet
PuTTY may or may not be the end-all, be-all of terminal programs, but I like it, it works, and is multiplatform.
Hope that helps.

tyvm, Darkstrumn. that worked great! Can't believe i didn't think to try this as a workaround.
all i did (on OSX Leopard):
adb shell telnetd &
adb forward tcp:9999 tcp:23
telnet localhost 9999
now, to get working on compiling dropbear 0.52 and / or patching adb *eek*
i guess a related question becomes, is there any way to change ash to the default login shell?

alapapa said:
tyvm, Darkstrumn. that worked great! Can't believe i didn't think to try this as a workaround.
all i did (on OSX Leopard):
adb shell telnetd &
adb forward tcp:9999 tcp:23
telnet localhost 9999
now, to get working on compiling dropbear 0.52 and / or patching adb *eek*
i guess a related question becomes, is there any way to change ash to the default login shell?
Click to expand...
Click to collapse
Just a note: The windows version of this is just as simple as those 3 commands, the complexity of the script is simply allowing the script to lock-on to the device by id; my actual scripts enumerate the devices including the emulator into the %adevN% variables where N is 0-X. %adev0% will always be the first instance of the emulator found and %adev1% will always be the first instance of a true device found. I simple made it light and posted it. I think it only matters if you are using the emulator and have a live device connected and what to work with both.
Let me know if the enumeration script would be handy and I can post it also.
I haven't gone the route of dropbear just yet, but I'm interested in using ssh vs telnet.
As far as ash goes, I reckon the trick is to setup a chroot to use it as the console...maybe override the console service defined in init.rc.
Note I think ash is expecting the passwd file to exist and have meaning, so that may need to be setup to have ash behave a little better in the Android environment.

Thanks! This worked a treat for me.
I was having trouble with lynx and ansi chars within an adb session, the forward made my day .
Actually I got rid of the complex batch above, I just set up two small batch files:
myadbshell1.bat
@echo 1
@adb forward tcp:18022 tcp:22
@adb forward tcp:18023 tcp:23
@adb shell telnetd
@exit
myadbshell2.bat
@echo 2
@putty.exe telnet://127.0.0.1:18023
@exit
Run the first, then the second.
Do your story in putty, when exit everything will close.
Why echo 1 and 2? Because withouy I was getting the two batchs hanging, dunno why. :-?
Everything on windows environment.

In windows I created a .bat file called adb.bat, where c:/adb/ is where I installed the SDK:
Code:
c:/adb/tools/adb remount
c:/adb/tools/adb forward tcp:9999 tcp:23
c:/adb/tools/adb shell telnetd
I run this file as Administrator, and then I can telnet into localhost:9999 with putty. Works great!

Putty on Windows
In windows I created a .bat file called adb.bat, where c:/adb/ is where I installed the SDK:
Code:
c:/adb/tools/adb remount
c:/adb/tools/adb forward tcp:9999 tcp:23
c:/adb/tools/adb shell telnetd
I run this file as Administrator, and then I can telnet into localhost:9999 with putty. Works great!

[Q] Change adb shell sh executable

How do I change what command is executed when I type "adb shell"? Currently, it is /system/bin/sh.
Even if I run adb shell ls, it seems like it needs to execute sh at first.
There has to be some script somewhere to edit, right? I cannot use a symlink from /system/bin/sh.
The specific program is "busybox sh" in my case. What do I do?

It may actually work to link /system/bin/sh to busybox, but I'd be hesitant to do it. Any mistake could make the system unusable.
It might be possible to pull /system/bin/sh (or get a copy from a nandroid backup), try the above, then push the file back if something goes wrong. I don't know if the adb push command requires /system/bin/sh to be already working. Certainly adb push requires the ability to successfully do adb remount first.

ssh into the Note over USB

Anyone been able to ssh in through the USB connection?
I've done it with other Android phones, but here when I connect the USB cable, it doesn't even bring up the usb0 interface on my GNU/Linux PC, so don't know what's wrong...
Anyone doing it?

You need usb debugging active in settings. You will use adb shell command, not ssh (at least not without an android ssh server app).

Right, it does seem no android ssh server app is available to work over USB.
I was able to do, after redirecting ports from the local PC to the phone via adb, as per http://forum.xda-developers.com/showpost.php?p=20104928&postcount=71
However, interestingly, I cannot ssh in via wifi, as per symptoms in the above posts, i.e. the Galaxy Note will not initiate the connection, although using the same software on a Motorola Droid 3 will connect, so it must be some peculiar setup about the Note. In the thread many other users, notably it seems of Galaxy2 note the same inability to connect.
Anyone been able to connect through ssh via wifi? What am I missing?

any updates on this? I can't connect as well. I'm using sshdroid.

I gave up on SSH via USB, seems it's messed up under android. Just using the wifi method as per above.
There might be some hope with CM9, using the latest kernel, will see...

I tried using the earlier post by 白い熊 (!) which is basically noed's tip and it working beautifully. I think noed made a typo.
This is how it works for me :
1) Installed busybox/droidsshd
2) Connected to the windows pc which had drivers (kies)
3) Issued adb forward tcp:22 tcp:2222 (this is because droidsshd listens at 2222, when i changed that to 22, it worked also)
4) putty to 127.0.0.1 worked (I enabled root and set password in droidsshd prefernces -> Service and Authentication)
Due to busybox, i could run natural linux commands like ps, grep, find. top also worked showing what application bogging cpu - droidsshd for me

Yeah, the problem with this is the adb part... Running it in a Linux box, after a while adb consumes most of the memory, I have to kill it and restart, the connection gets dropped often too. Just a very poor experience, not the solidity you need for sshfs for instance...

Download a cyanogenmod 7 rom and extract dropbear, dropbearkey and dropbearconvert from the /system/xbin/ directory. Dropbear is a lightweight alternative to sshd. Copy them over to the phone, move them to /system/xbin/ and give them the permissions and ownership they had in the archive.
Generate an ssh key for your desktop if you don't have one already: ssh-keygen -t rsa
Copy the public key to the phone: adb push .ssh/id_rsa.pub /sdcard/authorized_keys
Set up your keys on your phone via adb shell:
mkdir /data/dropbear
chmod 755 /data/dropbear
mkdir /data/dropbear/.ssh
chmod 700 /data/dropbear/.ssh
mv /sdcard/authorized_keys /data/dropbear/.ssh/
chown root.root /data/dropbear/.ssh/authorized_keys
chmod 600 /data/dropbear/.ssh/authorized_keys
dropbearkey -t rsa -f /data/dropbear/dropbear_rsa_host_key
dropbearkey -t dss -f /data/dropbear/dropbear_dss_host_key
Run dropbear on your phone in a terminal or using adb shell: dropbear -s -F -v -p 2222
Connect from your desktop: ssh -i .ssh/id_rsa -p 2222 -l root 127.0.0.1

External Bluetooth Keyboard Mapping with HTC Vivid

Hello,
I didn't know if there was already a post for this, my searches were coming up not matching anything.
If you happen to have an external keyboard (bluetooth in my case), you might have the problem that many of the key events from the keyboard do not map nicely to the HTC Vivid. I am running 4.0.3 in my case with 3.6 sense, and other than the alpha-numerics, many of the system level keys were not working for me. Since I often play HD video from my phone to the HDTV, it's handy for me to control things like Volume_UP/Down, HOME / MENU / BACK, Pause / Play, Select Movie title, reply to Text, etc. So I had to find a way to improve the keyboard mappings to make it functional, and I was curious if others may have done similar things as what I describe here. I am still stuck on a few mappings, so would glad to have any info from others who have succeeded or failed in a similar regard.
I went and spent about $35 for this G-Cube bluetooth keyboard model BK-30 at Frye's.
h t t p :// www .gggcube .com/ Upload/ ProImgs/ smaImg/ 201303101915016774.jpg
It was a nice weight with a good feel on the keys, and good enough for a test run. The bluetooth device was discovered and paired easily on my HTC Vivid, and some of the system functions from keyboard were working, like Volume UP/Down and Mute. But I noticed right away I had no way to open a MENU option, or to perform a BACK function from a given application or settings screen. In order to change the keyboard mappings, it's necessary to boot into Recovery, un-mount /system and use ADB to re-mount /system in order to be able to edit the file called Generic.kl (keyboard layout file) which lives in the /system/usr/keylayout/ directory. Here are the steps I used to update the file.
Before editing the Generic.kl file, it's helpful to gather some information using an APP called KeyEvent Display (free in Google Play store).
1. Download, Install and Run the KeyEvent Display application, it gives you a keyEvent monitor for the Bluetooth Keyboard
2. Pick a few keys on the Bluetooth which seem to do nothing, and press them, noting their SCANCODE values in the app. I chose the PrintScr, Pause/Break, Insert and Delete keys, just as a test. These 4 keys gave me scancodes of 99, 119, 110, and 111, respectively.
Now, you can reboot the phone into Recovery, and perform operations using ADB, providing your PC has the right USB drivers. Usually installing HTC Sync will give you these drivers, or from Ubuntu Linux, you may not need them. Google to install the ADB tool
1. Make sure your Vivid is rooted with a Recovery Image for bootup
2. Boot into Recovery, Connect your USB cable from the PC, and test that your ADB tool can properly communicate:
a) to use ADB, you need to have download these files (adb.exe, AdbWinApi.dll and AdbWinUsbApi.dll)
b) from the directory where you have ADB, test the connection with a simple 'adb devices'
c) you should get a response from the phone device like this:
[C:\Users\JohnDoe\ADB_Tool] adb devices
adb server is out of date. killing...
* daemon started successfully *
List of devices attached
FA27VVJ01452 device
Click to expand...
Click to collapse
3. Assuming you are successful, you can now send ADB commands to the phone as needed here below. (If you got nothing after List of devices attached, you can research this seperately - its usually and USB driver issue.) ADB commands are used to mount and unmount file systems (like /system), to send commands or open a shell to the phone, and to push and pull files back and forth.
a) adb remount (should see: remount succeeded)
NOTE: if this fails with an error, use your Recovery Developer options to un-mount /system first, then try again.
b) adb pull /system/usr/keylayout/Generic.kl
NOTE: Generic.kl is the file we want with all the mappings of keyEvents. If the file is pulled successfully, you see something like:
pull /system/usr/keylayout/Generic.kl
982 KB/s (9058 bytes in 0.009s)
Click to expand...
Click to collapse
c) Note with File Explorer in the folder with ADB, you should have a copy of the Generic.kl file.
d) Make a backup of this file, you can cause the keyboard and other items to fail with incorrect changes!
e) Edit the file with your favorite text editor, and look for sections that we want to change, for example:
key 109 PAGE_DOWN
key 110 INSERT
key 111 FORWARD_DEL
# key 112 "KEY_MACRO"
key 113 VOLUME_MUTE
key 114 VOLUME_DOWN
key 115 VOLUME_UP
key 116 POWER WAKE
Click to expand...
Click to collapse
f) Change keys 110 and 111 (for example) to now look like this, and then save the file:
key 109 PAGE_DOWN
key 110 BACK
key 111 MENU
# key 112 "KEY_MACRO"
Click to expand...
Click to collapse
g) adb push Generic.kl /system/usr/keylayout/ (this places the file back to the phone)
h) adb shell (need a shell to reset the permissions of the file)
i) chmod 644 /system/usr/keylayout/Generic.kl (should be read only to group/world)
j) ls -l /system/usr/keylayout/ (check to see ownership and permissions look correct)
ls -l /system/usr/keylayout/
-rw-r--r-- 1 root root 894 Jul 12 2012 AVRCP.kl
-rw-r--r-- 1 root root 9048 Nov 12 20:59 Generic.kl
-rw-r--r-- 1 root root 1293 Jul 12 2012 Vendor_045e_Product_028e.kl
-rw-r--r-- 1 root root 1027 Jul 12 2012 Vendor_046d_Product_c216.kl
Click to expand...
Click to collapse
k) exit (exit from the ADB shell)
l) adb reboot (reboot the phone out of recovery into normal mode)
3. Now when the phone is ready, test the new key functions you have defined. For me, I had success with the MENU, BACK, CALL and ENVELOPE functions, among others. It is very helpful that I can use ALT-TAB to toggle between running apps.
The main one which I am failing to define is the 'OPEN ALL APPS'. If anyone else is performing mappings such as these for an external bluetooth keyboard, I would be interested to know which functions you have gotten to work. I am now at a state where I can control most everything, provided it is already running in the background. But I can't swipe my Sense desktop left and right, and I have trouble toggling certain switches like Wifi and Mobile data. Any suggestions or thoughts on these functions are appreciated.
Darren
Troubleshooting TIP: You can also run ADB when the phone is running in Normal Mode and you have the USB cable connected from your phoe to the PC. Then you can test certain keypresses through functions that are formatted in this way:
adb shell input keyevent 5
Click to expand...
Click to collapse
On my phone, this function will send the CALL event with brings up the phone from the desktop.
Other examples (you can also launch then from a *.cmd file):
If you have a terminal open on the phone, will send "ls -l"(includes the space-62 and enter-66):
@echo off
adb shell input keyevent 40
adb shell input keyevent 47
adb shell input keyevent 62
adb shell input keyevent 69
adb shell input keyevent 40
adb shell input keyevent 66
Click to expand...
Click to collapse
If you have a terminal open on the phone, will send "env|grep PATH":
@echo off
adb shell input text "env"
adb shell input text "|"
adb shell input text "grep"
adb shell input keyevent 62
adb shell input text "PATH"
adb shell input keyevent 66
Click to expand...
Click to collapse

[Q][DEV] system() call fail when executing native app with su permission

Hi all,
I have run into very disturbing problem when developing a native app with NDK. When my program calls system(), popen() or other function of that kind the return value of system() call is 32512 (which is 127: "command not found"). popen() does not return error code but crashes when trying to read() (returns -1). I have tested this on basic commands such as ls, ps, etc. Tried to provide a full path to the binaries as well without success.
The issue appears only when executing binary with su (I have tried interactive su, su -c and many other variations- I run it via adb shell). When calling system() without su permission then commands are executed correctly. When programmatically reading files in /system/bin (when my program is run with su) I see all files and everything is accessible.
I have verified that su is installed correctly, I can do all kind of root-only stuff without any problem. My program when executed with su permission is able to enter protected areas of Android.
I have tried to switch context without any luck. There is no interesting logcat output that could point to any permission I could allow with supolicy.
This happens on Samsung S3 i9300, S4 i9505, S5 G900F, Note3 N9005...
Happens both on SELinux enforcing and permisive.
Code:
[email protected]:/ $ su -v
2.45:SUPERSU
[email protected]:/ # id
uid=0(root) gid=0(root) context=u:r:init:s0
Any help and clues are much appreciated.
Thanks,
Piotr.

Turns out that the reason is that fork() is prohibited when executable is not located under /system. When placed binary on /system/bin everything works fine.