[Android] CollectionView: Fix drag-and-drop reordering into empty groups

[SuthiYuvaraj]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Issue Description:

Dragging and dropping an item into an empty group in the CollectionView was failing. The item could not be dropped because the drag-and-drop logic was not handling empty groups correctly.

RootCause:

The OnMove method controls drag-and-drop behaviour in CollectionView. When dropping into an empty group, the only element present is the group header, which has a different ItemViewType than normal items. Because of this mismatch, the check inside OnMove prevented the drop operation from completing.

Description of Change

Updated the condition in OnMove to validate that the dragged item is a record, allowing drops into empty groups.

Issues Fixed

Fixes #12008

Tested the behaviour in the following platforms

• Android
• Windows
• iOS
• Mac

Output Screenshot

Before Issue Fix	After Issue Fix
12008before.mov	12008Final.mov

[jsuarezruiz]

/azp run MAUI-UITests-public

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jsuarezruiz]

/rebase

[rmarinho]

🤖 AI Summary

📊 Expand Full Review

---

🔍 Pre-Flight — Context & Validation

---

📝 Review Session — Update Issue12008.cs · b245a0e

---

Issue: #12008 - CollectionView Drag and Drop Reordering Can't Drop in Empty Group
PR: #31867
Author: SuthiYuvaraj (community ✨, partner/syncfusion)
Platforms Affected: Android (primary, confirmed), iOS/Mac (also fixed)
Files Changed: 6 implementation files, 2 test files

Issue Summary

When using a CollectionView with grouping and reordering (CanMixGroups=true, CanReorderItems=true), dragging an item into an empty group fails. The empty group only has its header, and the header has a different ItemViewType than normal items. The OnMove check (viewHolder.ItemViewType != target.ItemViewType) rejected drops onto group headers, preventing drops into empty groups.

Root Cause (from PR)

OnMove in SimpleItemTouchHelperCallback.cs (Android) compared source and target ItemViewType. An empty group's only element is a group header, so the type mismatch caused OnMove to return false.

Files Changed

Fix files (Android):

• src/Controls/src/Core/Handlers/Items/Android/SimpleItemTouchHelperCallback.cs (+4, -1)
• src/Controls/src/Core/Handlers/Items/Android/Adapters/ReorderableItemsViewAdapter.cs (+10, 0)

Fix files (iOS - both handler versions):

• src/Controls/src/Core/Handlers/Items/iOS/ReorderableItemsViewController.cs (+37, -9)
• src/Controls/src/Core/Handlers/Items/iOS/ReorderableItemsViewDelegator.cs (+59, -11)
• src/Controls/src/Core/Handlers/Items2/iOS/ReorderableItemsViewController2.cs (+37, -10)
• src/Controls/src/Core/Handlers/Items2/iOS/ReorderableItemsViewDelegator2.cs (+60, -11)

Test files:

• src/Controls/tests/TestCases.HostApp/Issues/Issue12008.cs (+225, new)
• src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue12008.cs (+44, new)

Key Changes

Android (SimpleItemTouchHelperCallback.cs):
Old: if (viewHolder.ItemViewType != target.ItemViewType) return false;
New: Only blocks moves if source is a Header/Footer/GroupHeader/GroupFooter type — allows dropping onto group headers (empty groups).

Android (ReorderableItemsViewAdapter.cs):
Added bounds validation on fromItemIndex and toItemIndex before list access.

iOS:
Enhanced index path validation in MoveItem (both Items/ and Items2/), with support for empty groups (insert at index 0). GetTargetIndexPathForMove refactored to handle empty group routing and boundary conditions.

PR Discussion

• jsuarezruiz: Triggered CI run (/azp run MAUI-UITests-public) and requested /rebase
• No reviewer disagreements or inline comments found

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #31867	Check source ItemViewType instead of comparing source==target; add bounds validation	⏳ PENDING (Gate)	6 impl + 2 test	Original PR

---

🚦 Gate — Test Verification

---

📝 Review Session — Update Issue12008.cs · b245a0e

---

Result: ✅ PASSED
Platform: android
Mode: Full Verification
TestFilter: Issue12008

• Tests FAIL without fix ✅
• Tests PASS with fix ✅

Check	Expected	Actual	Result
Tests WITHOUT fix	FAIL	FAIL	✅
Tests WITH fix	PASS	PASS	✅

---

🔧 Fix — Analysis & Comparison

---

