Add a single-.so Vulkan+XNNPACK executorch JNI target (#22398)

[youxie]

Summary:

Lets the executorch Android JNI sources be compiled from a Buck package other
than their own.

log.cpp and the JNI headers were not exported, and jni_helper.cpp and
log.cpp included their headers by relative path (#include "log.h"). That
form only resolves while the file is compiled inside
extension/android/jni; the moment another target picks the .cpp up as an
exported source, the include fails. This exports the missing files and
switches both includes to the full <executorch/extension/android/jni/...>
path used everywhere else in the tree.

Motivating case: building one libexecutorch.so that bundles the JNI bridge,
the runtime, and both the Vulkan and XNNPACK backends. Android's linker only
runs static initializers for libraries reached through an explicit
System.loadLibrary, so splitting the backends across several .so files
leaves their REGISTER_BACKEND globals unexecuted and the backends invisible
at runtime. Composing everything into a single .so requires reusing these
JNI sources from another package, which is what the include change enables.

No behavior change to any existing target.

Differential Revision: D118236328

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 3 New Failures

As of commit 8cd16f8 with merge base 02ee1ca ():

NEW FAILURES - The following jobs have failed:

• pull / unittest / linux / linux-job (gh)
  pytorch_tokenizers
• pull / unittest-buck / linux / linux-job (gh)
  pytorch_tokenizers
• pull / unittest-editable / linux / linux-job (gh)
  pytorch_tokenizers

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

[meta-codesync]

@youxie has exported this pull request. If you are a Meta employee, you can view the originating Diff in D118236328.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[psiddh]

@claude thoroughly review this PR and look out for any regressions

[claude]

Claude finished @psiddh's task in 1m 36s —— View job

---

PR Review: Single-.so Vulkan+XNNPACK JNI target

• Read changed files and surrounding context
• Verify include-path changes are consistent with the tree
• Check BUCK export additions for correctness
• Look for regressions / missed spots
• Post review

Verdict: LGTM. This is a low-risk, mechanical change. I traced the two concerns that could cause a regression and both check out. No changes requested.

What the PR does

1. Switches jni_helper.cpp and log.cpp from relative includes (#include "log.h") to the fully-qualified <executorch/extension/android/jni/...> form.
2. Adds runtime.export_file entries for log.cpp, jni_helper.h, log.h, and jni_layer_constants.h so another Buck package can pick these up as exported sources.

Include-path change — consistent ✅

The new include style already matches the rest of the tree. Every other file in extension/android/jni/ uses the <executorch/extension/android/jni/...> form:

• jni_layer.cpp:9,10,12, jni_layer_training.cpp:9-11, jni_layer_asr.cpp:23, jni_layer_image.cpp:21, jni_layer_llama.cpp:28 all use it.

jni_helper.cpp and log.cpp were the only stragglers, so this makes the directory uniform.

No regression to the CMake build ✅

extension/android/CMakeLists.txt:75-78 compiles jni/log.cpp and jni/jni_helper.cpp into the executorch_jni target. That same target also compiles jni/jni_layer.cpp, which already includes <executorch/extension/android/jni/log.h> and resolves fine — so the executorch repo root is already on the include path there. The changed files now use the identical include and will resolve the same way.

No regression to existing Buck targets ✅

Two things worth calling out that I verified:

• log_provider also compiles log.cpp (BUCK:126-135, srcs = ["log.cpp"]). Its include of <executorch/extension/android/jni/log.h> relies on the executorch root being on the include path. This is the standard executorch runtime cxx_library convention (the same convention jni_layer.cpp depends on in executorch_jni), so it holds. Non-blocking, but this is the one target I'd sanity-check in a Buck build if you want belt-and-suspenders.
• No target-name collision from the new export_files. export_file(name = "jni_helper.h") creates a target named jni_helper.h, while jni_headers (BUCK:165-171) lists jni_helper.h / jni_layer_constants.h as bare filenames in exported_headers — those resolve to source files, not the export targets, so there's no clash.

CI note

The 3 red jobs (unittest / unittest-buck / unittest-editable) all fail on pytorch_tokenizers, which is unrelated to these three files — no JNI/Android or include changes are exercised by those jobs. Not caused by this PR.

Minor observations (non-blocking)

• The description says "No behavior change to any existing target," which matches what I see — the export_file additions only create new file targets; nothing existing consumes them yet.
• log.h lacks a #pragma once (unlike jni_helper.h:9). Pre-existing and out of scope for this PR, just flagging since the header is now being exported more broadly. Worth a follow-up if it ever gets included from multiple translation units in one target.