An interesting bit of Android's Rust integration: android.googlesource.com/platform/devel. It converts Cargo packages into Blueprint modules integrated into the normal build system. Blueprint is Android's declarative build system implemented on top of ninja. Fits into overall incremental build.
Conversation
Replying to
Question, does this (and/or "Blueprint") create a path to writing Android software without using Gradle?
1
Replying to
The Android Open Source Project builds everything including apps with ninja. The modern approach is the declarative Blueprint system. The legacy approach is the template-based Android.mk build system which was the basis for Blueprint. It's far nicer than gradle...
2
Here's an example of a Rust crate (futures) converted to Blueprint:
android.googlesource.com/platform/exter
Here's a manually written example for a C executable and static library:
android.googlesource.com/platform/exter
This is what it looks like for an app:
android.googlesource.com/platform/packa
I think it's great.
1
1
This is an example of an app using the legacy Android.mk-based system:
github.com/GrapheneOS/pla
It's essentially the same thing, but everything gets expanded into an enormous Makefile. Legacy system isn't implemented via make anymore but rather Kati and integrates with the rest.
1
Kati is a reimplementation of GNU make into ninja. AOSP incorporates it in a way that's interoperable with the new declarative Blueprint build system. The old approach was essentially a poor man's declarative build system. The usage is very similar to how they use Blueprint.
2
Replying to
oh, wait, that's very interesting.
so here is my situation.
i develop for Oculus Mobile. they have a devkit which is distributed only as a hairy pile of Gradle + android.mk scripts
Gradle is INCAPABLE of building android.mk and cmake in the same build
1
We are getting around this by just reimplementing the gradle scripts in tup but if I could use this new system to import Oculus's android.mk scripts, while still getting to use a modern/functional build system for the main part of our app that would be great
1
(although we are likely to stick with cmake or tup just becuase we want to use the same build system for oculus and non-oculus platforms)
1
Replying to
The Android NDK uses a build system inspired by the old Android Open Source Project build system. It's not quite the same but it uses the same format and most of the same variables for the templates. Android Studio and the SDK took a much different path than AOSP itself though.
Replying to
Oh, I see. So you're talking about AOSP, ie, developing Android itself, rather than developing apps *for* Android?
I guess I should have read your documentation before asking questions lol maybe it would have made that clear
1
Replying to
Yeah, I'm talking about building AOSP. AOSP is largely implemented via a bunch of app-based components though. Many of those are regular apps without any special privileges. It builds the apps using the normal Android.bp (or legacy Android.mk) build system.
AOSP used Android.mk for everything including apps. It got expanded as needed to cover everything that was required including sophisticated sanitizer integration for C and C++, etc. Android.bp replaces it with a more modern / capable Blueprint-based implementation.
1
Android Studio / Android SDK wanted to fit into the broader Java ecosystem and tried to make things work the way Java and Kotlin developers expect. I really don't like it. I find it really hard to get anything done vs the AOSP's new build system being the best I've worked with.
1
Show replies