.NET Android 36.1.69 / Mono 10.0.12: clarification and fix for non-16-KB-aligned GNU_RELRO ends

Start with the synthetic LLD repro in the issue: assemble the snippet for aarch64 and x86_64, link with -z max-page-size=16384, and inspect GNU_RELRO with llvm-readelf. The SDK side is in LinkApplicationSharedLibraries.cs and NativeLinker.cs, plus the _CreateApplicationSharedLibraries target and Documentation/project-docs/ApkSharedLibraries.md. Done means maintainers state whether these layouts are supported on 16 KB pages and name a supported setting or fixed SDK for generated libraries.

Android framework version

net10.0-android

Affected platform version

Microsoft.Android.Sdk.Windows 36.1.69; Mono Android runtime 10.0.12; Windows host; net10.0-android Release; min API 23, target API 36; LLD 18.1.6

Description

Finding and expected result

The current Android guidance requires (VirtAddr + MemSiz) % 0x4000 == 0 for GNU_RELRO. Seventeen arm64/x64 libraries supplied or generated by this .NET Android toolchain fail this formula although their LOAD alignment passes. This is a static compatibility finding, not an observed crash report. Please clarify the supported layouts against that guidance and identify a stable toolchain fix or supported project setting if relinking is required.

Environment: Windows host; Microsoft.Android.Sdk.Windows 36.1.69; Mono Android runtime 10.0.12; Release net10.0-android; min API 23, target API 36; AOT and RELRO retained. ZIP alignment passes. Twelve affected libraries match vendor package prebuilts byte for byte; five are SDK-generated. No application binaries, business data, credentials or proprietary source are included.

ELF evidence

ABI	Library	RELRO VirtAddr	RELRO MemSiz	End	Prebuilt SHA-256 / origin
arm64-v8a	libassembly-store.so	0x42D0	0xD30	0x5000	Application-generated; binary not attached
x86_64	libassembly-store.so	0x42D0	0xD30	0x5000	Application-generated; binary not attached
arm64-v8a	libarc.bin.so	0x42D0	0xD30	0x5000	Application-generated; binary not attached
x86_64	libarc.bin.so	0x42D0	0xD30	0x5000	Application-generated; binary not attached
x86_64	libxamarin-app.so	0x6C4B0	0x5B50	0x72000	Application-generated; binary not attached
arm64-v8a	libSystem.Globalization.Native.so	0x14850	0x7B0	0x15000	B917AAE2973E3BC7286655B8DD85F331FC39DD3DB3820D7374D6440EB092EA18
arm64-v8a	libSystem.IO.Compression.Native.so	0xBC4B0	0xB50	0xBD000	EBB9A6B7C216A6461A8F2C212524AE41F44662496AC01DB56A6AA098FF810F71
arm64-v8a	libSystem.Native.so	0x1C4B0	0xB50	0x1D000	9C39E80C604E34DA94388518E91C64024302FB92E5E45F54B9EE9FC9A638AF76
arm64-v8a	libmono-component-marshal-ilgen.so	0xC340	0xCC0	0xD000	4D7482352AFD571769F3E70A62F0A89A254D0A5FD1FC9A466CCA4D5D3666C453
arm64-v8a	libmonosgen-2.0.so	0x2F3970	0x6690	0x2FA000	13C160BF504107E2FED22F74BF88D6FDE281C4334E081BB48FDB26ADD060FBD8
arm64-v8a	libmonodroid.so	0x105E90	0x7170	0x10D000	60B5A7FBC513A26BE52E1F895B8C3EF05CCE25A81AB86A5F4EF90BE8721FF848
x86_64	libSystem.Globalization.Native.so	0x14150	0xEB0	0x15000	134404BDC693FF60E9A363F407E180A81D440A98000FA78CBF798E44A8936130
x86_64	libSystem.IO.Compression.Native.so	0xCC940	0x6C0	0xCD000	BE42B89EFADFD7409787BA33D8800A408D9B4BD141590FA3281001C137265253
x86_64	libSystem.Native.so	0x1BF20	0x10E0	0x1D000	496DE7E983B2A27BA92FA9F9DCCC323504705C66459750B4B23EA72ACE64F81E
x86_64	libmono-component-marshal-ilgen.so	0xC810	0x7F0	0xD000	CF8A9EA55288CAE01418F5046C52FDB580D344E865C17F10D0CF91E7BD95C7B1
x86_64	libmonosgen-2.0.so	0x31D4C0	0x5B40	0x323000	EEC01A889DC71F5DB5C98A32A4877FF2C1AC5119E654C3B8AA3EEA0BD2D4F6D0
x86_64	libmonodroid.so	0x11C920	0x66E0	0x123000	293EB7C8752BF678C6AA317E80F051305BB9C31926D83155A5807393FE7AE784

