Follow-up to the 0c693237 'sdk version bump' (net10.0 -> net11.0
across the whole solution) and the work to get PostIt.Android building
under the .NET 11 preview SDK installed locally (~/.dotnet):
- Drop Xamarin.AndroidX.Browser and Xamarin.AndroidX.Core.SplashScreen
from PostIt/Directory.Packages.props. They are not pulled by
Avalonia.Android 12.1.1 (its nuspec declares AppCompat + Window only),
are not referenced by any PostIt code, and we already removed the
SplashScreen XML attributes from styles.xml in commit 6b2867c8.
- PostIt.Android.csproj: bump SupportedOSPlatformVersion 23.0.0 ->
24.0.0. Required by the Microsoft.Android.Sdk.Linux 37.0.0-preview.7
target (Android API 24 is the new minimum under .NET 11); below that
the build emits NETSDK warnings about an EoL target SDK level.
Build status (PostIt.Android, Debug, android-x64, EmbedAssemblies):
0 errors, 15 warnings, ~4m24s cold. The locally-installed .NET 11
SDK 11.0.100-preview.7.26381.103 needs /opt/android-sdk/platforms
/android-37.0 to exist; Paul has set up a symlink to the
android-37.1 (Android 17 preview) install until Microsoft catches
up the SDK manifest.
PostIt.Tests: 49/62 passing after the migration; 13 new failures,
most of them HttpListener teardown noise around the OIDC stub
authority suite. Out of scope of this commit.
WIP: addressing the layer-3 WindowingPlatformStub.NotSupportedException
crash on PostIt.Android by downgrading to the Avalonia 11 / Avalonia.Maui
11 stack, where the Android runtime platform layer (IWindowingPlatform)
gets properly bound via the MAUI embedding extension instead of being
left as a stub.
Touched files:
- src/PostIt/Directory.Packages.props:
- Avalonia 12.1.1 -> 11.3.20 (Avalonia, Avalonia.Android,
Avalonia.AvaloniaEdit, Avalonia.Browser, Avalonia.Desktop,
Avalonia.Fonts.Inter, Avalonia.Themes.Fluent).
- New: Avalonia.Maui 11.3.0.
- Microsoft.Maui.Essentials 10.0.100 -> 8.0.100 (aligns with the
Microsoft.Maui.Controls 8.0.x family that Avalonia.Maui 11.3.0
pulls transitively).
- New: Microsoft.Maui.Controls 8.0.100.
- src/PostIt/PostIt.Android/PostIt.Android.csproj:
- TargetFramework net10.0-android -> net9.0-android36.0 (Avalonia
Android 11.3.20 targets net8.0-android34.0, but the
compat-ascending fallback lets us consume from net9.0-android36.0
against the API-36 platform that's already installed locally).
- Add Avalonia.Maui PackageReference.
- Restore Microsoft.Maui.Essentials PackageReference (left in
earlier removal during the MAUI-cause-of-crash hypothesis check).
- src/PostIt/PostIt/PostIt.csproj: TargetFramework net10.0 -> net9.0
(must match what PostIt.Android consumes transitively, otherwise
the build chain breaks).
- src/Yavsc.Abstract/Yavsc.Abstract.csproj: net10.0 -> net9.0 (same
reason; six other consumers stay on net10.0 and pick up the new
assembly via standard TFM compat).
- src/Yavsc.Api.Client/Yavsc.Api.Client.csproj: net10.0 -> net9.0
(same reason).
- src/PostIt/PostIt.Android/Application.cs: rewritten as a bare
Android.App.Application. Avalonia 11 no longer ships
AvaloniaAndroidApplication<TApp> (that was an Avalonia 12
introduction); the Avalonia init now lives in MainActivity via
AvaloniaMainActivity<TApp>. The class is kept only so the
[Application] manifest entry remains.
- src/PostIt/PostIt.Android/MainActivity.cs: now inherits
AvaloniaMainActivity<App> and overrides CustomizeAppBuilder to
chain .UseMaui<PostIt.Maui.MauiEmbeddingApp>(this) before
.WithInterFont(). AvaloniaMainActivity<TApp> handles the
AvaloniaView initialisation in OnCreate.
- src/PostIt/PostIt/Maui/MauiEmbeddingApp.cs (new): empty
Microsoft.Maui.Controls.Application used as the embedding host for
Avalonia.Maui. The MAUI window it produces is consumed by the
Avalonia.Maui embedding pipeline and never surfaces to the user;
Avalonia owns the actual visual tree.
Build status: 11 errors remaining, all CS0234 / CS0246 against
'Avalonia.Controls.ContentPage'. Avalonia 11 did not ship
ContentPage (it's an Avalonia 12 type, presumably for MAUI parity).
All seven PostIt pages inherit ContentPage today and need to be
reworked to UserControl before the build can complete. Follow-up
commit will do that.
Reference: AGENTS.md, 'PostIt.Android boot crash sur AVD x86_64 :
investigation par couches', couche 3.
Two adjustments after the Android boot investigation
(cf. AGENTS.md section 'PostIt.Android boot crash sur AVD
x86_64 : investigation par couches'):
- Avalonia 12.0.4 -> 12.1.1 in PostIt/Directory.Packages.props.
12.1.x is the current Avalonia 12 stable line; 12.0.4 had a
known WindowingPlatformStub regression on Pixel x86_64 AVDs
(issue AvaloniaUI/Avalonia#18459 family). 12.1.1 does not
actually fix the layer-3 NotSupportedException on this
specific Pixel + Android 16 + x86_64 combination (verified
by rebuild + logcat capture on 2026-08-22), but staying on
12.0.4 forever is wrong, and 12.1.1 is the baseline most
users are on. The Makefile qemu-build already passes
-p:EmbedAssembliesIntoApk=true and -p:RuntimeIdentifier=
android-x64 to work around the Fast Deployment / AOT issues.
- qemu-logcat-boot LOGCAT_BOOT_WAIT 15s -> 30s. The crash
reproduces well under 5s, so the wait value is moot for
diagnosis, but 30s gives a wider margin when the runtime
happens to be slow to JIT (boot tries to draw a frame in
texture-pass scenarios). Override on the command line is
unchanged: 'make qemu-logcat-boot LOGCAT_BOOT_WAIT=N'.
No MAUI change: Microsoft.Maui.Essentials was deliberately
unhooked during a hypothesis check and put back to keep the
contact-flow code path stable. The MAUI removal made no
difference to the crash (verified).
Adds Microsoft.Maui.Essentials package and <UseMaui>true</UseMaui> to
src/PostIt/PostIt/PostIt.csproj so the shared project can compile code
that calls MAUI Essentials APIs (Microsoft.Maui.ApplicationModel.*).
Also adds a draft ContactService that wraps Contacts.Default.GetAllAsync()
behind a runtime platform check and permission request.
WIP caveats:
- The portable MAUI Essentials facade compiles on net10.0 but throws
NotImplementedInReferenceAssemblyException at runtime when no
platform-specific MAUI Essentials binary is loaded. A PostIt.Android
project (or equivalent) must reference the Android MAUI Essentials
implementation for Contacts.Default.GetAllAsync() to actually work.
- On desktop (Linux/macOS/Windows) the API is unsupported by design;
ContactService currently throws PlatformNotSupportedException. A
desktop stub returning Array.Empty<Contact>() is the likely next step.
- No tests yet. The scaffold is unverified at runtime; build passes.
The earlier commit removed the client_secret and wired
MainActivity.OnNewIntent to AndroidOidcCallbackSink, but
IdentityModel.OidcClient.LoginAsync still had no IBrowser to drive
the user-agent half of the flow. Without it, the desktop / browser
projects continue to fail at login with 'No browser is available'.
Android now plugs in Chrome Custom Tabs:
* PostIt.Android/Services/AndroidSystemBrowser.cs implements
IBrowser.InvokeAsync using CustomTabsIntent.LaunchUrl and waits
for MainActivity.AndroidOidcCallbackSink to deliver the deep-link
Intent (android://postit-signin?code=...&state=...).
* PostIt/Services/Platform.cs is a tiny static indirection the
shared library uses to ask the running platform for an
IBrowser and the appropriate default RedirectUri, without
referencing any UI framework from the shared assembly.
* LoginPageViewModel reads Platform.DefaultRedirectUri and
Platform.CreateBrowser().Invoke() before calling LoginAsync.
* PostIt.Android/PlatformBootstrap.cs wires the Android side at
startup, and MainActivity.OnCreate calls EnsureInitialized().
* Xamarin.AndroidX.Browser 1.8.0 added to the central package
versions so CustomTabsIntent resolves.
Move product-local package versions out of the root Directory.Packages.props
into per-product props files under src/<Product>/. The root file now only
contains versions for packages declared by two or more top-level products,
which is the actual shared set.
Each per-product Directory.Packages.props imports the root via
GetPathOfFileAbove so that the shared versions are inherited; this is
necessary because the .NET SDK picks the closest Directory.Packages.props
in the hierarchy and does not merge multiple ones.
Per-product file contents:
- src/cli/ Microsoft.AspNetCore.Razor.Language,
Microsoft.Extensions.{CommandLineUtils,Configuration,Hosting}
- src/PostIt/ Avalonia* and CommunityToolkit.Mvvm
- src/PostIt.Tests/ Avalonia.Headless{,XUnit}
- src/Yavsc.Org/ AsciiDocSharp*, Google.Apis.Compute.v1,
HigginsSoft.IdentityServer8.AspNetIdentity,
IdentityServer8.EntityFramework.Storage,
IdentityServer8.Security, IdentityServer8.Storage,
Microsoft.AspNetCore.Antiforgery, Authentication.Google,
Diagnostics.EntityFrameworkCore, Mvc.NewtonsoftJson,
SignalR, EntityFrameworkCore.Tools, Swashbuckle,
System.Security.Cryptography.Pkcs, YamlDotNet
- src/Yavsc.Org.Tests/ Microsoft.AspNetCore.Hosting,
Extensions.Caching.Memory, Options,
Options.ConfigurationExtensions,
Selenium.WebDriver, xunit.v3.{common,extensibility.core}
- src/Yavsc.Server/ Anthropic.SDK, Google.Apis.Calendar.v3,
Magick.NET-Q8-AnyCPU, MailKit, MimeKit,
Microsoft.AspNetCore.Http.Features, StaticFiles,
EntityFrameworkCore.SqlServer,
Npgsql.EntityFrameworkCore.PostgreSQL,
PayPalMerchantSDK, pazof.rules, RazorEngine.NetCore
- src/Yavsc.Web/ IdentityModel.AspNetCore
No per-product file is created for Yavsc.Api, Yavsc.Blogs, Yavsc.Abstract,
or templateWeb: Api and Blogs only declare the shared JwtBearer, Abstract
and templateWeb declare no package references at all.
Also includes a minor cosmetic update to FirstUIStript.cs (Firefox -> Chrome
driver, dedent, comment header). Tests previously failing on DataProtection
keyset / SMTP were unrelated environment issues (resolved by fixing the
SMTP password locally).