📝 Review Session — Update Issue12008.cs · b245a0e

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix	GroupHeader early-exit in OnMove + clamp toItemIndex to 0 in adapter	✅ PASS	2 files	Android-only; target-focused check
2	try-fix	Delegate all type validation to adapter via new CanItemMove() interface	✅ PASS	4 files	Android-only; adds public API change to IItemTouchHelperAdapter
3	try-fix	viewHolder.ItemViewType != target.ItemViewType && target.ItemViewType != ItemViewType.GroupHeader + clamp	✅ PASS	2 files	Smallest change; Android-only
4	try-fix	Offset target position by +1 for GroupHeader targets in OnMove	❌ FAIL	2 files	Position arithmetic incorrect; item not inserted
5	try-fix	Check source IS TextItem/TemplatedItem (inverse allowlist) + clamp	✅ PASS	2 files	Inverse of PR; equivalent but Android-only
PR	PR #31867	Check source IS Header/Footer/GroupHeader/GroupFooter in OnMove; bounds validation in adapter; iOS fix in Items/ and Items2/	✅ PASS (Gate)	6 impl + 2 test	Fixes Android + iOS

Cross-Pollination Round 2

Model	Response
claude-sonnet-4.5	Suggested OnSelectedChanged override, sentinel detection, ChooseDropTarget — but concluded "over-engineering, recommend PR's fix"
claude-opus-4.6	NO NEW IDEAS — design space saturated
gpt-5.2	Suggested CanDropOver/ChooseDropTarget (complex, over-engineering)
gpt-5.2-codex	Suggested temporary placeholder item in empty groups (complex, invasive)
gemini-3-pro-preview	NO NEW IDEAS

Exhausted: Yes — all 5 models confirmed no viable new ideas beyond over-engineering

Selected Fix: PR's fix — Reason: The PR is the only fix that addresses ALL affected platforms (Android + iOS both Items/ and Items2/). The alternative try-fix attempts only fixed Android and missed the significant iOS improvements (MoveItem index validation and GetTargetIndexPathForMove empty group routing). The PR's approach is also the most complete with bounds validation in the adapter, making it more defensive against edge cases.

---

📋 Report — Final Recommendation

---

📝 Review Session — Update Issue12008.cs · b245a0e

---

✅ Final Recommendation: APPROVE

Summary

PR #31867 fixes CollectionView drag-and-drop reordering into empty groups, which was broken because the OnMove guard in SimpleItemTouchHelperCallback compared source and target ItemViewType, rejecting drops onto GroupHeader views (the only visible element in an empty group). The PR correctly identifies the root cause, fixes it across Android and iOS (both handler versions), and includes UI tests that verify the fix.

Gate passed: tests FAIL without the fix, PASS with it.

Five independent try-fix alternatives were explored (4 passed, 1 failed). All passing alternatives are narrower in scope (Android-only) — the PR's fix is the most complete because it also fixes iOS (both Items/ and Items2/).

---

Root Cause

In SimpleItemTouchHelperCallback.OnMove (Android), the original condition was:

if (viewHolder.ItemViewType != target.ItemViewType) return false;

An empty group has no items — only a group header. When dragging an item over an empty group, the target ViewHolder is a GroupHeader with a different ItemViewType than the dragged item, causing the drop to be silently rejected.

On iOS, similar issues existed in MoveItem (no validation for empty destination lists) and GetTargetIndexPathForMove (no routing to empty groups).

---

Fix Quality

Android fix is correct and minimal:

• SimpleItemTouchHelperCallback.OnMove: Checks if source is a structural element (Header/Footer/GroupHeader/GroupFooter); allows items to be dropped onto GroupHeaders
• ReorderableItemsViewAdapter.OnItemMove: Adds bounds validation before list access

iOS fix is correct and comprehensive:

• MoveItem: Added section bounds check, fromList/fromItemIndex validation, and empty group toItemIndex clamping
• GetTargetIndexPathForMove: Refactored to properly route drops to empty groups, with FindFirstEmptyGroup helper

---

Code Review Findings

🟡 Minor Issue: Off-by-One in Bounds Check

File: src/Controls/src/Core/Handlers/Items/Android/Adapters/ReorderableItemsViewAdapter.cs

if (fromItemIndex < 0 || fromItemIndex > fromList.Count)  // should be >= fromList.Count

