[libcamera-devel] libcamera AOSP Integration

Wed Oct 12 12:11:26 CEST 2022

Hi Nicholas,

Quoting Nicholas Roth via libcamera-devel (2022-10-12 04:16:03)
> Hello all,
> 
> TL;DR: I would propose adding a top-level Android.bp Bazel-based build and
> tests to support building libcamera inline with AOSP to expose the
> libcamera HAL.

Thanks for taking this on.

> *Short intro because I'm new* (feel free to skip):
> I'm Nicholas, a long-time amateur programmer with ~10 years of industry
> experience now, although it doesn't seem like it's been that long. I've
> published work in distributed scale-out systems and for the last ~6 years,
> I've worked in AI. More relevant to you all, I have free time and a phone
> with an RK3399 SoC that I'd like to get supported in Waydroid.

Welcome to the team! :-)

> *Background*:
> There's been back-and-forth discussion on Kieran's personal GitHub account
> (link: https://github.com/kbingham/libcamera/pull/26
> <https://mailtrack.io/trace/link/9c70a621d6594480c04ab3722218fff2dec55196?notrack=1&url=https%3A%2F%2Fgithub.com%2Fkbingham%2Flibcamera%2Fpull%2F26&userId=4192442&signature=13231078163330ff>)
> about how to potentially build libcamera inline with AOSP. If I understand
> correctly, the original contributor proposed some minor changes and also a

The minor changes/fixes could certainly be considered already when
posted to the list.

> major change that would add ~349 lines of Makefiles, including a deprecated
> Android.mk. The original contributor ran out of bandwidth recently and

The build system is probably the hard part, and indeed it sounds like
there are two options.

1) an Android.mk 'wrapper' around the meson infrastructure
2) A parallel build system.

1. may become deprecated, but we don't know when. And the one thing I've
learnt about open source is - if you don't know when somethings going to
happen, it seems best sometimes to assume it won't until it does.
Because it can be *far away in the future*  (Just like our first
libcamera stable API release :D)

2. Is painful to maintain... but sounds like the route you are
interested in...

