Is there an ADB push nautilus script out there?
That'll be handy, but i'm no scripting expert. I suspect it'll be bit tricky since adb is terminal only, I'm sure someone will have to figure out a way to pipe the output from terminal to GUI pop up dialog box to display progress bar, with success or failure message.
this one seem to work but no progress bar or success/fail message tho. YMMV
Code:
#/bin/sh
adb push $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS /sdcard
save this as adb_push.sh
be sure to set this file with permission:
Code:
chmod a+x adb_push.sh
think of this as rough draft, not perfect. Above code will push straight to sdcard. Suppose you could create few scripts like this..
ADB - Push to System APP
Code:
#/bin/sh
adb remount
adb push $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS /system/app
ADB - Install APK
Code:
#/bin/sh
adb install $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS
EDIT: Forgot to mention this, it'll work only if you've already set path to Android's SDK tools folder in .bashrc
awesome, thanks! I'll test it in a minute
Simple scrip to push files to your android device.
Just put it in your Nautilus script dir (HOME/.gnome2/nautilus-scripts) and make it executable (chmod +x Push\ sdcard). also set path for ADB inside script (ADB=...)
I did something similar a while back for both Konqueror and Dolphin in KDE, but I realized, I just don't use a file manager since I prefer the command line instead. I had a working ADB zsh completion script, but somehow forgot to back it up before my previous hard drive failure.
https://code.google.com/p/send-to-android/
this is interesting
Does anyone know how to connect your phone, to its own native adb. If your running 4.0 or better like the new 4.0.1 sense on evo 4g lte you have the native adb, in the terminal you can start it by typing adb start-server, but I cannot connect the phone to it.
This is nice to use to connect to other phones and use it as a debug station, but does anyone know how to connect to the phones adb server from the terminal on its own phone. When I start the server it says its listening on 5083 I have tried adb forward tcp:5555 tcp:55, tried adb tcpip 5555, but none of the forwarding ports seems to work. I have started adb on the phone and adb over wifi but still do not see the ip in adb.
Some help on this would be nice, I will keep thinking, but any help would be nice.
Some ideas might be to start a wifi server using the phones wifi tether, or hotspot to connect to itself
ip addr add 192.168.1.10/24 dev eth0
ip addr add 192.168.1.10/24 dev wlan0
maybe we can manually add and connect the devices threw wifi hotspot or tether with this. someone want to take this on and get back to me
Screen shot..
https://www.dropbox.com/sc/69v6co2l4nrd8qg/0PQqlpzI1M
I got the sdk runing natively following this..... http://fieldefect.info/w/NativeCompileAPK
he uses qemu-user-static and an i386 chroot to run the SDK, done natively on arm debian chroot.
I prefer to use multistrap over debootstrap, also I modify his run-i386 scripts to work with x86_64 chroot.
I connect adb to adbd like so,
setprop service.adb.tcp.port 5555
stop adbd
start adbd
adb connect 127.0.0.1
then try
adb shell
or
adb devices
to confirm.
My screenshot has some output from netstat which may answer your questions about ips/ports. you can see localhost
is listening on both 5038 and 5037. port 5037 belongs to adbd. adb will connect to 127.0.0.1:5037 but only gives errors.
PM me if you have questions ill gladly help.
Yea I have a chrooted ubuntu 10.04 img that I have mounted, I was going to do it that way install the sdk and use the localhost. but I was hoping to keep the chroot out of it. At least it works that way very nice. Only reason I didnt want to use a chroot is its gonna be alot of switching between terminals, was hoping for easy way to use 1 terminal. I suppose i can use 2 windows on the one terminal.
Thanks for the post.
as root
Code:
[email protected]:/ adb kill-server
[email protected]:/ adb start-server
[email protected]:/ adb connect 192.168.1.3
unable to connect to 192.168.1.3:5555
[email protected]:/ adb connect 192.168.1.3:5083
unable to connect to 192.168.1.3:5083
[email protected]:/ adb connect 127.0.0.1
unable to connect to 127.0.0.1:5555
[COLOR="Red"][email protected]:/ adb connect 127.0.0.1:5038
connected to 127.0.0.1:5038[/COLOR]
[email protected]:/ adb devices
list of attached devices
234234234234 offline
I got the adb to start and connect, but the phone still says offline. This is all native not with any chroot or anything else. any ideas?
try port 5037
email me about the other thing [email protected]
I connected using the second post like this
terminal #:
#adb kill-server
#stop adbd
#setprop service.adb.tcp.port 5555
#setprop service.adb.tcp.port 5083
#adb connect 127.0.0.1:5083
#adb devices:
127.0.0.1:5083 device
Hello,
I am trying to figure out a way to launch an application from the Android CLI **without** using adb.
**Note. I am connected to the device via SSH on the CLI.
For example:
255|[email protected]:/data/data # am start -a android.intent.action.MAIN -n com.android.browser/.BrowserActivity
[email protected]:/data/data #
In this case nothing happens on the device.
I noticed that other running applications are started with users like u0_a41..
I tried it also as this user
[email protected]:/data/data $ id
uid=10043(u0_a43) gid=10043(u0_a43) groups=0(root)
[email protected]:/data/data $
No dice
I am doubting whether I am able to run the am commands from the CLI on the device.
The thought is to put applications in startup scripts. in init.d somewhere.
**No I do not want to use an app to control startup applications.
Any thoughts?
Thanks in advance.
I recently moved to PA due to various reasons but I miss something from CM: being able to type ssh into Android Terminal Emulator and get a functional result.
PA already includes busybox but CM also includes other binaries such as htop and the one I'm specifically in need, ssh
This addition is not really a big change and would greatly improve the appeal of PA to server admins and such
P4Block said:
I recently moved to PA due to various reasons but I miss something from CM: being able to type ssh into Android Terminal Emulator and get a functional result.
PA already includes busybox but CM also includes other binaries such as htop and the one I'm specifically in need, ssh
This addition is not really a big change and would greatly improve the appeal of PA to server admins and such
Click to expand...
Click to collapse
In the meantime you could install it by yourself. Disclaimer: I hate to do that and would love to see ssh being integrated into PA!!!
I am not allowed to post URLs here, so I will just post the search term for Google and hope that you will find Google by yourself
Steps (rooted phone needed):
- Install an ssh server on the device. What about this one? Play Store or Google: com.icecoldapps.sshserver
- Start a SSH session on the device and log in
- Copy the SSH binaries on the device. SSH, SFTP and SCP as well as libssh.so are available precompiled here:Google: "android-command-line-ssh code google"
- Become root in the SSH session on the device:
su
- Remount the system partition in read-write:
mount -o remount,rw /system
- copy binaries to /system/bin:
cp ssh /system/bin/
cp scp /system/bin/
cp sftp /system/bin/
- Adjust the permissions
chmod 555 /system/bin/ssh
chmod 555 /system/bin/scp
chmod 555 /system/bin/sftp
- copy libssh.sp to /system/lib/:
cp libssh.so /system/lib/
- adjust permissions:
chmod 555 /system/lib/libssh.so
- remount /system in read-only
mount -o remount,ro /system
Done!
Cheers, Marshell
I prefer juicessh so it can keep bookmarks for all the servers I have to touch.
Sent from my Nexus 5
Pirateghost said:
I prefer juicessh so it can keep bookmarks for all the servers I have to touch.
Sent from my Nexus 5
Click to expand...
Click to collapse
Fair enough. I use JuicySSH myself and it is great - it is just that the native ssh client binary is scriptable, e.g. with gscript, which is not possible (or just barely possible with intents) from the command line.
Just another use case.
Best regards,
Marshell
We should talk about including not only ssh but some Linux tools for advanced users.
Any news regarding the integration of ssh into Paranoid Android? It would be a great help for administrators.
AddiB said:
Any news regarding the integration of ssh into Paranoid Android? It would be a great help for administrators.
Click to expand...
Click to collapse
I guess we all use JuiceSSH...
I have a rooted a GT-I9195 (SGS4-mini) done with CF-Auto-Root and the latest Busybox. I then decided to use the "Ssh server" from The Olive Tree, since it is simple, small, free, but unfortunately have ads. For on-device/local shell, I use the Android Terminal Emulator and everything works great, including su and shell environment.
However, I have a really strange bahaviour when connecting using ssh via WiFi, and trying to su.
First when connecting via ssh, I get the following message.
Code:
[SIZE=2]$ ssh -2 -4 -t [email protected] -p 50555
Authenticated with partial success.
[email protected]'s password:
/system/bin/sh: No controlling tty: open /dev/tty: No such device or address
/system/bin/sh: can't find tty fd
/system/bin/sh: warning: won't have full job control
[email protected]:/ $[/SIZE]
I have Googled this and there's little useful info. On one site they even say:
Code:
[SIZE=2]Getting a controlling tty
[B]How does one get a controlling terminal? [COLOR=Red]Nobody knows[/COLOR], this is a great mystery.[/B]
The System V approach is that the first tty opened by the process
becomes its controlling tty. The BSD approach is that one has to
explicitly call
ioctl(fd, TIOCSCTTY, ...);
to get a controlling tty.
Linux tries to be compatible with both, as always, and this results in
a very obscure complex of conditions. Roughly:
The [B]TIOCSCTTY [/B]ioctl will give us a controlling tty, provided that (i)
the current process is a session leader, and (ii) it does not yet have
a controlling tty, and (iii) maybe the tty should not already control
some other session; if it does it is an error if we aren't root, or we
steal the tty if we are all-powerful.
Opening some terminal will give us a controlling tty, provided that
(i) the current process is a session leader, and (ii) it does not yet
have a controlling tty, and (iii) the tty does not already control
some other session, and (iv) the open did not have the [B]O_NOCTTY[/B] flag,
and (v) the tty is not the foreground VT, and (vi) the tty is not the
console, and (vii) maybe the tty should not be master or slave pty.
[/SIZE]
Now this is not the end of the world, if it was not that it doesn't understand normal terminal control characters and in addition, when I do su, I loose the command prompt. However, using the "-i" (interactive) switch gets me the "#" prompt, but environment is still completely messed up:
Code:
[SIZE=2][email protected]:/ $ [B]su -c /system/bin/sh -i[/B]
/system/bin/sh: No controlling tty: open /dev/tty: No such device or address
/system/bin/sh: can't find tty fd
/system/bin/sh: warning: won't have full job control
[email protected]:/ #[/SIZE]
I've never had or seen this issue before. Any ideas?
(Also, where would I put a source to my .bashrc and make sure it runs when su'ing or ssh?)
PS. The phone is using a stock 4.2.2 SELinux kernel.
Code:
[SIZE=2]Device: Samsung Galaxy S4 Mini LTE (GT-I9195)
Board/Platform: MSM8930AB (Snapdragon 400)
Baseband: I9195XXUBML4
Kernel: 3.4.0-2340422
[email protected] #1
Build: JDQ39.I9195XXUBML4
SE: SEPF_GT-I9195_4.2.2_0022
ro.build.date: Sat Dec 21 01:46:00 KST 2013
ro.build.description: serranoltexx-user 4.2.2 JDQ39 I9195XXUBML4
[/SIZE]
I still have no idea of what's causing those error messages above, also because logcat is not telling us anything interesting either. Only as Warning from "System.err", but without any useful information. However, I have got some improvement in the terminal behavior when doing the initial ssh connection.
One problem seem to be that the TERM environment variable was copied from local machine (PC side) to remote server (Android phone), thus giving TERM=cygwin to the Android shell. This can be disabled or changed as follows.
Some relevant SSH options:
Code:
[SIZE=2]
-e escape_char
Sets the escape character for sessions with a pty (default: `~'). The escape
character is only recognized at the beginning of a line. The escape charac-
ter followed by a dot (`.') closes the connection; followed by control-Z sus-
pends the connection; and followed by itself sends the escape character once.
Setting the character to "none" disables any escapes and makes the session
fully transparent.
-T Disable pseudo-tty allocation.
-t Force pseudo-tty allocation. This can be used to execute arbitrary screen-
based programs on a remote machine, which can be very useful, e.g. when
implementing menu services. Multiple -t options force tty allocation, even
if ssh has no local tty.
[/SIZE]
Some relevant SSH -o options:
Code:
[SIZE=2][B]RequestTTY[/B]
Specifies whether to request a pseudo-tty for the session. The argument may
be one of: "no" (never request a TTY), "yes" (always request a TTY when stan-
dard input is a TTY), "force" (always request a TTY) or "auto" (request a TTY
when opening a login session). This option mirrors the -t and -T flags for
ssh(1).
[B]
SendEnv[/B]
Specifies what variables from the local environ(7) should be sent to the
server. Note that environment passing is only supported for protocol 2. The
server must also support it, and the server must be configured to accept
these environment variables. Refer to AcceptEnv in sshd_config(5) for how to
configure the server. Variables are specified by name, which may contain
wildcard characters. Multiple environment variables may be separated by
whitespace or spread across multiple SendEnv directives. The default is not
to send any environment variables.
[/SIZE]
So by using the ssh -T option (which is equivalent to using '-o RequestTTY="no"'), we are disabling "pseudo-tty allocation" which doesn't work anyway, but with the effect of not forwarding local TERM to server, and thus setting it to default "vt100" which accepts backspace (but not insert). But a better way is to actually set the TERM variable on our own. This is done by simply adding it as a prefix to the ssh command like this:
Code:
[SIZE=2]TERM=[B]vt220[/B] ssh -t [email protected] -p 50555[/SIZE]
(This effectively, but temporarily overrides the local TERM value and forwards it to remote server shell.)
RanTime!
Since Google intruduced the SELinux/SEAndroid features, they have essentially fukced up the entire AOS ecosystem as based on good-old normal Linux environments and all the years of standards therein. Basically nothing works as before and as logically intended or preferred and I bet from now on, developers will have to spend a significant and expensive time, on just trying to setup their various developer environments and jump through the hoops of dikchead Google engineers, rather than on actual developing. A very sad story all thanks to the populist "security" eye-candy marketing.
The SU time!
Apparently after having read about the various quirks and issues in using an SELinux Enforced based AOS {4}, it seem that the issue from OP is probably due to one of 3 things or a combination thereof.
My su binary (SuperSU 1.94) is not yet handling SElinux properly
The SSHd server is not handling SELinux properly
Lack of properly set SSH and SHELL environment files on the server side
As for (1) I just have to wait and see. For (2) we can only test with other SSHd servers/solutions which I don't know what to use. (They're all, either not free or full of ads. WTF!) And finally, for (3) we can only test, since I don't have the source code...
Unfortunately listing the SuperSU (1.94) command line options is not very helpful, since they're rather poorly explained. While some of the option themselves just doesn't work (for me). It would have been great if @Chainfire could write a more detailed how-to {2} for all these options, but then again we should be extremely grateful he's written anything at all.
Code:
[SIZE=2]Usage: su [options] [--] [-] [LOGIN] [--] [args...]
------------------------------------------------------------------------------------
Options:
-c, --command COMMAND pass COMMAND to the invoked shell
-cn, --context CONTEXT switch to SELinux CONTEXT before invoking
-h, --help display this help message and exit
-, -l, --login pretend the shell to be a login shell
-m, -p,
-mm, --mount-master connect to a shell that can manipulate the
master mount namespace - requires su to be
running as daemon, must be first parameter
--preserve-environment do not change environment variables
-s, --shell SHELL use SHELL instead of the default detected shell
-v, --version display public version and exit
-V display internal version and exit
Usage#2: su LOGIN COMMAND...
Usage#3: su {-d|--daemon|-ad|--auto-daemon|-r|--reload}
auto version starts daemon only on SDK >= 18 or
if SELinux is set to enforcing
Usage#4: su {-i|--install|-u|--uninstall}
perform post-install / pre-uninstall maintenance
[/SIZE]
References:
[1] [Chainfire G+] Next Android version: even more breakage
[2] [Chainfire] How-To SU (Guidelines for problem-free su usage)
[3] SuperSU Download
[4] [Google] Validating Security-Enhanced Linux in Android
From THIS very old post by @mirabilos , it is possible that command-line TAB-completion and up-arrow is not working on all mksh binaries. So perhaps we just need a new static mksh binary installed?
Tab expansion is pretty broken on BSD with xterm and GNU screen, but the same seems to work better on ssh’ing out to Linux, I wonder why, since all software involved is the same… except tput though. But it works like that and is usable. With post-R40 mksh, you can get about with even less hacks (more similarity to AT&T ksh).
Click to expand...
Click to collapse
However, this still doesn't explain why I have no controlling tty for ssh sessions.
Also I tested a new and different SSH server called SSHelper, which has more features and is better maintained, without ads, but is also 6 times larger at ~ 6MB, because of included OpenSSH, FTP and webserver log functionality. When logging in via ssh I get:
Code:
...
Server refused to allocate pty
Followed by an empty non-responsive connection.
Is this the same as […]this problem elsewhere? Man, I'm searching for ideas and keep coming back to your questions all over the 'net
To clarify, I talked to someone at Google; they renamed mksh into just sh lately, but this should have no adverse effect. They currently ship R48 and “would have updated it if I knew there was a new version”. That being said, the code of the shell itself is not at fault here.
The “no controlling tty” message here is a red herring: you do not have access to a tty at all, let alone a ctty
As I said elsewhere, use “ssh -t” and either change the SELinux policies to allow pty/tty pair allocation, or disable it (possibly set it into permissive mode).
@mirabilos: Yes, thanks for that info. I haven't updated this thread since I started it, in anticipation of a writeup about SELinux. However, that proves to be a little over my head, so it will take some time. What is clear though, is that the above problem is connected with the SEAndroid protection mechanisms, which in turn have been mangled and incorporated into Samsungs KNOX.
Also I have been busy making the SSHelper support thread:
[APP][INFO|SUPPORT] SSHelper (The free Android SSH Server Application)
There I have also added a small section about mksh.
@ E:V:A - I recently put together a little package containing all necessary bins/scripts to create a SSH server (via dropbear and dropbearkey) (properly secured, not public) and connect with a SSH client (ssh). The package also contains bins/scripts to create a Telnet server (via utelnetd) and connect with Telnet client (via "static busybox" telnet). Everything works with superuser that I've tested. Linked in my signature and attached to post as well.
Instructions (for anyone who sees this and would like a guide)::
Basically just extract it anywhere with:
Code:
tar -xf easy.ssh.and.telnetz.clients+servers.tar.gz
(if it's in /sdcard/Download which is probable, do "cd /sdcard/Download" then run the above)
Change directory inside the folder:
Code:
cd ./ssh.telnetz
There are 6 scripts: ssh.start(connect to ssh server via ssh), sshd.start(create ssh server), ssh.kill(kill ssh processes and remove ssh server keys), and... 3x telnet scripts for the telnet equivalents.
Running scripts and optional parameters:
Code:
./telnetd.start [ shell ]
e.g. TELNET_PORT=8080 ./telnetd.start /system/bin/mksh
./telnet.start [ ip port ]
e.g. ./telnet.start 192.168.0.3 8080
./sshd.start [ <dropbear_flags_and_options ]
e.g. ./sshd.start (default port is 8090)
./ssh.start [ ip port shell ]
e.g. ./ssh.start 192.168.0.3 8090 /system/bin/mksh
Default ip is the loopback 127.0.0.1 so you can test running a server and connecting to it on your phone at the same time. Just change params as described above to connect from/to your phone (phone is client/server).
***As far as I have tested on Android 4.4.4, this works perfectly as root or restricted user. You can get a su'd ssh shell by starting the sshd.start with /system/xbin/su or just entering su after you've connected as a restricted user.***
I've finally found a work-around for the crippled /dev/pts job-control and su combination. There are two small problems that combines to this issue.
1. The SELinux policy is screwed up by Samsung. And others?
2. The /dev/pts is mounted wrong by default.
The work-around:
Make sure you're device is already in Enforcing mode, so that you get the proper su prompt (#).
1. Open terminal session 1.
Code:
[SIZE=2]
## On Terminal 1
ssh -2 [email protected] -p 2222
$ su -c /system/bin/sh -i
# su 0 setenforce 0
# umount /dev/pts
# su -cn u:r:init:s0 -c "busybox mount -t devpts -o rw,seclabel,relatime,mode=620,gid=5 devpts /dev/pts"[/SIZE]
2. Now go to Terminal 2 and login:
Code:
[SIZE=2]## On terminal 2
ssh -2 [email protected] -p 2222
$
[/SIZE]
(You now have job-control but no su possibility.)
3. Now go back to Terminal 1 and enable Enforcing mode:
Code:
[SIZE=2]## On Terminal 1
# su 0 setenforce 1
[/SIZE]
4. Now go back to Terminal 2 and escalate to su:
Code:
[SIZE=2]## On terminal 2
$ su -c /system/bin/sh -i
# [/SIZE]
Unfortunately if you exit the su (#) shell, you'll have to repeat steps 2-4 of the procedure.