Question, does this (and/or "Blueprint") create a path to writing Android software without using Gradle?
Conversation
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.
2
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.
the funny thing is having lots of Java experience I found them making more and more gratuitous moves to break my workflows.