6 ms·
Nobody's stopping you from using the NDK to compile Rust though. Android's ABI is just an ABI like any other. The system doesn't care if you built an .so using
by quotemstr 1y ago
Nobody's stopping you from using the NDK to compile Rust though. Android's ABI is just an ABI like any other. The system doesn't care if you built an .so using Rust or anything else so long as it plays by the rules.
- pjmlp 1y agoSome people rather reach out for first party support, instead of filling in the gaps for the big boys.
- dwattttt 1y agoBy first party support, would you be expecting a Rust toolchain shipped in the NDK, or maybe Rust bindings shipped in the NDK? I could see the latter, although I'd still question whether they should be special cased in terms of a Rust dependency compared to bindings being hosted on crates.io. Or maybe they should ship scripts that shell out to an existing Rust toolchain.
- pjmlp 1y agoI expect Rust being documented here, https://developer.android.com/ndk https://developer.android.com/ndk I expect the whole Rust build process being part of Android Studio, including mixed language debugging between Java, Kotlin and Rust. I expect all NDK APIs to have Rust bidding crates. I expect that Android developer forums also care to support devs using Rust. And anything else that I forgot to mentioned, that is provided for Java, Kotlin, C and C++.
- flohofwoe 1y agoThe Android NDK just barely supports C and C++ either, unless you're ok with 1990's tooling standards. The whole thing feels like it's maintained by two dudes locked in a Google basement somewhere. I doubt they have the capacity to deal with Rust support in the NDK, unless there's a big strategic change in Android tooling.
- cogman10 1y agoI'm not sure what you mean by this. Looking at a sample app [1] for the NDK, the tooling appears to be gradle and Cmake. Cmake isn't the newest of tools, but it's also not that dated. [1] https://github.com/android/ndk-samples/tree/main/endless-tunnel/app https://github.com/android/ndk-samples/tree/main/endless-tun...
- flohofwoe 1y agoBoth Gradle and CMake have a strong late 1990's smell to them. While CMake is sort of a necessary evil in the C/C++ world, there's no excuse for dragging Gradle into the NDK, combining both build tools leads to a complexity explosion that rarely works and tends to break after either the NDK or SDK is updated, or somebody merely looks the wrong way at the build files.
- pjmlp 1y agoCMake is the defacto tool adopted by the industry, regardless how many love to hate it. You can use BSD Make instead of Gradle, isn't UNIX great?
- flohofwoe 1y ago> You can use BSD Make instead of Gradle, isn't UNIX great? So the NDK officially supports creating an APK just with a Makefile? That would be news to me (and great news at that). It is possible to cobble together a build process that directly calls various Android SDK command line tools to build an APK directly from a C/C++ build tool without involving Gradle, but as far as I know, most of those invoked cmdline tools are deprecated and building APKs outside Gradle is not 'supported' by the Android SDK/NDK (e.g. it may stop working at any time).
- pjmlp 1y agoNo, I wasn't talking about APKs. The NDK supports building shared objects with Makefiles, via ndk-build. The original plan to deprecate ndk-build was reversed, due to the complaints. Pretty much official, https://developer.android.com/ndk/guides/build https://developer.android.com/ndk/guides/build I also stand corrected, it is actually GNU Make, not BSD Make.
- eggy 1y agoDon't forget this list of expectations for SPARK [1] too, if you want even safer, high-integrity, and formally verified code on Android! [1] https://www.adacore.com/about-spark https://www.adacore.com/about-spark
- iknowstuff 1y agoI think we can indeed forget about it.
- pjmlp 1y agoAndroid has zero lines of Ada code, why should I care about it in this case?