TodoApp.Avalonia.Android: SkiaSharp native library not 16 KB page-size aligned (XA0141)

[adrianhall]

Summary

Surfaced by the new mobile CI added in #511 (PR #519), specifically the TodoApp.Avalonia.Android build (net10.0-android). The build succeeds, but produces:

Xamarin.Android.Common.targets(2417,3): warning XA0141: Android 16 will require 16 KB page sizes, shared
library 'libSkiaSharp.so' does not have a 16 KB page size. Please inform the authors of the NuGet package
'SkiaSharp.NativeAssets.Android' version '2.88.9' which contains 'runtimes/android-arm64/native/libSkiaSharp.so'.
See https://developer.android.com/guide/practices/page-sizes for more details.

(reported once per ABI - android-arm64 and android-x64 - and once per compile pass, so 4 total lines for 2 distinct findings.)

Root cause

SkiaSharp.NativeAssets.Android isn't referenced directly anywhere in samples/todoapp/TodoApp.Avalonia/; it's a transitive dependency of Avalonia.Android (Avalonia renders via Skia). samples/todoapp/TodoApp.Avalonia/Directory.Build.props pins AvaloniaVersion to 11.3.18, which resolves SkiaSharp.NativeAssets.Android to 2.88.9 - a version whose native libSkiaSharp.so binaries predate 16 KB memory page size alignment. Newer SkiaSharp releases exist upstream (checked nuget.org directly: versions well past 4.15x.x are published today, vs. the 2.88.9 pulled in here), so this is plausibly already fixed further up the dependency chain, but SkiaSharp.NativeAssets.Android's version here is entirely controlled by whatever version Avalonia.Android 11.3.18 depends on - it isn't something this repo pins directly today.

Impact

Low/informational today - this is a forward-looking compatibility warning, not a build failure, and doesn't affect arm64/x64 devices running current Android page sizes. It will become a real compatibility problem once 16 KB page size becomes mandatory (Android has been phasing this in via Play Store requirements for new app submissions), so it shouldn't be ignored indefinitely.

Suggested fix directions (needs investigation before picking one)

1. Check whether a newer Avalonia/Avalonia.Android release (past 11.3.18) already pulls a 16 KB-aligned SkiaSharp.NativeAssets.Android. If so, bumping AvaloniaVersion in samples/todoapp/TodoApp.Avalonia/Directory.Build.props is the cleanest fix and would also apply automatically to TodoApp.Avalonia.iOS/.Desktop.
2. If no compatible Avalonia release exists yet, consider whether explicitly overriding SkiaSharp.NativeAssets.Android to a newer version (independent of Avalonia's own pin) is safe - this carries some risk of a version mismatch with whatever native API surface Avalonia's Skia bindings expect from that release, so would need real on-device/emulator testing, not just a clean build.
3. If neither is viable yet, this may simply need to wait on upstream (Avalonia/SkiaSharp) and be revisited later - in which case this issue should stay open as a tracking item rather than being closed with a workaround.

This is a samples/ dependency-version investigation, similar in shape to #506 (Uno's Uno.WinUI/CommunityToolkit.WinUI.Behaviors conflict) - the right fix isn't obvious without testing an actual Avalonia version bump on a real Android target.

Related

• Add CI workflow to build mobile /samples heads: Android, iOS, Uno (Phase 3 of #509) #511 / PR ci: add build-samples workflow for Phase 3 mobile heads (#511) #519 - Phase 3 samples CI rollout, where this was surfaced.