Tap to focus only works 2-4 times [159039233]

Fixed

Bug

Status Update

No update yet.

Description

sc...@gmail.com

created issue #1

Jun 15, 2020 06:45PM

Please describe your issue and include details such as the version of CameraX you are using and any relevant logs related to your issue.

// If at all possible, capture an Android logcat (

https://developer.android.com/studio/command-line/logcat) when you're experiencing the issue, preferably while the camera is still active.

CAMERAX VERSION (ex - 1.0.0-alpha07)
androidx.camera:camera-camera2:1.0.0-beta05
androidx.camera:camera-lifecycle:1.0.0-beta05
androidx.camera:camera-view:1.0.0-alpha12

CAMERA APPLICATION NAME AND VERSION: (Settings > Apps > (app name) > version)
1.0

ANDROID OS BUILD NUMBER: (Settings > About > Build number)
R16NW.G930VVRU8CRJ3

DEVICE NAME: (Nexus 5X, Samsung S6, etc)
Samsung Galaxy S7 (SM-G930V)

DESCRIPTION:
Tap to focus (via startFocusAndMetering()) only works a few times. Anywhere between 2 and 4 times before it stops actually focusing the requested point. Instead of focusing on the requested point it clearly makes an attempt and then reverts back to the original focus point. Equivalent behavior to attempting to focus on an object too close.
See screenshot to see the screen I'm testing with. Phone is on a stand, focusing another smaller stand.

LIST ANY EXPERIMENTAL FEATURES: (As an example - @ExperimentalCamera2Interop)
Unaware of any.

STEPS TO REPRODUCE:
1. Add tap to focus
2. Run app
3. Tap on an object far away
4. Tap on an object nearby
5. Repeat step 3-4 until it stops working (usually stops working after 2 changes to focus)

OBSERVED RESULTS:
The lens blurs for a second or so as it attempts to focus the requested point, then reverts back to original focus point.

EXPECTED RESULTS:
The lens blurs for a second and then focuses on the requested point

REPRODUCIBILITY: (5 of 5, 1 of 100, etc)
5 of 5 (100%)

ADDITIONAL INFORMATION:
I have attempted to add a call to cancelFocusAndMetering() (and using the future to await the completion) prior to calling startFocusAndMetering() to no avail.
The code I used is adapted from the official recommended way of doing tap to focus, including trying to add disableAutoCancel() since I saw it mentioned in one of the issues reported by another user in here. I tried the following:
1. Calling cancelFocusAndMetering prior
2. Adding .disableAutoCancel() to the action builder
3. Checking that the coordinates are accurate (they are)
4. Searching for similar issues
5. Searching the github sample code for any examples of tap to focus (there are none)
5. Disabling the scaleDetector code but ensuring we only focus once (on ACTION_UP)
Sometimes it seems to recover after a while. I'm not entirely sure what triggers it but it may be related to autofocus.

CODE FRAGMENTS (this will help us troubleshoot your issues):
```
viewFinder.setOnTouchListener { v, event ->
if (event.action != MotionEvent.ACTION_UP) {
return@setOnTouchListener scaleDetector.onTouchEvent(event)
}

val camera = camera ?: return@setOnTouchListener true

// Create a factory for creating a MeteringPoint
val factory = viewFinder.createMeteringPointFactory(cameraSelector)

// Convert UI coordinates into camera sensor coordinates
val point = factory.createPoint(event.x, event.y)

// Prepare focus action to be triggered
val action = FocusMeteringAction.Builder(point)
.disableAutoCancel()
.build()

// Execute focus action
camera.cameraControl.startFocusAndMetering(action).addListener(Runnable {
Log.d(TAG, "Focused at ${point.x} x ${point.y}.")
}, cameraExecutor)

v.performClick();
}
```

af-issue-logcat.txt

69 KB

View

Download

af-issue-screenshot.png

1.9 MB

View

Download

Comments

sc...@google.com <sc...@google.com> #2Jun 16, 2020 01:19AM

Accepted by sc...@google.com.

SDK Revision 5

sc...@google.com <sc...@google.com> #3Jun 16, 2020 09:21AM

Successful workaround: Kill the ADB process if it does not return within 120 seconds.

sc...@gmail.com <sc...@gmail.com> #4Jun 16, 2020 04:54PM

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 0

127.0.0.1:5037 0.0.0.0:* LISTEN 4440/adb
tcp 0 0

0.0.0.0:22 0.0.0.0:* LISTEN 406/sshd
tcp 0 0

127.0.0.1:38007 0.0.0.0:* LISTEN 5216/emulator
tcp 0 0

127.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.

sc...@gmail.com <sc...@gmail.com> #5Jun 16, 2020 05:12PM

[Comment deleted]

ap...@google.com <ap...@google.com> #6Jun 17, 2020 04:15PM

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);
}
}

sc...@google.com <sc...@google.com> #7Jun 18, 2020 01:10AM

Marked as fixed.

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

Issue 159039233