PR #33756 Review: Add Android NativeAOT integration tests

Executive Summary

Verdict: ✅ APPROVE with minor notes

This PR successfully adds Android NativeAOT support to the MAUI integration test suite. The implementation is solid, follows existing patterns, and includes proper workarounds for known Android SDK issues. CI failures are unrelated infrastructure issues (simulator timeouts), not code problems.

Detailed Review by File

1. ✅ eng/pipelines/ci.yml — CI Pipeline Configuration

Changes:

• Adds win_aot_tests and mac_aot_tests jobs with testCategory: AOT
• Windows: 120min timeout
• macOS: 240min timeout (appropriate for slower builds)
• Proper pool selection (public vs internal)

Assessment:

• ✅ Correct: Follows existing pattern for integration test jobs
• ✅ Timeout values: macOS 240min is reasonable (AOT + Android emulator)
• ✅ Parallel execution: Both platforms run in parallel as intended
• ✅ Integration: Properly integrates with stage-integration-tests.yml template

Risk: None. Standard CI configuration.

2. ✅ Microsoft.Maui.Controls.targets — MSBuild Workaround

Changes:

<Target Name="_MauiFixTrimmerRootAssemblyMetadata"
        BeforeTargets="PrepareForILLink"
        Condition="'$(UsingAndroidNETSdk)' == 'true'">
  <ItemGroup>
    <TrimmerRootAssembly Update="@(TrimmerRootAssembly)" 
                         Condition="'%(TrimmerRootAssembly.RootMode)' == ''" 
                         RootMode="All" />
  </ItemGroup>
</Target>

Assessment:

• ✅ Correctness: Properly qualified metadata check (%(TrimmerRootAssembly.RootMode))
• ✅ Scope: Android-only via $(UsingAndroidNETSdk) condition
• ✅ Timing: BeforeTargets="PrepareForILLink" is correct
• ✅ Default value: RootMode="All" matches Android SDK's _FixRootAssembly target
• ✅ Documentation: Clear comment explaining the workaround and linking to issue

Background:

• Android SDK bug dotnet/android#10758 (closed)
• The Android SDK's _FixRootAssembly target uses unqualified %(RootMode) which triggers MSBuild batching errors when user-defined items lack this metadata
• This workaround pre-fills the metadata to avoid the error

Risk: Very low. Android-only, defensive condition, well-documented.

3. ✅ MultiPageFragmentStateAdapter.cs — Trimming Annotation Fix

Changes:

// BEFORE:
[DynamicallyAccessedMembers(BindableProperty.DeclaringTypeMembers
#if NET8_0 // IL2091
  | BindableProperty.ReturnTypeMembers
#endif
)]

// AFTER:
[DynamicallyAccessedMembers(BindableProperty.DeclaringTypeMembers | BindableProperty.ReturnTypeMembers)]

Assessment:

• ✅ Correctness: Removes incorrect NET8_0 ifdef
• ✅ Justification: ReturnTypeMembers should apply to ALL TFMs, not just NET8_0
• ✅ Consistency: Matches other generic collection types in codebase:
  • ItemsView<T>: Uses both members
  • MultiPage<T>: Uses both members
  • TemplatedItemsList<TView, TItem>: Uses both members

Why this change is correct:

• The original #if NET8_0 was a workaround for IL2091 warnings
• The proper fix is to include ReturnTypeMembers for ALL target frameworks
• This ensures the trimmer preserves required constructors on type parameter T

Risk: None. This makes the code MORE correct for trimming.

4. ✅ AOTTemplateTest.cs — Android Test Cases

Major Changes:

1. Added Android test cases (android-arm64, android-x64)
2. Added OnlyAndroid() helper for Linux CI (no iOS workload)
3. Extracted AddNoCodeSigningProps() helper
4. Added PrepareNativeAotBuildPropsAndroid() with NDK path handling
5. Updated warning baselines to use Android-specific warnings

Assessment:

Test Coverage:

[InlineData("maui", $"{DotNetCurrent}-android", "android-arm64")]
[InlineData("maui", $"{DotNetCurrent}-android", "android-x64")]

• ✅ Complete: Covers both Android architectures (arm64, x64)
• ✅ Consistent: Follows existing iOS/Windows patterns
• ✅ Applied to both tests: PublishNativeAOT and PublishNativeAOTRootAllMauiAssemblies

Linux CI Support:

if (isAndroidPlatform && !TestEnvironment.IsMacOS && !TestEnvironment.IsWindows)
{
    OnlyAndroid(projectFile);
}