> decided not to pursue their changes further, and I volunteered to carry
> this forward.
> 
> *My Prior Work*
> I have tried building libcamera with these proposed changes inline with
> AOSP using sdk 30 under "/external/libcamera" (full procedure link:
> https://docs.google.com/document/d/1Sly_VH3w6wFIdE72WXijQegoHZh8IxEnJ9m0hH7GodU/edit
> <https://mailtrack.io/trace/link/e6ac3150dcbfa009e3880aa030d8176036dc2199?notrack=1&url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1Sly_VH3w6wFIdE72WXijQegoHZh8IxEnJ9m0hH7GodU%2Fedit&userId=4192442&signature=abdf0877da91078c>)
> and it does not work as intended as far as I can tell. Specifically,
> /vendor/lib/hw/camera.libcamera.so
> <https://mailtrack.io/trace/link/f38ddeb643e9e502355e6d6c7078c4f678867495?url=http%3A%2F%2Fcamera.libcamera.so%2F&userId=4192442&signature=f3a416f93f49123b>
> does
> not get bundled into the Android images. This may be user error on my part,
> however.
> 
> *Options for AOSP Inline Build*
> The way I can see, we have at least these options for building libcamera
> inline with AOSP. Personally, parallel build systems (see below) seems like
> the best option to me. Please feel free to jump in if I'm wrong about any
> of this or if you have options to add:
> 
>    - Transition libcamera to Soong and build intuitively
>    Tradeoffs: Simplest and most consistent option, but potentially very
>    disruptive
>    - Invoke Meson from Soong with a genrule, akin to what meson_cross.mk
>    <https://mailtrack.io/trace/link/8b8bf21362b7febf0a481b5bf274ad86d982180e?url=http%3A%2F%2Fmeson_cross.mk%2F&userId=4192442&signature=c34c1a84f1c76a29>
>     does
>    Tradeoffs: complex-- I would be happy to do this but I'll need help
>    understanding how meson_cross.mk
>    <https://mailtrack.io/trace/link/35387558b6d890dee771bdbfb1f7bf8f6132b75f?url=http%3A%2F%2Fmeson_cross.mk%2F&userId=4192442&signature=dfc9af2da8b37fa2>
> works;
>    probably harder than writing meson_cross.mk
>    <https://mailtrack.io/trace/link/fecb2bde4cbf9c1d4e4afb58415434f6bf142167?url=http%3A%2F%2Fmeson_cross.mk%2F&userId=4192442&signature=3458951a34f69bc0>
> was;
>    possibly infeasible since Soong is quite opinionated
>    - *Parallel build systems*-- Create an Android.bp file that would live
>    at the top-level of the libcamer repo in addition to the existing Meson
>    files. We would use Soong for Android, and Meson for other use-cases.
>    Tradeoffs: Less complex and less error-prone than invoking Meson from
>    Soong, and less disruptive than moving to Soong exclusively, but would
>    incur an increased maintenance burden compared to doing nothing or using a
>    single build system.
>    - Android.mk-- Use a legacy (link:
>    https://source.android.com/docs/setup/build
>    <https://mailtrack.io/trace/link/a590ddf9d4e0fc2459ff68e2943bcb5feb034056?notrack=1&url=https%3A%2F%2Fsource.android.com%2Fdocs%2Fsetup%2Fbuild&userId=4192442&signature=124f558360d74d95>)
>    Android.mk file and figure out how to get the proposed Android.mk and
>    meson_cross.mk
>    <https://mailtrack.io/trace/link/b47795745b452c00239c6966c5fabd90e9ff7a07?url=http%3A%2F%2Fmeson_cross.mk%2F&userId=4192442&signature=1528cb5f2f1cd6c7>
> files
>    working and tested.
>    Tradeoffs: New code would depend on a legacy tool and Makefiles can be
>    error-prone and hard to read (not great), but the maintenance burden
>    *might* be lower than creating a parallel Android.bp build file.

Of the above options, the only one that I don't think we could easily
merge would be a parallel build system. That would be difficult to
maintain.

A wrapper around our build system with either an Android.mk or a Soong
genrule (or both!?) would be more reasonable in my opinion ... as long
as :

> *Test Plan*

We have a way to at least compile test it ;-)

> I'm not exactly sure how the libcamera community approaches testing. That
> said, I would write a sanity check based on
> https://source.android.com/docs/core/tests/development/blueprints
> <https://mailtrack.io/trace/link/566af31c86d4ae27635d28c2f28a21e50ddd700b?notrack=1&url=https%3A%2F%2Fsource.android.com%2Fdocs%2Fcore%2Ftests%2Fdevelopment%2Fblueprints&userId=4192442&signature=76612081ac230acc>.
> Ideally, we would agree to run this before submitting new code. This is
> probably the weakest part of my proposal, and I'd love any resources on
> libcamera's testing philosophy and thoughts on how to make this stronger.

We already have infrastructure that builds libcamera across various GCC
and clang versions. It also runs CTS (Chrome Test Suite) on a Chromebook
(IPU3) which tests the Android HAL layer.

I would extend this to support compiling with either the Android.mk or
genrule wrappers (again, or both) ... as long as I'm guided on what is
required. I have a build machine with plenty of space and resources for
such a task.

> *Next Steps*
> If this looks good to the community (parallel build systems option), I'll
> figure out how to make Android.bp work. Most likely though, we have more to
> discuss. I'm ready to hear your thoughts!

Parallel build is the one that worries me. libcamera is already complex
to build, with many separate and sometimes optional components.

Will it be a single file that covers our entire build? as well as the
configuration options for different platforms, and specially built IPA
proxies, and module signing? That sounds ... like a lot of work, and a
lot of maintenance.

But now we're on the libcamera list - lets await more feedback.

--
Kieran