Android.bp support?

At work somewhat brought up maintaining a separate build system for Android.bp along with our current cmake build system.

This is the first time I heard of Android.bp, we have been using cmake for Android for a while.

Could/can cmake just generate the Android.bp files?
Either as a generator or install step? (https://gitlab.kitware.com/cmake/cmake/-/issues/15562)

I really don’t want to have to maintain 2 build systems…

This is the first time I’ve heard about Android.bp. It looks like Make-ish? I believe that Android will be supporting CMake through hooks where they provide the guts and CMake the hooks that need to be implemented. Support for Android.bp would need to be investigated as to whether export() or a generator would be a better solution.

Cc: @kyle.edwards @brad.king

Android.bp is declarative JSON file without control flow or conditionals at all. In addition to Android.bp advanced build systems often implement GO modules for handling control flow. Android build system parses Android.bp + compiles GO modules, then it produces Kati files, which then are producing Ninja files.

If Cmake can generate Android.bp files, it is the best solution for software, where Android, Linux and Windows must be supported.

For more information, please read this pages:


or install step?

Something like install(EXPORT_ANDROID_MK) could be added for this.

@brad.king perhaps something like install(EXPORT_ANDROID_BP) is the solution.

I work with @mwezdeck so they can clarify if something like that is an acceptable solution for us.

(@mwezdeck knows more about building for Android than I do, I’m the Windows/Linux guy)

Quote:

The EXPORT form is useful to help outside projects use targets built and installed by the current project. For example, the code

install(TARGETS myexe EXPORT myproj DESTINATION bin) 
install(EXPORT myproj NAMESPACE mp_ DESTINATION lib/myproj) 
install(EXPORT_ANDROID_MK myproj DESTINATION share/ndk-modules)

will install the executable myexe to <prefix>/bin and code to import it in the file <prefix>/lib/myproj/myproj.cmake and <prefix>/share/ndk-modules/Android.mk . An outside project may load this file with the include command and reference the myexe executable from the installation tree using the imported target name mp_myexe as if the target were built in its own tree.

I’m not quite sure about this solution. Why do we need <prefix>/lib/myprij/myproj.cmake at all? Can we use <prefix>/share/ndk-modules/Android.mk as standalone Makefile, I mean without <prefix>/lib/myprij/myproj.cmake?

If the answer is yes, then install(EXPORT_ANDROID_BP) is the solution we are looking for.

I have only one concern here.

Android.bp doesn’t have “if” statements at all. All control flow logic is implemented in GO-lang modules which come in parrallel to Android.bp. How this can be handled?

If the answer is no, then this solution is not proper for us, as building with NDK and cmake toolchain under Android seems to take more time, than “native” Android.bp solution, especially when we are compiling both x86 and x86_64 shared libraries.

I think the Android.mk file is standalone (it is Makefile code, so how it would use the .cmake file, I’m not sure). The details of how we write .bp files would need to be investigated, but CMake would probably just write “here is where the install put things” and they can be used as necessary.

To be 100% clear here the problem isn’t building for Android.
The problem is building for AOSP (Android Open Source Project).

This stackoverflow question says it quite concisely:

Dan Albert a Google/Android engineer from the looks of it comments that:
“It is not possible to build cmake projects in the AOSP build system.”

And this is the problem we are looking to solve. Anything that can fix this problem is the solution we need from cmake. What would it take to achieve this?

FWIW to anyone the way we handled this at my old company was just have Android.bp invoke CMake under the hood.

Android.bp was flexible enough to be able to build CMake transparently for the user.

Which satisfied AOSP and made our engineers happy since they just had to deal with CMake for the most part.

2 Likes

can you share some examples? how did you deal with the toolchain?