Android: build/runtime fixes for modern Clang + ETDump path override

[jgibson2]

Summary

Five small fixes needed to build and run ExecuTorch Android on hosts with Apple Clang 21, on devices where /data/local/tmp isn't app-writable, and to make the Android build script behave correctly on hosts with multiple Python interpreters:

1. flatcc -Werror on modern Clang. flatcc's vendored CMakeLists.txt hits -Wimplicit-int-conversion-on-negation and -Wunterminated-string-initialization on new Clang. Pass FLATCC_ALLOW_WERROR=OFF into the flatcc_ep ExternalProject so the third-party build doesn't fail.

2. EXECUTORCH_ANDROID_PROFILING was never forwarded. scripts/build_android_library.sh set EXECUTORCH_ENABLE_EVENT_TRACER from $EXECUTORCH_ANDROID_PROFILING but never forwarded the separate -DEXECUTORCH_ANDROID_PROFILING define that gates ETDumpGen allocation in extension/android/jni/jni_layer.cpp. As a result the event tracer was compiled in but the JNI never attached it, and Module.etdump() always returned false.

3. Module.etdump(String outputPath) overload. Add a JNI method (etdumpToNative) and Java wrapper so apps can write the ETDump into their own filesDir. The existing etdump() hardcodes /data/local/tmp/result.etdump, which is not app-writable on modern Android (Pixel 9 / API 36 returns EACCES). The new overload factors the write path through a shared etdump_to_path() helper; etdump() now delegates to it with the legacy path.

4. define_overridable_option was expanding ${DESCRIPTION} unquoted. The set(... CACHE TYPE DOCSTRING [FORCE]) form expects the docstring as a single argument, but ${DESCRIPTION} was unquoted, so any STRING option with a multi-word description that the user overrides on the cmake command line had its description text spill into subsequent set() arguments. One-character fix: quote "${DESCRIPTION}" in both set() calls.

5. scripts/build_android_library.sh never forwarded PYTHON_EXECUTABLE to cmake. The script defaults PYTHON_EXECUTABLE=python3 and honors a caller override, but only used it for which. cmake's find_package(Python3) then picked up whatever interpreter came first on PATH (e.g. Homebrew's python3 on macOS) instead of the project's torch-equipped venv, failing at find_package_torch_headers with 'NoneType' object has no attribute 'submodule_search_locations'. Pass -DPYTHON_EXECUTABLE="${PYTHON_EXECUTABLE}" so the script's documented behavior actually flows through.

Test plan

• Apple Clang 21 host build: scripts/build_android_library.sh now succeeds (flatcc no longer fails -Werror).
• With EXECUTORCH_ANDROID_PROFILING=1: -DEXECUTORCH_ANDROID_PROFILING reaches the JNI compile, ETDumpGen is attached, Module.etdump() returns true and writes a valid .etdump.
• On Pixel 9 / API 36: Module.etdump(context.getFilesDir() + "/result.etdump") succeeds; legacy Module.etdump() still works on devices where /data/local/tmp is writable.
• Default build (EXECUTORCH_ANDROID_PROFILING unset): unchanged — etdump() returns false as before.
• cmake -DEXECUTORCH_VULKAN_FP16_PRECISION=mediump … (multi-word description STRING option) now configures cleanly.
• Hosts with both Homebrew python3 and a torch-equipped venv: PYTHON_EXECUTABLE=$VENV/bin/python scripts/build_android_library.sh configures correctly.

🤖 Authored with Claude Code

cc @kirklandsign @cbilgin

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❗ 1 Active SEVs

There are 1 currently active SEVs. If your PR is affected, please view them below:

• Ubuntu services are down

❌ 2 New Failures, 1 Cancelled Job, 4 Unrelated Failures

As of commit dc1bcb3 with merge base 8a397b4 ():

NEW FAILURES - The following jobs have failed:

• pull / test-lora-linux / linux-job (gh)
  RuntimeError: Command docker exec -t 21548167bf81fbb090f5bd574f013fdf11518b988e1c8a5b4f5bdfe21a86d1b8 /exec failed with exit code 1
• pull / test-lora-multimethod-linux / linux-job (gh)
  RuntimeError: Command docker exec -t 0d46223f11df5a38c92d5c6b3dc8417813b884a27bcfac526b32a4488e98da9f /exec failed with exit code 1

