[build] Fix tools//<file> paths in Microsoft.Android.Sdk pack

[jonathanpeppers]

Context

When inspecting Microsoft.Android.Sdk.Windows.*.nupkg, every file that lives directly under tools/ (e.g. r8.jar, aapt2.exe, bundletool.jar, Xamarin.Android.Build.Tasks.dll, all the *.targets files, etc.) is packed with a malformed entry path containing a double slash:

tools//r8.jar
tools//aapt2.exe
tools//bundletool.jar
tools//Xamarin.Android.Build.Tasks.dll
...

83 of the 281 entries in the package are affected.

Root Cause

In build-tools/create-packs/Microsoft.Android.Sdk.proj:

<AndroidSdkBuildTools Include="@(MSBuildItemsWin)"
    TargetPath="tools\$([System.IO.Path]::GetDirectoryName('%(MSBuildItemsWin.RelativePath)'))" ... />

For an item whose RelativePath is just a filename like r8.jar, Path.GetDirectoryName('r8.jar') returns "", so TargetPath becomes tools\ (trailing slash). The SharedFramework.Sdk packaging logic then appends /r8.jar, producing tools//r8.jar.

Items with a real subdirectory (e.g. cs\Foo.resources.dll, bcl\Foo.dll) are unaffected, because the directory name suppresses the trailing-slash issue.

Fix

Switch to Path.Combine, which collapses an empty second argument cleanly:

Input RelativePath	Old result	New result
r8.jar	tools\ ❌	tools ✅
cs\Foo.resources.dll	tools\cs ✅	tools\cs ✅
bcl\Foo.dll	tools\bcl ✅	tools\bcl ✅

This bug has been latent since dc089720b [build] Use SharedFramework.Sdk to create workload packs (#10000). Verified that Microsoft.Android.Sdk.proj is the only place in the repo using this dynamic TargetPath pattern; the sibling Microsoft.Android.Ref.proj uses static path properties, so it is unaffected.

[Copilot]

Pull request overview

Fixes malformed tools//<file> entry paths in the Microsoft.Android.Sdk.$(HostOS) workload pack by ensuring TargetPath doesn’t end up with a trailing separator when the item’s RelativePath has no directory component.

Changes:

• Switch AndroidSdkBuildTools.TargetPath construction from tools\{GetDirectoryName(...)} to Path.Combine("tools", GetDirectoryName(...)) so root-level files map to tools (not tools\).
• Add an inline comment explaining the packaging-path double-slash root cause and why Path.Combine fixes it.

[jonathanpeppers]

Verified the fix against the build 1469356 artifacts:

Microsoft.Android.Sdk.Windows.37.0.0-ci.pr.gh11689.0.nupkg (281 entries):

• Entries containing //: 0 ✅ (was 83 before this fix)
• tools/r8.jar is now a single-slash path

Microsoft.Android.Sdk.Linux.37.0.0-ci.pr.gh11689.0.nupkg (364 entries):

• Entries containing //: 0 ✅
• tools/r8.jar ✅

The build's only failure was a transient Checkout dotnet/android@refs/pull/11689/merge task; the pack stages succeeded.