Status Update
Comments
en...@google.com <en...@google.com> #2
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
al...@ifit.com <al...@ifit.com> #3
al...@ifit.com <al...@ifit.com> #4
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 :-)
en...@google.com <en...@google.com> #5
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 :-)
al...@ifit.com <al...@ifit.com> #6
5120 is likely not really the maxPacketSize on our Macs. It's probably 512. And a burst is probably 10 packets.
Note that usb_osx.cpp calculates the maxPacketSize as follows
if (maxBurst != 0)
// bMaxBurst is the number of additional packets in the burst.
maxPacketSize /= (maxBurst + 1);
If the theory about packet size truly being 512 is correct, then it means the real bug is in GetPipePropertiesV2() returning zero for maxBurst instead of 9. If it returned 9, then maxPacketSize would be 512 (again, a power of 2), and the zero_mask expression would work out just fine. All situations where we've had our adbd abort because of the unexpected stowaway amessage header in a packet are ones where the sent buffer are an integer multiple of 512. None are an integer multiple of 5120.
Still there's no denying that the unchecked assumption of maxPacketSize being a power of 2 is a bug. Changing the code to use modulus operation instead of a bit-mask check would be technically more correct, but wouldn't fix the broken behavior in our case, since ultimately, it appears the maxPacketSize adb is getting is wrong. But if you had an assert in the client/server on macPacketSize being a power of 2, then that would at least have brought the incorrect maxPacketSize issue front and center.
al...@ifit.com <al...@ifit.com> #7
al...@ifit.com <al...@ifit.com> #8
From GetEndpointPropertiesV3's documentation:
... The wMaxPacketSize is the BASE maxPacketSize as found in the endpoint descriptor, and has not been multiplied to take into account burst and mult...
Whereas GetPipePropertiesV3 documentation states that it does mention is may be a multiple
> .. current FULL maxPacketSize for this pipe, which includes both the mult and the burst...
So using GetEndpointProperties would avoid the need to compute the actual max packet length which goes wrong.
en...@google.com <en...@google.com> #9
use GetPipePropertiesV2 ( and not GetEndpointProperties)
the opposite way round, right? we should switch to GetEndpointProperties?
do you have a pointer to the docs? my search-fu failed me :-(
al...@ifit.com <al...@ifit.com> #11
جهازي مخترق
en...@google.com <en...@google.com> #12
sh...@google.com <sh...@google.com> #15
sh...@google.com <sh...@google.com> #16
(i've added dvander to the fastboot cl, since he's the fastboot owner.)
magicleap folks: please take a look if you have time, and note that you can download prebuilt binaries from ci.android.com if you want to test but can't easily rebuild yourselves. these changes will go out in the next platform tools release, so let us know if they don't solve the issues you've been seeing!
al...@ifit.com <al...@ifit.com> #17
en...@google.com <en...@google.com>
sh...@google.com <sh...@google.com>
go...@gmail.com <go...@gmail.com> #18
Release Notes:
34.0.0 (February 2023)
adb
Fixed zero length packet sends for macOS [(issuetracker: 208675141)](
Addressed unstable connectivity (MacBook high speed cable): frequent adb disconnects.
Improved error message for adb push with insufficient number of arguments.
fastboot
Improved flashing: `flashall` will now skip reboots to userspace if it can.
Fixed zero length packet sends for macOS [(issuetracker: 208675141)](
Fixed flashing recovery.img resulting in wrong AVB footer.
on...@gmail.com <on...@gmail.com> #19
sh...@google.com <sh...@google.com> #20
al...@ifit.com <al...@ifit.com> #21
al...@ifit.com <al...@ifit.com> #22
I am not a robot
en...@google.com <en...@google.com> #23
al...@ifit.com <al...@ifit.com> #24
en...@google.com <en...@google.com> #25
sh...@google.com <sh...@google.com> #26
Hy
al...@ifit.com <al...@ifit.com> #27
al...@ifit.com <al...@ifit.com> #28
Google.com
sh...@google.com <sh...@google.com> #29
google.com
al...@ifit.com <al...@ifit.com> #30
Good
en...@google.com <en...@google.com> #31
al...@ifit.com <al...@ifit.com> #32
al...@ifit.com <al...@ifit.com> #33
on
My address country India jila Sultanpur post kamtaganj gram basti paharpur Narsinghpur My name is Arun bihari
sh...@google.com <sh...@google.com> #34
al...@ifit.com <al...@ifit.com> #35
Enviado desde mi Samsung Mobile de Telcel
-------- Mensaje original --------De: buganizer-system@google.com Fecha: 1/8/23 9:50 p. m. (GMT-06:00) Para: b-system+-1105710592@google.com Cc: brotherskankandpechei@gmail.com Asunto: Re:
Replying to this email means your email address will be shared with the team that works on this product.
Changed
fa...@gmail.com added
Goot
_______________________________
Reference Info: 208675141 Bug in usb_osx.cpp logic for sending Zero Length Packet
component: Android Public Tracker > App Development > SDK > platform tools > adb
status: In Progress (Accepted)
reporter: jc...@magicleap.com
assignee: sh...@google.com
cc: ad...@google.com, en...@google.com, jc...@magicleap.com, and 1 more
type: Bug
access level: Default access
priority: P2
severity: S2
retention: Component default
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google IssueTracker
Unsubscribe from this issue.
sh...@google.com <sh...@google.com> #36
sh...@google.com <sh...@google.com> #37
al...@ifit.com <al...@ifit.com> #38
en...@google.com <en...@google.com> #39
al...@ifit.com <al...@ifit.com> #40
sh...@google.com <sh...@google.com> #41
al...@ifit.com <al...@ifit.com> #42
20240720111212800100166608922333431
do...@gmail.com <do...@gmail.com> #44
Fixed in aosp and will be fixed in adb 36.0.0
do...@gmail.com <do...@gmail.com> #45
do...@gmail.com <do...@gmail.com> #46
zh...@gmail.com <zh...@gmail.com> #47
ch...@gmail.com <ch...@gmail.com> #48
The problem is still the same after upgrading to version 34.0.1. I had to rollback to 33.0.3 to be able to install APK on my devices.
al...@ifit.com <al...@ifit.com> #49
sh...@google.com <sh...@google.com> #50
- Are you all on Intel Mac host laptops (vs Intel ARM/M1)? If so, please let us know your host kernel version (e.g. 13.3).
- Since it *appears* that the device-side is also a dependency, please provide the details about the Android device as well (both successful as well as unsuccessful), and any other relevant information (e.g workaround such as 33.0.3, enable the environment variable for 34.0.0 and later).
@do.topevolutions@gmail:
>>If I use emulators for debugging everything is fine. When I connect my usb debugging device, Flutter Daemon stops working.
What's the emulator Android API level (which succeeded)?
What's the physical device API level (that failed)?
Do *all* devices succeed against 33.0.3?
@zhoujianbo1205@gmail:
@nenti1980@gmail:
@christophe.dongieux@gmail:
Please provide additional information for the table below (Intel Mac vs ARM M1 Mac? Macbook kernel version? successfully connected Android version? unsuccessful Android version? Workaround if/any)
@alech@ifit; Host: Intel Mac/i9 formerly 12.6.3 kernel; Successful device:<Android 13?>; Unsuccessful device:<?> Workaround: 34.0.0, 34.0.1 worked with env var setting, 33.0.3 succeeded
@alech@ifit; Host: Intel Mac/i9 upgraded to 13.3 kernel; Successful device:<Android 13?>; Unsuccessful device:<?> Workaround: 34.0.0, 34.0.1 failed, 33.0.3 succeeded
@do.topevolutions@gmail;Host: <Intel Mac? 13.3 Ventura kernel>; Successful device:<emulator Android ver?>; Unsuccessful device:<physical device version: ?> Workaround: <33.0.3 works?>
@zhoujianbo1205@gmail; Host: <Intel Mac?> 13.3 Ventura kernel; Successful device:<Android 13?>; Unsuccessful device:<?> Workaround: <?>
@nenti1980@gmail; Host: <Intel Mac? kernel?>; Successful device:<Android 13?>; Unsuccessful device:<?> Workaround:<?>
@christophe.dongieux@gmail; Host: <Intel Mac? kernel?>; Successful device:<Android 13?>; Unsuccessful device:<?> Workaround: 34.0.0, 34.0.1 failed, 33.0.3 succeeded
al...@ifit.com <al...@ifit.com> #51
yo...@gmail.com <yo...@gmail.com> #52
ma...@gmail.com <ma...@gmail.com> #53
Boa noite sou novo aqui mecânico de motos a 30 anos preciso evoluir rs
ma...@gmail.com <ma...@gmail.com> #54
Boa noite como sou mecânico de motos preciso de velocidade 🚄
ma...@gmail.com <ma...@gmail.com> #55
Como destravar evoluir perdão fuiii tão rápido que não dei boa-noite
zh...@gmail.com <zh...@gmail.com> #56
Darwin Kernel Version 22.4.0;
Android 9, but different devices with the same version have different connection results.
Currently using adb version 33.0.3 with no issues.
[Deleted User] <[Deleted User]> #57
He he
al...@ifit.com <al...@ifit.com> #58
sh...@google.com <sh...@google.com> #59
$ export ADB_LIBUSB=1
$ adb kill-server && adb root
I hope you'll be able to get past that IOService error ( "usb_osx.cpp:170] Unable to create an interface plug-in (e00002be)") when attempting to execute `adb install <>`
al...@ifit.com <al...@ifit.com> #60
When I tried running the:
$adb kill-server && adb root
command after running the:
$export ADB_LIBUSB=1
command
I got the following error:
adb: unable to connect for root: device offline
So I just ran the adb install
after I set the export ADB_LIBUSB=1
and it installed successfully.
sh...@google.com <sh...@google.com>
al...@ifit.com <al...@ifit.com> #61
sh...@google.com <sh...@google.com> #62
al...@ifit.com <al...@ifit.com> #63
ki...@gmail.com <ki...@gmail.com> #64
Hi
ra...@gmail.com <ra...@gmail.com> #65
Hey everyone! I had the same problem and this solution fixed my issues. I wanted to share the issue I was facing with ADB on a physical device. It was driving me crazy, but I managed to resolve it, and I thought it would be helpful to share it here for anyone who might face the same problem in the future.
First off, let me provide some context. I'm using a MacBook Pro Mid 2012 with an Intel 7 processor, and I'm running MacOS Monterey using OpenCore-Legacy-Patcher. The emulator was working fine, but I encountered errors when connecting a physical device (Samsung) to my setup.
When I ran flutter doctor -v without any phone connected, everything seemed to be in order. However, when I connected my phone, things went south. The error message I received was:
Exception: Unable to run "adb", check your Android SDK installation and ANDROID_SDK_ROOT environment variable:
/Users/me/Library/Android/sdk/platform-tools/adb
After some investigation, I came across this solution and it worked for me. Here are the steps I took:
- Open a terminal window.
- Run the following commands:
export ADB_LIBUSB=1
adb kill-server && adb root
After running these commands, I ran flutter doctor -v again, and voila! The issue was resolved, and everything was working smoothly. Here's the output I received:
[✓] Flutter (Channel stable, 3.3.3, on macOS 12.6.5 21G531 darwin-x64, locale en-CA)
• Flutter version 3.3.3 on channel stable at /Users/lifen/SDKs/flutter
• Upstream repository https://github.com/flutter/flutter.git
• Framework revision 18a827f393 (8 months ago), 2022-09-28 10:03:14 -0700
• Engine revision 5c984c26eb
• Dart version 2.18.2
• DevTools version 2.15.0
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
• Android SDK at /Users/lifen/Library/Android/sdk
• Platform android-33, build-tools 33.0.2
• ANDROID_SDK_ROOT = /Users/lifen/Library/Android/sdk
• Java binary at: /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/java
• Java version OpenJDK Runtime Environment (build 11.0.11+0-b60-7590822)
• All Android licenses accepted.
[✓] Xcode - develop for iOS and macOS (Xcode 13.4)
• Xcode at /Applications/Xcode.app/Contents/Developer
• Build 13F17a
• CocoaPods version 1.12.1
[✓] Chrome - develop for the web
• Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
[✓] Android Studio (version 2021.1)
• Android Studio at /Applications/Android Studio.app/Contents
• Flutter plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/9212-flutter
• Dart plugin can be installed from:
🔨 https://plugins.jetbrains.com/plugin/6351-dart
[✓] Connected device (3 available)
• SM A520W (mobile) • 521011e6fca754cf • android-arm64 • Android 8.0.0 (API 26)
• macOS (desktop) • macos • darwin-x64 • macOS 12.6.5 21G531 darwin-x64
• Chrome (web) • chrome • web-javascript • Google Chrome 113.0.5672.126
[✓] HTTP Host Availability
• All required HTTP hosts are available
• No issues found!
Explanation from ChatGPT:
The commands you ran did two things:
export ADB_LIBUSB=1: This command sets the ADB_LIBUSB environment variable to 1. When this variable is set, ADB uses the libusb library instead of the default USB library. This can sometimes resolve issues with device detection if there are problems with the default USB library.
adb kill-server && adb root: This command does two things. First, adb kill-server stops the ADB server process. Then, adb root restarts the ADB server with root permissions. This can resolve issues with device detection if the ADB server was not running or was running without the necessary permissions.
So, in summary, your issue was likely due to a problem with ADB, either because the Android SDK was not installed correctly, the ANDROID_SDK_ROOT environment variable was not set correctly, or the ADB server was not running with the necessary permissions. The commands you ran changed how ADB interacts with USB devices and restarted the ADB server with root permissions, which resolved the issue.
I hope this solution works for you too! If you have any questions or need further assistance, feel free to ask. Happy coding!
jq...@gmail.com <jq...@gmail.com> #66
da...@gmail.com <da...@gmail.com> #67
de...@gmail.com <de...@gmail.com> #68
ol...@gmail.com <ol...@gmail.com> #69
adb is GitHub the issue?
th...@gmail.com <th...@gmail.com> #70
va...@hotmail.com <va...@hotmail.com>
sc...@gmail.com <sc...@gmail.com> #71
export ADB_LIBUSB=1
adb kill-server && adb root
ja...@gmail.com <ja...@gmail.com> #72
but @<en...@google.com>
"so in the meantime, there are lots of other more bugs to look at, that we're already convinced are real.
you can make this bug more convincing by trying to work out what the actual variable is --- is it some specific model of mac? is it only some specific macOS versions? android versions? is there anything interesting in logcat?"
Isn't that your job? I guess someone should get you some type of underling to pick up your slack. I mean, I'm just saying.
..l.. (-_-) ..l..
de...@gmail.com <de...@gmail.com> #73
Device: moto g6
Android version: 9
The latest adb doesn't work. It hangs for any command like adb install, adb shell, etc.
Workaround:
1. Download older adb from
2. export PATH=~/Downloads/platform-tools:$PATH
3. adb kill-server
4. You may need to reconnect your device
Please fix this bug, it is very annoying.
sh...@google.com <sh...@google.com> #74
adb E 08-25 08:19:46 97552 2437794 usb_osx.cpp:175] Unable to create an interface plug-in (e00002be)
ms...@masslight.com <ms...@masslight.com> #75
I concur the issue exists on MacOS Ventura 13.5 (M1) and adb Version 34.0.4-10411341
.
An excerpt from the adb log:
adb server killed by remote request
08-31 15:49:48.894 41776 3136798 I adb : transport.cpp:1155 kicking transport 0x141e05120 fdd8dd0
08-31 15:49:48.894 41776 3136798 I adb : transport.cpp:407 BlockingConnectionAdapter(fdd8dd0): stopping
08-31 15:49:48.894 41776 3136798 I adb : usb_osx.cpp:617 Kicking handle
08-31 15:49:48.894 41776 3136804 E adb : usb_osx.cpp:592 usb_read failed with status: e00002eb
08-31 15:49:48.894 41776 3136804 I adb : transport.cpp:339 fdd8dd0: read failed: Undefined error: 0
08-31 15:49:48.894 41776 3136804 I adb : transport.cpp:1248 fdd8dd0: connection terminated: read failed
08-31 15:49:48.894 41776 3136798 I adb : transport.cpp:425 BlockingConnectionAdapter(fdd8dd0): stopped
Setting the ADB_LIBUSB fixes an issue.
sh...@google.com <sh...@google.com> #76
ms...@masslight.com <ms...@masslight.com> #77
Sorry, forgot to mention, it's on Android 9.0.6.
mo...@gmail.com <mo...@gmail.com> #78
ReevesCharles
sh...@google.com <sh...@google.com> #79
ms...@masslight.com <ms...@masslight.com> #80
Attaching three files with logs:
- ADB_LIBUSB is set -- OK.
- ADB_LIBUSB is unset -- FAILS.
- ADB_LIBUSB is set and copy over tcpip succeeds.
ms...@masslight.com <ms...@masslight.com> #81
Correction to the above (can't edit):
- ADB_LIBUSB is UNSET and copy over tcpip succeeds.
mo...@gmail.com <mo...@gmail.com> #82
This is marked as closed and in the release notes for 34.0.4 but I'm not sure it's actually been addressed.
Running 34.0.4 adb very often hangs on install on my laptop. Reverting to 33.0.3 fixes the issue as mentioned
Once adb hangs on install it will also hang on any other commands until I run adb kill-server && adb start-server
. This fixes the issue for a short period of time, but the next install will often fail.
I'm running this on a Macbook Pro with an M1 chip, running Ventura 13.4.
sh...@google.com <sh...@google.com>
si...@gmail.com <si...@gmail.com> #83
sh...@google.com <sh...@google.com>
po...@gmail.com <po...@gmail.com> #84
adb kill-server && adb start-server
da...@gmail.com <da...@gmail.com>
rk...@hubspot.com <rk...@hubspot.com> #85
Is there any update on this? My team and I are strongly affected by this as it really breaks the flow if you have to restart adb every couple of minutes. It works for a few builds but then quickly stops working... Is there anything we can do locally to circumvent the problem until the problem is fixed?
no...@gmail.com <no...@gmail.com> #86
Adb kill server
sh...@google.com <sh...@google.com> #87
wa...@gmail.com <wa...@gmail.com> #88
Thank
aa...@gmail.com <aa...@gmail.com> #89
var loop = function() { // do cool stuff }
ls...@gmail.com <ls...@gmail.com> #91
sh...@google.com <sh...@google.com> #92
Alternatively, set the env variable mentioned in
ew...@dropbox.com <ew...@dropbox.com> #93
ve...@whirlpool.com <ve...@whirlpool.com> #95
ve...@whirlpool.com <ve...@whirlpool.com> #96
dj...@gmail.com <dj...@gmail.com> #97
doc/api/n-api.md
sh...@google.com <sh...@google.com> #98
It should *not* hang. If it does, the logs need to be uploaded to an appropriate bug (spanning `adb kill-server` )
rk...@hubspot.com <rk...@hubspot.com> #99
I'm on 34.0.5 now for a few weeks now and the problem is still the same as with previous version - adb only works for a few minutes after killing it.
sh...@google.com <sh...@google.com> #100
rk...@hubspot.com <rk...@hubspot.com> #101
Hello, I'm mostly experiencing this while developing on the Android emulators, but it's happening on all emulators and on a physical device (specs below). In terms of connection it happens on the emulator, usb-C cable (tried 2 different ones, with 2 different original Apple hubs) and on Wi-Fi debugging connection.
In terms of reproducibility, it's reproducible 100%. But I can't trigger it. I stop ADB by running killall -9 adb
, Android studio reconnects it and it works for cca. 15-30 minutes. And then at some point, suddenly, stops working.
Symptoms:
- logcat in AS stops updating
- trying to install the app through AS doesn't work (says "waiting for devices" but never finishes)
- debugger doesn't connect
- adb commands mostly don't respond, except for --help or --version (I guess because they're static and don't rely on server)
About ADB_LUBUSB, I'm only running adb from Android Studio. How do I tell it to export that value to 1? I also don't know how to get logs on adb. Googling didn't help, I only found instructions on how to get logs off the Android device that's connected over adb, not for the adb itself. Any tips?
Computer
Apple M1 Max
macOS Ventura 13.6
Android Studio
Android Studio Giraffe | 2022.3.1 Patch 4
Build #AI-223.8836.35.2231.11090377, built on November 13, 2023
Runtime version: 17.0.6+0-17.0.6b829.9-10027231 aarch64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Devices
Emulator Pixel 4, API 33, Android 13.0 Google Play, arm64-v8a (used mostly)
Emulator Pixel 6a, API 34, Android 14.0 Google Play, arm64-v8a
OnePlus 8, Android 13
Java version
➜ ~ java --version
openjdk 17.0.6 2023-01-17
OpenJDK Runtime Environment Temurin-17.0.6+10 (build 17.0.6+10)
OpenJDK 64-Bit Server VM Temurin-17.0.6+10 (build 17.0.6+10, mixed mode)
ADB version
➜ ~ adb --version
Android Debug Bridge version 1.0.41
Version 34.0.5-10900879
Installed as /Users/.../Library/Android/sdk/platform-tools//adb
Running on Darwin 22.6.0 (arm64)
rk...@hubspot.com <rk...@hubspot.com> #102
I set the ADB_LIBUSB to 1 and it still happened:
➜ ~ killall -9 adb
➜ ~ export ADB_LIBUSB=1
➜ ~ echo $ADB_LIBUSB
1
➜ ~ adb devices
List of devices attached
emulator-5554 device
// 1 hour later ...
➜ ~ echo $ADB_LIBUSB
1
➜ ~ adb devices
^C <- I had to kill the command manually as it didn't return anything for 1 minute
➜ ~ killall -9 adb
➜ ~ adb devices
List of devices attached
emulator-5554 device
sh...@google.com <sh...@google.com>
sc...@gmail.com <sc...@gmail.com> #103
From: <buganizer-system@google.com>
Date: Mon, Oct 16, 2023, 6:42 PM
Subject: Re:
latest platform tools version 34.0.0
To: <b-system+404257552@google.com>
Cc: <schultrodney928@gmail.com>
Replying to this email means your email address will be shared with the
team that works on this product.
*Changed*
status: In Progress (Accepted) → Fixed
*sh...@google.com <sh...@google.com> added
<
_______________________________
*Reference Info: 270205252 ADB install not working on Android 9 with latest
platform tools version 34.0.0*
component: Android Public Tracker > App Development > SDK > platform tools
> adb <
status: Fixed
reporter: al...@ifit.com
assignee: sh...@google.com
cc: al...@ifit.com, ja...@google.com, sh...@google.com, and 3 more
type: Bug
access level: Default access
priority: P2
severity: S2
blocking: 269001731 <
duplicate issue: 288902771
<
<
retention: Component default
Generated by Google IssueTracker notification system
You're receiving this email because you are subscribed to updates on Google
IssueTracker
<
starred.
Unsubscribe from this issue.
<
sh...@google.com <sh...@google.com> #104
identify the approximate timestamp at which you suspect connectivity dropped.
Host debugging:
- set ADB_TRACE (dynamic setting)
- aosp-master$ export ADB_TRACE=all
- On MacOS, the logs can be found in the directory pointed by the TMPDIR environment variable.
-$ tail -f /tmp/adb*.log
adb I 02-08 09:30:25 139670 139670 main.cpp:62] Android Debug Bridge version 1.0.41
<snip>
Device-side (adbd) debugging:
Set trace_mask on
Restart the daemon and analyze the logs. Caveat is that the device-logs tend to be noisy.
$ adb shell getprop persist.adb.trace_mask
1
$ adb shell setprop persist.adb.trace_mask 0
$ adb shell pkill adbd
$ adb shell
# cd /data/adb
/data/adb # ls -al
total 23
drwx------ 2 root root 3488 2022-02-08 18:04 .
drwxrwx--x 49 system system 4096 2022-01-18 12:13 ..
-rw------- 1 root root 8521 2022-02-08 18:05 adb-2022-02-08-18-04-49-18527
Error(s) that you may run into, and resolution:
$ adb shell setprop persist.adb.trace_mask 0
Failed to set property 'persist.adb.trace_mask' to '0'.
See dmesg for error reason.
$ adb root
$ adb shell setprop persist.adb.trace_mask 0
>>happens on the emulator, usb-C cable (tried 2 different ones, with 2 different original Apple hubs) and on Wi-Fi debugging connection.
FYI, `WiFi Debugging` runs over a different transport therefore it might make sense to open a separate bug for any failure you
experience over that transport. In fact, libusb transport is also distinct from the legacy transport (as far as the possible failure point which is likely USB, is concerned).
One other question: do you experience this failure from adb alone? (if you eliminate Android Studio from this equation)
Studio interacts with the adb server (and is itself the equivalent of the adb client).
If not, the Studio logs are also relevant.
ga...@gmail.com <ga...@gmail.com> #107
El mar., 28 de noviembre de 2023 18:33, <buganizer-system@google.com>
escribió:
li...@gmail.com <li...@gmail.com> #108
sc...@gmail.com <sc...@gmail.com> #109
he...@gmail.com <he...@gmail.com> #110
ra...@gmail.com <ra...@gmail.com> #111
ra...@gmail.com <ra...@gmail.com> #112
ch...@gmail.com <ch...@gmail.com> #113
hs...@gmail.com <hs...@gmail.com> #114
فعلت تحديث كامل للفون software
rk...@hubspot.com <rk...@hubspot.com> #115
Hey sh... sorry for the late reply. The problem is still here. I tried the steps you wrote above and I can't activate the root user, I get this:
➜ ~ adb shell setprop persist.adb.trace_mask 0
Failed to set property 'persist.adb.trace_mask' to '0'.
See dmesg for error reason.
➜ ~ adb root
adbd cannot run as root in production builds
➜ ~
What does this mean? Any way around that?
ja...@gmail.com <ja...@gmail.com> #116
rk...@hubspot.com <rk...@hubspot.com> #117
I managed to find a solution to the problem adbd cannot run as root in production builds
, I had to use the emulator without Play Store included, I had only the Google APIs.
rk...@hubspot.com <rk...@hubspot.com> #118
Regarding the original issue, this weekend I updated my Android Studio to the stable Iguana 2023.2.1 and I also update SDK which included ADB 35.0.0-11411520 (1.0.41) and for the past 27 hours I didn't have to kill adb once. So it seems the problem is fixed, at least for me. Thanks!
ja...@gmail.com <ja...@gmail.com> #119
ia...@gmail.com <ia...@gmail.com> #120
How install
ka...@gmail.com <ka...@gmail.com> #121
al...@gmail.com <al...@gmail.com> #122
[Deleted User] <[Deleted User]> #123
Reinstall all
rk...@hubspot.com <rk...@hubspot.com> #124
I'm sad to inform you that the issue reappeared. My whole team and I are back to killing adb on an hourly basis. :(
rk...@hubspot.com <rk...@hubspot.com> #125
I'm on
Android Debug Bridge version 1.0.41
Version 35.0.0-11411520
Running on Darwin 23.5.0 (arm64)
And Android Studio is
Android Studio Jellyfish | 2023.3.1 Patch 1
Build #AI-233.14808.21.2331.11842104, built on May 15, 2024
Runtime version: 17.0.10+0-17.0.10b1087.21-11572160 aarch64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
ab...@gmail.com <ab...@gmail.com> #126
#270205252
ab...@gmail.com <ab...@gmail.com> #128
Job
kr...@gmail.com <kr...@gmail.com> #131
This fix has made my custom AOSP based device not being recognized as an Android device (not there at all on the adb devices
list).
Only downgrading to 34.0.4
helps.
OSX Sonoma 14.5, MacBook Air M2.
Let me know if you'd like me to provide some debug logs to help with fixing that in the latest version.
am...@gmail.com <am...@gmail.com> #132
I need to Update my New Phone right now to android 15
em...@sumup.com <em...@sumup.com> #133
Hello, this issue is very present for us. We have a custom AOSP-based device (Android 10) that now often fails to be shown in the device list or hangs on the install command. Sometimes, downgrading to adb prior to 34.0.5 fixes the issue, sometimes upgrading above 34.0.4 fixes it. Sometimes it cannot be fixed. So far we were unable to find a correlation between OS&hardware and the step that fixes it.
Here are adb host logs from a device that attempted connecting with adb 34.0.4-10411341. It is an M1 Pro with Ventura 13.6.1.
One file has the logs where the device was not listed with adb devices
, the other file are the logs from where adb devices
showed the device, but then adb install
hung indefinitely.
en...@google.com <en...@google.com> #134
both of those traces seem to be using the non-libusb macOS usb backend, which is no longer supported. please repro with a 35.* adb using libusb.
em...@sumup.com <em...@sumup.com> #135
The device is a MacBook Pro M3 with Sonoma 14.5.
I've not been able to find someone to reproduce the indefinite install hang on 35+, yet, but I know we had this in the past (unfortunately without collecting host logs). I'll continue to ask around.
m2...@gmail.com <m2...@gmail.com>
am...@gmail.com <am...@gmail.com> #136
b....@gmail.com <b....@gmail.com> #137 Restricted
b....@gmail.com <b....@gmail.com> #138 Restricted
mw...@gmail.com <mw...@gmail.com> #139
#404
Description