CANCELLED JOB - The following job was cancelled. Please retry:

• periodic / gather-models (gh)

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

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

• pull / unittest / linux / linux-job (gh) (trunk failure)
  examples/models/llama/tests/test_static_attention.py::StaticAttentionTest::test_within_transformer
• pull / unittest / macos / macos-job (gh) (trunk failure)
  ##[error]The operation was canceled.
• pull / unittest-editable / linux / linux-job (gh) (trunk failure)
  examples/models/llama/tests/test_static_attention.py::StaticAttentionTest::test_within_transformer
• pull / unittest-editable / macos / macos-job (gh) (trunk failure)
  ##[error]The operation was canceled.

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

[jgibson2]

@pytorchbot label "release notes: android"

[SS-JIA]

@claude Review these changes

[claude]

Claude finished @SS-JIA's task in 2m 8s —— View job

---

Code Review for PR #19293

• Read changed files and gather context
• Review third-party/CMakeLists.txt (flatcc -Werror fix)
• Review scripts/build_android_library.sh (profiling flag forwarding)
• Review extension/android/jni/jni_layer.cpp (JNI etdump changes)
• Review extension/android/executorch_android/src/main/java/org/pytorch/executorch/Module.java (Java wrapper)
• Post review summary

---

Summary

Overall this is a solid, well-scoped PR that fixes real issues. The three changes are logically independent and each solves a clear problem. A few items to consider:

---

1. third-party/CMakeLists.txt — LGTM

Adding -DFLATCC_ALLOW_WERROR=OFF to the flatcc_ep ExternalProject is the correct approach. This is a third-party build; we shouldn't be blocked by new warnings in vendored code.

Note: I wasn't able to verify that FLATCC_ALLOW_WERROR is an actual option in flatcc's CMakeLists (the submodule isn't checked out in CI), but given the PR's test plan confirms the build succeeds, this looks correct.

---

2. scripts/build_android_library.sh — LGTM

Forwarding -DEXECUTORCH_ANDROID_PROFILING is necessary because extension/android/CMakeLists.txt:94-98 uses it to both link etdump/flatccrt and define the compile definition. Without this, the event tracer headers are compiled in but the JNI code is #ifdef'd out.

---

3. extension/android/jni/jni_layer.cpp — Mostly good, a few observations

Positive changes:

• Adding O_TRUNC to open() — correct fix, prevents stale data if the file already exists.
• Resource leak fixes: close(etdump_file) and free(etdump_data.buf) on write failure — good catch on the original code's missing cleanup.
• %zd format for ssize_t — correct.

Potential issues:

1. Null check on event_tracer() (line 479-480): If module_->event_tracer() returns null for any reason (e.g., tracing was enabled at compile time but the module was created without an ETDumpGen in some code path), the cast + get_etdump_data() call would segfault. Consider a null guard:

   auto* tracer = module_->event_tracer();
   if (!tracer) {
     ET_LOG(Error, "No event tracer attached");
     return false;
   }
   executorch::etdump::ETDumpGen* etdumpgen =
       static_cast<executorch::etdump::ETDumpGen*>(tracer);

   Fix this →

2. private: / public: visibility toggle (lines 476, 512): The helper is inserted between existing public methods, toggling visibility mid-class. This works but is a bit unusual — consider moving etdump_to_path near other private members or at least removing the extra blank line after public: on line 512 for style consistency.

3. outputPath null safety (line 473): If Java passes a null String, outputPath->toStdString() will crash via JNI. The Java wrapper currently doesn't null-check outputPath before calling etdumpToNative. Consider adding a null check in either Java or C++.
   Fix this →

---

4. Module.java — Good

The new etdump(String) overload correctly follows the existing pattern (lock, validity check, delegate to native). The Javadoc is clear and appropriate.

The difference in style from the no-arg etdump() (which is a bare native method without lock/validity check) is worth noting — it means the no-arg version doesn't have the same safety guarantees. But that's pre-existing behavior and not something this PR needs to fix.

---

Overall Assessment

Approve with minor suggestions. The fixes are correct and well-motivated. The two suggestions above (null guards) are defensive improvements that would prevent potential crashes in edge cases but aren't blockers.

---

[jgibson2]

Addressed review

[SS-JIA]

Changes LGTM, but will defer to @kirklandsign or @psiddh for the final stamp.