If you are planning to build Android 17 from source, the short answer is that you need more than 55 GiB of RAM, and you need it before the compiler even starts. We learned this last week while bringing Android 17 to Raspberry Pi. One of our build machines ran out of memory and was killed by the kernel during a stage that had not compiled a single file yet.
A full AOSP build runs in stages. First, Soong reads every Android.bp file in the source tree, assembles the complete dependency graph in memory, and writes it out as a Ninja build file. This is the soong_build step, and it runs as a single process. Second, Ninja takes that file and runs the actual compilation in parallel, across as many threads as you allow with the -j flag. On older releases there was also a documentation step using Java that tended to run out of memory, which is what most old guides are really about. The mistake those guides make is treating these stages as one thing. On Android 17, the memory problem lives entirely in the first stage.
Soong discovery phase starts a process soong_build, which does not stream the dependency graph to disk. It loads the entire set of modules into memory at once and keeps building up and modifying that graph until it is complete. The more modules the platform contains, the more memory this needs, and Android has only grown over time. On our Android 17 build, this single process reached 53.6 GiB of anonymous resident memory and was still climbing when the kernel stopped it. That figure is for generating the build graph alone, before any compilation has started.
The usual advice when an AOSP build runs out of memory is to lower the number of parallel jobs, for example -j4 instead of -j16. On older releases people also adjusted the Java heap with -Xmx, or added tens of gigabytes of swap. None of that touches the problem on Android 17. The -j flag controls the second stage, the parallel compile. The memory wall is in the first stage, which runs before any of that, as a single process. You cannot spread it across fewer threads, because the threads were never the cause. Adding swap prevents the crash, but only by constantly moving memory to disk and back, which turns a slow build into a far slower one.
Two trends point in the same direction:
Every release adds modules, so the graph that soong_build holds in memory keeps growing. Android build engineers have said for years that loading the entire graph into RAM is an assumption that cannot hold forever, with some expecting a comfortable build to need 128 GB before long.
Google now publishes AOSP source only twice a year instead of every quarter. You no longer follow the platform in small steps. Each drop is a larger jump, and you have to absorb it quickly if you want to ship on current software.
For companies building rarily on a spare machine, the answer is to find a box with more RAM and be patient. For a company shipping devices, that is not a plan. You cannot have releases blocked because the one workstation that can generate the graph is busy, or because an engineer's laptop simply cannot do it. The realistic setup is dedicated build infrastructure with enough memory and headroom for the next few releases, together with an automated pipeline so that any build is reproducible and not tied to a single person's machine. Emteria moved Android builds onto that kind of infrastructure years ago, which is why we had Android 17 running on Raspberry Pi two days after the source went public.
Please don't hesitate to contact Emteria if you want to talk about building or maintaining Android for your own devices.