Fixed
Status Update
No update yet.
Comments
an...@google.com
This should not be the case.
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.
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.
ap...@google.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".
Description
1) If you add multiple views as a ghosts for the same parent they would be added in the order in which they would be drown in the original hierarchy
2) They will also be drawn on top of other overlay views(not ghosts)