Android: export curated EXECUTORCH_1_0 ABI from libexecutorch.so (hot-pluggable backends, milestone 1)

[RanjithRagavan]

Summary

First step of the hot-pluggable backends plan (#10457), which lets Android apps opt out of unused backends to shrink binary size (#19329).

Today the Android AAR ships a single libexecutorch.so that links every backend via --whole-archive, and its linker version script exports only JNI_OnLoad and Java_*. A backend built as a standalone .so therefore can't reach the process-wide backend/kernel registries — its self-registration silently writes into a private copy, and delegation fails. This is why external attempts at per-backend .so files hit "duplicate kernel" errors.

The fix: add a versioned EXECUTORCH_1_0 node to extension/android/jni/version_script.txt that exports the curated surface an external .so needs to self-register at load time through normal ELF symbol interposition — the same mechanism the QNN backend already relies on:

• Registration entry points — register_backend, get_backend_class, register_kernels
• RTTI/vtables for polymorphic public types such as BackendInterface (its key function is emitted in the core .so, so subclasses in external .so files need these symbols)
• The public executorch::runtime / executorch::aten API namespaces backend implementations are written against (Tensor, EValue, MemoryManager, FreeableBuffer, logging)
• The et_pal_* C API so backend .so files share the process-wide logging/allocation hooks

The boundary is deliberately namespace-scoped rather than symbol-by-symbol so it stays maintainable as the public headers evolve; everything else stays hidden for LTO/--gc-sections. Additive symbols go into a new version node so external .so files get a stable ABI tag — answering the issue's open question in favor of a curated, versioned list.

What this does NOT change: the monolithic .so topology is untouched — no target, link, or loading-behavior change for existing consumers. Split build mode (milestone 2) and the first carved-out backend (milestone 3) build on top of this.

Test plan

• Self-verifying build: scripts/build_android_library.sh now asserts — via the NDK's llvm-nm — that the built libexecutorch.so actually exports the required symbols (registration functions, BackendInterface RTTI/vtable, etensor::Tensor, EValue, et_pal_emit_log_message, JNI_OnLoad). If the ABI surface ever regresses, the Android AAR build fails loudly instead of shipping a silently broken artifact.
• No-regression: existing Android CI exercises the monolithic path end to end (unit tests, instrumentation tests, demo app builds); exporting additional symbols does not alter code generation, only the dynamic symbol table.
• This unblocks the milestone-1 acceptance criterion: a standalone backend .so can now resolve the core registry symbols at dlopen time; milestone 3's Vulkan pilot will demonstrate the end-to-end flow.

Refs #10457 (milestone 1 of 7), #19329

cc @kirklandsign @cbilgin

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/21945

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

⚠️ 14 Awaiting Approval

As of commit b35dcb0 with merge base 1b2838b ():

AWAITING APPROVAL - The following workflows need approval before CI can run:

• Build documentation (gh)
• Build Presets (gh)
• Cadence Build & Test (gh)
• Lint (gh)
• periodic (gh)
• pull (gh)
• Test ARM Backend (gh)
• Test CoreML Backend (gh)
• Test Cortex-M Backend (gh)
• Test QNN Backend (gh)
• Test QNN Windows MSVC build (gh)
• Test Vulkan Backend (gh)
• Test WebGPU Backend (gh)
• Test XNNPACK Backend (gh)

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[RanjithRagavan]

@pytorchbot label "module: android"

[RanjithRagavan]

@pytorchbot label "release notes: none"