Hello everyone! I've updated my issue about android here : https://github.com/osquery/osquery/issues/7144#issue-913346308. Feel free to correct what seems to be wrong. I know that my post is a bit long. To sum up: if we want to use Osquery as an app (service or deamon) on Android, it is needed first to compile with the Android NDK (cross-compilation). And one of the biggest issues is that NDK (BIONIC) does not support the pthread_cancel function of gnu-libc. There is a function that BIONIC proposes as replacement (pthread_cleanup_push), but the arguments are differents, so I'm not sure whether it is possible. Thus, right now, the solution that seems to work fine, is to compile from a Linux-arm machine with static option to provide a binary that will run as a deamon in the system layer (will not run in the Java Android layer). I know that it is not functionnal for the user and it could not be a real portage solution, but it works (osqueryi and osqueryd) with some restrictions that I try to enumerate. The next step for me is to make some tables for Android. From now on, I can't go on with the NDK compilation (unless you can help me with this) @alessandrogario @Mike Myers @Stefano Bonicatti

You've made some great progress with this so far. I wish I could help out with the NDK exploration but it's outside of my familiarity. I suspect several of osquery's statically compiled and linked dependencies may try to use pthread_cancel. I do not believe osquery uses this directly. If this is the only blocker for using the NDK then you'll might want to isolate what code has that requirement. Keep in mind you can use your own toolchain to build osquery, you do not need to use the official osquery toolchain. We provide that mostly to provide static versions of compiler intrinsics and compatible glibc linkage for Linux OSes back to around 2011.

Thank you Ted! Indeed, I can get rid of these pthread_cancel errors, by avoiding import some targeted libraries. As long as these files are not needed, it solves this problem. Now there are others that I try to fix

For the NDK you also don't want to use the

OSQUERY_TOOLCHAIN_SYSROOT

option, because otherwise you're mixing toolchains (or most likely compile options and include folders). It should compile only with the NDK, somewhat following the instructions that are present on their website, which talks about integrating it with CMake. I'm not sure how ideal it is to have osquery be built with the ARM toolchain; it might seem to work now but it can have all sorts of subtle issues. I would also expect the different kernel possibly not supporting the same syscalls set.

Yes. I did not put it yet in my blueprint, but I now I just do

cmake -DCMAKE_TOOLCHAIN_FILE=$NDK/build/cmake/android.toolchain.cmake -DANDROID_ABI=arm64-v8a -DANDROID_NATIVE_API_LEVEL=21 ..

and seems to launch fine

Kind of, you can generate it with CMake via https://cmake.org/cmake/help/latest/module/CMakeGraphVizOptions.html

Ok I see. I think it is what Alessandro explained to me last time

if you generate the graphviz file, you can then cat | grep 'thirdparty_' to just list the deps

Thrift is used to provide extensions support to osquery. I'm not sure it can be temporarily removed without changing the code. Boost is a "helper" library, much like the C++ standard library and it's used all around. It seems that you're not linking against them in CMake; when you link against their targets (thirdparty_boost for instance), they should transitively pass their include folder