AOSP still primarily uses make but it's not really intended for external projects. They moved to their own implementation of make on top of ninja for better incremental build performance but it still works with GNU make.
-
-
They're slowly moving away from using make but not for performance reasons anymore (https://github.com/google/kati solved those). They treat it make as a declarative build system everywhere but central build code which just includes all of the declarative http://Android.mk files.
1 reply 0 retweets 0 likes -
Their new build system is essentially just an implementation of their http://Android.mk templates in a way that enforces they're declarative. It's a little bit faster but the main reason is just avoiding the chance of making mistakes with make somewhere in the source tree.
1 reply 0 retweets 0 likes -
Not sure how hard it would be to do things by hand with make. It would be painful because you would be exposed to the underlying tools changing over time. A year ago, they compiled Java -> dex with jack without javac, but now it's javac for bytecode -> dex compiler.
1 reply 0 retweets 0 likes -
You'd need to manually deal with compiling resources, proguard optimization, bundling it into an apk, signing releases, etc. Tools aren't that hard to use by hand but it would be annoying. If someone wrote an equivalent to AOSP make support for standalone apps it'd be fine.
1 reply 0 retweets 0 likes -
Personally prefer http://Android.mk (old) / Android.bp (new) over build.gradle and prefer the simpler AOSP style directory structure with src/ and res/ at the top-level. Wouldn't want to lose IDE support despite writing everything in Vim though.
2 replies 0 retweets 0 likes -
sorry to sneak into the convo, but could you point me to some resource comparing Android build systems over time? Seems like they’ve had a few, even parallel ones...
1 reply 0 retweets 1 like -
The Android Open Source Project started with a uniform make-based build system for the entire OS. External projects like SQLite, LLVM, etc. have http://Android.mk files added to build them in the declarative Android way with a single instance of make for the whole OS.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @MarkVillacampa and
They eventually replaced GNU make with Kati to implement make via ninja for performance, but that's an implementation detail. It's still fully compatible with GNU make and it's still initiated by running `make` and just uses Kati under the hood since it's faster than GNU make.
1 reply 0 retweets 0 likes -
Replying to @CopperheadOS @MarkVillacampa and
They use make in a somewhat unique way: they define a build system in build/make and then everything else uses declarative rules by reusing templates from there. It's now migrating to a real declarative build system that's a 1:1 mapping of http://Android.mk .
2 replies 0 retweets 0 likes
Yes. That's kinda BSD-ish. I tend to dislike it tho because it's non-obvious where the rules are and what will actually get run.
-
-
Forgot that the NDK actually does use a simplified variant of http://Android.mk as part of the external SDK: https://developer.android.com/ndk/guides/android_mk.html … AOSP uses it for everything though. NDK also probably doesn't use Kati.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.