• ✅ Correct: Modifies TargetFrameworks to only include Android on Linux
• ✅ Prevents restore failures: Linux agents don't have iOS/macOS workloads
• ✅ Reuses existing helper: OnlyAndroid() method already exists in BaseTemplateTests

Code Signing Refactoring:

private static void AddNoCodeSigningProps(List<string> buildProps)
{
    buildProps.Add("EnableCodeSigning=false");
    buildProps.Add("_RequireCodeSigning=false");
}

• ✅ Good refactoring: Extracts duplicate code
• ✅ Only for Apple platforms: Properly conditioned
• ⚠️ Minor note: Could use XML doc comment, but not critical for private method

Android Build Props:

private List<string> PrepareNativeAotBuildPropsAndroid()
{
    var extendedBuildProps = new List<string>(BuildProps)
    {
        "PublishAot=true",
        "PublishAotUsingRuntimePack=true",
        "_IsPublishing=true",
        "IlcTreatWarningsAsErrors=false",
        "TrimmerSingleWarn=false"
    };

    var ndkRoot = Environment.GetEnvironmentVariable("ANDROID_NDK_ROOT");
    if (!string.IsNullOrEmpty(ndkRoot))
    {
        var ndkRootEscaped = ndkRoot.Replace("\"", "\\\"", StringComparison.Ordinal);
        extendedBuildProps.Add($"AndroidNdkDirectory=\"{ndkRootEscaped}\"");
    }

    return extendedBuildProps;
}

• ✅ Correct: Matches iOS/Windows patterns
• ✅ NDK path handling: Properly escapes quotes for paths with spaces
• ✅ Optional NDK override: Only sets if ANDROID_NDK_ROOT is defined
• ✅ Environment variable name: Uses Android SDK standard

Warning Baseline Routing:

var expectedWarnings = isAndroidPlatform
    ? BuildWarningsUtilities.ExpectedNativeAOTWarningsAndroid
    : isWindowsFramework
        ? BuildWarningsUtilities.ExpectedNativeAOTWarningsWindows
        : BuildWarningsUtilities.ExpectedNativeAOTWarnings;

• ✅ Correct: Routes Android to Android-specific baseline
• ✅ Consistent: Follows existing Windows pattern

Risk: Very low. Well-tested patterns, proper platform detection.

5. ⚠️ BuildWarningsUtilities.cs — Android Warning Baseline

Changes:

1. Android baseline with XA1040 + 4× IL3050 warnings
2. Fixed CompareWarningsFilePaths() to handle empty expected paths

Android Warning Baseline:

private static readonly List<WarningsPerFile> expectedNativeAOTWarningsAndroid = new()
{
    new WarningsPerFile
    {
        File = "Xamarin.Android.Common.targets",
        WarningsPerCode = new List<WarningsPerCode>
        {
            new WarningsPerCode
            {
                Code = "XA1040",
                Messages = new List<string>
                {
                    "The NativeAOT runtime on Android is an experimental feature and not yet suitable for production use. File issues at: https://github.com/dotnet/android/issues",
                }
            },
        }
    },
    new WarningsPerFile
    {
        WarningsPerCode = new List<WarningsPerCode>
        {
            new WarningsPerCode
            {
                Code = "IL3050",
                Messages = new List<string>
                {
                    "Microsoft.Android.Runtime.ManagedTypeManager.<GetInvokerTypeCore>g__MakeGenericType|4_1(Type,Type[]): Using member 'System.Type.MakeGenericType(Type[])' which has 'RequiresDynamicCodeAttribute' can break functionality when AOT compiling. The native code for this instantiation might not be available at runtime.",
                    "Android.Runtime.JNIEnv.MakeArrayType(Type): Using member 'System.Type.MakeArrayType()' which has 'RequiresDynamicCodeAttribute' can break functionality when AOT compiling. The code for an array of the specified type might not be available.",
                    "Android.Runtime.JNINativeWrapper.CreateDelegate(Delegate): Using member 'System.Reflection.Emit.DynamicMethod.DynamicMethod(String,Type,Type[],Type,Boolean)' which has 'RequiresDynamicCodeAttribute' can break functionality when AOT compiling. Creating a DynamicMethod requires dynamic code.",
                    "Java.Interop.JavaConvert.<GetJniHandleConverter>g__MakeGenericType|2_0(Type,Type[]): Using member 'System.Type.MakeGenericType(Type[])' which has 'RequiresDynamicCodeAttribute' can break functionality when AOT compiling. The native code for this instantiation might not be available at runtime.",
                }
            },
        }
    },
};

