[kevinaboos]

Fixes for running on 32-bit ARM Android (armv7, ABI armeabi-v7a), so Robrix can ship an APK for devices with a 32-bit Android system. Many of those devices run Android 8 or 9, so the last commit adds a file provider that Robrix needs to share attachments there. Each change is a separate commit.

Fixes

1. DrawVars: padding so instance fields follow dyn_instances on 32-bit targets. This ports the DrawVars part of upstream commit 100b70c, so upstream dev already has it.
   • On 32-bit targets the 8-byte-aligned struct ended 4 bytes past dyn_instances.
   • That shifted every draw call's #[live] instance fields (rect_pos, rect_size, colors, glyph data, ...) by one f32 lane, so the whole UI would draw wrong on armv7.
   • A const assert now keeps that gap at zero. Without the padding it fails to compile for armv7 and passes for aarch64.
2. Android: correct gettid syscall number on 32-bit ARM and x86.
   • These use the legacy syscall table, where 178 (the old fallback) is rt_sigqueueinfo.
   • android_entry made that call with garbage arguments on every launch on armv7.
   • The result is only used for OpenXR, but the stray syscall itself could do damage.
3. cargo-makepad: look for NDK shared libs in the armv7 sysroot directory.
   • The NDK keeps armv7 libraries under sysroot/usr/lib/arm-linux-androideabi, not under the clang wrapper prefix armv7a-linux-androideabi.
   • So an armv7 APK/AAB never bundled a needed NDK library such as libc++_shared.so. That would crash at load time as soon as any dependency used C++. Nothing in Robrix's tree does today.
   • Adds a unit test.
4. Images: cap decoded images at 128 MiB on 32-bit native targets (it is 1 GiB elsewhere).
   • Decoding holds a few cap-sized buffers at once: the decoder output, the RGBA buffer and an EXIF-rotated copy. Several 1 GiB buffers don't fit in a 32-bit address space.
   • So a large or crafted image (about 1 MB on the wire) aborted the whole app on an infallible allocation, instead of failing with DimensionsTooLarge.
   • 128 MiB is 32 MP of RGBA, which still covers typical phone photos.
5. SharedBytes: link mmap64 on Android and glibc. Their plain mmap takes a 32-bit off_t on 32-bit targets, so the 64-bit offset we pass landed where the ABI doesn't look. This isn't reached on Android today: resource paths are build-host paths, so the file open fails first.
6. cargo-makepad: add MakepadFileProvider, a read-only file provider that apps can declare.
   • On Android 8 and 9, an app can only share a private file through a content:// URI from one of its own providers. Makepad apps don't bundle androidx's FileProvider. A provider class must be compiled into the APK, so robius-share, whose Java is loaded at runtime, can't ship one either.
   • It is compiled into every APK's classes.dex, but does nothing unless the app's AndroidManifest.xml.template declares it. The meta-data dev.makepad.android.MakepadFileProvider.cacheDirs lists the cache subdirectories it serves (the class's Javadoc shows the declaration).
   • It is read-only and serves files only to apps that were granted the URI. Like FileProvider, it refuses to start if it is exported or doesn't grant URI permissions. It resolves .. and symlinks before checking that a file is inside a listed directory.
   • Robrix declares it for robius-share (Support 32-bit ARM Android (armeabi-v7a), and share files on Android 8 and 9 project-robius/robius#30).

Testing

• All 61 cargo-makepad tests pass, including the new one.
• makepad-draw: all 36 image_cache tests pass on the host, including the new one, and its unit tests type-check for armv7.
• makepad-platform passes cargo check on armv7, aarch64 and the host, plus the draw_list test with the updated DrawVars literal.
• makepad-shared-bytes tests pass on x86_64 and as a 32-bit (i686) process, with the mmap path actually taken, so the mmap64 link works on 32-bit glibc. They don't reproduce the bug itself: the old declaration happened to work on i686, and only goes wrong on armv7's calling convention.
• Robrix's whole tree, with this branch patched in, passes cargo check for armv7-linux-androideabi and aarch64-linux-android.
• Robrix's CI, with its Cargo.lock pointing at this branch, builds and links the armv7 and arm64 APKs with the real NDK. That also covers javac, d8 and aapt for the provider.
• MakepadFileProvider:

  • It compiles cleanly with cargo-makepad's javac flags against the API 28 and API 33 stubs.

  • Robolectric tests on the Android 8.0 and 8.1 runtimes cover it, together with robius-share. They check:

    • serving files and their name/size;
    • .., encoded /, symlinks and sibling directories, which all stay refused;
    • the meta-data lookup and parsing;
    • the exported/grant checks;
    • read-only modes.

    They fail on deliberately broken variants. The tests live outside the repo.

• Not verified: a run on a device.

Notes

• Related: Build and release a 32-bit ARM Android (armeabi-v7a) APK, and share files on Android 8 and 9 project-robius/robrix#1208 (the Robrix side; its Cargo.lock temporarily points at this branch's head) and Support 32-bit ARM Android (armeabi-v7a), and share files on Android 8 and 9 project-robius/robius#30 (the robius side).
• The same changes, minus DrawVars, are ported onto upstream dev in the android_armv7_fixes branch, for an upstream PR.
• Robrix's CI and release jobs install cargo-makepad from the makepad rev in Robrix's Cargo.lock, so they get fixes 3 and 6 through that pin. Robrix's manifest declares the provider, so a cargo-makepad without fix 6 would build a Robrix APK that crashes at launch.
• Known and left alone, because none of them affect Robrix on armv7:
  • The armv7 Rust target builds without NEON (performance only).
  • Stitch assumes sibling-call optimisation, which is only guaranteed on 64-bit. Nothing in Robrix reaches it.
  • Android manifests declare glEsVersion 0x00020000, while the Android EGL code needs ES3.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Va5dxPCRyW8YN5b1Yt1Awy