WIP: Android meson integration #26

rsglobal · 2021-06-08T13:41:25Z

Require additional dependencies:

# Mainline libyaml with Android.mk file
git clone --branch android https://github.com/rsglobal/libyaml.git external/libyaml

# Chromium libyuv (as libyuv_chromium target)
git clone --branch android https://github.com/rsglobal/libyuv.git external/libyuv_chromium

How to use:

Enable libcamera, add pipelines and IPAs into your board.mk file:

board.mk:
    BOARD_LIBCAMERA_USES_MESON_BUILD := true
    BOARD_LIBCAMERA_IPAS := rkisp1
    BOARD_LIBCAMERA_PIPELINES := simple rkisp1

Add the following package configuration into your device.mk file:

device.mk:
    PRODUCT_PACKAGES += \
        camera.libcamera
    PRODUCT_PROPERTY_OVERRIDES += \
        ro.hardware.camera=libcamera

Example of /vendor/etc/libcamera/camera_hal.yaml:
https://chromium-review.googlesource.com/c/chromiumos/overlays/board-overlays/+/2866850/2/overlay-soraka-libcamera/media-libs/libcamera-configs/files/camera_hal.yaml

rsglobal · 2021-06-08T13:41:51Z

CC: @johnstultz-work

rsglobal · 2021-06-08T13:47:13Z

@kbingham ,

Hello Kieran,

Sorry for creating this PR in your personal repository. Hope you don't mind we do some preliminary review here until it will be ready for submission via mailing list.

kbingham

It's a bit unfortunate not to be able to use the standard library - but I guess that's a limitation on Android.
And given that this is an 'android hal' it's probably not unreasonable to highglight that as an issue.
We use the HAL in ChromeOS where we can utilise the std::filesystem.
I wonder if it can be wrapped in some way so we can take advantage of the std::filesystem when it's there or not otherwise.

Also you've droped a check, you're no longer validating that the file is there before opening it. I guess the difference is subtle as the fopen will likely fail anyway, but it will be a different error message reported. Looks like previously that only reports a Debug level, so maybe this is actually better...!?

src/android/camera_hal_config.cpp

kbingham · 2021-06-08T18:02:03Z

src/android/camera_hal_config.cpp

