Infeasible
Status Update
No update yet.
Comments
ed...@gmail.com
Correction:
So, the end result is that usb_write() sometimes sends a ZLP when it doesn't need to
should be
So, the end result is that usb_write() sometimes sends a ZLP when it doesn't need to, and sometimes neglects to send a ZLP when it should
So, the end result is that usb_write() sometimes sends a ZLP when it doesn't need to
should be
So, the end result is that usb_write() sometimes sends a ZLP when it doesn't need to, and sometimes neglects to send a ZLP when it should
st...@google.com
st...@google.com
Note that the CHECK_LE has since been replaced with HandleError(), which causes adbd to not abort...but that stowaway amessage header is being dropped all the same...and so the behavior is pretty much undefined, I imagine. I'm not sure the switch to HandleError was a good idea, since it more or less swept the real problem under the rug.
st...@google.com
good bug report, thanks! i'm assuming this isn't darwin-specific either --- it looks like we have similar logic using masks in the linux and windows backends and in the libusb backend too.
I'm not sure the switch to HandleError was a good idea, since it more or less swept the real problem under the rug.
yeah, i know what you mean, but it's also hard to argue with this logic in the commit message that made that change:
These CHECKs are expected to happen if the client does the wrong thing,
so we probably shouldn't be aborting in adbd.
a CHECK in the client (as you suggested earlier) would probably have been the best idea... postel's law and all that :-)
st...@google.com
Thanks for the quick response.
Indeed, I see similar logic in usb_write() in usb_linux. maxPacketSize is 512 (a power of 2) on my Ubuntu environment, so all good there as far as runtime behavior. It sure is odd that on macOS it's 5120, which happens to be exactly 10x the linux value. Seem suspicious, doesn't it?
Yeah, on the CHECK thing... I guess I see the client and server as a closed system in that the code is developed and distributed together. That said, obviously anyone can write their own adb client/server, so in that respect, I agree with the disagreement :-)
Indeed, I see similar logic in usb_write() in usb_linux. maxPacketSize is 512 (a power of 2) on my Ubuntu environment, so all good there as far as runtime behavior. It sure is odd that on macOS it's 5120, which happens to be exactly 10x the linux value. Seem suspicious, doesn't it?
Yeah, on the CHECK thing... I guess I see the client and server as a closed system in that the code is developed and distributed together. That said, obviously anyone can write their own adb client/server, so in that respect, I agree with the disagreement :-)
Description
(Note: It is the build when sending this report. For exact build reference, please see the attached bugreport.)
What type of Android issue is this? User Interface, Display, or Rendering issue
What steps would let us observe this issue?
1. Bubbles worked the first time
2. After that it doesn't work anymore
What did you expect to happen?
Bubble conversation
What actually happened?
No bubbles
How often has this happened?
Every time
What was the effect of this issue on your device usage, such as lost time or work?
Slight
Debugging information
Google Play services
com.google.android.gms
Version 223915044 (22.39.15 (190400-480654083))
System App (Updated)
Android System WebView
com.google.android.webview
Version 519513633 (105.0.5195.136)
System App (Updated)
Network operator: yoodo
SIM operator: yoodo
Filed by Android Beta Feedback. Version (Updated): 2.29-betterbug.external_20220914a_RC01
To learn more about our feedback process, please visit