adb devices requires adb kill-server following adb reboot [302212871]

Fixed

Bug

Status Update

No update yet.

Description

ju...@sonos.com

created issue #1

Sep 27, 2023 03:00AM

Pretty much what the title says. Any time I run adb reboot, adb devices returns an empty list. Running adb kill-server, followed by adb devices returns a non-empty list after running adb reboot. Same behavior is observed after running adb root when root is not already acquired. This is unfortunately very cumbersome, as I am working on a project that requires me to run adb reboot quite frequently. Please see below for example console output (device identifiers have been scrubbed).

$ adb --version
Android Debug Bridge version 1.0.41
Version 34.0.4-10411341
Installed as /usr/local/android/sdk-linux_x86/platform-tools/adb
Running on Linux 6.2.0-33-generic (x86_64)
$ adb devices
List of devices attached
<scrubbed> device

$ adb reboot
$ adb devices
List of devices attached

$ adb kill-server
$ adb devices
* daemon not running; starting now at tcp:5037
* daemon started successfully
List of devices attached
<scrubbed> device

For what it's worth, this is impacting a few of my co-workers, whom all have similar hardware / build environments.

Any information / debugging suggestions would be greatly appreciated. Thanks in advance.

Comments

sh...@google.com <sh...@google.com> #2Sep 27, 2023 05:51AM

Accepted by sh...@google.com.

Project: platform/frameworks/support
Branch: androidx-master-dev

commit b90079595f33f58fece04026a97faa0d243acdb1
Author: Yuichi Araki <yaraki@google.com>
Date: Wed Sep 18 16:55:49 2019

Change the way to detect mismatch between POJO and query

This fixes cursor mismatch warnings with expandProjection.

Bug: 140759491
Test: QueryMethodProcessorTest
Change-Id: I7659002e5e0d1ef60fc1af2a625c0c36da0664d8

M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt
M room/compiler/src/test/kotlin/androidx/room/processor/QueryMethodProcessorTest.kt
M room/compiler/src/test/kotlin/androidx/room/testing/TestProcessor.kt

https://android-review.googlesource.com/1123258

https://goto.google.com/android-sha1/b90079595f33f58fece04026a97faa0d243acdb1

en...@google.com <en...@google.com> #3Sep 27, 2023 03:48PM

The following changes were cherrypicked through Coastguard (

https://android-build.googleplex.com/coastguard/)
Release Track: (

https://android-build.googleplex.com/coastguard/dashboard/6093116828680192/#/cherrypickHistory/all)
Created: 2019-10-14 17:23:42.610596+00:00
Changes: aosp/1123258

da...@sonos.com <da...@sonos.com> #4Sep 27, 2023 04:12PM

Project: platform/frameworks/support
Branch: androidx-master-dev

commit bdde5a1a970ddc9007b28de4aa29d60ffa588f08
Author: Yigit Boyar <yboyar@google.com>
Date: Thu Apr 16 16:47:05 2020

Re-factor how errors are dismissed when query is re-written

This CL changes how we handle errors/warnings if query is
re-written.
There was a bug in expandProjection where we would report warnings
for things that Room already fixes automatically (

b/140759491

).
The solution to that problem (I7659002e5e0d1ef60fc1af2a625c0c36da0664d8)
solved it by deferring validating of columns until after re-write
decision is made. Unfortunately, this required changing PojoRowAdapter
to have a dummy mapping until it is validating, make it hard to use
as it does have a non-null mapping which is not useful.

This CL partially reverts that change and instead rely on the log
deferring logic we have in Context. This way, we don't need to break
the stability of PojoRowAdapter while still having the ability to
drop warnings that room fixes. This will also play nicer when we
have different query re-writing options that can use more information
about the query results.

Bug: 153387066
Bug: 140759491
Test: existing tests pass
Change-Id: I2ec967c763d33d7a3ff02c1a13c6953b460d1e5f

M room/compiler/src/main/kotlin/androidx/room/log/RLog.kt
M room/compiler/src/main/kotlin/androidx/room/processor/QueryMethodProcessor.kt
M room/compiler/src/main/kotlin/androidx/room/solver/TypeAdapterStore.kt
M room/compiler/src/main/kotlin/androidx/room/solver/query/result/PojoRowAdapter.kt

https://android-review.googlesource.com/1288456

ju...@sonos.com <ju...@sonos.com> #5Sep 27, 2023 07:03PM

I've tested the fix proposed above and can confirm it does indeed resolve the unexpected behavior described in my original comment.

ju...@sonos.com <ju...@sonos.com> #6Sep 27, 2023 07:04PM

Would be great to see the proposed solution incorporated into Google's adb source in the future!

sh...@google.com <sh...@google.com> #7Sep 29, 2023 10:46AM

Marked as fixed.

Please stay tuned for an upcoming 34.0.5 platform tools release that will include the proposed resolution (

https://android.googlesource.com/platform/packages/modules/adb/+/7f469838d2d4abd01c6e904db2fece7fc17d75b9%5E%21/)

da...@sonos.com <da...@sonos.com> #8Sep 29, 2023 01:59PM

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

en...@google.com <en...@google.com> #9Sep 29, 2023 02:04PM

Status: Assigned (reopened)

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

sh...@google.com <sh...@google.com> #10Sep 29, 2023 04:06PM

I intentionally left that part in, since this is the exact scenario you are encountering (and we're relying on problem reproduction in the field). However if the consensus is to cover it more broadly (even for unknown situations), that's fine.

en...@google.com <en...@google.com> #11Sep 29, 2023 04:29PM

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.

sh...@google.com <sh...@google.com> Oct 3, 2023 05:20AM

Marked as fixed.

ne...@gmail.com <ne...@gmail.com> #12Mar 9, 2024 12:36AM

Buenas tardes

aa...@gmail.com <aa...@gmail.com> #13Jun 19, 2024 09:01AM

Good

si...@gmail.com <si...@gmail.com> #14Jan 25, 2025 03:20PM

ShareThis

hu...@gmail.com <hu...@gmail.com> #15Jan 30, 2025 04:38PM

Marked as fixed

ja...@gmail.com <ja...@gmail.com> #16Feb 9, 2025 12:41AM

fixed