SDK-generated linker configuration checked

The installed 36.1.69 _CreateApplicationSharedLibraries target and the matching tagged upstream LinkApplicationSharedLibraries task were inspected. The task exposes ZipAlignmentPages, not an arbitrary linker-arguments property. Its NativeLinker uses maximum-page-size arguments; no common-page-size argument or public additional-arguments hook appears in this inspected path. App AOT arguments therefore do not configure this separate generated-library task. Please identify a supported setting or fixed SDK, rather than requiring replacement of internal tasks or global SDK edits. This inspection is limited to the named task/path.

Runtime evidence and limits

The exercised application runs on an x64 Android 36 emulator with PAGE_SIZE=16384 and page-size compatibility modes disabled. Authenticated module lists, calendars, Contacts CRUD, logout/MFA login and virtual QR camera preview were exercised without a native crash on those paths. QR decoding, invalid-QR rejection and valid Web-to-Android pairing subsequently passed on 9 October 2026, including authenticated home. This is not exhaustive runtime coverage and not arm64 16 KB evidence; complete photo capture/upload remains unqualified. A read-only padding diagnostic found no overlap with declared writable LOAD bytes in the rounded RELRO tail for these findings; this is not treated as an exemption.

The SDK documents libassembly-store.so and libarc.bin.so as mmap payload containers appended to ELF stubs. Please confirm whether different requirements apply to such containers, while also addressing the executable runtime libraries.

Questions

1. Are these exact prebuilt/generated layouts supported on 16 KB Android despite the documented formula?
2. If a relink is needed, which stable runtime/SDK release addresses it?
3. Which supported project setting controls common page size for SDK-generated native libraries?
4. What additional arm64/x64 runtime evidence is needed to resolve this finding?

Primary references

• https://developer.android.com/guide/practices/page-sizes#check-the-relro-security-flag
• https://github.com/dotnet/android/wiki/Android-support-for-devices-with-16k-pages
• https://raw.githubusercontent.com/dotnet/android/36.1.69/Documentation/project-docs/ApkSharedLibraries.md
• https://raw.githubusercontent.com/dotnet/android/36.1.69/src/Xamarin.Android.Build.Tasks/Tasks/LinkApplicationSharedLibraries.cs
• https://raw.githubusercontent.com/dotnet/android/36.1.69/src/Xamarin.Android.Build.Tasks/Utilities/NativeLinker.cs

Steps to Reproduce

1. Inspect the GNU_RELRO program headers of the listed arm64-v8a/x86_64 runtime prebuilts shipped with Microsoft.Android.Sdk.Windows 36.1.69 / Mono Android 10.0.12, and of the SDK-generated libraries in a Release net10.0-android output.
2. Check LOAD alignment separately, then compute (GNU_RELRO VirtAddr + MemSiz) % 0x4000. The end addresses listed above fail the documented RELRO formula.
3. Independently reproduce the linker layout with LLD 18.1.6 and llvm-mc using only the synthetic source below. No proprietary application is needed for this linker example.

.text
.globl repro_function
.type repro_function, %function
repro_function:
    ret
.size repro_function, .-repro_function
.section .data.rel.ro, "aw"
    .quad repro_function
.data
.globl repro_mutable
.type repro_mutable, %object
repro_mutable:
    .quad 0
.size repro_mutable, .-repro_mutable
.section .note.GNU-stack, ""

Assemble separately for aarch64-linux-android and x86_64-linux-android. Link with the corresponding emulation (aarch64linux or elf_x86_64), --shared --no-relax -z relro -z now -z max-page-size=16384. Inspect the program headers with llvm-readelf. LOAD alignment passes but the RELRO end is not 16 KB aligned on both architectures. Repeat adding -z common-page-size=16384: this aligns the RELRO end in both isolated examples.

This independent linker result does not itself rebuild the precompiled runtime libraries or the SDK payload stubs, and no vendor binary or SDK installation was modified.

Did you find any workaround?

No supported application-level workaround has been established for all listed libraries. Adding -z common-page-size=16384 fixes the isolated synthetic linker examples only. We have not patched supplier ELF binaries, replaced SDK tasks, disabled AOT/RELRO or weakened the audit.

Relevant log output

Static ELF findings, not a crash log. The exact RELRO addresses and public prebuilt hashes are included in Description. No application binlog, APK/AAB, private source, account or secret is attached.