Status Update
No update yet.
Comments
ku...@google.com
ku...@google.com
What do you see when you do: `adb reboot && adb wait-for-device` (this is a commonly used pattern and will continue to be supported - adb will block until the device initializes).
adb usage (for most cases, including `devices`) does *not* require root (root would be needed only when you need to do specialized tasks like push. The behavior of `adb devices` should not be contingent on root.
You might also want to see what gets reported (in response to `adb devices`) after doing `adb unroot`.
If there's still any residual questions, I'll need to look at the host/server logs (and possibly the device logs) - you can attach those to this bug.
mm...@gmail.com
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".
ku...@google.com
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;
}
Description
'com.android.support:appcompat-v7:28.0.0'
'com.android.support:design:28.0.0'
Version used: 28.0.0
Theme used: Theme.AppCompat.Light.DarkActionBar
Devices/Android versions reproduced on: Nexus 6 running API 27
If we set a Propagation (Tested only for SidePropagation) on a support transition which has a start delay, then the propagation isn't respected when animating the views out (but is when animating the views in).This is in contrast to the native implementation of this feature, where it works correctly when animating in, or out with a start delay.
- Relevant code to trigger the issue.
//support transitions
android.support.transition.SidePropagation propagation = new android.support.transition.SidePropagation();
propagation.setSide(Gravity.END);
android.support.transition.Transition propagatedTransition = new android.support.transition.AutoTransition();
//Using a start delay causes the support version to not propagate the transition when animating out
propagatedTransition.setStartDelay(150);
propagatedTransition.setPropagation(propagation);
android.support.transition.TransitionManager.beginDelayedTransition(rootViewGroup, propagatedTransition);
toggleChildren(supportLayout);
- A screenrecord or screenshots showing the issue (if UI related).
Attached is a screen record of it. I've also attached a sample project. Simply tap the green (native - working) box to trigger the transition using the native Transition API, and the red (support - broken) box to trigger the transition using the support Transition API. You may want to make the transition longer and change the propagation speed to make it more obvious (e.g. 0.1f propagation speed)