Bug P4
Status Update
No update yet.
Comments
jm...@google.com
SDK Revision 5
fk...@gmail.com
Successful workaround: Kill the ADB process if it does not return within 120 seconds.
jm...@google.com
I've seen the same problem on rare occasion -- I believe on both 32-bit and 64-bit machines (all running Ubuntu).
This scenario is from an Amazon EC2 instance running Ubuntu 10.04.
== Long-running processes involved:
* PID 4440 adb (daemon)
* PID 5396 adb -s localhost:52384 install -r MyApp-debug.apk
* PID 5216 emulator -ports 38007,52384 -no-boot-anim -prop persist.sys.language=de -prop persist.sys.country=DE -avd hudson_de-DE_240_WVGA_android-8 -no-window
== Commands run:
* adb daemon was (presumably) already running
* emulator is started as above
* `adb connect localhost:52384`
* `adb logcat -v time` is left running in the background
* `adb install` below is run once emulator is ready
adb -s localhost:52384 install -r MyApp-debug.apk
116 KB/s (57642 bytes in 0.482s)
pkg: /data/local/tmp/MyApp-debug.apk
Success
** hangs here indefinitely without returning (despite "Success") **
== Investigation
* `ps` shows that the hung `adb install` process has PID 5396
root@ip-10-228-211-159:~# strace -p 5396
Process 5396 attached - interrupt to quit
read(4, ^C <unfinished ...>
Process 5396 detached
* adb is blocked reading from FD 4 -- what is that?
root@ip-10-228-211-159:~# ls -l /proc/5396/fd/
total 0
lr-x------ 1 root root 64 2010-09-12 12:26 0 -> pipe:[135089]
l-wx------ 1 root root 64 2010-09-12 12:26 1 -> pipe:[135090]
l-wx------ 1 root root 64 2010-09-12 12:26 2 -> pipe:[135090]
lrwx------ 1 root root 64 2010-09-12 12:26 3 -> socket:[135142]
lrwx------ 1 root root 64 2010-09-12 12:26 4 -> socket:[136177]
root@ip-10-228-211-159:~# lsof | grep 136177
adb 5396 root 4u IPv4 136177 0t0 TCP localhost:51221->localhost:5037 (ESTABLISHED)
root@ip-10-228-211-159:~# netstat -antp | grep LISTEN
tcp 0 0127.0.0.1:5037 0.0.0.0:* LISTEN 4440/adb
tcp 0 00.0.0.0:22 0.0.0.0:* LISTEN 406/sshd
tcp 0 0127.0.0.1:38007 0.0.0.0:* LISTEN 5216/emulator
tcp 0 0127.0.0.1:52384 0.0.0.0:* LISTEN 5216/emulator
* So we're waiting to read from port 5037 -- the adb daemon (PID 4440)?
root@ip-10-228-211-159:~# strace -tt -T -p 4440
Process 4440 attached - interrupt to quit
12:28:55.909470 select(26, [4 5 14 18 25], [], [], NULL^C <unfinished ...>
Process 4440 detached
* It's blocking in select(), waiting for FD 26 to become ready. What's that?
root@ip-10-228-211-159:~# ls -l /proc/4440/fd/
total 0
lr-x------ 1 root root 64 2010-09-12 12:27 0 -> /dev/null
l-wx------ 1 root root 64 2010-09-12 12:27 1 -> /tmp/adb.log
lrwx------ 1 root root 64 2010-09-12 12:27 14 -> socket:[133791]
lrwx------ 1 root root 64 2010-09-12 12:27 15 -> socket:[133790]
lrwx------ 1 root root 64 2010-09-12 12:27 16 -> socket:[133792]
lrwx------ 1 root root 64 2010-09-12 12:27 18 -> socket:[133949]
l-wx------ 1 root root 64 2010-09-12 12:27 2 -> /tmp/adb.log
lrwx------ 1 root root 64 2010-09-12 12:27 25 -> socket:[136178]
lrwx------ 1 root root 64 2010-09-12 12:27 3 -> socket:[127504]
lrwx------ 1 root root 64 2010-09-12 12:27 4 -> socket:[127505]
lrwx------ 1 root root 64 2010-09-12 12:27 5 -> socket:[127506]
lr-x------ 1 root root 64 2010-09-12 12:27 6 -> /dev/null
l-wx------ 1 root root 64 2010-09-12 12:27 7 -> /tmp/adb.log
root@ip-10-228-211-159:~# ls -l /proc/4440/fd/26
ls: cannot access /proc/4440/fd/26: No such file or directory
* Hmm.. it doesn't exist?
* Ok, let's see what the server does when we manually kill the `adb install` process (PID 5396), at time 12:32:50:
root@ip-10-228-211-159:~# strace -tt -T -p 4440
Process 4440 attached - interrupt to quit
12:32:43.366720 select(26, [4 5 14 18 25], [], [], NULL) = 1 (in [25]) <7.274112>
12:32:50.641019 read(25, "", 4096) = 0 <0.000015>
12:32:50.641596 write(14, "\20R\6\t", 4) = 4 <0.000061>
12:32:50.641711 close(25) = 0 <0.000058>
12:32:50.641805 select(26, [4 5 14 18], [], [], NULL) = 1 (in [14]) <0.002506>
12:32:50.644385 read(14, "\20r\6\t", 4) = 4 <0.000025>
12:32:50.644470 select(26, [4 5 14 18], [], [], NULL) = 1 (in [5]) <0.281615>
12:32:50.926206 accept(5, {sa_family=AF_INET, sin_port=htons(44907), sin_addr=inet_addr("127.0.0.1")}, [16]) = 8 <0.000043>
12:32:50.926370 setsockopt(8, SOL_SOCKET, SO_RCVBUF, [65536], 4) = 0 <0.000030>
12:32:50.926477 fcntl64(8, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 <0.000053>
12:32:50.926651 select(26, [4 5 8 14 18], [], [], NULL) = 1 (in [8]) <0.000015>
12:32:50.926727 read(8, "000chost:version", 4096) = 16 <0.000020>
12:32:50.926787 read(8, 0x9067244, 4080) = -1 EAGAIN (Resource temporarily unavailable) <0.000013>
12:32:50.926860 write(8, "OKAY0004001a", 12) = 12 <0.000037>
12:32:50.926943 close(8) = 0 <0.000053>
12:32:50.927031 select(19, [4 5 14 18], [], [], NULL) = 1 (in [5]) <0.000037>
12:32:50.927144 accept(5, {sa_family=AF_INET, sin_port=htons(44908), sin_addr=inet_addr("127.0.0.1")}, [16]) = 8 <0.000035>
12:32:50.927251 setsockopt(8, SOL_SOCKET, SO_RCVBUF, [65536], 4) = 0 <0.000029>
12:32:50.927334 fcntl64(8, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 <0.000029>
12:32:50.927433 select(19, [4 5 8 14 18], [], [], NULL) = 1 (in [8]) <0.000030>
12:32:50.927526 read(8, "001fhost:disconnect:localhost:52"..., 4096) = 35 <0.000033>
12:32:50.927623 read(8, 0x9067257, 4061) = -1 EAGAIN (Resource temporarily unavailable) <0.000028>
12:32:50.927729 shutdown(15, 2 /* send and receive */) = 0 <0.000053>
12:32:50.927825 close(15) = 0 <0.000028>
12:32:50.934829 close(16) = 0 <0.000062>
12:32:50.934959 write(3, "\260\237\5\t\0\0\0\0", 8) = 8 <0.000036>
12:32:50.935064 write(8, "OKAY0000", 8) = 8 <0.000048>
12:32:50.935154 close(8) = 0 <0.000032>
12:32:50.935233 select(19, [4 5 14 18], [], [], NULL) = 2 (in [4 14]) <0.000015>
12:32:50.935290 read(4, "\260\237\5\t\0\0\0\0", 8) = 8 <0.000141>
12:32:50.935470 close(14PANIC: attached pid 4440 exited with 255
<unfinished ... exit status 255>
* Not so good.
This scenario is from an Amazon EC2 instance running Ubuntu 10.04.
== Long-running processes involved:
* PID 4440 adb (daemon)
* PID 5396 adb -s localhost:52384 install -r MyApp-debug.apk
* PID 5216 emulator -ports 38007,52384 -no-boot-anim -prop persist.sys.language=de -prop persist.sys.country=DE -avd hudson_de-DE_240_WVGA_android-8 -no-window
== Commands run:
* adb daemon was (presumably) already running
* emulator is started as above
* `adb connect localhost:52384`
* `adb logcat -v time` is left running in the background
* `adb install` below is run once emulator is ready
adb -s localhost:52384 install -r MyApp-debug.apk
116 KB/s (57642 bytes in 0.482s)
pkg: /data/local/tmp/MyApp-debug.apk
Success
** hangs here indefinitely without returning (despite "Success") **
== Investigation
* `ps` shows that the hung `adb install` process has PID 5396
root@ip-10-228-211-159:~# strace -p 5396
Process 5396 attached - interrupt to quit
read(4, ^C <unfinished ...>
Process 5396 detached
* adb is blocked reading from FD 4 -- what is that?
root@ip-10-228-211-159:~# ls -l /proc/5396/fd/
total 0
lr-x------ 1 root root 64 2010-09-12 12:26 0 -> pipe:[135089]
l-wx------ 1 root root 64 2010-09-12 12:26 1 -> pipe:[135090]
l-wx------ 1 root root 64 2010-09-12 12:26 2 -> pipe:[135090]
lrwx------ 1 root root 64 2010-09-12 12:26 3 -> socket:[135142]
lrwx------ 1 root root 64 2010-09-12 12:26 4 -> socket:[136177]
root@ip-10-228-211-159:~# lsof | grep 136177
adb 5396 root 4u IPv4 136177 0t0 TCP localhost:51221->localhost:5037 (ESTABLISHED)
root@ip-10-228-211-159:~# netstat -antp | grep LISTEN
tcp 0 0
tcp 0 0
tcp 0 0
tcp 0 0
* So we're waiting to read from port 5037 -- the adb daemon (PID 4440)?
root@ip-10-228-211-159:~# strace -tt -T -p 4440
Process 4440 attached - interrupt to quit
12:28:55.909470 select(26, [4 5 14 18 25], [], [], NULL^C <unfinished ...>
Process 4440 detached
* It's blocking in select(), waiting for FD 26 to become ready. What's that?
root@ip-10-228-211-159:~# ls -l /proc/4440/fd/
total 0
lr-x------ 1 root root 64 2010-09-12 12:27 0 -> /dev/null
l-wx------ 1 root root 64 2010-09-12 12:27 1 -> /tmp/adb.log
lrwx------ 1 root root 64 2010-09-12 12:27 14 -> socket:[133791]
lrwx------ 1 root root 64 2010-09-12 12:27 15 -> socket:[133790]
lrwx------ 1 root root 64 2010-09-12 12:27 16 -> socket:[133792]
lrwx------ 1 root root 64 2010-09-12 12:27 18 -> socket:[133949]
l-wx------ 1 root root 64 2010-09-12 12:27 2 -> /tmp/adb.log
lrwx------ 1 root root 64 2010-09-12 12:27 25 -> socket:[136178]
lrwx------ 1 root root 64 2010-09-12 12:27 3 -> socket:[127504]
lrwx------ 1 root root 64 2010-09-12 12:27 4 -> socket:[127505]
lrwx------ 1 root root 64 2010-09-12 12:27 5 -> socket:[127506]
lr-x------ 1 root root 64 2010-09-12 12:27 6 -> /dev/null
l-wx------ 1 root root 64 2010-09-12 12:27 7 -> /tmp/adb.log
root@ip-10-228-211-159:~# ls -l /proc/4440/fd/26
ls: cannot access /proc/4440/fd/26: No such file or directory
* Hmm.. it doesn't exist?
* Ok, let's see what the server does when we manually kill the `adb install` process (PID 5396), at time 12:32:50:
root@ip-10-228-211-159:~# strace -tt -T -p 4440
Process 4440 attached - interrupt to quit
12:32:43.366720 select(26, [4 5 14 18 25], [], [], NULL) = 1 (in [25]) <7.274112>
12:32:50.641019 read(25, "", 4096) = 0 <0.000015>
12:32:50.641596 write(14, "\20R\6\t", 4) = 4 <0.000061>
12:32:50.641711 close(25) = 0 <0.000058>
12:32:50.641805 select(26, [4 5 14 18], [], [], NULL) = 1 (in [14]) <0.002506>
12:32:50.644385 read(14, "\20r\6\t", 4) = 4 <0.000025>
12:32:50.644470 select(26, [4 5 14 18], [], [], NULL) = 1 (in [5]) <0.281615>
12:32:50.926206 accept(5, {sa_family=AF_INET, sin_port=htons(44907), sin_addr=inet_addr("127.0.0.1")}, [16]) = 8 <0.000043>
12:32:50.926370 setsockopt(8, SOL_SOCKET, SO_RCVBUF, [65536], 4) = 0 <0.000030>
12:32:50.926477 fcntl64(8, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 <0.000053>
12:32:50.926651 select(26, [4 5 8 14 18], [], [], NULL) = 1 (in [8]) <0.000015>
12:32:50.926727 read(8, "000chost:version", 4096) = 16 <0.000020>
12:32:50.926787 read(8, 0x9067244, 4080) = -1 EAGAIN (Resource temporarily unavailable) <0.000013>
12:32:50.926860 write(8, "OKAY0004001a", 12) = 12 <0.000037>
12:32:50.926943 close(8) = 0 <0.000053>
12:32:50.927031 select(19, [4 5 14 18], [], [], NULL) = 1 (in [5]) <0.000037>
12:32:50.927144 accept(5, {sa_family=AF_INET, sin_port=htons(44908), sin_addr=inet_addr("127.0.0.1")}, [16]) = 8 <0.000035>
12:32:50.927251 setsockopt(8, SOL_SOCKET, SO_RCVBUF, [65536], 4) = 0 <0.000029>
12:32:50.927334 fcntl64(8, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 <0.000029>
12:32:50.927433 select(19, [4 5 8 14 18], [], [], NULL) = 1 (in [8]) <0.000030>
12:32:50.927526 read(8, "001fhost:disconnect:localhost:52"..., 4096) = 35 <0.000033>
12:32:50.927623 read(8, 0x9067257, 4061) = -1 EAGAIN (Resource temporarily unavailable) <0.000028>
12:32:50.927729 shutdown(15, 2 /* send and receive */) = 0 <0.000053>
12:32:50.927825 close(15) = 0 <0.000028>
12:32:50.934829 close(16) = 0 <0.000062>
12:32:50.934959 write(3, "\260\237\5\t\0\0\0\0", 8) = 8 <0.000036>
12:32:50.935064 write(8, "OKAY0000", 8) = 8 <0.000048>
12:32:50.935154 close(8) = 0 <0.000032>
12:32:50.935233 select(19, [4 5 14 18], [], [], NULL) = 2 (in [4 14]) <0.000015>
12:32:50.935290 read(4, "\260\237\5\t\0\0\0\0", 8) = 8 <0.000141>
12:32:50.935470 close(14PANIC: attached pid 4440 exited with 255
<unfinished ... exit status 255>
* Not so good.
[Deleted User] <[Deleted User]>
[Comment deleted]
[Deleted User] <[Deleted User]>
I've met almost the same problem, without 'Success' printed out.
My env: Mac OS 10.6.5 i386, sdk r07 with latest platform packages.
my test script to reproduce:
i=0
while [ 1 ] ; do
let i=$i+1
echo "========== $i ==============="
adb install -r Test.apk
done
output:
========== 1 ===============
1255 KB/s (137164 bytes in 0.106s)
pkg: /data/local/tmp/Test.apk
Success
========== 2 ===============
1882 KB/s (137164 bytes in 0.071s)
pkg: /data/local/tmp/Test.apk
Success
^A========== 3 ===============
1830 KB/s (137164 bytes in 0.073s)
^A pkg: /data/local/tmp/Test.apk
Success
========== 4 ===============
1695 KB/s (137164 bytes in 0.079s)
pkg: /data/local/tmp/Test.apk
Success
========== 5 ===============
1905 KB/s (137164 bytes in 0.070s)
pkg: /data/local/tmp/Test.apk
Success
========== 6 ===============
1849 KB/s (137164 bytes in 0.072s)
---> hangs here, then use gdb to get the stack trace:
$ ps ax|grep adb
11587 ?? S 0:01.31 adb fork-server server
15773 s001 S+ 0:00.00 grep adb
15757 s003 S+ 0:00.01 adb install -r Test.apk
$ gdb adb 15757
(gdb) bt
#0 0x9503b459 in read$UNIX2003 ()
#1 0x00009c34 in read_and_dump ()
#2 0x0000c1d7 in send_shellcommand ()
#3 0x0000c30c in pm_command ()
#4 0x0000c516 in install_app ()
#5 0x0000b940 in adb_commandline ()
#6 0x000042b6 in start ()
it seems in system/core/adb/commandline.c, adb_read expects a 4096 byte result but never returns ...
static void read_and_dump(int fd)
{
char buf[4096];
int len;
while(fd >= 0) {
len = adb_read(fd, buf, 4096);
if(len == 0) {
break;
}
if(len < 0) {
if(errno == EINTR) continue;
break;
}
fwrite(buf, 1, len, stdout);
fflush(stdout);
}
}
My env: Mac OS 10.6.5 i386, sdk r07 with latest platform packages.
my test script to reproduce:
i=0
while [ 1 ] ; do
let i=$i+1
echo "========== $i ==============="
adb install -r Test.apk
done
output:
========== 1 ===============
1255 KB/s (137164 bytes in 0.106s)
pkg: /data/local/tmp/Test.apk
Success
========== 2 ===============
1882 KB/s (137164 bytes in 0.071s)
pkg: /data/local/tmp/Test.apk
Success
^A========== 3 ===============
1830 KB/s (137164 bytes in 0.073s)
^A pkg: /data/local/tmp/Test.apk
Success
========== 4 ===============
1695 KB/s (137164 bytes in 0.079s)
pkg: /data/local/tmp/Test.apk
Success
========== 5 ===============
1905 KB/s (137164 bytes in 0.070s)
pkg: /data/local/tmp/Test.apk
Success
========== 6 ===============
1849 KB/s (137164 bytes in 0.072s)
---> hangs here, then use gdb to get the stack trace:
$ ps ax|grep adb
11587 ?? S 0:01.31 adb fork-server server
15773 s001 S+ 0:00.00 grep adb
15757 s003 S+ 0:00.01 adb install -r Test.apk
$ gdb adb 15757
(gdb) bt
#0 0x9503b459 in read$UNIX2003 ()
#1 0x00009c34 in read_and_dump ()
#2 0x0000c1d7 in send_shellcommand ()
#3 0x0000c30c in pm_command ()
#4 0x0000c516 in install_app ()
#5 0x0000b940 in adb_commandline ()
#6 0x000042b6 in start ()
it seems in system/core/adb/commandline.c, adb_read expects a 4096 byte result but never returns ...
static void read_and_dump(int fd)
{
char buf[4096];
int len;
while(fd >= 0) {
len = adb_read(fd, buf, 4096);
if(len == 0) {
break;
}
if(len < 0) {
if(errno == EINTR) continue;
break;
}
fwrite(buf, 1, len, stdout);
fflush(stdout);
}
}
pi...@gmail.com
I experienced the same problem several times. This is kind of a blocker for me as my regression test system uses adb commands repeatedly.
Experienced hang for "install","uninstall","shell" commands.
Host OS: Windows 7
SDK tools version (available in the "About" section of the 'android' tool
UI): Revision 10
Platform targeted by your project: 2.2
Version of the platform running in the emulator: 2.2
Experienced hang for "install","uninstall","shell" commands.
Host OS: Windows 7
SDK tools version (available in the "About" section of the 'android' tool
UI): Revision 10
Platform targeted by your project: 2.2
Version of the platform running in the emulator: 2.2
dr...@gmail.com
I had this problem too until I restarted the usb daemon using the command "adb usb" and it works
lc...@gmail.com
The point here is we shouldn't HAVE to restart the daemon.
ci...@gmail.com
There is a case where issuing "adb usb" does not reestablish the device in the device list produced via "adb devices". The device can be resuscitated by disabling "USB debugging" and then enabling it again using the Settings -> Applications -> Development settings menu.
em...@gmail.com
WORKAROUND: Calling adb_proxy.py in place of adb directly will greatly improve reliability.
[Deleted User] <[Deleted User]>
I am seeing a similar issue collecting logcat logs. In my case I am connecting to on the order of 30 devices over TCP with logcat, in which I occasionally have to disconnect and reconnect devices. Eventually (between 1 and 12 hours) the adb server just completely stops responding to commands. I have to send SIGKILL to the server process to kill it so I can restart it. I grabbed a stack trace from one hung adb server process:
[Current thread is 1 (Thread 0xf77c96d0 (LWP 15086))]
(gdb) bt
#0 0x00505430 in __kernel_vsyscall ()
#1 0x49909521 in __lll_lock_wait_private () from /lib/libc.so.6
#2 0x49895c6c in _L_lock_11025 () from /lib/libc.so.6
#3 0x49894067 in malloc () from /lib/libc.so.6
#4 0x498894b7 in __libc_message () from /lib/libc.so.6
#5 0x498921ed in _int_malloc () from /lib/libc.so.6
#6 0x49894070 in malloc () from /lib/libc.so.6
#7 0x498894b7 in __libc_message () from /lib/libc.so.6
#8 0x49890fb6 in _int_free () from /lib/libc.so.6
#9 0x080532d3 in local_socket_destroy (s=0x91175e8) at system/core/adb/sockets.c:215
#10 local_socket_close_locked (s=0x91175e8) at system/core/adb/sockets.c:235
#11 0x0805337d in local_socket_close (s=0x91175e8) at system/core/adb/sockets.c:194
#12 0x0805379c in remote_socket_disconnect (_s=0x9117dc0, t=0x9117688) at system/core/adb/sockets.c:477
#13 0x0804c5a2 in run_transport_disconnects (t=0x9117688) at system/core/adb/transport.c:85
#14 0x0804e53d in transport_registration_func (_fd=28, ev=<value optimized out>, data=0x0)
at system/core/adb/transport.c:589
#15 0x08059092 in fdevent_loop () at system/core/adb/fdevent.c:502
#16 0x0804b98f in adb_main (is_daemon=1, server_port=5037) at system/core/adb/adb.c:975
#17 0x08050bbe in adb_commandline (argc=0, argv=0xffccdc40) at system/core/adb/commandline.c:774
#18 0x0804aaa2 in main (argc=3, argv=0xffccdc34) at system/core/adb/adb.c:1274
Platform target: 2.2
Device platform: 2.2
SDK Tools: 11
SDK Platform-tools: 4
[Current thread is 1 (Thread 0xf77c96d0 (LWP 15086))]
(gdb) bt
#0 0x00505430 in __kernel_vsyscall ()
#1 0x49909521 in __lll_lock_wait_private () from /lib/libc.so.6
#2 0x49895c6c in _L_lock_11025 () from /lib/libc.so.6
#3 0x49894067 in malloc () from /lib/libc.so.6
#4 0x498894b7 in __libc_message () from /lib/libc.so.6
#5 0x498921ed in _int_malloc () from /lib/libc.so.6
#6 0x49894070 in malloc () from /lib/libc.so.6
#7 0x498894b7 in __libc_message () from /lib/libc.so.6
#8 0x49890fb6 in _int_free () from /lib/libc.so.6
#9 0x080532d3 in local_socket_destroy (s=0x91175e8) at system/core/adb/sockets.c:215
#10 local_socket_close_locked (s=0x91175e8) at system/core/adb/sockets.c:235
#11 0x0805337d in local_socket_close (s=0x91175e8) at system/core/adb/sockets.c:194
#12 0x0805379c in remote_socket_disconnect (_s=0x9117dc0, t=0x9117688) at system/core/adb/sockets.c:477
#13 0x0804c5a2 in run_transport_disconnects (t=0x9117688) at system/core/adb/transport.c:85
#14 0x0804e53d in transport_registration_func (_fd=28, ev=<value optimized out>, data=0x0)
at system/core/adb/transport.c:589
#15 0x08059092 in fdevent_loop () at system/core/adb/fdevent.c:502
#16 0x0804b98f in adb_main (is_daemon=1, server_port=5037) at system/core/adb/adb.c:975
#17 0x08050bbe in adb_commandline (argc=0, argv=0xffccdc40) at system/core/adb/commandline.c:774
#18 0x0804aaa2 in main (argc=3, argv=0xffccdc34) at system/core/adb/adb.c:1274
Platform target: 2.2
Device platform: 2.2
SDK Tools: 11
SDK Platform-tools: 4
jm...@google.com
Request Google to provide a work around for the same, as this is a blocker for CTS and monkey testing.
th...@gmail.com
I experienced the same issue. Manual workaround is not suitable, since I would like to automate unit tests after each build at Jenkins.
ti...@gmail.com
salwin...@gmail.com, have you tried the Android Emulator Plugin for Jenkins: https://wiki.jenkins-ci.org/display/JENKINS/Android+Emulator+Plugin
It runs a separate adb server for each Jenkins job, and kills it after running the session. That should significantly reduce the number of hangs you experience - and the impact of those hangs.
It runs a separate adb server for each Jenkins job, and kills it after running the session. That should significantly reduce the number of hangs you experience - and the impact of those hangs.
jm...@google.com
I have the same bug with multiple emulators, after few times, the adb process hangs with 100% of the CPU:
fcntl64(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(5, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(8, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(9, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(12, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(13, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(16, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(17, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(23, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(25, F_GETFL) = -1 EBADF (Bad file descriptor)
fcntl64(26, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(30, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(34, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
read(25, 0xffbefcec, 4) = -1 EBADF (Bad file descriptor)
select(35, [4 5 8 9 12 13 16 17 23 25 26 30 34], [], [], NULL) = -1 EBADF (Bad file descriptor)
fcntl64(4, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(5, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(8, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(9, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(12, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(13, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(16, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(17, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(23, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(25, F_GETFL) = -1 EBADF (Bad file descriptor)
fcntl64(26, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
fcntl64(30, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(34, F_GETFL) = 0x802 (flags O_RDWR|O_NONBLOCK)
read(25, 0xffbefcec, 4) = -1 EBADF (Bad file descriptor)
select(35, [4 5 8 9 12 13 16 17 23 25 26 30 34], [], [], NULL) = -1 EBADF (Bad file descriptor)
lc...@gmail.com
Did anyone ever root cause this? I am in the same boat with an android V6 device (HTC touch), and it's really causing some problems. Doesn't seem to happen with the same script on a V7 device though.
jm...@google.com
I dug into it for a while about a year ago and started to improve the debug logging in adb, but ran out of free time and never ended up getting far enough along to find the problem. I'll see if I still have the code however; if I do I'll put it up on github so that it can be continued.
lc...@gmail.com
We are also experiencing this issue during our automated tests ON A DAILY BASIS.
We are using an emulator though, and not a real device as some have described, although i am not sure it really matters.
Is there anyone who knows what is the root cause or how this can be fixed? (or at least improve the stability) ?
We are using an emulator though, and not a real device as some have described, although i am not sure it really matters.
Is there anyone who knows what is the root cause or how this can be fixed? (or at least improve the stability) ?
lc...@gmail.com
Finally find this thread! I am experiencing same issue. adb devices work. But adb install, adb shell all hangs. I am using Ubuntu via VM Player. The issue happened after I update VM player. I tried to reinstall adb, tried to copy other's ubuntu. None of them brings my adb working correctly. I have to reinstall vmplayer, ubuntu, adb and everything eventually. Any thoughts, Googler and Google Android team??
dr...@codetri.be
Why is this feature abandoned?
sa...@gmail.com
+1 why abandoned?
jm...@google.com
What fixes this issue on Ubuntu 14.04 is disabling of MTP in Settings > Storage > Hamburger icon (top-right) > USB computer connection (Nexus). I guess what happens is that Ubuntu runs some service that tries to mount nexus as MTP device and that interacts with ADB in a bad way (makes it crash).
ch...@gmail.com
[Comment deleted]
[Deleted User] <[Deleted User]>
With AVG antivirus adb seems to be hanging, on its deletion the problem was solved.
rg...@gmail.com
With AVG "-adb nodaemon server" returns "cannot bind tcp:5037"
bo...@google.com
ap...@google.com
Issue still valid against a 4.4.2 2014 Nexus 7, seen on some continuous integration shell scripts. This appears to be a pretty major bug for any large-scale project and is over four years old.
ap...@google.com
I was having a similar issue with Eclipse -- it was getting locked up by the adb thread.
In Linux only (two very different distos -- Fedora and Ununtu), but not in Windows 8.1.
Tried some magic things in udev, replaced cables, no help... What finally fixed it was tweaking some USB settings in the BIOS.
This is my original bug report:https://code.google.com/p/android/issues/detail?id=75562
FWIW, YMMV, etc...
In Linux only (two very different distos -- Fedora and Ununtu), but not in Windows 8.1.
Tried some magic things in udev, replaced cables, no help... What finally fixed it was tweaking some USB settings in the BIOS.
This is my original bug report:
FWIW, YMMV, etc...
gm...@gmail.com
I resolve this problem on mac by using older version VirtualBox.
- Host OS
Mac Book Pro, OX X Yosemite 10
- Client OS
Ubuntu-12.04.4-desktop-amd64
VirtualBox 4.3.18-96516 : adb hangs Intermittently
VirtualBox 4.2.20-90983 : adb is working correctly
- Host OS
Mac Book Pro, OX X Yosemite 10
- Client OS
Ubuntu-12.04.4-desktop-amd64
VirtualBox 4.3.18-96516 : adb hangs Intermittently
VirtualBox 4.2.20-90983 : adb is working correctly
tr...@gmail.com
I encountered this problem when running an emulator image built from the Android source code. I only had this problem when I create the x86 image, the ARM image works just fine.
I found a solution.
I discovered that if I send any command to the adb shell while it is hanging, it will resume its task. To solve my problem I just run the following bash script in parallel while I'm running my regression tests:
#!/bin/bash
while [ true ]
do
adb shell exit
sleep 60
done
I found a solution.
I discovered that if I send any command to the adb shell while it is hanging, it will resume its task. To solve my problem I just run the following bash script in parallel while I'm running my regression tests:
#!/bin/bash
while [ true ]
do
adb shell exit
sleep 60
done
tr...@gmail.com
I still get this problem with VirtualBox 5.1.8 and Kubuntu 16.04.1 with xHCI enabled.
Any solutions or workaround known?
Any solutions or workaround known?
ka...@gmail.com
I get this:
adb install -r /path/to/android-debug.apk
[ 61%] /data/local/tmp/android-debug.apk
adb: error: failed to copy '/path/to/android-debug.apk' to '/data/local/tmp/android-debug.apk': no response: Success
after this error the device goes offline
device connects correctly, I can issue adb shell commands, adb pull works, adb push works but only for files smaller than 4MB approximately.
android version:
getprop ro.build.version.release 5.1.1
getprop ro.build.version.sdk 22
Android Debug Bridge version 1.0.36 Revision 0e9850346394-android
lsb_release -cds
Ubuntu 16.04.1 LTS xenial
the same PC and device worked 15 days ago, the same PC and a different android device works.
adb install -r /path/to/android-debug.apk
[ 61%] /data/local/tmp/android-debug.apk
adb: error: failed to copy '/path/to/android-debug.apk' to '/data/local/tmp/android-debug.apk': no response: Success
after this error the device goes offline
device connects correctly, I can issue adb shell commands, adb pull works, adb push works but only for files smaller than 4MB approximately.
android version:
getprop ro.build.version.release 5.1.1
getprop ro.build.version.sdk 22
Android Debug Bridge version 1.0.36 Revision 0e9850346394-android
lsb_release -cds
Ubuntu 16.04.1 LTS xenial
the same PC and device worked 15 days ago, the same PC and a different android device works.
ka...@gmail.com
the issue disappear if the device is connected using his original usb cable! note that the "defective" cable works perfectly with another android device. lesson learned: do use the factory cable, usb is not as standard as it is claimed.
kr...@gmail.com
deleted
ou...@gmail.com
I've read some codes in Tink.
Under Android M, security library uses Tink's AesGcmJce.encrypt() to encrypt the preference values.
So, actually, the values are not stored as clear text but encrypted text.
But it can't use KeyStore so IV's attached to value and encrypted key's bytes array is used as AAD.
As a result, yes, it's insecure.
Please let me know if I'm wrong.
Under Android M, security library uses Tink's AesGcmJce.encrypt() to encrypt the preference values.
So, actually, the values are not stored as clear text but encrypted text.
But it can't use KeyStore so IV's attached to value and encrypted key's bytes array is used as AAD.
As a result, yes, it's insecure.
Please let me know if I'm wrong.
bo...@google.com
Before getting into details, the TL;DR is this: in order to improve your app’s security, it should only be allowed to run on devices that
Before Marshmallow (API 23), Android Keystore did not have support for symmetric keys. This, among
Without security updates, an actor can utilize exploits to gain access to encrypted data, _even when those secrets are protected by a TEE_².
Using the Jetpack security library makes it more difficult for an actor to access those secrets. Tink stores keys in the app's shared preferences, which are saved in the app's private directory. On devices which use fopen the keys.
We felt that the functionality provided by the library would be helpful for developers, including developers who, for various reasons we understand, need to support users on devices that run older versions of Android.
¹ It's possible to verify the OS version and patch level with
ka...@gmail.com
Tink stores keys in the app's shared preferences, which are saved in the app's private directory.
This is true. But if you consider this a secure directory, why bother having an EncryptedSharedPreferences.java?
bo...@google.com
Tink stores keys in the app's shared preferences, which are saved in the app's private directory.
This is true. But if you consider this a secure directory, why bother having an
EncryptedSharedPreferences.java?
Saving information into an app's private directory is safe. EncryptedSharedPreferences is intended to store small bits of data that are particularly sensitive. By using it, it increases the amount of effort required to extract that data from the device.
ss...@gmail.com
How secure is storing keys in Shared Preferences? Wouldn't a rooted user be able to lift the keys (even if they are encrypted)?
bo...@google.com
How secure is storing keys in Shared Preferences? Wouldn't a rooted user be able to lift the keys (even if they are encrypted)?
A rooted user can always access an app's data. It's more difficult when it's encrypted, and it's even more difficult when the key is stored in Key Store, but it's always possible for a rooted user to gain access to data on their device.
ss...@gmail.com
That doesn't really answer my question as to how secure Android's saving of keys to Shared Preferences is.
bo...@google.com
That doesn't really answer my question as to how secure Android's saving of keys to Shared Preferences is.
From reply #36:
Tink stores keys in the app's shared preferences, which are saved in the app's private directory. On devices which use
, those files are encrypted. The files are also protected by full-disk or file based encryption , so that other apps, including the user when connected via ADB or USB, cannot access them. So an app or user cannot simply dump or SELinux user permissions fopenthe keys.
Files stored in an app's private directory, which includes regular SharedPreferences files, are generally secure.
ss...@gmail.com
Thank you for the information.
p....@anfe.ma
So, although SharedPreferences / the app sandbox are generally considered secure it is good practice to additionally encrypt sensitive information - hence the existence of EncryptedSharedPreferences.
Woudn't it be logical to support encryption for Android 21 & 22 utilizing asymmetric keys?
Like suggested here:
> There are known workarounds which allow generation of symmetric keys backed by Android Keystore on API < 23 by generating symmetric keys using different provider (Bouncy Castle), encrypting them with private key from asymmetric keypair stored in Android Keystore (assymetric keys are supported by Android Keystore from API >= 19) and storing them in internal storage. Such workarounds should be implemented in
>https://github.com/google/tink but I didn't find similar public issue there. Maybe it should be started?
Woudn't it be logical to support encryption for Android 21 & 22 utilizing asymmetric keys?
Like suggested here:
> There are known workarounds which allow generation of symmetric keys backed by Android Keystore on API < 23 by generating symmetric keys using different provider (Bouncy Castle), encrypting them with private key from asymmetric keypair stored in Android Keystore (assymetric keys are supported by Android Keystore from API >= 19) and storing them in internal storage. Such workarounds should be implemented in
>
da...@gmail.com
Hi, does the library support migration from Android 21 (Lollipop) and Android 23 (Marshmallow)?
In other words, if I ship an app using androidx.security 1.1.0-alpha01 / 1.1.0-alpha02 on a lollipop device, what will happen when (if) the device is updated to android 23?
Will the data be migrated to the usage of the masterkey?
thanks!
bo...@google.com
jo...@gmail.com
4b...@gmail.com
Any news on this?
st...@gmail.com
Also hoping for news on this...
jm...@google.com
st...@gmail.com
Good morning from 2023 :) Any news on this...?
Description
And saw that the minsdk support for jetpack security library is Android 6+(API 23+). Would it be possible to support from Android 4.4.x(API 19+) as currently for my project (a govt national identity application), we need to support 95% of the devices out there.