Add CI-backed Android runtime support

[shimat]

Context

This is a technical implementation and maintainability follow-up to #1509.

Official mobile runtime support should not depend on a maintainer-owned physical device or a manually maintained local mobile development environment. The build, packaging, and release decision must be reproducible and regression-tested in GitHub Actions.

The initial goal is Android. iOS is an optional follow-up investigation and is not required to close this issue.

Findings from existing community implementations

Android

sdcb/opencvsharp-mini-runtime demonstrates that OpenCV and OpenCvSharpExtern can be cross-compiled with the Android NDK for arm64-v8a and x86_64. Its current pipeline also runs a native smoke executable on an x64 Android emulator.

It is a useful feasibility reference, but it is not directly suitable as the official OpenCvSharp5 implementation:

• it currently targets OpenCvSharp4;
• the Android NuGet artifacts use linux-* runtime paths;
• the emulator test exercises the native C ABI rather than OpenCvSharp's managed API in a .NET Android app;
• the supported module profile and package contract need to be defined by this repository.

iOS

ariankordi/OpenCvSharp4.iOS demonstrates that device and Simulator arm64 slices can be built as an XCFramework in GitHub Actions.

It is also a feasibility reference rather than an upstream-ready solution. It replaces the normal managed package, provides only a minimal native build, fills unavailable P/Invoke exports with generated abort stubs, and does not run a managed smoke test in the iOS Simulator.

GitHub currently provides hosted Linux arm64 runners and macOS arm64 runners with Xcode and iOS Simulator images, so more complete CI validation is technically possible: https://docs.github.com/en/actions/reference/runners/github-hosted-runners

Initial Android scope

Start with a deliberately small CPU-only runtime profile:

• OpenCV core, imgproc, and imgcodecs;
• Android arm64-v8a for devices;
• Android x86_64 for Windows/Linux emulator use;
• a documented minimum Android API level and pinned NDK version;
• official OpenCvSharp5 runtime NuGet packaging.

Possible later additions such as dnn should be evaluated separately for value, size, dependencies, and CI cost.

The following are out of scope for the initial runtime:

• MAUI UI components;
• camera integration;
• VideoCapture(0) support;
• HighGUI;
• device-specific hardware acceleration.

Applications should acquire camera frames through platform APIs and pass the image data to OpenCvSharp.

Required CI validation

A release candidate should be produced and validated entirely in GitHub Actions:

• Build OpenCV and OpenCvSharpExtern for arm64-v8a and x86_64 from pinned sources.
• Verify ELF architecture, exported symbols, and native dependencies; the package must not accidentally depend on host glibc or an unbundled C++ runtime.
• Pack local OpenCvSharp5 Android runtime NuGet packages using Android-appropriate assets/RIDs or build targets.
• Restore those local packages into a minimal net10.0-android test application.
• Install and run the application on an x64 Android emulator.
• Exercise OpenCvSharp managed APIs through P/Invoke, including Mat creation, an imgproc operation, and image encode/decode.
• Execute an equivalent arm64 runtime smoke test in CI. If a stable arm64 emulator cannot be maintained on GitHub-hosted infrastructure, do not claim stable arm64 support based only on successful cross-compilation.
• Verify the contents of the produced NuGet packages.
• Document the supported module profile and unsupported APIs clearly.
• Ensure that no manual local step is required for packaging or release approval.

A Windows development PC with the Visual Studio MAUI workload and an x86_64 Android Emulator can be used for faster interactive diagnosis, but it must remain optional and must not become part of the release process.

Proposed sequence

1. Prove package loading and managed API execution in an x64 Android emulator.
2. Add the arm64 build and CI execution path.
3. Finalize package naming, module profile, and documentation.
4. Publish as preview first; promote only after CI has remained reproducible across clean runs.

Optional iOS follow-up

After Android is working, a time-boxed iOS feasibility spike may be attempted. Prefer testing a dynamic OpenCvSharpExtern XCFramework so the normal OpenCvSharp5 managed assembly can remain usable and unavailable native modules do not require generated abort stubs.

The spike should build device and Simulator slices, consume a locally packed NuGet package from a minimal .NET iOS application, run managed OpenCvSharp calls in an iOS Simulator, and link the device target in CI.

Do not proceed to official iOS support if the only viable design requires a replacement managed package, a large abort-stub surface, unstable Simulator automation, or recurring manual work after Xcode/.NET workload updates. iOS work is optional and is not part of this issue's Android completion criteria.