@@ -357,15 +357,8 @@ CameraHalConfig::CameraHalConfig()
 */
 int CameraHalConfig::parseConfigurationFile()
 {
-	std::filesystem::path filePath = LIBCAMERA_SYSCONF_DIR;


It's a bit unfortunate not to be able to use the standard library - but I guess that's a limitation on Android.
And given that this is an 'android hal' it's probably not unreasonable to highglight that as an issue.
We use the HAL in ChromeOS where we can utilise the std::filesystem.
I wonder if it can be wrapped in some way so we can take advantage of the std::filesystem when it's there or not otherwise.

std::filesystem is present in AOSP but not available for vendor libraries.
To make it available Android.bp should specify vendor: true field HERE
But for some reason nobody added it there.

It is a single usage. Do we really want to have 2 implementations here depending on presence of std::filesystem?

kbingham · 2021-06-08T18:02:22Z

src/android/camera_hal_config.cpp

@@ -357,15 +357,8 @@ CameraHalConfig::CameraHalConfig()
 */
 int CameraHalConfig::parseConfigurationFile()
 {
-	std::filesystem::path filePath = LIBCAMERA_SYSCONF_DIR;
-	filePath /= "camera_hal.yaml";
-	if (!std::filesystem::is_regular_file(filePath)) {


Also you've dropped a check, you're no longer validating that the file is there before opening it. I guess the difference is subtle as the fopen will likely fail anyway, but it will be a different error message reported. Looks like previously that only reports a Debug level, so maybe this is actually better...!?

So should I fstat() it and check is it a regular file or better to keep as is?

kbingham · 2021-06-08T18:03:19Z

src/libcamera/meson.build

-libgnutls = cc.find_library('gnutls', required : true)
+libdl = dependency('', required : false)
+if not cc.has_function('dlopen')
+    libdl = cc.find_library('dl')


does this need to be required : true ?

Perhaps that's default. I can't recall.

mesa3d meson.build was used as a reference for doing this.
I've created another var null_dep to make things more clear.

Could you please expand the commit message to explain why this is needed ?

src/libcamera/utils.cpp

kbingham · 2021-06-08T18:19:35Z

Android.mk

@@ -0,0 +1,75 @@
+# Mesa 3-D graphics library


John Stultz has been telling me about this other work! Sounds like some good progress on getting things moving.
I guess this is not mesa 3-d graphics library here though ;-)

Yes. It was a copy-paste from mesa3d. I spent a day to make it buildable for libcamera and to get quick feedback. Changed.
Can I use Apache-2.0 license for Android.mk files?

Android.mk

kbingham · 2021-06-08T18:21:33Z

Android.mk

+LOCAL_SHARED_LIBRARIES := $(__MY_SHARED_LIBRARIES)
+
+# Modules 'camera.libcamera', produces '/vendor/lib{64}/hw/camera.libcamera.so' HAL
+$(eval $(call libcamera-lib,camera.libcamera,hw,LIBCAMERA_BIN))


I'm planning to split out the android hal so it builds a separate .so rather than uses the libcamera.so - Just something to be aware of

Sounds good. Probably LOCAL_CHECK_ELF_FILES := false can be dropped then. It fails at this moment because ELF soname is still libcamera.so, but filename is camera.libcamera.so.

meson_cross.mk

kbingham · 2021-06-08T18:30:05Z

If we can resolve the workaround/hacks, I'd say the meson_cross.mk should be something we could integrate into libcamera! Very interesting work.
Needs posting through the libcamera mailing list of course though.

rsglobal · 2021-06-09T08:47:01Z

Sounds good.

Do you know if raspberry pi guys have any plans to drop boost dependency?

kbingham · 2021-06-09T09:35:34Z

Sounds good.

Do you know if raspberry pi guys have any plans to drop boost dependency?

It's used for json parsing and property trees. We're trying to find a way to not need boost but it hasn't been a high priority yet.
You can disable the boost requirement by not enabling the RPi IPA.

kbingham · 2021-06-09T09:36:23Z

Just been takling to Laurent about this - he's concerned that the android.mk files support will be deprecated and replaced by .bp files, which are only declarative. Is there a plan to manage this with Mesa?

rsglobal · 2021-06-09T09:44:47Z

Just been takling to Laurent about this - he's concerned that the android.mk files support will be deprecated and replaced by .bp files, which are only declarative. Is there a plan to manage this with Mesa?

We know that someday Google plan to stop supporting Android.mk's .
Also Google announced that it will switch to Bazel as a replacement of Soong.
But since date for both is unknown, and Android.mk is the only option known ATM, we have no plans to manage this.

rsglobal · 2021-06-22T10:42:36Z

@pinchartl,

Hi, )

I just saw 969da31 which is causing conflicts. It is very similar to my ("libcamera: Make issetugid() optional").

I can assume someone else is also working on Android integration.
Otherwise please don't hesitate to at least keep Suggested-by tag. Or push me to up-stream it next time.

kbingham · 2021-06-22T12:09:12Z

Hi @rsglobal

There is another team which has been working on android for quite some time as well.
Though they have taken a different approach to you, and they are manually creating blue prints, so I don't think they overlap with the same goals.

pinchartl · 2021-06-22T12:55:26Z

Commit 969da31 has been developed independently from this pull request. I'm sorry for not having noticed your patch first, the change came from a hack I noticed in a parallel development, as mentioned by Kieran. I'm also afraid I can't add a Suggested-by tag as the commit has been merged already.

I'd recommend submitting patches to the libcamera-devel mailing list, as that's what we use for development. Kieran is kind enough to follow issues and pull requests on github, but he can't scale by himself :-)

pinchartl · 2021-06-22T12:59:25Z

src/libcamera/meson.build

-libgnutls = cc.find_library('gnutls', required : true)
+libdl = dependency('', required : false)
+if not cc.has_function('dlopen')
+    libdl = cc.find_library('dl')


Could you please expand the commit message to explain why this is needed ?

pinchartl · 2021-06-22T13:00:08Z

src/libcamera/meson.build

+if not cc.has_function('dlopen')
+    libdl = cc.find_library('dl')
+endif
+libgnutls = cc.find_library('gnutls', required : false)


This changed from required : true to required : false. If that was intentional, it should be moved to a separate commit, with an explanation in the commit message.

AOSP doesn't have this library. I'll move it out of this commit.

Android libc++fs library does not have VNDK support. Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>

Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>

How to use: 1. Enable libcamera, add pipelines and IPAs into your board.mk file: board.mk: BOARD_LIBCAMERA_USES_MESON_BUILD := true BOARD_LIBCAMERA_IPAS := rkisp1 BOARD_LIBCAMERA_PIPELINES := simple rkisp1 2. Add the following package configuration into your device.mk file: device.mk: PRODUCT_PACKAGES += \ camera.libcamera PRODUCT_PROPERTY_OVERRIDES += \ ro.hardware.camera=libcamera Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>

Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>

rsglobal · 2021-08-22T20:02:39Z

Updated:

Fixed missing libcamera.so and libcamera-base.so deps
Small fixes in makefiles
First successful run. I can see the logs probing for camera device.

rsglobal · 2021-10-20T08:49:36Z

Latest new:
Looks like meson build within AOSP script can build shared libraries only, but can't build executables.
Executables require different set of linker arguments, so it require additional handling.
And libcamera uses proxy executable for IPA (is it really necessary?....). So I'm currently stuck on bringing-up camera for rpi4.

kbingham · 2021-10-20T09:38:51Z

The proxy executable isn't necessary as long as you don't run isolated IPAs. For RPi this is fine, as the IPA can be built from source and signed accordingly.
Except - you stated above that you don't have gnutls - which is the mechanism that it decides whether to trust the IPA or not I think.
So you'll need to do some hacking to disable IPA isolation.

rsglobal · 2021-10-20T13:52:09Z

@kbingham ,

Thanks, It worked!!!

Got rpi4 pipeline initialized on Android-12 with libcamera. Camera app now visible, but no preview image ATM..

pinchartl · 2021-10-20T20:46:01Z

One issue with the Android.mk approach is that Android is moving away from make. The current build system, Soong (https://android.googlesource.com/platform/build/soong/+/refs/heads/master/README.md), uses blueprint (Android.bp) files instead, which don't allow running arbitrary commands. They are moving to yet another build system, Bazel, as detailed in https://cs.android.com/android/platform/superproject/+/master:build/bazel/docs/concepts.md, but it will still take some time.

rsglobal · 2021-10-22T10:33:12Z

@pinchartl ,

So, what's the plan?

rsglobal · 2021-11-03T17:44:47Z

@kbingham

Looks like raspberrypi pipeline is incomplete. It doesn't set bufferscount during validation as ipu3 does, which disapoints the Android.

kbingham · 2021-11-03T19:17:05Z

Interesting, the RPi hasn't been tested much with the Android layer, but I'd like to see it tested more.
I'd need either a working Chrome or AOSP image for that though.

I see that there was some work to refactor bufferCount recently, but it has stalled. The latest version is https://lists.libcamera.org/pipermail/libcamera-devel/2021-August/023773.html

This might be a path towards solving this - or otherwise, initialising a default bufferCount of say 4 in the RPi pipeline handler might help.

Can you post this on the mailing list perhaps?

kbingham · 2021-11-03T19:18:21Z

I keep meaning to try: https://github.com/FydeOS/chromium_os-raspberry_pi/releases/tag/r92 but I haven't had any opportunity or time to do so.

kbingham · 2022-09-06T12:13:22Z

Sounds good.

Do you know if raspberry pi guys have any plans to drop boost dependency?

This is dropped now by the way. I wonder if it helps any development here.

rsglobal · 2022-09-06T12:20:19Z

This is dropped now by the way. I wonder if it helps any development here.

I'll check it soon, thanks

rothn · 2022-10-07T03:28:49Z

Hey! @rsglobal @kbingham , I'm interested in this too and can offer help, a second pair of eyes, etc. if that would help get this merged to git.libcamera.org. Let me know!

Additional context: waydroid/waydroid#519

kbingham · 2022-10-07T06:15:38Z

Can you rebase to the latest libcamera, and make sure everything compiles successfully, then post to the libcamera mailing list please?

rsglobal · 2022-10-07T08:14:34Z

This is dropped now by the way. I wonder if it helps any development here.

I'll check it soon, thanks

It works.

Can you rebase to the latest libcamera, and make sure everything compiles successfully, then post to the libcamera mailing list please?

Yes, but it would be nice to have code owner for these files from libcamera side. Otherwise it won't work for a long period.

pinchartl · 2022-10-07T08:36:50Z

The first two commits can be reviewed on the list and merged. The third one is more problematic, as make-based build are deprecated in Android (see https://source.android.com/docs/setup/build).

rsglobal · 2022-10-07T08:54:15Z

The first two commits can be reviewed on the list and merged. The third one is more problematic, as make-based build are deprecated in Android (see https://source.android.com/docs/setup/build).

It was deprecated long time ago nevertheless it is still supported and currently works and used by mainline mesa3d and everybody is happy :) . Building using NDK is an alternative, but it may have a different set of challenges, and NDK doesn't allow to build it within AOSP.

rothn · 2022-10-09T01:40:05Z

@rsglobal, My understanding is that @pinchartl's comment refers to Android's new Soong build system, based on Bazel. So, Android.mk would be replaced by Android.bp.

The main challenge here is that libcamera uses the Soong build system. We have at least a few options if we want to use an Android.bp instead of the deprecated Android.mk:

Transition libcamera to bazel and build intuitively (best, simplest, most consistent, but potentially disruptive)
Invoke Soong from bazel with a genrule, akin to what meson_cross.mk does (complex-- I would be happy to do this but I'll need help understanding how meson_cross.mk works; probably harder than writing meson_cross.mk was)
Parallel build systems-- Bazel for ChromeOS and Android, and meson for any other users. This would be less complex and less error-prone than invoking Soong from bazel, and less disruptive than moving to Bazel exclusively, but would incur an increased maintenance burden.

If there's appetite for either of these options, I'm happy to help out where I can. I use Bazel regularly at work, but I'll need help understanding these Makefiles.

For example, we'd have something like this:

cc_library_shared {
    name: "camera.libcamera",
    relative_install_path: "hw",
    vendor: true,
    srcs: [
        "foo",
        "bar",
    ],
    shared_libs: [
        "libc",
        "libexif",
        "libjpeg",
        "libyuv_chromium",
        "libdl",
        "libyaml",
    ],
}

cc_library_shared {
    name: "libcamera",
    vendor: true,
    srcs: [
        "foo",
        "bar",
    ],
    shared_libs: [
        "libc",
        "libexif",
        "libjpeg",
        "libyuv_chromium",
        "libdl",
        "libyaml",
    ],
}

cc_library_shared {
    name: "libcamera-base",
    vendor: true,
    srcs: [
        "foo",
        "bar",
    ],
    shared_libs: [
        "libc",
        "libexif",
        "libjpeg",
        "libyuv_chromium",
        "libdl",
        "libyaml",
    ],
}

...Instead of this:

# SPDX-License-Identifier: Apache-2.0
#
# Copyright (C) 2021, GlobalLogic Ukraine
# Copyright (C) 2021, Roman Stratiienko (r.stratiienko@gmail.com)
#
# Android.mk - Android makefile
#

ifneq ($(filter true, $(BOARD_LIBCAMERA_USES_MESON_BUILD)),)

LOCAL_PATH := $(call my-dir)
LIBCAMERA_TOP := $(dir $(LOCAL_PATH))

include $(CLEAR_VARS)

LOCAL_SHARED_LIBRARIES := libc libexif libjpeg libyuv_chromium libdl libyaml
MESON_GEN_PKGCONFIGS := libexif libjpeg yaml-0.1 libyuv dl

ifeq ($(TARGET_IS_64_BIT),true)
LOCAL_MULTILIB := 64
else
LOCAL_MULTILIB := 32
endif
include $(LOCAL_PATH)/meson_cross.mk

ifdef TARGET_2ND_ARCH
LOCAL_MULTILIB := 32
include $(LOCAL_PATH)/meson_cross.mk
endif

#-------------------------------------------------------------------------------

define libcamera-lib
LOCAL_MODULE_CLASS := SHARED_LIBRARIES
LOCAL_MODULE := $1
LOCAL_VENDOR_MODULE := true
LOCAL_MODULE_RELATIVE_PATH := $2
ifdef TARGET_2ND_ARCH
LOCAL_SRC_FILES_$(TARGET_ARCH) := $(call relative_top_path,$(LOCAL_PATH))$($3)
LOCAL_SRC_FILES_$(TARGET_2ND_ARCH) := $(call relative_top_path,$(LOCAL_PATH))$(2ND_$3)
LOCAL_MULTILIB := both
else
LOCAL_SRC_FILES := $(call relative_top_path,$(LOCAL_PATH))$($3)
endif
LOCAL_CHECK_ELF_FILES := false
LOCAL_MODULE_SUFFIX := .so
include $(BUILD_PREBUILT)
include $(CLEAR_VARS)
endef

__MY_SHARED_LIBRARIES := $(LOCAL_SHARED_LIBRARIES)
include $(CLEAR_VARS)
LOCAL_SHARED_LIBRARIES := $(__MY_SHARED_LIBRARIES)

# Modules 'libcamera', produces '/vendor/lib{64}/libcamera.so'
$(eval $(call libcamera-lib,libcamera,,LIBCAMERA_BIN))
# Modules 'libcamera-base', produces '/vendor/lib{64}/libcamera-base.so'
$(eval $(call libcamera-lib,libcamera-base,,LIBCAMERA_BASE_BIN))

LOCAL_SHARED_LIBRARIES += libcamera libcamera-base
# Modules 'camera.libcamera', produces '/vendor/lib{64}/hw/camera.libcamera.so' HAL
$(eval $(call libcamera-lib,camera.libcamera,hw,LIBCAMERA_HAL_BIN))

#-------------------------------------------------------------------------------

endif

rothn · 2022-10-09T01:46:46Z

I'll add that a lot of thought has been put into steering people away from using genrule()s like the one described, so I fully expect this to be more challenging than writing meson_cross.mk if not completely infeasible. By far the best option would seem to be moving libcamera to Bazel if we need a .bp, parallel build systems, or accepting a deprecated .mk if the libcamera team doesn't want to use Bazel. Considering that 2/3 use-cases (ChromeOS, Android) for libcamera are Google ecosystems, Bazel might even be the best way to go for the whole project. It's a solid build system too, and I don't immediately see a good reason not to use it.

Interested to read your thoughts on this too, @kbingham!

rsglobal · 2022-10-09T17:33:05Z

@rothn ,

Each solution has its pros and cons, maintainers should decide which way to go.

@kbingham @pinchartl ,

Since libcamera advertises Android support , could you tell us more how and on what hardware it's used now? It would be very nice to have some android-related how-to docs.

kbingham · 2022-10-10T11:46:55Z

I would very much like it to be easier to use libcamera with AOSP, so this deserves a discussion on the libcamera mailing list (https://lists.libcamera.org/listinfo/libcamera-devel) not here.

I can't see us changing the build system drastically though, we've chosen meson already - so we'd need to see real clear benefits for the change.

We already support ChromeOS with meson.

Keeping two builds in parallel will be a pain as well though, but if a build for android exists, I think perhaps it's better to live in libcamera.git than outside. At least then it's centralised - but we'd probably want a way to easily automate building against AOSP/NDK so we can track it.

It seems I have a lot of questions about how we can handle this - but I'd really prefer we discuss the options on the actual development list so others can be involved, not just me.

kbingham · 2022-10-11T08:33:22Z

If we merge the Android.mk file, how do we build test it?

kbingham · 2022-10-11T11:25:35Z

Since libcamera advertises Android support , could you tell us more how and on what hardware it's used now? It would be very nice to have some android-related how-to docs.

The Android HAL is used by ChromeOS. We currently use this with Intel IPU3 Chromebooks, and I believe it can be used already by a Rockchip RK3399 ChromeTab too, though I don't think that one has been used in quite a while. Most of our development has been with the IPU3.

rsglobal · 2022-10-11T11:43:33Z

If we merge the Android.mk file, how do we build test it?

Since there're a lot of issues that require resolution, I would suggest to start from something small, like build using Android NDK for raspberry-pi4 and starting semi-official support for it. Then you could extend Android coverage.

And finally adapt Android.mk to build within AOSP.

I think a lot of rpi4-based distributions already adapted meson/Android.mk and use libcamera, but I would still suggest using glodroid/rpi4 images because in this case I could support you.

After successful NDK build you should be able to push binaries onto the board using adb push command.

kbingham · 2022-10-11T13:25:44Z

@rsglobal Is this something that you are willing to do ? I.e. will you post the support to the libcamera mailing list, and provide documentation on how to build/use it ?

rsglobal · 2022-10-11T16:26:43Z

@rsglobal Is this something that you are willing to do ? I.e. will you post the support to the libcamera mailing list, and provide documentation on how to build/use it ?

Unfortunately I don't have enough free time for that right now. Also @pinchartl statements that Android.mk is obsolete makes me feel that I'm risking to waste a lot of time without eventually get things up-streamed.

kbingham · 2022-10-11T16:43:58Z

I'm happy to merge an Android.mk if we can build test it to catch breakage. If Android.mk options become obsolete by Android, then it won't work past that version, but it would still work for earlier versions that the deprecation - so I still think there's value.

But ... the patches need to be posted to the libcamera-devel mailing list - They won't get merged here.

rsglobal · 2022-10-11T18:02:14Z

@kbingham ,

To many effort has to be done to modify common code to support building within AOSP. I feel like review process will take forever. Also I hate mailing lists.

If you can assign some smart trainee from libcamera team I could share all my experience and support him outside mailing list.

kbingham · 2022-10-11T18:10:33Z

We're a small team and resource constrained. I don't think we have anyone that could do that right now.

@rothn , as you resumed this conversation here, is this something you want to take on?

rothn · 2022-10-11T22:10:45Z

Yes, I'm happy to help, not least because this happens to support my phone's camera :). I'd like to take a stab at creating a parallel Android.bp which would be continuously tested with "blaze test ..." or similar. Let me know if that would work for you. I'll try posting this to the mailing list as well later this evening along with some context, and you may prefer to reply there.

…

On Tue, Oct 11, 2022, 1:10 PM Kieran Bingham ***@***.***> wrote: We're a small team and resource constrained. I don't think we have anyone that could do that right now. @rothn <https://github.com/rothn> , as you resumed this conversation here, is this something you want to take on? — Reply to this email directly, view it on GitHub <#26 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABDTDN6LB3OGYQN5PPINQD3WCWUSJANCNFSM46J7WCKA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

rsglobal · 2022-10-12T07:58:47Z

Yes, I'm happy to help, not least because this happens to support my
phone's camera :). I'd like to take a stab at creating a parallel
Android.bp

Mesa3d was living with similar approach for a long time. Once a week it required tuning and therefore Android build was usually broken. With current Android.mk approach we have just a 1 fix per 6 month which is a way better.

Building using android NDK should similar to building for pure linux.

rsglobal · 2022-10-12T08:01:44Z

https://docs.mesa3d.org/android.html

kbingham · 2022-10-12T09:46:03Z

https://docs.mesa3d.org/android.html

Thanks, if we merge support to build android in libcamera, then some equivalent documentation for this should be added to libcamera too so it can be referenced for how people can use it.

kbingham · 2022-10-12T09:47:38Z

Yes, I'm happy to help, not least because this happens to support my
phone's camera :). I'd like to take a stab at creating a parallel
Android.bp

Mesa3d was living with similar approach for a long time. Once a week it required tuning and therefore Android build was usually broken. With current Android.mk approach we have just a 1 fix per 6 month which is a way better.

Wrapping the existing meson build sounds more supportable than a parallel build that needs constant maintenance everytime we make a change / add a new object / compile flags etc...
But lets follow that discussion on the list.

Building using android NDK should similar to building for pure linux.

Good, that makes it easy to incorporate into the build tests.

This was referenced Jun 8, 2021

PINEPHONE: Adapt libcamera HAL GloDroid/glodroid_manifest#59

Closed

Using as android HAL experience #11

Closed

kbingham reviewed Jun 8, 2021

View reviewed changes

src/android/camera_hal_config.cpp Outdated Show resolved Hide resolved

kbingham reviewed Jun 8, 2021

View reviewed changes

rsglobal force-pushed the android-meson-integration branch 2 times, most recently from 251b687 to 7d97046 Compare June 9, 2021 08:27

pinchartl reviewed Jun 22, 2021

View reviewed changes

rsglobal added 4 commits August 22, 2021 20:36

android: Do not use std::filesystem

d7dcd61

Android libc++fs library does not have VNDK support. Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>

meson: Allow linking libdl without -ldl linker flag.

ad9c1b2

Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>

[DO NOT MERGE]: Tweaks to build on Android

38c125e

Signed-off-by: Roman Stratiienko <r.stratiienko@gmail.com>

rsglobal force-pushed the android-meson-integration branch from 7d97046 to 38c125e Compare August 22, 2021 19:49

rsglobal mentioned this pull request Nov 11, 2021

RPI4: Libcamera integration CSI+ISP GloDroid/glodroid_manifest#166

Closed

aleasto mentioned this pull request Sep 14, 2022

Feature Request: libcamera support waydroid/waydroid#519

Open

rsglobal closed this Oct 12, 2022

WIP: Android meson integration #26

WIP: Android meson integration #26

Conversation

rsglobal commented Jun 8, 2021 • edited

rsglobal commented Jun 8, 2021

rsglobal commented Jun 8, 2021

kbingham left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rsglobal Jun 9, 2021 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kbingham commented Jun 8, 2021

rsglobal commented Jun 9, 2021

kbingham commented Jun 9, 2021

kbingham commented Jun 9, 2021

rsglobal commented Jun 9, 2021

rsglobal commented Jun 22, 2021 • edited

kbingham commented Jun 22, 2021

pinchartl commented Jun 22, 2021

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rsglobal commented Aug 22, 2021 • edited

rsglobal commented Oct 20, 2021

kbingham commented Oct 20, 2021

rsglobal commented Oct 20, 2021

pinchartl commented Oct 20, 2021

rsglobal commented Oct 22, 2021

rsglobal commented Nov 3, 2021

kbingham commented Nov 3, 2021

kbingham commented Nov 3, 2021

kbingham commented Sep 6, 2022

rsglobal commented Sep 6, 2022

rothn commented Oct 7, 2022

kbingham commented Oct 7, 2022

rsglobal commented Oct 7, 2022

pinchartl commented Oct 7, 2022

rsglobal commented Oct 7, 2022

rothn commented Oct 9, 2022 • edited

rothn commented Oct 9, 2022 • edited

rsglobal commented Oct 9, 2022

kbingham commented Oct 10, 2022

kbingham commented Oct 11, 2022

kbingham commented Oct 11, 2022

rsglobal commented Oct 11, 2022

kbingham commented Oct 11, 2022

rsglobal commented Oct 11, 2022

kbingham commented Oct 11, 2022

rsglobal commented Oct 11, 2022

kbingham commented Oct 11, 2022

rothn commented Oct 11, 2022 via email

rsglobal commented Oct 12, 2022

rsglobal commented Oct 12, 2022

kbingham commented Oct 12, 2022

kbingham commented Oct 12, 2022

rsglobal commented Jun 8, 2021 •

edited

rsglobal Jun 9, 2021 •

edited

rsglobal commented Jun 22, 2021 •

edited

rsglobal commented Aug 22, 2021 •

edited

rothn commented Oct 9, 2022 •

edited

rothn commented Oct 9, 2022 •

edited