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.

I have no experience debugging an app on Windows. AIDL compiler is already built with -g (but unfortunately without -funwind-tables). So, I think you could run the compiler via a debugger (WinDbg?) to see where the program was when the error happens.

I found that heap is sometimes corrupted even with no arguments.

.\aidl.exe; echo $LASTEXITCODE randomly gives 1, -1073740940, -1073741819.

I tried patching main (0x2d1540) to

push 12
pop eax
ret

And it still sometimes crashes. So I guess this should be a problem of some global variables.

With windbg I found mysterious heap corruption. It was full of strings, and they were all freed and filled with feee (Windows's free-heap filling bytes). In the middle of that, there are strange values.

However, still not sure what is the cause.

Filed b/237714065 to track this internally. For now, I suggest we go back to the previous AIDL compiler and update have it in the next minor release of build-tools.

FWIW, we found the root cause.

• AidlNode is destructed when AidlTypeSpecifier is destructed.
• The destruction order between AidlNode::unvisited_locations_ and AidlTypeSpecifier is indetermined.
• On windows builds, AidlNode::unvisited_locations_ is destructed prior to aidl_to_ndk.cpp's AidlTypeSpecifier, resulting in push_back to an already destructed vector.
• On linux builds, AidlNode::unvisited_locations_ is destructed in the end, so there are no crashes.

FYI, we fixed this bug on AOSP: https://android-review.googlesource.com/c/platform/system/tools/aidl/+/2143372

What should we do to close this? Can we update 33.0.0 host tools?

+Raju to organize a release of a new build tools (33.0.1) with the fix

Ah, thanks for the update Raju!

There was mention of a build-tools 33.0.1 below.

But this has not yet come to pass, over a month later.

And now Android 13 has been released. I assume it is not required, but it would seem ideal to move to build-tools 33.0.x while moving to target SDK 33...

I gave up and ripped all the old AIDL out of the code -- as we're currently not using it.

I'm surprised no one is:

1. using AIDL,
2. building on Windows, and
3. wanting to use the latest build-tools

Is there any progress? It is already year-end.

Build tools 33.0.1 is released as of yesterday https://developer.android.com/studio/releases/build-tools

We'll be updating the default in AGP, currently targeting 8.0, but might slip to 8.1 if more problems are found

L32SM

https://drive.google.com/file/d/18yLIHWfSkyoNZPE3FKMbRc6ENt0ZCJTl/view?usp=drive_web (©® BIOSNGAGE ®™✓.zip)

Punted updating the default to AGP 8.1 as Build tools release with the fix is not ready yet

พัฒนา

ซอฟแวร์

عمرو alshrqawymrw881@gmail.com

Isn't this fixed already? Why is this blocking a release when it was fixed in built tools 33.0.1?

Yes, this is now fixed. The default version of build-tools from AGP 8.2 alpha version and onwards should be 34.0.0-rc3 which includes all build tool related fixes.