fromList[fromItemIndex] would throw ArgumentOutOfRangeException if fromItemIndex == fromList.Count. The check should be >=. In practice this edge case is unlikely (the index calculation won't produce == Count for valid drags), but it's worth noting for correctness.

The toItemIndex > toList.Count check is correct because IList.Insert allows index == Count (append).

🟡 Style: Double Blank Line

File: src/Controls/src/Core/Handlers/Items/iOS/ReorderableItemsViewDelegator.cs (and Delegator2.cs)

There's an extra blank line before the if (proposedIndexPath.Section >= totalSections) check. Minor style issue only.

✅ Positives

• The core Android fix is surgical and correct — only the source type check changes, and it uses existing ItemViewType constants consistently with GetMovementFlags
• iOS empty-group routing via FindFirstEmptyGroup is a clean helper that avoids duplicate logic between Items/ and Items2/
• Tests include both happy path (empty group creation) and behavior (drag into empty group) verification
• #if TEST_FAILS_ON_WINDOWS guard is correct since Windows CollectionView drag-and-drop with groups is unsupported

---

Title / Description Assessment

Title: "Fix for CollectionView Drag and Drop Reordering Can't Drop in Empty Group "

• Trailing space should be trimmed
• Could follow platform-component convention: [Android/iOS] CollectionView: Fix drag-and-drop into empty groups
• Current title is functional but verbose

Description: Good quality — contains root cause, description of change, issues fixed, tested platforms, and screenshots. NOTE block is present. No rewrite needed.

---

📋 Expand PR Finalization Review

---

Title: ⚠️ Needs Update

Current: Fix for CollectionView Drag and Drop Reordering Can't Drop in Empty Group

Issues:

• Trailing space at the end
• "Fix for" prefix is title should describe behavior changed, not say "Fix for"noise
• No platform the fix covers Android AND iOS/MacCatalyst (both Items/ and Items2/ handlers)prefix
• Doesn't follow recommended formula: [Platform] Component: What changed

Recommended: [Android][iOS] CollectionView: Fix drag-and-drop reordering into empty groups

Description: ⚠️ Needs Update

• Trailing space at the end
• "Fix for" prefix is title should describe behavior changed, not say "Fix for"noise
• No platform the fix covers Android AND iOS/MacCatalyst (both Items/ and Items2/ handlers)prefix
• Doesn't follow recommended formula: [Platform] Component: What changed

✨ Suggested PR Description

[!NOTE]
Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Root Cause

When performing drag-and-drop reordering in a grouped CollectionView with CanReorderItems=true and CanMixGroups=true, dropping an item into an empty group fails.

Android: SimpleItemTouchHelperCallback.OnMove compared viewHolder.ItemViewType of the dragged item against the target's ItemViewType. In an empty group, the only visible element is the group header, which has a different ItemViewType (Header/GroupHeader) than regular items. This mismatch caused OnMove to return false, blocking the drop.

iOS/MacCatalyst: GetTargetIndexPathForMove in the delegators didn't handle empty groups — it had no awareness of group item counts and didn't clamp index paths into valid positions within empty groups. MoveItem in the view controllers assumed fromList and toList were both non-null and didn't guard against out-of-range indices.

Description of Change

Android (SimpleItemTouchHelperCallback.cs)
Changed the OnMove guard from comparing item view types between source and target to instead checking whether the source item is a non-draggable type (Header, Footer, GroupHeader, GroupFooter). This allows drops onto group headers (which represent empty groups) while still preventing dragging headers and footers themselves.

Android (ReorderableItemsViewAdapter.cs)
Added bounds checks for fromItemIndex and toItemIndex before accessing/inserting into the underlying lists, preventing potential IndexOutOfRangeException edge cases.

iOS/MacCatalyst — Delegators (ReorderableItemsViewDelegator.cs, ReorderableItemsViewDelegator2.cs)
Significantly reworked GetTargetIndexPathForMove to properly resolve drop targets for empty groups:

• Checks CanMixGroups before allowing cross-group drops
• Retrieves ItemCountInGroup for the proposed target section
• For empty target groups (targetGroupItemCount == 0), returns NSIndexPath(row: 0, section: proposedSection)
• Clamps proposed rows exceeding the group count to the last valid position
• Added FindFirstEmptyGroup helper for the edge case of hovering back over the original index while in mix-groups mode

iOS/MacCatalyst — View Controllers (ReorderableItemsViewController.cs, ReorderableItemsViewController2.cs)
Improved MoveItem for grouped reordering:

• Added section bounds guard (early return if destinationIndexPath.Section >= itemsSource.GroupCount)
• Restructured null checks for fromList/toList to use early returns for clarity
• Clamps toItemIndex to [0, toList.Count] to handle drops into empty or boundary positions

Both Items/ (legacy handler) and Items2/ (current handler) iOS/MacCatalyst implementations receive identical fixes.

Issues Fixed

Fixes #12008

Platforms Tested

• Android
• Windows (drag-and-drop with grouped reordering not supported)
• iOS
• Mac

Code Review: ⚠️ Issues Found

Code Review — PR #31867

PR: CollectionView Fix — Drag and Drop Reordering Can't Drop in Empty Group

---

🔴 Critical Issues

Potential IndexOutOfRangeException in Android Adapter

File: src/Controls/src/Core/Handlers/Items/Android/Adapters/ReorderableItemsViewAdapter.cs

Problem: The bounds check for fromItemIndex uses > instead of >=:

if (fromItemIndex < 0 || fromItemIndex > fromList.Count)
{
    return false;
}

When fromItemIndex == fromList.Count, the condition evaluates to false, so execution continues down to:

var fromItem = fromList[fromItemIndex];

This accesses the list at index Count, which is one past the end — this will throw ArgumentOutOfRangeException.

Correct fix:

if (fromItemIndex < 0 || fromItemIndex >= fromList.Count)
{
    return false;
}

Note: The toItemIndex check correctly uses > (since you can Insert at index Count), so only the fromItemIndex guard needs fixing.

---

🟡 Suggestions

1. Test [Issue] Attribute: Missing iOS and Mac Platforms

File: src/Controls/tests/TestCases.HostApp/Issues/Issue12008.cs

Problem: The [Issue] attribute only marks PlatformAffected.Android:

[Issue(IssueTracker.Github, 12008, "CollectionView Drag and Drop Reordering Can't Drop in Empty Group", PlatformAffected.Android)]

But this PR also fixes the same bug for iOS and MacCatalyst (both Items/ and Items2/ handlers). The attribute should reflect all affected platforms.

Recommendation:

[Issue(IssueTracker.Github, 12008, "CollectionView Drag and Drop Reordering Can't Drop in Empty Group", PlatformAffected.Android | PlatformAffected.iOS | PlatformAffected.macOS)]

---

2. Test Class Wrapped in #if TEST_FAILS_ON_WINDOWS — Should Run on iOS/Android

File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue12008.cs

Problem: The entire test class is wrapped in #if TEST_FAILS_ON_WINDOWS:

#if TEST_FAILS_ON_WINDOWS
// ... both tests ...
#endif

This is used to exclude tests that fail on Windows because drag-and-drop with grouping isn't supported there. However, wrapping the whole class means the tests are only compiled and visible on non-Windows platforms. The tests should still run on both Android and iOS (both of which received fixes in this PR). This is the current correct pattern for Windows exclusion, so it is acceptable — but the PR description should note that both Android and iOS are tested.

No code change required — this is flagged only for awareness.

---

3. Missing Newline at End of File

File: src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue12008.cs

Problem: The diff shows \ No newline at end of file at the bottom of Issue12008.cs in the shared tests project.

Recommendation: Add a newline at the end of the file to follow standard conventions.

---

4. FindFirstEmptyGroup Logic in Delegators: Unusual Trigger Condition

Files:

• src/Controls/src/Core/Handlers/Items/iOS/ReorderableItemsViewDelegator.cs
• src/Controls/src/Core/Handlers/Items2/iOS/ReorderableItemsViewDelegator2.cs

Problem: FindFirstEmptyGroup is only invoked when:

if (originalIndexPath.Equals(proposedIndexPath) && itemsView.CanMixGroups)

During a drag operation, originalIndexPath typically differs from proposedIndexPath (that's the whole point of the drag), so this condition may rarely or never be true. This means the FindFirstEmptyGroup helper might be dead code in practice or only covers a very narrow edge case (e.g., hovering exactly back over the item's original position while CanMixGroups is true).

Recommendation: Verify whether this condition is actually reachable during normal drag-and-drop. If this is meant to handle hovering over an empty group area that maps back to the original index (because there are no items to target), the logic may need a different trigger condition. If this case is intentionally niche, add a comment explaining when it fires.

---

✅ What's Done Well

• Android SimpleItemTouchHelperCallback.cs: The fix to replace viewHolder.ItemViewType != target.ItemViewType with an explicit check for non-draggable types (Header, Footer, GroupHeader, GroupFooter) is semantically correct. Old check prevented dropping on a group header because headers have a different ItemViewType; the new check correctly allows dropping when the dragged item is a regular record.
• Both Items/ and Items2/ iOS handlers fixed in sync: The identical fixes applied to ReorderableItemsViewController.cs/ReorderableItemsViewController2.cs and both delegator files ensures consistent behavior across both handler implementations.
• iOS index clamping: The logic that clamps toItemIndex to [0, toList.Count] for empty groups is well-structured and handles the three cases (empty target, overflow, underflow) explicitly.
• Section bounds check in iOS controllers: The early-return guard if (destinationIndexPath.Section >= itemsSource.GroupCount) prevents crashes when dragging past the valid section range.
• Null checks restructured in iOS controllers: Splitting the original if (fromList != null && toList != null) into separate early returns is a good readability improvement.
• UI test coverage added: Both EmptyGroupCreationShouldWork and DragItemIntoEmptyGroupShouldSucceed tests cover the primary scenarios.

---

[kubaflo]

Could you please split these pr for 2 new ones - iOS and Android?

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 31867

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 31867"

[MauiBot]

🚦 Gate - Test Before and After Fix

📊 Expand Full Gate — 64871a0 · Merge branch 'main' into fix-12008

---

Gate Result: ✅ PASSED

Platform: ANDROID · Base: main · Merge base: 794a9fa6

Test	Without Fix (expect FAIL)	With Fix (expect PASS)
🖥️ Issue12008 Issue12008	✅ FAIL — 1667s	✅ PASS — 485s

🔴 Without fix — 🖥️ Issue12008: FAIL ✅ · 1667s

(truncated to last 15,000 chars)

0010:    at Xamarin.Android.Tasks.FastDeploy.InstallPackage(Boolean installed) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at Xamarin.Android.Tasks.FastDeploy.InstallPackage(Boolean installed) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at Xamarin.Android.Tasks.FastDeploy.RunInstall() [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]

Build FAILED.

/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010: Mono.AndroidTools.InstallFailedException: Unexpected install output: cmd: Failure calling service package: Broken pipe (32) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:  [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at Mono.AndroidTools.Internal.AdbOutputParsing.CheckInstallSuccess(String output, String packageName) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at Mono.AndroidTools.AndroidDevice.<>c__DisplayClass105_0.<InstallPackage>b__0(Task`1 t) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010: --- End of stack trace from previous location --- [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at System.Threading.Tasks.Task.ExecuteWithThreadLocal(Task& currentTaskSlot, Thread threadPoolThread) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010: --- End of stack trace from previous location --- [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at AndroidDeviceExtensions.PushAndInstallPackageAsync(AndroidDevice device, PushAndInstallCommand command, CancellationToken token) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at AndroidDeviceExtensions.PushAndInstallPackageAsync(AndroidDevice device, PushAndInstallCommand command, CancellationToken token) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at Xamarin.Android.Tasks.FastDeploy.InstallPackage(Boolean installed) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at Xamarin.Android.Tasks.FastDeploy.InstallPackage(Boolean installed) [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
/home/vsts/work/1/s/.dotnet/packs/Microsoft.Android.Sdk.Linux/36.1.2/tools/Xamarin.Android.Common.Debugging.targets(333,5): error ADB0010:    at Xamarin.Android.Tasks.FastDeploy.RunInstall() [/home/vsts/work/1/s/src/Controls/tests/TestCases.HostApp/Controls.TestCases.HostApp.csproj::TargetFramework=net10.0-android]
    0 Warning(s)
    1 Error(s)

Time Elapsed 00:16:48.70
* daemon not running; starting now at tcp:5037
* daemon started successfully
  Determining projects to restore...
  All projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0-android36.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0-android36.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0-android36.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Maps -> /home/vsts/work/1/s/artifacts/bin/Maps/Debug/net10.0-android36.0/Microsoft.Maui.Maps.dll
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0-android36.0/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Microsoft.AspNetCore.Components.WebView.Maui/Debug/net10.0-android36.0/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.Foldable/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Foldable.dll
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.Xaml/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Xaml.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.Maps/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Maps.dll
  Controls.TestCases.HostApp -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Controls.TestCases.HostApp.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.dll
  Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Maps.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Xaml.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Maps.dll
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Foldable.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:07:56.07
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
  Determining projects to restore...
  Restored /home/vsts/work/1/s/src/TestUtils/src/VisualTestUtils/VisualTestUtils.csproj (in 1.25 sec).
  Restored /home/vsts/work/1/s/src/TestUtils/src/VisualTestUtils.MagickNet/VisualTestUtils.MagickNet.csproj (in 4.66 sec).
  Restored /home/vsts/work/1/s/src/Controls/tests/TestCases.Android.Tests/Controls.TestCases.Android.Tests.csproj (in 6 sec).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.Core/UITest.Core.csproj (in 5 ms).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.Appium/UITest.Appium.csproj (in 2 ms).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.NUnit/UITest.NUnit.csproj (in 457 ms).
  Restored /home/vsts/work/1/s/src/Controls/tests/CustomAttributes/Controls.CustomAttributes.csproj (in 4 ms).
  Restored /home/vsts/work/1/s/src/TestUtils/src/UITest.Analyzers/UITest.Analyzers.csproj (in 1.71 sec).
  5 of 13 projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0/Microsoft.Maui.Essentials.dll
  Controls.CustomAttributes -> /home/vsts/work/1/s/artifacts/bin/Controls.CustomAttributes/Debug/net10.0/Controls.CustomAttributes.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0/Microsoft.Maui.Controls.dll
  UITest.Core -> /home/vsts/work/1/s/artifacts/bin/UITest.Core/Debug/net10.0/UITest.Core.dll
  VisualTestUtils -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils/Debug/netstandard2.0/VisualTestUtils.dll
  UITest.NUnit -> /home/vsts/work/1/s/artifacts/bin/UITest.NUnit/Debug/net10.0/UITest.NUnit.dll
  VisualTestUtils.MagickNet -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils.MagickNet/Debug/netstandard2.0/VisualTestUtils.MagickNet.dll
  UITest.Appium -> /home/vsts/work/1/s/artifacts/bin/UITest.Appium/Debug/net10.0/UITest.Appium.dll
  UITest.Analyzers -> /home/vsts/work/1/s/artifacts/bin/UITest.Analyzers/Debug/netstandard2.0/UITest.Analyzers.dll
  Controls.TestCases.Android.Tests -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
Test run for /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (x64)

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
/home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.10]   Discovering: Controls.TestCases.Android.Tests
[xUnit.net 00:00:00.27]   Discovered:  Controls.TestCases.Android.Tests
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
   NUnit3TestExecutor discovered 2 of 2 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 04/06/2026 22:07:31 FixtureSetup for Issue12008(Android)
>>>>> 04/06/2026 22:07:35 DragItemIntoEmptyGroupShouldSucceed Start
>>>>> 04/06/2026 22:07:44 DragItemIntoEmptyGroupShouldSucceed Stop
>>>>> 04/06/2026 22:07:44 Log types: logcat, bugreport, server
  Failed DragItemIntoEmptyGroupShouldSucceed [10 s]
  Error Message:
     Item was not moved into the empty group
Assert.That(countText, Is.EqualTo("Count: 1"))
  String lengths are both 8. Strings differ at index 7.
  Expected: "Count: 1"
  But was:  "Count: 0"
  ------------------^

  Stack Trace:
     at Microsoft.Maui.TestCases.Tests.Issues.Issue12008.DragItemIntoEmptyGroupShouldSucceed() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue12008.cs:line 41

1)    at Microsoft.Maui.TestCases.Tests.Issues.Issue12008.DragItemIntoEmptyGroupShouldSucceed() in /_/src/Controls/tests/TestCases.Shared.Tests/Tests/Issues/Issue12008.cs:line 41


>>>>> 04/06/2026 22:07:45 EmptyGroupCreationShouldWork Start
>>>>> 04/06/2026 22:07:47 EmptyGroupCreationShouldWork Stop
  Passed EmptyGroupCreationShouldWork [1 s]
NUnit Adapter 4.5.0.0: Test execution complete

Test Run Failed.
Total tests: 2
     Passed: 1
     Failed: 1
 Total time: 36.0198 Seconds

🟢 With fix — 🖥️ Issue12008: PASS ✅ · 485s

  Determining projects to restore...
  All projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0-android36.0/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0-android36.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0-android36.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Maps -> /home/vsts/work/1/s/artifacts/bin/Maps/Debug/net10.0-android36.0/Microsoft.Maui.Maps.dll
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0-android36.0/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.Maps/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Maps.dll
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.Foldable/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Foldable.dll
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Microsoft.AspNetCore.Components.WebView.Maui/Debug/net10.0-android36.0/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.Xaml/Debug/net10.0-android36.0/Microsoft.Maui.Controls.Xaml.dll
  Controls.TestCases.HostApp -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Controls.TestCases.HostApp.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Graphics.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Maps.dll
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Controls.Xaml -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Xaml.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Controls.Foldable -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Foldable.dll
  Microsoft.AspNetCore.Components.WebView.Maui -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.AspNetCore.Components.WebView.Maui.dll
  Controls.Maps -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.HostApp/Debug/net10.0-android/Microsoft.Maui.Controls.Maps.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:06:10.08
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
Broadcasting: Intent { act=android.intent.action.CLOSE_SYSTEM_DIALOGS flg=0x400000 }
Broadcast completed: result=0
  Determining projects to restore...
  All projects are up-to-date for restore.
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Graphics -> /home/vsts/work/1/s/artifacts/bin/Graphics/Debug/net10.0/Microsoft.Maui.Graphics.dll
  Controls.CustomAttributes -> /home/vsts/work/1/s/artifacts/bin/Controls.CustomAttributes/Debug/net10.0/Controls.CustomAttributes.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Essentials -> /home/vsts/work/1/s/artifacts/bin/Essentials/Debug/net10.0/Microsoft.Maui.Essentials.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Core -> /home/vsts/work/1/s/artifacts/bin/Core/Debug/net10.0/Microsoft.Maui.dll
  Controls.BindingSourceGen -> /home/vsts/work/1/s/artifacts/bin/Controls.BindingSourceGen/Debug/netstandard2.0/Microsoft.Maui.Controls.BindingSourceGen.dll
  ##vso[build.updatebuildnumber]10.0.60-ci+azdo.13757578
  Controls.Core -> /home/vsts/work/1/s/artifacts/bin/Controls.Core/Debug/net10.0/Microsoft.Maui.Controls.dll
  VisualTestUtils -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils/Debug/netstandard2.0/VisualTestUtils.dll
  UITest.Core -> /home/vsts/work/1/s/artifacts/bin/UITest.Core/Debug/net10.0/UITest.Core.dll
  UITest.NUnit -> /home/vsts/work/1/s/artifacts/bin/UITest.NUnit/Debug/net10.0/UITest.NUnit.dll
  UITest.Appium -> /home/vsts/work/1/s/artifacts/bin/UITest.Appium/Debug/net10.0/UITest.Appium.dll
  VisualTestUtils.MagickNet -> /home/vsts/work/1/s/artifacts/bin/VisualTestUtils.MagickNet/Debug/netstandard2.0/VisualTestUtils.MagickNet.dll
  UITest.Analyzers -> /home/vsts/work/1/s/artifacts/bin/UITest.Analyzers/Debug/netstandard2.0/UITest.Analyzers.dll
  Controls.TestCases.Android.Tests -> /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
Test run for /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll (.NETCoreApp,Version=v10.0)
VSTest version 18.0.1 (x64)

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
/home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
[xUnit.net 00:00:00.00] xUnit.net VSTest Adapter v2.8.2+699d445a1a (64-bit .NET 10.0.0)
[xUnit.net 00:00:00.16]   Discovering: Controls.TestCases.Android.Tests
[xUnit.net 00:00:00.44]   Discovered:  Controls.TestCases.Android.Tests
NUnit Adapter 4.5.0.0: Test execution started
Running selected tests in /home/vsts/work/1/s/artifacts/bin/Controls.TestCases.Android.Tests/Debug/net10.0/Controls.TestCases.Android.Tests.dll
   NUnit3TestExecutor discovered 2 of 2 NUnit test cases using Current Discovery mode, Non-Explicit run
>>>>> 04/06/2026 22:15:41 FixtureSetup for Issue12008(Android)
>>>>> 04/06/2026 22:15:44 DragItemIntoEmptyGroupShouldSucceed Start
>>>>> 04/06/2026 22:15:53 DragItemIntoEmptyGroupShouldSucceed Stop
  Passed DragItemIntoEmptyGroupShouldSucceed [8 s]
>>>>> 04/06/2026 22:15:53 EmptyGroupCreationShouldWork Start
>>>>> 04/06/2026 22:15:55 EmptyGroupCreationShouldWork Stop
  Passed EmptyGroupCreationShouldWork [1 s]
NUnit Adapter 4.5.0.0: Test execution complete

Test Run Successful.
Total tests: 2
     Passed: 2
 Total time: 24.5977 Seconds

📁 Fix files reverted (3 files)

• eng/pipelines/ci-copilot.yml
• src/Controls/src/Core/Handlers/Items/Android/Adapters/ReorderableItemsViewAdapter.cs
• src/Controls/src/Core/Handlers/Items/Android/SimpleItemTouchHelperCallback.cs

---

[MauiBot]

🤖 AI Summary

📊 Expand Full Review — 64871a0 · Merge branch 'main' into fix-12008

---

🔍 Pre-Flight — Context & Validation

---

Issue: #12008 - CollectionView Drag and Drop Reordering Can't Drop in Empty Group
PR: #31867 - [Android] CollectionView: Fix drag-and-drop reordering into empty groups
Author: SuthiYuvaraj (community ✨, partner/syncfusion)
Platforms Affected: Android (primary fix, tested), iOS/Mac referenced in issue but separate PRs
Files Changed: 2 implementation, 2 test

Key Findings

• Issue: When using CollectionView with IsGrouped=true, CanReorderItems=true, CanMixGroups=true, dragging an item into an empty group fails because the empty group's only element is the group header.
• Root cause: OnMove in SimpleItemTouchHelperCallback.cs originally checked the target item view type and blocked moves to GroupHeader items — which is the only element in an empty group.
• Fix: Changed OnMove to check the source (dragged item's) view type instead of the target, so drops onto group headers are allowed.
• Secondary fix: Added bounds validation in ReorderableItemsViewAdapter.OnItemMove for fromItemIndex and toItemIndex to prevent out-of-bounds list access.
• Trailing whitespace introduced in GetMovementFlags (line 21 of SimpleItemTouchHelperCallback.cs): { with a trailing space.
• Test EmptyGroupCreationShouldWork only tests UI state (button tap + label text), not the actual drag-and-drop fix.
• Test DragItemIntoEmptyGroupShouldSucceed tests the actual drag-and-drop into empty group.
• Tests wrapped in #if TEST_FAILS_ON_WINDOWS — correct since Windows doesn't support grouped reordering.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #31867	Change OnMove to check source view type (not target); add bounds checks in adapter	✅ PASSED (Gate)	SimpleItemTouchHelperCallback.cs, ReorderableItemsViewAdapter.cs	Android only

---

🔧 Fix — Analysis & Comparison

---

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix (opus-4.6)	Narrow target check: only block top-level Header/Footer; allow GroupHeader/GroupFooter as drop targets; bounds clamping in adapter	✅ PASS	2 files	Precise — still guards global header/footer
2	try-fix (sonnet-4.6)	Remove ALL type checks from OnMove; Math.Max/Min clamping in adapter	✅ PASS	2 files	Simplest — fewest lines, trusts GetMovementFlags fully
3	try-fix (gpt-5.3-codex)	Allow only GroupHeader as target (keep Header/Footer/GroupFooter blocked); normalize index -1→0 only for header-drop case in adapter	✅ PASS	2 files	Targeted — explicit model for "drop onto header = insert at group start"
4	try-fix (gpt-5.4)	Split target filtering via private helper; allow GroupHeader through; adapter handles empty-group-specific insertion	✅ PASS	2 files	Clear separation of concerns
PR	PR #31867	Check source view type (not target) in OnMove; return false bounds checks in adapter	✅ PASSED (Gate)	2 files	Android fix

Cross-Pollination

Model	Round	New Ideas?	Details
claude-opus-4.6	2	Yes	Override CanDropOver() to block Header/Footer while allowing GroupHeader — semantically correct Android API for drop-target filtering
claude-sonnet-4.6	2	Yes	Override chooseDropTarget() for target substitution before OnMove — redirect GroupHeader to real item slot
gpt-5.3-codex	2	Yes	Add ResolveDropPosition() mapper in adapter to convert structural targets to nearest valid insertion slot
gpt-5.4	2	Yes	Introduce temporary virtual "drop slot" row for empty groups during drag — avoids header-specific logic entirely

All cross-pollination ideas are architecturally more complex (more files/design) than existing passing candidates. No additional test runs needed.

Exhausted: Yes
Selected Fix: PR's fix — correct, minimal, and defensive. Source-type check in OnMove + bounds guards in adapter. Attempt 2 (remove all checks + clamping) is an equally valid, marginally simpler alternative.

---

📋 Report — Final Recommendation

---

✅ Final Recommendation: APPROVE

Phase Status

Phase	Status	Notes
Pre-Flight	✅ COMPLETE	Issue #12008 — Android grouped CollectionView drag-and-drop into empty groups
Gate	✅ PASSED	Android — tests fail without fix, pass with fix
Try-Fix	✅ COMPLETE	4 attempts, 4 passing; PR's fix selected
Report	✅ COMPLETE

Selected Fix: PR — Source-type check in OnMove + bounds guards in adapter

---

Summary

PR #31867 fixes a longstanding Android bug where items could not be dragged into an empty group in a grouped CollectionView. The root cause was SimpleItemTouchHelperCallback.OnMove blocking all moves onto GroupHeader view types — and since an empty group's only element is its GroupHeader, drops into empty groups were impossible. The fix is correct for the primary scenario, passes the gate, and is safe to merge with a few minor notes for the author.

---

Root Cause

In SimpleItemTouchHelperCallback.OnMove, the original code checked the target ItemViewType and returned false if the target was any structural element (Header, Footer, GroupHeader, GroupFooter). When dragging into an empty group, the only available drop target is the GroupHeader — so the check always rejected the move. No adapter-side crash protection existed for the resulting out-of-bounds indices.

---

Fix Quality

What the PR does:

1. SimpleItemTouchHelperCallback.OnMove — Switches from checking the target view type to checking the source (dragged item's) view type. This unblocks drops onto GroupHeader elements.
2. ReorderableItemsViewAdapter.OnItemMove — Adds return false bounds guards for fromItemIndex and toItemIndex.

Issues to flag to the author:

1. Source type check in OnMove is redundant (dead code). GetMovementFlags already returns MakeMovementFlags(0, 0) for Header/Footer/GroupHeader/GroupFooter, which prevents them from being long-press-dragged at all. Therefore viewHolder.ItemViewType in OnMove can never be a structural element — the new if (sourceItemViewType == ...) block is unreachable. It's harmless as a defensive check, but the deleted comments explaining the original design were more informative than the replacement.

2. Potential incomplete fix for upward drag into empty groups. The adapter calculates toItemIndex = toIndex - 1 (header offset). It then only applies +1 when toGroupIndex > fromGroupIndex (target group is below source). If the empty group is above the source group, toItemIndex remains -1 and the new return false guard blocks the drop — same as before the fix. The existing test only covers the case where the empty group is added at the end (always below source). Replacing return false with clamping (toItemIndex = Math.Max(0, toItemIndex)) would handle both directions correctly. Three of the four try-fix alternatives used clamping and all passed.

3. Trailing whitespace. Line 21 of SimpleItemTouchHelperCallback.cs has a trailing space: { (the GetMovementFlags opening brace). Minor but should be cleaned up before merge.

4. EmptyGroupCreationShouldWork test doesn't test the bug. It only verifies that tapping a button updates a label — this is unrelated to the drag-and-drop fix. Not blocking, but the test name is misleading.

Strengths:

• Fix is minimal and focused on the right files
• Test DragItemIntoEmptyGroupShouldSucceed correctly validates the core scenario
• Tests are properly wrapped in #if TEST_FAILS_ON_WINDOWS
• INotifyPropertyChanged, ObservableCollection, and DataTemplate usage in HostApp is idiomatic

Comparison with alternatives:

Approach	Simplicity	Handles upward drag	Recommended
PR fix (source check + return false)	✅ Simple	⚠️ Partial	✅ Approvable with note
Attempt 2: Remove all checks + clamping	✅ Simpler	✅ Full	Better long-term
Attempt 3: Allow only GroupHeader as target + normalize	✅ Targeted	✅ Full	Valid alternative

The PR's fix is approvable. The upward-drag edge case is a secondary concern that can be addressed in a follow-up if a user reports it, or the author can address item 2 now with a one-line clamping change.

---