Publish an android-x64 .NET runtime package - #3818
Conversation
Without an android-x64 runtime package, .NET RID fallback resolves android-x64 -> linux-bionic-x64 -> linux-x64, so .NET for Android and MAUI apps building for the x86_64 ABI pack the manylinux glibc libsherpa-onnx-c-api.so and libonnxruntime.so into lib/x86_64/. Those are 4 KB aligned (failing Google Play's 16 KB page size requirement) and link against ld-linux-x86-64.so.2, so they cannot load under bionic. The correct binaries already ship in sherpa-onnx-v<VERSION>-android.tar.bz2 under jniLibs/x86_64/. Source the new package from there, exactly as android-arm64 is sourced from jniLibs/arm64-v8a/.
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
📝 WalkthroughWalkthroughThe .NET Android packaging pipeline now supports the ChangesAndroid x64 packaging
Estimated code review effort: 2 (Simple) | ~10 minutes Sequence Diagram(s)sequenceDiagram
participant BuildScript
participant AndroidArchive
participant RuntimeDirectories
participant NuGetProject
BuildScript->>AndroidArchive: Download and extract Android libraries when needed
AndroidArchive->>RuntimeDirectories: Copy arm64 and x64 native libraries
BuildScript->>NuGetProject: Build and package configured runtime identifiers
Possibly related issues
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@scripts/dotnet/run.sh`:
- Around line 91-110: Update the Android staging guards in the
download/extraction block to verify both required files, libonnxruntime.so and
libsherpa-onnx-c-api.so, for each android-arm64 and android-x64 directory.
Trigger extraction and copying whenever either library is missing, while
preserving the existing per-architecture copy behavior.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: aa91e916-33c1-42ee-89e3-650a1c3557fa
📒 Files selected for processing (4)
scripts/dotnet/.gitignorescripts/dotnet/generate.pyscripts/dotnet/run.shscripts/dotnet/sherpa-onnx.csproj.in
|
Thanks — keeping the single-file guard as-is, for consistency with the rest of the script. All seven other download blocks in run.sh use the same one-sentinel idiom (check a single library, e.g. libsherpa-onnx-c-api.so), and this PR deliberately preserves the guard that the original android-arm64 block already had. A partially-staged directory can't occur through normal execution: both libraries are copied by a single cp invocation, and the script runs under set -e, so a failed copy aborts the run before leaving partial state. CI starts from a fresh /tmp each run, so the only way to hit the missing-libonnxruntime.so case is manually deleting one file from a local cache — and rm -rf $src_dir/android-* recovers that. Happy to switch to the both-files check if the maintainers prefer it, but I'd rather not diverge from the established style of the script in this PR. |
There was a problem hiding this comment.
Pull request overview
This PR fixes a .NET/NuGet packaging gap by adding an android-x64 runtime package so RID resolution no longer falls back to linux-x64 (glibc / 4 KB-aligned binaries) for Android x86_64 consumers. It extends the existing .NET packaging scripts/templates to stage and pack the already-published Android release tarball’s jniLibs/x86_64 binaries into a proper runtimes/android-x64/native/ NuGet runtime package, and wires that package into the meta-package.
Changes:
- Add
android-x64to the .NET meta-package<RuntimeIdentifiers>and its runtime-package dependency list. - Extend the dotnet packaging scripts to stage
jniLibs/x86_64from the Android release tarball and generate/build anandroid-x64runtime.nupkg. - Ignore the generated
scripts/dotnet/android-x64/staging directory in the dotnet scripts’.gitignore.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| scripts/dotnet/run.sh | Adds android-x64 RID and reworks Android tarball staging to populate both android-arm64 and android-x64 from one download/extract. |
| scripts/dotnet/generate.py | Generates the android-x64 runtime project alongside the existing android-arm64 one. |
| scripts/dotnet/sherpa-onnx.csproj.in | Adds android-x64 to the meta-package RIDs and references org.k2fsa.sherpa.onnx.runtime.android-x64. |
| scripts/dotnet/.gitignore | Ignores the new android-x64 staging directory. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
csukuangfj
left a comment
There was a problem hiding this comment.
Thank you for your contribution!
Fixes #3817
Problem
The .NET distribution ships per-RID native packages plus the
org.k2fsa.sherpa.onnxmeta-package, but there is noandroid-x64runtime package. The .NET RID graph falls backandroid-x64→linux-bionic-x64→linux-x64, so any .NET for Android or MAUI app building for thex86_64ABI silently resolves the manylinux glibc binaries fromorg.k2fsa.sherpa.onnx.runtime.linux-x64and packs them intolib/x86_64/of the APK/AAB. Those binaries cannot load under bionic at all, and additionally fail Google Play's 16 KB page size requirement (which blocks app updates from 31 May 2026).android-x64is the only affected ABI:android-arm64already has a more specific package that wins RID resolution, and the 32-bit Android RIDs have nolinux-arm/linux-x86packages to fall back to, so they fail loudly at restore/build time instead of packing broken binaries.Evidence
Broken binaries currently resolved via fallback —
org.k2fsa.sherpa.onnx.runtime.linux-x641.13.4,runtimes/linux-x64/native/:4 KB
p_alignfails the 16 KB page size requirement; the glibc/ld-linux-x86-64.so.2dependencies cannot be satisfied by bionic.Correct binaries already published —
sherpa-onnx-v1.13.4-android.tar.bz2,jniLibs/x86_64/:16 KB aligned, bionic-only dependencies. This is the same release asset the
android-arm64package is already built from — the fix is packaging only; nothing is recompiled.Changes
scripts/dotnet/run.sh— addandroid-x64toRIDS; restructure the Android download block so the singlesherpa-onnx-v<VERSION>-android.tar.bz2is downloaded at most once and feeds bothandroid-arm64(fromjniLibs/arm64-v8a/) andandroid-x64(fromjniLibs/x86_64/), keeping the per-RID idempotency guards. Renamedandroid_arm64_tarball*vars toandroid_tarball*since the tarball was never arm64-specific.scripts/dotnet/generate.py— addprocess_android(s, "x64");process_androidwas already RID-parameterized.scripts/dotnet/sherpa-onnx.csproj.in— addandroid-x64to<RuntimeIdentifiers>and aPackageReferencetoorg.k2fsa.sherpa.onnx.runtime.android-x64in the meta-package.scripts/dotnet/.gitignore— ignore the generatedandroid-x64/staging directory, matching the other RID directories.Verified locally:
bash -n run.shandast.parse(generate.py)pass; renderingsherpa-onnx.csproj.runtime.inforandroid-x64produces<RuntimeIdentifier>android-x64</RuntimeIdentifier>,<PackageId>org.k2fsa.sherpa.onnx.runtime.android-x64</PackageId>, andPackagePathruntimes/android-x64/native/%(Filename)%(Extension); the meta template renders the new RID and package reference.No changes to
.github/workflows/were needed:dot-net.yamlandtest-dot-net.yamlinvokescripts/dotnet/run.shand pushorg.k2fsa.sherpa.onnx.*.nupkgwith a wildcard — they don't enumerate RIDs. All otherandroid-arm64grep hits are NDK build scripts (build-android-arm64-v8a.sh), APK scripts, or Flutter packaging, which are unrelated to .NET RIDs.Notes
scripts/dotnet/run.sh(via thedot-net.yamlrelease workflow) for a release; merging alone publishes nothing.android-arm/android-x86(32-bit) are deliberately not added. They are not silently broken today — with nolinux-arm/linux-x86fallback packages, resolution fails visibly instead of packing wrong binaries. The tarball does containarmeabi-v7a/andx86/libraries, so the same pattern could add them later if anyone still targets 32-bit Android; kept out of scope here to keep the review focused.🤖 Generated with Claude Code
Summary by CodeRabbit
New Features
Bug Fixes
Chores