[HN Gopher] Bare-metal Rust in Android
___________________________________________________________________
Bare-metal Rust in Android
Author : iamd3vil
Score : 193 points
Date : 2023-10-09 18:13 UTC (4 hours ago)
(HTM) web link (security.googleblog.com)
(TXT) w3m dump (security.googleblog.com)
| ireallywantthat wrote:
| Ok, now enable us to let create Android Applications entirely in
| Rust (including the GUI). Let's get rid of Kotlin/Java monopoly
| in Android App development. Shall we?
| grishka wrote:
| You can technically create an Android app without any Java
| code. There are native APIs for graphics and input. However, as
| these are intended for games, you get a window into which you
| can draw... something. With OpenGL, for example. You don't get
| access to Android's regular UI framework. You will also have to
| go through the Java layer to do many things you might want to
| do -- like requesting permissions or launching other apps'
| activities.
|
| Here's all the APIs you get:
| https://developer.android.com/ndk/reference?hl=en
| flohofwoe wrote:
| You can call into any Android Java API from native code using
| JNI. It's not exactly convenient, but you are not limited to
| the C APIs exposed by the NDK.
| grishka wrote:
| Many Android APIs expect you to extend classes and
| implement interfaces for things like callbacks. You can't
| do that with JNI alone, you will have to have a .dex of
| your own anyway.
| izacus wrote:
| That's not really what's going on. Those "native" APIs you
| mention in most cases just call back to Java APIs under the
| hood. For better or worse, most of what Android is is written
| in Java. There's no hidden "C++" layer of Android to access.
| nologic01 wrote:
| You can also "outsource" the Java based interaction with
| Android to somebody else, Qt style?
| https://doc.qt.io/qt-6/android-getting-started.html
| rohandhruva wrote:
| Tell me you've never done any Android development, without
| telling me...
|
| This is such a low-effort "take" without any effort to justify
| _why_ you'd want something like this. There's a high amount of
| impedance mismatch trying to write GUIs in a non-GC language
| like Rust which _has_ to run on what's essentially a Java VM
| (ART).
|
| At least with a language like Go, it somewhat makes sense, and
| has been attempted: https://gioui.org/
|
| All this Java/Kotlin bashing is getting really old, especially
| for a forum like this one.
| lcfcjs wrote:
| [dead]
| jeroenhd wrote:
| There's a reason Chrome is mostly written in C++. Android's
| JVM system is a collection of Java wrappers around C++
| libraries. There's some overhead in that translation layer,
| and it's unfortunate that you can't skip it. Even Google's
| own Flutter uses a C++ engine to run Dart applications.
|
| Kotlin (and Java) is fast enough for many applications, but
| even with the recent advancements in ART, does have overhead
| compared to pure native code. I can't think of a reason why
| the API interaction overhead would pose a problem, but if
| Google themselves can find use cases for almost JVM-less
| apps, I'm sure there are reasons to give a Rust version a
| try.
| izacus wrote:
| > Android's JVM system is a collection of Java wrappers
| around C++ libraries.
|
| This isn't even remotely true and it's obvious if you'd
| ever looked closely at Android. This take is as bizarre as
| saying that whole web/JS/React ecosystem is "just" wrappers
| on top of Skia.
| ForkMeOnTinder wrote:
| > At least with a language like Go, it somewhat makes sense,
| and has been attempted: https://gioui.org/
|
| Gio UI is an immediate-mode UI, and immediate-mode UIs map
| very nicely to Rust. egui is quite expressive and easy to
| use. https://www.egui.rs/
|
| If you had pointed at something like GTK, then yes, there is
| a big impedance mismatch there.
| ireallywantthat wrote:
| I didn't bash Java/Kotlin. In fact, I have written few
| android apps in Kotlin, Java and I also have fiddled with
| Jetpack compose, JNI and NDK (I have also played with mpv's
| Opengl/Vulkan's rendering on Android if that matters to you).
| I don't want to share the projects of mine because i don't
| want to reveal my identity.
|
| > https://gioui.org/
|
| I know that tailscale's android application is written in it
| but i don't think gioui is great for android apps.
|
| > Tell me you've never done any Android development, without
| telling me...All this Java/Kotlin bashing is getting really
| old, especially for a forum like this one.
|
| Ok, this one hurts. Why are you attacking me instead of
| defending your stance. All are allowed to have opinions and I
| am allowed to have one(It's sad to explain this to someone on
| forum like this one). I dream of Linux-desktop kinda
| situation where you can program in any language you want,
| where you are not hindered by any platform/framework, where
| you have complete freedom and where you don't want to be
| bothered/(vendor locked-in) by Bigcorps(looking at you Google
| services framework).
|
| > write GUIs in a non-GC language like Rust which _has_ to
| run on what's essentially a Java VM (ART).
|
| Haha, non-GC languages power the GUIs on Android fyi. Jetpack
| compose is powered by Skia. Chromium is powered by Skia. Skia
| is C++.
|
| Please do your own research before commenting low-effort
| replies.
| izacus wrote:
| He's attacking you because you're spewing things that are
| fundamentally misguided without even seeming to try to look
| at basic structure of how Android is put together.
|
| Show some basic ability if you want people to engage with
| your takes, there's already too much ignorant opinions
| spewed out with assumed authority on this site.
| voxl wrote:
| What does a GC have anything to do with it? You can reference
| count all the pointers if you want, you can expose JVM
| pointers in Rust where Rust doesn't manage the heap memory.
| There are plenty of easy solutions to work with the JVM
| ncruces wrote:
| If you're willing to work with the JVM (i.e. through JNI),
| there's really nothing stopping you.
|
| You can 100% make entire apps using nothing but C, C++, or
| whatever, as long as you're willing interface with the JVM
| that's created for you to access Android APIs.
|
| But the Android API is a JVM API. There's no getting around
| that. At this point, it's another OS (i.e. not Android) if
| it doesn't have Java in it.
| azemetre wrote:
| Isn't this what Tauri wants to achieve? At least it's on the
| roadmap I mean.
|
| https://tauri.app/
|
| Does anyone have any experience creating production apps with
| Tauri? Seems like a sane alternative to Electron, especially if
| they can target all major platforms and keep the promise of
| smaller footprints.
| asrael_io wrote:
| Not quite production, but I was on a paid contract on a PoC.
| I would say back at 1.0, mobile was pretty painful and
| signing of any binary dependencies was up to you. It looks
| like they addressed signing in 1.5 and I haven't picked it
| back up to check out the mobile experience.
| flohofwoe wrote:
| The traditional alternative to Electron on mobile platforms
| is Capacitor (which uses the system webview, so in that sense
| it's closer to Tauri):
|
| https://capacitorjs.com/
|
| (fka Apache Cordova, fka PhoneGap)
| Vt71fcAqt7 wrote:
| You can already. The ndk allows any language to be compiled to
| android. For rust see
|
| https://github.com/rust-mobile/ndk
|
| Which has the tools to do this.
| wredue wrote:
| What would rust achieve aside from just enabling another,
| entirely distinct from the existing workflow, language?
|
| Haven't android apps been compiled to native code since like
| 2012? (I actually don't know, I left android a while ago and
| stopped caring what they do)
| rstat1 wrote:
| Not having to use Java or any of its weird derivatives.
| smith7018 wrote:
| I implore you to try Kotlin; it's a fantastic language and
| is a wonder to code in
| TheDesolate0 wrote:
| [dead]
| cogman10 wrote:
| I don't think it's a good idea, mainly because android is
| multiplatform and rust, by it's nature, is only available for
| what it's built for. Unless you are giving google your rust
| code to compile, your app will be limited on it's reach.
|
| All that said.
|
| Rust doesn't have a GC so it'd (likely) have a lower memory
| consumption and could possibly be lighter on the CPU.
|
| Native compilation helps mainly with startup time and memory
| consumption. It's not exactly great for runtime performance
| as it takes away some key optimizations.
|
| Another benefit of rust assuming you are distributing
| binaries is you'll be able to use the latest version of Rust
| rather than being pinned to older versions of the SDK with
| partial support based on the whims of google.
| galangalalgol wrote:
| VM warmup isn't consistently a thing, in fact for over a
| decade there has been plenty of observation of the reverse,
| that runtime optimization often slows performance. Systems
| languages (c/c++/rust) consistently outperform warmed up
| managed languages. And that is ok, it doesn't mean we
| shouldn't have managed languages, but they are slower.
| pjmlp wrote:
| Managed languages also exist in AOT with PGO data.
| flohofwoe wrote:
| > Unless you are giving google your rust code to compile,
| your app will be limited on it's reach.
|
| Android has supported native code in apps for a long time
| via the Android NDK, mainly to enable game development. The
| Android team seems to hate the NDK, but the alternative is
| to have no games on the platform, so they can't simply kill
| it.
|
| > ...[native] ... It's not exactly great for runtime
| performance as it takes away some key optimizations.
|
| In _theory_ a JIT might produce better runtime performance
| than AOT compiled code, but in practice that usually turns
| out as wishful thinking.
| pjmlp wrote:
| Thankfully ART not only uses JIT, it also has an AOT
| compiler with PGO data shared across all devices in the
| ecosystem via the Play Store.
|
| In practice, people should learn how Android actually
| works.
| shopvaccer wrote:
| >mainly because android is multiplatform and rust, by it's
| nature, is only available for what it's built for
|
| Android is one platform: android. I thought rust worked
| across multiple operating systems.
|
| >Rust doesn't have a GC so it'd (likely) have a lower
| memory consumption and could possibly be lighter on the
| CPU.
|
| So what? I have never used G.C.
|
| >Native compilation helps mainly with startup time and
| memory consumption. It's not exactly great for runtime
| performance as it takes away some key optimizations.
|
| That is fair I suppose
|
| I think the main benefit of rust/c++/ndk on android is that
| I can just port desktop programs and I don't have to learn
| android's java/kotlin and sdk.
| wiseowise wrote:
| > Android is one platform: android. I thought rust worked
| across multiple operating systems.
|
| Operating systems, not architectures. You'd have to
| cross-compile your application 4 times if you want to
| support all arms and x86s.
|
| > I think the main benefit of rust/c++/ndk on android is
| that I can just port desktop programs and I don't have to
| learn android's java/kotlin and sdk.
|
| It's not "just" port desktop programs. Android doesn't
| even use glibc.
| [deleted]
| wiseowise wrote:
| Why?
| 1f60c wrote:
| Ideally, Android wouldn't have any security vulnerabilities, but
| that's not realistic. Rust won't prevent every bug (and it's even
| possible to cause segmentation faults in an ostensibly safe
| language like Python), but "better" is still a huge leap forward.
| kupopuffs wrote:
| just.... no more buffers overflown
| jiripospisil wrote:
| Is there similar effort from Apple?
| monocasa wrote:
| I don't believe Apple has embraced Rust the same way Google
| has. Particularly their firmware is still very based on C.
| dagmx wrote:
| Specifically a dialect called Firebloom (supposedly anyway)
|
| https://saaramar.github.io/iBoot_firebloom/
| jonpalmisc wrote:
| Firebloom is more of a custom compiler/toolchain than a
| dialect of C--apart from annotations to relate
| pointer+length parameters, etc., it is still just C.
| jd3 wrote:
| Reminds me of this blurb from djb's qmail security
| guarantee [0]:
|
| > I've mostly given up on the standard C library. Many of
| its facilities, particularly stdio, seem designed to
| encourage bugs. A big chunk of qmail is stolen from a
| basic C library that I've been developing for several
| years for a variety of applications. The stralloc concept
| and getln() make it very easy to avoid buffer overruns,
| memory leaks, and artificial line length limits.
|
| [0]: http://cr.yp.to/qmail/guarantee.html
| mrpippy wrote:
| Possible related to the '-fbounds-safety' feature they've
| proposed for Clang
|
| https://discourse.llvm.org/t/rfc-enforcing-bounds-safety-
| in-...
| jonpalmisc wrote:
| Firebloom == `-fbounds-safety`
| jonpalmisc wrote:
| The other commenter mentioning Firebloom is correct that some
| firmware (iBoot family) has been using C w/ Firebloom
| extensions for a while. Parts of SEPOS also use Swift, which
| would make more sense as a non-C language than Rust, from
| Apple's perspective at least.
| pjmlp wrote:
| Apparently people keep forgetting Swift exists.
|
| "CppNow 2023:Introducing a Memory-Safe Successor Language in
| Large C++ Code Bases"
|
| https://www.youtube.com/watch?v=lgivCGdmFrw
| candiddevmike wrote:
| What benefit would Apple get from this? They want you all in on
| an ecosystem they control.
|
| EDIT: Thought OP was talking about writing iOS apps using Rust.
| steveklabnik wrote:
| Apple does use Rust, though from job postings, we can infer
| it's more like network services than firmware.
|
| Regardless though, I don't see how the implementation
| language of your firmware is locking you into a specific
| ecosystem, so this criticism seems misguided to me.
| SuaveSteve wrote:
| The Doom of programming languages? Rust must be run everywhere
| with no irony.
| asrael_io wrote:
| Yeah but does Doom run on rust-analyzer?
| gpm wrote:
| Rust analzyer type checks rust and type checking is turing
| complete... it's only a matter of time.
| [deleted]
| theusus wrote:
| I found adoption of Rust being slow, but it has started to grow.
| az09mugen wrote:
| I may have wrong assumptions, but I find it funny they didn't use
| Golang. Is it not capable of doing the same thing ? Anyway, happy
| to see rust being adopted for that usage.
| izacus wrote:
| No, Go isn't appropriate for these things. Use the best tool
| for the job
| digdugdirk wrote:
| Can you please explain why Go isn't appropriate here?
| sangnoir wrote:
| Binary size, for one. The blog mentions a binary file grew
| from 220kb (C) to over 400kb (Rust).
|
| I also doubt a garbage-collected language work very well
| for drivers that require precise timing (MMIO) and/or
| control over memory allocation.
| izacus wrote:
| The non-JVM code used in mentioned context will run in
| environments where yet another GC fighting the JVM GC isn't
| desired or have to be a shared library talking to existing
| JVM code. While you can use Go to build libraries with C
| calling convention, it's not the most supported use case
| and it shows in ergonomics. This also includes standard Go
| types and standard library which don't fit nicely into a
| model where code needs to talk a lot with JVM world.
|
| It's possible... But it feels like screwing screws with a
| knife. It's doable, but noone from the language designers,
| stl designers and library developers are really thinking
| about that use case.
|
| Rust on the other hand fits very well into the model where
| it needs to be just a piece of a bigger whole - it's been
| built that way ("system" programming language) and it
| doesn't come with GC that will fight with JVM or Binder
| lifetimes, compatible type system and plenty of libraries
| that help develop libraries on an embedded platform. When
| building the language, Rust designers consider this as one
| of the main use cases of the language and it shows with how
| much less hassle it is to work with.
|
| The fact that it easily fits into existing C/C++ codebases
| helps too.
| pix128 wrote:
| Go is garage collected
___________________________________________________________________
(page generated 2023-10-09 23:01 UTC)