In theory Android Studio supports that as well, although in practice this might be a little difficult because as far as I can tell officially this is only supported when building the native part of the app through Gradle (with the help of CMake) as well. With a little bit of luck it might be possible to generate some sort of fake CMake project that isn't actually used for building, just to trick Android Studio into doing the processing necessary for code completion. If not, I guess we're out of luck there, since unlike what we did with our Java code, switching the build system for the rest of Gecko is obviously no option.

OK, I tried to make this happen. Assorted notes follow: 1) JanH is correct, we do need to have an `externalNdkBuild` block to achieve this. That is either an `ndkBuild` block or a `cmake` block. `ndkBuild` is Make based (so infinitely hackable) but old and crufty. `cmake` is new and inflexible. I had more success with hacking around `cmake`. 2) there are two steps to the Gradle/AS integration (as of `com.android.tools.build:gradle:3.1.4`). `generateJsonModel*` produces a JSON description of the native build; `externalNativeBuild` does _everything_ -- all targets, all architectures -- without any regard to the actual model. 3) the generated JSON model determines the directories and files considered "part of the build" at a very fine-grained level. It's kind of good (per-file include/exclude) and also horrendous with a project as large as Gecko. 4) I had success including three projects and one `cmake { target '...' }` restriction. One fake project (that's actually built), one dummy project for libmozglue.so, one dummy project for libxul.so. A target restriction doesn't make the underlying cmake target considered "not part of the build", so that addressed that problem. 5) Per-directory includes (and flags) really, really matter in Gecko. That means generating a CMakeLists.txt that is directory specific, at least. The build system doesn't really produce a nice representation of the Gecko build model... but the Visual Studio build backend produces such a representation that is basically what we want: https://searchfox.org/mozilla-central/source/python/mozbuild/mozbuild/backend/visualstudio.py. The next steps here will be to share the model building functionality of that backend, and then generate either a single CMakeLists.txt, or interconnected per-directory CMakeLists.txt. I did this somewhat manually and good success, but I found the Visual Studio backend after pursuing a different approach (in the regular emitter and RecursiveMake build backend) so my WIP isn't worth posting. 6) Indexing Gecko takes 20-30 minutes and 3-4Gb of RAM on my ancient Late 2013 MacBook Pro. AS itself is mostly responsive after indexing but seems to peg 1 or 2 cores at 100% afterwards. Hard to say if that's due to debugging or indexing or what; AS is generally bloated at this point. 7) Android Studio doesn't do very well with tons of directories that are "above" the project directory. That is, when I rooted the `externalNdkBuild` at `mobile/android/geckoview/build.gradle`, AS struggled with all the `../../{caps,dom,...}` directories. When I rooted the `externalNdkBuild` at `/build.gradle` (I know that it is very unusual for a multi-project build to have a real project in the root directory) things got a lot better. I did find that the omnijar project needed to be reworked with this configuration, 'cuz it conflicted in many directories (namely toolkit/ -- I think the omnijar project defines everything under toolkit/ as JavaScript, which just ain't so.) It's not clear to me if this rooting issue is significant or just something I saw while experimenting (with many, many things). 8) I didn't pay any attention to wiring `mach build binaries` into the Gradle build graph -- that's both complicated (https://bugzilla.mozilla.org/show_bug.cgi?id=1418464) and easier in many ways. Less experimentation needed, at least! So: to the next person who cares about this, start by trying to produce CMakeLists.txt out of the Visual Studio build backend, and see where you get to!

(In reply to Nick Alexander :nalexander [he/him] (Away from Bugmail Dec 22-Jan 3) from comment #1) > 6) Indexing Gecko takes 20-30 minutes and 3-4Gb of RAM on my ancient Late > 2013 MacBook Pro. AS itself is mostly responsive after indexing but seems > to peg 1 or 2 cores at 100% afterwards. Hard to say if that's due to > debugging or indexing or what; AS is generally bloated at this point. Thanks for trying this out, but given how much memory AS is already using today I guess personally I'll pass on this then for the time being, especially given that I need to use a VM for building Android. This also means that my only wish for now is that this integration should be made optional even for full (non-artifact) builds.