[bityard]

Meh, content marketing for a commercial biz. There are no interesting technical details here.

I was a build engineer in a previous life. Not for Android apps, but some of the low-effort, high-value tricks I used involved:

* Do your building in a tmpfs if you have the spare RAM and your build (or parts of it) can fit there.

* Don't copy around large files if you can use symlinks, hardlinks, or reflinks instead.

* If you don't care about crash resiliency during the build phase (and you normally should not, each build should be done in a brand-new pristine reproducible environment that can be thrown away), save useless I/O via libeatmydata and similar tools.

* Cross-compilers are much faster than emulation for a native compiler, but there is a greater chance of missing some crucial piece of configuration and silently ending up with a broken artifact. Choose wisely.

The high-value high-effort parts are ruthlessly optimizing your build system and caching intermediate build artifacts that rarely change.

[7e]

That’s all basic stuff, and none of it solves what this product claims to.

[bityard]

Not as basic as you seem to think.

I was brought into a team of 70-ish engineers working across 4-5 products. Big enterprise products written by very bright programmers. But build systems and infrastructure were not their core competency. Their flagship application took 6 hours to build when I was hired. I got it down to 30-45 minutes using a combination of the techniques above and a revamped build infrastructure. When I finally left that position, the build was much more modular, so you could rebuild a small part of it and glue it into a bunch of existing artifacts and have a final product in just a few minutes.

[serbancon]

We hear you on the “we want more technical blogs” part - they’ll be coming once we get a breather. We kept this first post high-level to reach a broader audience. Thanks for reading!