Status Update
No update yet.
Comments
wu...@google.com
de...@gmail.com
ch...@google.com
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.
de...@gmail.com
ch...@google.com
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);
}
}
de...@gmail.com
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
ch...@google.com
de...@gmail.com
de...@gmail.com
ch...@google.com
po...@google.com
[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
de...@gmail.com
ch...@google.com
de...@gmail.com
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.
ch...@google.com
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)
ch...@google.com
de...@gmail.com
ch...@google.com
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) ?
de...@gmail.com
ch...@google.com
All the ResolutionStrategy, AspectRatioStrategy and ResolutionFilter are designed to allow the apps to find their most suitable resolution. If your app has a preference to use size 1280x720, using ResolutionStrategy is definitely a good choice. And, remember to set a corresponding 16:9 AspectRatioStrategy (ex, RATIO_16_9_FALLBACK_AUTO_STRATEGY), so that you can get the desired resolution.
If you want to check which resolution is actually selected for ImageAnalysis, besides using
adb shell dumpsys media.camera | grep Dims
You might get something like:
Dims: 1440 x 1080, format 0x22, dataspace 0x0
Dims: 4032 x 3024, format 0x21, dataspace 0x8c20000
Dims: 640 x 480, format 0x23, dataspace 0x8c20000
The size of format 0x23 is the selected resolution for ImageAnalysis.
de...@gmail.com
Hi, I have tested today with Samsung A23 device. I am facing the same issue with aspect ration 16:9 as well. I change to target resolution with size, then there won’t be any issue.
Thanks
wu...@google.com
de...@gmail.com
ch...@google.com
ch...@google.com
ch...@google.com
de...@gmail.com
ch...@google.com
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...
rp...@gmail.com
- 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
de...@gmail.com
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
ch...@google.com
Any solutions or workaround known?
de...@gmail.com
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.
ch...@google.com
de...@gmail.com
ch...@google.com
I have a question: when should I use aspect ratio, and when should I use resolution?
Basically, if your app cares aspect ratio more, you can specify AspectRatioStrategy only. If your app cares about size for some performance or other reasons, you can specify ResolutionStrategy with corresponding AspectRatioStrategy together.
It seems we are deviating from the original issue.
Yes, we might be (for
Sorry that resolution selection is really a very complex part. And, this is a device specific issue that we can only try to using some existing API to find a way to work around it in app side. Or, we might only be able to wait to see whether Samsung will fix the issue by FOTA.
de...@gmail.com
Thank you for your valuable information and code snippet. My application is using preview+ImageAnalyser. I have to crop the images so I am using usecasegroup. I hope in that case resolution strategy is a good a fit.
fallback rule I am using is that CLOSET_LOWER_THEN_HIGHER.
I have a question based on your above comment, you can specify ResolutionStrategy with corresponding AspectRatioStrategy together. as per understanding we can't able to provide aspect ratio with resolution. I am confused about this point.
Also in your sample code snippet the resolution is using in the image analyser, problem is with Aspect ratio. You can see from my
Thanks
ch...@google.com
For question:
I have to crop the images so I am using usecasegroup. I hope in that case resolution strategy is a good a fit.
Yes, resolution strategy can be used when your app uses UseCaseGroup to bind UseCases.
For question:
as per understanding we can't able to provide aspect ratio with resolution. I am confused about this point.
Please refer to the following javadoc description of
The aspect ratio strategy has precedence over the resolution strategy for sorting the resolution candidate list. If applications specify a custom resolution filter, CameraX passes the resulting sizes list, sorted by the specified aspect ratio and resolution strategies, to the resolution filter to get the final desired list.
Please also be noticed that CameraX only supports the most generic aspect ratio settings (
BTW, we'll be able to get a A23 device next week. I'll try to add a quirk in CameraX side to make app select 1440x1440 in priority when the UseCase combination can support it. That should work for apps like yours that only need Preview + ImageAnalysis.
wo...@gmail.com
Is there an update on this? For us it's the mlkit barcode scanner that doesn't work on the A23 with camerax.
ch...@google.com
Unfortunately, there is no update from Samsung for this issue till now.
I list my test results on the A23 device in the table below. Currently, maybe you can check the table to see which passed item can fulfill your requirement, and then custom a ResolutionSelector with ResolutionFilter to force select the workable resolutions for your UseCases. (Please also verify on your side in case you may see different result on your device.)
| Preview (PRIVATE) | ImageAnalysis (YUV_420_888) | Test result |
|---|---|---|
| 1920x1080 | 1920x1080 | Pass |
| 1920x888 | Pass | |
| 1440x1440 | Pass | |
| 1440x1080 | Fail - CameraAccessException: CAMERA_ERROR (3) | |
| 1280x720 | Fail - cropped | |
| 960x720 | Fail - CameraAccessException: CAMERA_ERROR (3) | |
| 720x480 | Fail - cropped | |
| 640x480 | Fail - CameraAccessException: CAMERA_ERROR (3) | |
| 352x288 | Pass | |
| 320x240 | Pass | |
| 176x144 | Pass | |
| 1440x1080 | 1920x1080 | Pass |
| 1920x888 | Pass | |
| 1440x1440 | Pass | |
| 1440x1080 | Pass | |
| 1280x720 | Pass | |
| 960x720 | Fail - cropped | |
| 720x480 | Fail - cropped | |
| 640x480 | Fail - cropped | |
| 352x288 | Pass | |
| 320x240 | Pass | |
| 176x144 | Pass | |
| 640x480 | 1920x1080 | Pass |
| 1920x888 | Pass | |
| 1440x1440 | Pass | |
| 1440x1080 | Pass | |
| 1280x720 | Pass | |
| 960x720 | Pass | |
| 720x480 | Pass | |
| 640x480 | Pass | |
| 352x288 | Pass | |
| 320x240 | Pass | |
| 176x144 | Pass |
de...@gmail.com
Currently, I am using 1280x720 for both image analysis and preview, and it is working fine across all devices. Also, thank you for sharing the table; it is very helpful for understanding the failure cases, and I can easily refer to it if any issues are noticed in the future.
Thank you for your support. The code snippet you shared is very useful. Please share any updates you receive from Samsung.
I have a question as well: Is the table you created manually prepared, or did you use any script for it? If you can share that information, I can use it to check for any issues in the future for different device.
ch...@google.com
It's great that you can find a solution to your app for this issue.
I created the table by manual testing. We have added some related tests to ITS to prevent this issue in the future.
- test_aspect_ratio_and_crop test in
https://source.android.com/docs/compatibility/cts/its-release-notes-15#refactored-tests
But it might be a little bit difficult for the app side to have the environment and run the test.
de...@gmail.com
I can understand, Anyway thank you for sharing the informations :)
Description
CAMERAX VERSION : 1.2.3 and 1.3.0
CAMERA APPLICATION NAME AND VERSION: Any camerax with analyser can regenerate this issue.
ANDROID OS BUILD NUMBER: (Settings > About > Build number)
DEVICE NAME: Samsung A23
DESCRIPTION:
I am trying to analyse the image using CameraX. Some devices (Samsung A23) with a wide-angle camera do not provide proper images. The image in the analyser is entirely different from the image in the preview. I am using an aspect ratio of 4:3 in both the preview and image analyser. But when I changed to resolution it is properly working.
STEPS TO REPRODUCE:
Please check out the stack overflow url to see more information.
OBSERVED RESULTS:
Image in the previevview is entirely different in the image in the analyser.
EXPECTED RESULTS: Image analyser should contains the image in the previewview
REPRODUCIBILITY: Every time in Samsung A23
Samsung A23 devices.
ADDITIONAL INFORMATION:
I am using camerax with image analyser. I tried aspect ratio 4:3 and 16:9 in previewView and image analyser and noticed that image in the previewView is not in the image in the analyser.
When I changed to Resolution 1280x720, I am getting proper image in the analyser. Even the image size is same in both settings (Resolution and Aspect ratio) issue is regenerating only with Aspect ration setting.
CODE FRAGMENTS (this will help us troubleshoot your issues):
Code fragment added in the stackoverflow link.https://stackoverflow.com/questions/77359868/camerax-image-analysis-not-giving-proper-image-in-wide-angle-cameras