IssueTracker

Same behavior is observed after running adb root when root is not already acquired.

note that adb root re-starts the adbd running on the device. so the common element here -- if you're all talking to the same device(s) -- might be "there's a problem with the usb stack on the devices we're talking to, that means they don't come back when adbd restarts".

I have the same issue and I've actually found the problem and have a tested fix.

In usb_linux.cpp, where the following code is:

unsigned char length = bufptr[0];
unsigned char type = bufptr[1];

A corsair usb device results in a type and length of both 0, even though all processing in the code is correct. It has several good descriptors, eventually followed by a length and type of 0, before bufptr gets to the full descriptor length. Therefore, this code loops indefinitely, and plugging in new devices is never found.

The fix is simple:

@@ -292,6 +292,9 @@ static void find_usb_device(const std::string& base,
                                                  device->iSerialNumber, zero_mask, max_packet_size);
                         break;
                     }
+                } else if (length == 0) {
+                    D("interface descriptor has wrong size");
+                    break;
                 } else {
                     bufptr += length;
                 }

Thanks for the fix! This is great news.

The fix from 7f469838d2d4abd01c6e904db2fece7fc17d75b9%5E%21 will work, but I do worry about it checking that type is explicitly 0. It can still potentially lead to an infinite loop should some device contain a descriptor with a non-zero type and a zero length. While this fixes my problem, I'd still be weary of leaving this potential infinite loop in.

Thanks again

yeah, i missed that change from ps1 to ps2. i think we should change that back.

a zero-length descriptor will always cause this code to go into an infinite loop (because we only handle one type, and that's above this code --- if we could handle the type, we've already done so). it's never going to be useful for the adb server to hang if something's reporting a bad descriptor, so we should always break.

Buenas tardes

Marked as fixed

fixed

The behaviour described in the bug fix from #comment12 returned with https://android-review.googlesource.com/c/platform/frameworks/support/+/3017979

I am closing this as I have not been able to reliably produce any of the mentioned errors with the latest library versions and this bug was about providing support for shared elements, which did. I did see a case where if you use system back to interrupt, that the transition didn't finish, but I couldn't reproduce that either.

If you can provide an app that reproduces this case reliably please file a new bug.

The last issue with predictive back I've come across was fixed in fragment-1.8.5. Thanks for the fixes.