Major-version bump: Avalonia 11 → 12 (TodoApp.Avalonia sample)

[adrianhall]

Summary

Follow-up to #499. The Avalonia sample's NU1903 (Tmds.DBus.Protocol) was resolved by bumping to the latest Avalonia 11.3.x patch (11.3.18) — no major-version bump was required for that fix. This issue tracks a separate, larger effort: bumping the TodoApp.Avalonia sample from Avalonia 11 to 12 (recommend targeting the latest 12.0.x patch, 12.0.5 as of this writing) for general currency, since 11.x will presumably reach end-of-support once 12 is established.

This is not required to close #499 and should be treated as its own scoped PR with a normal fix/validate/PR cycle.

Scope

All items below were confirmed against the sample's actual source (samples/todoapp/TodoApp.Avalonia/) and the official Avalonia 12 breaking changes doc.

Required changes

1. Package versions — bump Avalonia, Avalonia.Themes.Fluent, Avalonia.Fonts.Inter, Avalonia.Desktop, Avalonia.Android, Avalonia.iOS to 12.0.5 (or later) via the shared $(AvaloniaVersion) property in Directory.Build.props.
2. Avalonia.Diagnostics package removed in v12 — drop the Debug-only PackageReference from TodoApp.Avalonia.csproj and TodoApp.Avalonia.Desktop.csproj. No code in the sample calls AttachDevTools(), so this is a clean removal (the paid AvaloniaUI.DiagnosticsSupport replacement is an Avalonia Plus feature and likely out of scope for this OSS sample).
3. App.axaml.cs — binding plugins removed — delete BindingPlugins.DataValidators.RemoveAt(0); and its two Avalonia.Data.Core* usings. The BindingPlugins class no longer exists in v12; behavior is preserved because v12 disables the data-annotations validation plugin by default.
4. App.axaml.cs — Android lifetime type changed — add an IActivityApplicationLifetime branch (using MainViewFactory) before the existing ISingleViewApplicationLifetime check, since Android now implements the former instead of the latter:

   else if (ApplicationLifetime is IActivityApplicationLifetime activityLifetime)
       activityLifetime.MainViewFactory = () => new MainView { DataContext = GetRequiredService<TodoListViewModel>() };

5. Android app-initialization rework:
   • Add a new TodoApp.Avalonia.Android/Application.cs:

     [Application]
     public class Application : AvaloniaAndroidApplication<App>
     {
         protected Application(nint javaReference, JniHandleOwnership transfer) : base(javaReference, transfer) { }
         protected override AppBuilder CustomizeAppBuilder(AppBuilder builder) => base.CustomizeAppBuilder(builder).WithInterFont();
     }

   • Change MainActivity : AvaloniaMainActivity<App> → non-generic MainActivity : AvaloniaMainActivity, removing its CustomizeAppBuilder override (moved above).
   • Add android:name=".Application" to the <application> element in AndroidManifest.xml.
6. MainView.axaml — rename Watermark="Add a new Item" → PlaceholderText="Add a new Item" (old property kept but obsolete; optional but recommended for cleanliness/future-proofing).
7. iOS AppDelegate.cs — its CustomizeAppBuilder override isn't listed as removed for iOS in the breaking-changes doc, so it should compile unchanged, but this needs a real build to confirm.

Confirmed NOT applicable (verified via source grep — no action needed)

Gestures.* attached events, clipboard/IDataObject APIs, GotFocusEventArgs, WindowState-in-styles, TextBlock.LetterSpacing, SystemDecorations/ExtendClientAreaChromeHints, KeyboardNavigationHandler, custom Screen construction, Direct2D1/Blazor/Tizen backends, headless xUnit/NUnit tests.

Tooling / environment prerequisites

• Avalonia.Android 12.0.5 targets net10.0-android36.0 bindings and Avalonia.iOS 12.0.5 targets net10.0-ios26.0/maccatalyst26.0/tvos26.0. The csproj TargetFramework values don't need to change, but the build machine/CI needs current Android API 36 and iOS 26 SDK components (dotnet workload update).
• No CI coverage exists for /samples at all today (build-library.yml, build-docs.yml, build-template.yml don't touch it), so this migration will ship with manual verification only — build + a real smoke-test run of the Desktop head (add/complete/delete an item, confirm sync + notifications) is strongly recommended given both the validation-plugin behavior and the Android lifetime path are changing. Adding a samples build workflow could be a worthwhile separate follow-up.

Related

• Investigate resolving NU1903 for Tmds.DBus.Protocol in Avalonia desktop sample #499 — Avalonia-side NU1903 fix (11.3.x patch bump), already resolved without this major bump.
• Investigate resolving NU1903 for Tmds.DBus in Uno desktop sample #506 — sibling Uno sample NU1903 investigation; the user is separately evaluating a related Uno 5.4.5 → 6.6+ major bump.

[adrianhall]

Cross-link from #522

#522 (TodoApp.Avalonia.Android XA0141 — libSkiaSharp.so not 16 KB page-size aligned) was investigated and closed as won't-fix independently of this issue, because the only viable upstream fix is this Avalonia 11 → 12 bump:

• Avalonia.Skia 11.3.18 (latest 11.x) pins SkiaSharp 2.88.9, which is itself the latest published 2.x SkiaSharp release — no 16 KB-aligned fix exists in the 2.x line.
• Avalonia.Skia 12.x moves to SkiaSharp 3.x (e.g. 12.1.0 → SkiaSharp 3.119.4), whose SkiaSharp.NativeAssets.Android build should be 16 KB-aligned.
• A standalone SkiaSharp.NativeAssets.Android override on top of Avalonia 11.3.18 was ruled out as unverifiable (native/managed ABI mismatch risk with no real Android device/emulator available to test).

Once this Avalonia 12 migration lands, please confirm the TodoApp.Avalonia.Android build no longer emits XA0141 for libSkiaSharp.so as part of verification. If it does resolve, that's worth a note back on #522 for the historical record (it's closed, no need to reopen).