IssueTracker

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".

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;
                 }

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

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

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.

Buenas tardes

Marked as fixed

fixed

Project: platform/frameworks/support
Branch: androidx-main
Author: Andrew Bailey <anbailey@google.com>
Link:      https://android-review.googlesource.com/3201994

Set disjoint parents in transition overlays

Set disjoint parents in transition overlays 
 
Test: ComposeViewOverlayTest, in follow-up CL 
Bug: b/340894487, b/287484338 
Relnote: """ 
    Transition now sets the disjoint parent for ViewOverlays used to 
    animate its transitions. This allows for the resolution of owners 
    through the disjoint parent, which means you can now correctly 
    resolve ViewModels, lifecycles, etc. during a transition. 
    """ 
Change-Id: I10a16c84ba1efbf89a503418889ddd56bb711bed

androidx.transition:transition:1.6.0-alpha01 is included in today's androidx release. For everyone running into this issue, please upgrade your transition dependency to this version.

The next steps on our end are to bump the transition version that Compose UI depends on, which needs to wait until we bump the androidx-main branch to Compose 1.9.0-alpha01.

Bugjuggler: wait 2 months

FYI I'm still seeing this crash with Transition 1.6.0-alpha01.

Stacktrace:

java.lang.IllegalStateException: ViewTreeLifecycleOwner not found from android.view.ViewOverlay$OverlayViewGroup{2f4358c V.E...... ......ID 0,0-1080,2138}
       	at androidx.compose.ui.internal.InlineClassHelperKt.throwIllegalStateExceptionForNullCheck(InlineClassHelper.kt:30)
       	at androidx.compose.ui.platform.WindowRecomposer_androidKt.createLifecycleAwareWindowRecomposer(WindowRecomposer.android.kt:466)
       	at androidx.compose.ui.platform.WindowRecomposer_androidKt.createLifecycleAwareWindowRecomposer$default(WindowRecomposer.android.kt:327)
       	at androidx.compose.ui.platform.WindowRecomposerFactory$Companion.LifecycleAware$lambda$0(WindowRecomposer.android.kt:170)
       	at androidx.compose.ui.platform.WindowRecomposerFactory$Companion.$r8$lambda$FWAPLXs0qWMqekhMr83xkKattCY(Unknown Source:0)
       	at androidx.compose.ui.platform.WindowRecomposerFactory$Companion$$ExternalSyntheticLambda0.createRecomposer(D8$$SyntheticClass:0)
       	at androidx.compose.ui.platform.WindowRecomposerPolicy.createAndInstallWindowRecomposer$ui_release(WindowRecomposer.android.kt:226)
       	at androidx.compose.ui.platform.WindowRecomposer_androidKt.getWindowRecomposer(WindowRecomposer.android.kt:302)
       	at androidx.compose.ui.platform.AbstractComposeView.resolveParentCompositionContext(ComposeView.android.kt:251)
       	at androidx.compose.ui.platform.AbstractComposeView.ensureCompositionCreated(ComposeView.android.kt:258)
       	at androidx.compose.ui.platform.AbstractComposeView.onAttachedToWindow(ComposeView.android.kt:290)
       	at android.view.View.dispatchAttachedToWindow(View.java:21980)
       	at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3490)
       	at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
       	at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
       	at android.view.ViewGroup.dispatchAttachedToWindow(ViewGroup.java:3497)
       	at android.view.ViewGroup.addViewInner(ViewGroup.java:5318)
       	at android.view.ViewGroup.addView(ViewGroup.java:5104)
       	at android.view.ViewGroup.addView(ViewGroup.java:5044)
       	at android.view.ViewGroup.addView(ViewGroup.java:5016)
       	at android.view.ViewOverlay$OverlayViewGroup.add(ViewOverlay.java:209)
       	at android.view.ViewGroupOverlay.add(ViewGroupOverlay.java:72)
       	at androidx.core.view.ViewCompat.addOverlayView(ViewCompat.java:2854)
       	at androidx.transition.TransitionUtils.createViewBitmap(TransitionUtils.java:103)
       	at androidx.transition.TransitionUtils.copyViewImage(TransitionUtils.java:64)
       	at androidx.transition.Visibility.onDisappear(Visibility.java:400)
       	at androidx.transition.Visibility.createAnimator(Visibility.java:254)
       	at androidx.transition.Transition.createAnimators(Transition.java:789)
       	at androidx.transition.TransitionSet.createAnimators(TransitionSet.java:458)
       	at androidx.transition.TransitionSet.createAnimators(TransitionSet.java:458)
       	at androidx.transition.Transition.playTransition(Transition.java:1912)
       	at androidx.transition.TransitionManager$MultiListener.onPreDraw(TransitionManager.java:301)
       	at android.view.ViewTreeObserver.dispatchOnPreDraw(ViewTreeObserver.java:1176)
       	at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:3772)
       	at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:2465)
       	at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:9305)
       	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1339)
       	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:1348)
       	at android.view.Choreographer.doCallbacks(Choreographer.java:952)
       	at android.view.Choreographer.doFrame(Choreographer.java:882)
       	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:1322)
       	at android.os.Handler.handleCallback(Handler.java:958)
       	at android.os.Handler.dispatchMessage(Handler.java:99)
       	at android.os.Looper.loopOnce(Looper.java:205)
       	at android.os.Looper.loop(Looper.java:294)
       	at android.app.ActivityThread.main(ActivityThread.java:8177)
       	at java.lang.reflect.Method.invoke(Native Method)

I was able to resolve the specific flavor of the crash described in #21 - the cause was a particular test screen that used android.R.id.content as a Fragment container for transactions. Setting up that test Activity with an actual layout file with a FragmentContainerView to host the Fragments resolved the crash.