IssueTracker

That's working as expected. Let's consult with Javier about his thoughts.

Did we get any input from Javier for this?

The current implementation after the fix is aligned with the foundation API AnchoredDraggable - I think it makes sense to provide an optional parameter for devs to provide the initial anchor to use, as it's hard to provide a reasonable default.

Let me know if you have different thoughts. : )

I think it makes sense to provide an optional parameter for devs to provide the initial anchor to use, as it's hard to provide a reasonable default.

That sounds reasonable to me. Is there a separate bug for that or should I file one?

One thing that I think will be weird is that the size of the panes can come from that anchor or from PaneScaffoldDirective defaultPanePreferredWidth (possibly influenced by the hinge?). In an ideal world, I think we would have the sizes all come from anchors, but that wouldn't work today with three panes visible. I'll add a note to the doc on this.

We don't have a separate bug for that but it's already being supported via:

rememberPaneExpansionState(
    ...
    initialAnchoredIndex = i,
)

You raised a very good point about having parallel ways to set up pane sizes.

To me it's sort of reasonable as there are actually referring to different use cases and have different priorities -

1. Hinge policies always have the highest priority.
2. Pane expansion (and its anchors) are associated with layout splits, but less with the "roles" of the panes that occupy those splits.
3. Modifier.preferredWidth always has the lowest priority - more like a fallback default.

I guess we can have more detailed explanation in the doc if this can be confusing?

Oh, it's in the remember call, perfect!

Yeah, it seems reasonable debating about the use cases, but I worry if it's reasonable for a developer who doesn't consider all that and just wants to show two panes? It's also even more nuanced since 2 only applies for two panes (e.g., if your app shows two panes in portrait on a Samsung Ultra tablet and three panes in landscape). Maybe in the kdoc we should have something similar to what you listed here and in DAC we can provide more context around these.

Yeah that sounds good to me. I plan to have some time to refine our kdoc and samples no matter what. Let's maybe work on this in the upcoming alpha/beta period.

Project: platform/frameworks/support
Branch: androidx-main
Author: Chris Craik <ccraik@google.com>
Link:      https://android-review.googlesource.com/3512010

Improve tag/listener update safety on API 24+

Improve tag/listener update safety on API 24+ 
 
Improve JankStats API 24 impl to reduce thread hops and simplify 
delegate iteration/adding/removal. This brings the API 24 impl to be 
much closer to the API 16 implementation. 
 
Also ensures that delegates and window frame metrics available 
listeners are consistently set on main thread. 
 
Test: JankStatsTest 
Fixes: 311218678 
 
Change-Id: I2ab7c892ae114708f3cd8e80f180ab73e32b9d11

The following release(s) address this bug.It is possible this bug has only been partially addressed:

• androidx.metrics:metrics-performance:1.0.0-beta02

This fix was released yesterday with androidx.metrics:metrics-performance:1.0.0-beta02, see https://developer.android.com/jetpack/androidx/releases/metrics#1.0.0-beta02.

Please try it out and let us know if it doesn't address the problem.