Assessment:

XA1040 Warning:

• ✅ Expected: Android NativeAOT is experimental
• ✅ Appropriate: Warning from Android SDK, not MAUI code
• ✅ File path: "Xamarin.Android.Common.targets" is correct

IL3050 Warnings (Dynamic Code):

• ⚠️ Source: All 4 warnings are from Android SDK runtime code (Microsoft.Android.Runtime, Android.Runtime, Java.Interop)
• ⚠️ Not MAUI code: These are Android SDK implementation details
• ✅ Expected with NativeAOT: Android's Java interop requires dynamic code for generic types
• ⚠️ File path is empty: Second WarningsPerFile has no File specified

Empty File Path Fix:

// BEFORE:
private static bool CompareWarningsFilePaths(this string actual, string expected) 
    => actual.Contains(expected, StringComparison.Ordinal);

// AFTER:
private static bool CompareWarningsFilePaths(this string actual, string expected) =>
    string.IsNullOrEmpty(expected) ? string.IsNullOrEmpty(actual) : actual.Contains(expected, StringComparison.Ordinal);

• ✅ Correct: Handles warnings without file paths (IL3050 from SDK)
• ✅ Necessary: IL3050 warnings don't include file paths in binlog

Questions about Android baseline:

1. Why are these warnings acceptable?

   • They're from Android SDK internals (Java interop)
   • MAUI doesn't control this code
   • Android NativeAOT is experimental (XA1040 says so)

2. Will these warnings always occur?

   • Yes, as long as Android NativeAOT uses Java interop
   • Android SDK team is aware (experimental feature)

3. Should MAUI suppress these in a different way?

   • No, these are SDK warnings, not MAUI warnings
   • Baseline approach is appropriate for integration tests

Recommendation:

• ✅ APPROVE: Baseline is reasonable for experimental Android NativeAOT
• 📝 Note: Add comment explaining why IL3050 warnings are expected
• 📝 Track: Monitor Android SDK progress on reducing these warnings

Risk: Low. These are SDK warnings, not MAUI code warnings.

Cross-Cutting Concerns

Code Quality

• ✅ Consistent with existing patterns (iOS, Windows)
• ✅ Proper platform detection and conditioning
• ✅ Good separation of concerns (Android vs iOS vs Windows)
• ✅ Helpful code comments

Test Coverage

• ✅ Both architectures covered (arm64, x64)
• ✅ Both test scenarios covered (standard + root-all)
• ✅ Warning validation included
• ✅ Linux CI compatibility

Risk to Existing Tests

• ✅ No impact on iOS/Windows: Platform-specific changes
• ✅ Code signing refactor: Safe, just extracts existing code
• ✅ MultiPageFragmentStateAdapter: Android-only file, no impact on iOS
• ✅ CI jobs: New jobs, don't modify existing ones

CI Status

Current Status:

• ✅ Build: PASS
• ✅ iOS NativeAOT (ARM64): SUCCESS
• ❌ Windows AOT: FAILURE (unrelated to PR - simulator timeout)
• ❌ macOS AOT: FAILURE (unrelated to PR - simulator timeout)

Failure Analysis:

• Issue #33862: "Failed to launch Test AVD" (Known Build Error)
• Infrastructure issue, not code issue
• Occurs on many PRs, has BuildRetry flag
• Author confirmed hitting this issue during development

Final Verdict

✅ APPROVE

Summary:
This PR successfully adds Android NativeAOT support to the integration test suite with proper workarounds for Android SDK limitations. All code changes are correct, well-documented, and follow existing patterns.

Strengths:

1. Proper MSBuild workaround for Android SDK bug
2. Correct trimming annotation fix (MultiPageFragmentStateAdapter)
3. Comprehensive test coverage (both architectures, both scenarios)
4. Good code quality and consistency
5. Linux CI compatibility

Minor Notes:

1. Android warning baseline includes SDK warnings (expected for experimental feature)
2. CI failures are infrastructure issues, not code issues
3. Consider adding comment explaining IL3050 baseline (not blocking)

No changes requested. PR is ready to merge.

Recommendations for Follow-Up

1. Track Android SDK progress on reducing IL3050 warnings
2. Update baseline when Android NativeAOT becomes stable
3. Monitor CI infrastructure for AVD launch issues (issue #33862)
4. Consider adding integration test for maui-blazor Android NativeAOT (future work)

Awesome work @sbomer! Thank you!