[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.

❌ 1 New Failure, 1 Unrelated Failure

As of commit 2b51364 with merge base fb60708 ():

NEW FAILURE - The following job has failed:

• pull / android / build-android (gh)

BROKEN TRUNK - The following job failed but were present on the merge base:

👉 Rebase onto the `viable/strict` branch to avoid these failures

• pull / test-arm-backend-no-driver (test_pytest_models_tosa) / linux-job (gh) (trunk failure)
  RuntimeError: Command bash /__w/_temp/exec_script failed with exit code 1

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

[RanjithRagavan]

@pytorchbot label "module: android"

[RanjithRagavan]

@pytorchbot label "release notes: none"

[kirklandsign]

@claude review

[claude]

Claude finished @kirklandsign's task in 4m 49s —— View job

---

Code Review: EXECUTORCH_1_0 ABI export

Reviewed the version script, the new check_exported_symbols.sh, and the build wiring. The mechanism is sound — a versioned node exporting the curated surface via ELF interposition is the right primitive for hot-pluggable backends, and gating the AAR build on an llvm-nm assertion is a nice self-verifying touch. A few substantive points below.

---

1. The executorch::aten::* export lines are dead — they match no symbols

executorch::aten is composed entirely of using-aliases (exec_aten.h:73-197): using Tensor = torch::executor::Tensor;, etc. No symbol is ever emitted into that namespace — the real portable types live in executorch::runtime::etensor (already covered by executorch::runtime::*). The PR's own check_exported_symbols.sh:37-40 even acknowledges this and deliberately checks executorch::runtime::etensor::Tensor instead.

So these four lines in version_script.txt (39/44/46 counterparts) never bind anything:

"executorch::aten::*";
"typeinfo for executorch::aten::*";
"vtable for executorch::aten::*";

Not harmful, but they — and the comment block at lines 16-18 describing the executorch::aten::* surface — are misleading about what's actually exported. Recommend dropping them (or replacing with executorch::runtime::etensor::* if you want to be explicit about the data model) so the script documents reality.

2. Broad executorch::runtime::* export works against the size goal it serves

Exported (global) symbols in a version script become GC roots: --gc-sections (Utils.cmake:143) and LTO can no longer strip or internalize anything reachable from executorch::runtime::*. The PR body states this "does not alter code generation, only the dynamic symbol table" — that isn't quite accurate. Making the whole runtime namespace externally visible defeats internal dead-stripping/inlining for those symbols and inflates .dynsym/.dynstr.

Given the motivating issue (#19329) is binary size reduction, it would be worth quantifying the libexecutorch.so size delta from this change (before/after ls -l + size). If it's material, a more surgical export list would keep milestone 1 from regressing the very metric milestones 2-3 aim to improve. Worth at least a sentence in the PR acknowledging the tradeoff.

3. NM_BIN glob is fragile (build_android_library.sh:76)

NM_BIN=$(echo "${ANDROID_NDK}"/toolchains/llvm/prebuilt/*/bin/llvm-nm)

If the glob matches nothing (unusual NDK layout), NM_BIN becomes the literal unexpanded pattern and the check fails with a confusing "no such file" rather than a clear diagnostic. If it matches more than one host dir, NM_BIN holds two space-separated paths and breaks the invocation. A guard makes the failure legible:

NM_BIN=$(ls "${ANDROID_NDK}"/toolchains/llvm/prebuilt/*/bin/llvm-nm 2>/dev/null | head -n1)
[[ -x "${NM_BIN}" ]] || { echo "llvm-nm not found under ${ANDROID_NDK}" >&2; exit 1; }

4. The check assumes a portable (non-ATen) build

In ATen mode ET_RUNTIME_NAMESPACE is runtime::aten (exec_aten.h:66), so register_backend et al. would be executorch::runtime::aten::register_backend and the hard-coded substrings in check_exported_symbols.sh:29-30 wouldn't match. The Android path is portable, so this is fine today — but a one-line comment noting the check is portable-mode-specific would save a future ATen-mode reader some confusion. (The version-script globs themselves are unaffected — * spans ::, so both namespaces are covered.)

Minor

• The required-symbol list in check_exported_symbols.sh duplicates intent from version_script.txt and can drift. That's an acceptable smoke-test design, but a comment cross-linking the two (you already reference the script from the version file — the reverse link exists too) keeps them in sync mentally.
• Placement of the check is correct: it runs on the pre-strip staged .so, and llvm-strip (build_aar) removes local/debug symbols but not dynamic exports, so the verified ABI survives into the AAR. 👍

---

Overall: The approach is correct and the guardrail is well-designed. Nothing blocking, but I'd (a) remove the dead executorch::aten::* lines + comment, and (b) measure/acknowledge the .so size impact of exporting the full runtime namespace, since that's in tension with the parent issue's goal. Items 3-4 are polish.
· branch android-split-backend-abi

[meta-codesync]

@psiddh has imported this pull request. If you are a Meta employee, you can view this in D122178024.

[psiddh]

Thanks for this! Please take a look at #21849 , which splits XNNPACK/Vulkan into same-release backend libraries and should address the size problem this PR is going after. My concern with this hot-swap approach is that EXECUTORCH_1_0 promises a stable cross-version C++ ABI we may not guarantee (for example BackendInterface/EValue layouts, TensorImpl may change often.).