bazelbuild / rules_android_ndk Goto Github PK

How do I get access to NDK headers android/log.h, android_native_app_glue.h, etc.

This does not seem to be documented.

android_ndk_repository in rules.bzl is currently hard-coded for Linux.

Hey, @ahumesky! Thanks again for releasing this and for all the great work you're doing, here and elsewhere.

With #1 resolved, we've switched to building our codebase with the new toolchains and NDK r25. Yay!

Just as you'd guessed, some of the default flags/features needed flipping. But more defaults were fixed than broken!

It sounded like you wanted user feedback on default features/flags, so here's mine. It's a bit long because I was trying to be thorough; probably best read incrementally!

1. [DONE] Linker flags: I love seeing -lm -ldl in there by default. (Formerly these weren't enabled, causing breakages out of the box, since libc++ was auto-linked. See bazelbuild/bazel#10837) Similarly, great to see --no-undefined, so errors are evident. And great to use lld by default! I'm getting to delete a lot of our manual configuration because this has much better linking defaults! I think this pretty well closes that old issue I'd filed :)
2. [DONE] I think that outside of Google, exceptions probably should be on by default.
   (That is, remove "-fno-exceptions" from)

   rules_android_ndk/ndk_cc_toolchain_config.bzl

   Line 656 in 81ec8b7

   "-fno-exceptions",

   
   I remember the backstory behind Google having them off internally, but since Google would probably recommend them if they could do a do over and lots of major libraries require them, I think probably they'd better default to on outside.
   If useful, the library pinning us to using them is Boost.Thread, which unconditionally uses try blocks (i.e. BOOST_NO_EXCEPTIONS doesn't work here.)
   To be clear, the problematic default is definitely user overridable with, e.g., build --cxxopt=-fexceptions (yay Bazel's feature system!), but having exceptions on does seem like the right default for most users.
   1. Is there a good way to still share code with Blaze and have a few of the default flags differ like this? Like maybe just a condition we could add, or a blaze/bazel specific feature? Collaborating seems better than having open source hard diverse from Google, as has happened in some of the other repos. Makes me sad seeing both sides lose. I'd rather help than be sad!
3. [DONE] Similarly, it seems to me that warnings_as_errors should probably be off by default. Good to encourage people to eliminate warnings, but like, probably not the right thing with external dependencies. Should a warning way down in a transitive third party library really break the build?
   For anyone else reading along, you can override this default with --features=-warnings_as_errors, but it does seem to me that we should change the default, in the other toolchains.
   [It also does seem like at least some of the warning flags are on by default or duplicative, but that's not really a problem. I do love the through warnings.]
4. [PR #26] Love seeing C++17 in the defaults :) I know the NDK compilers support C++20, since support for new NDKs in bazel was the last thing stopping my team from upgrading. Thoughts on making C++20 the default here instead? No pressure. It just seems like a good opportunity before the interface hardens.

   rules_android_ndk/ndk_cc_toolchain_config.bzl

   Line 657 in 81ec8b7

   "-std=gnu++17",

5. It's great to see the fully_strip feature on by default for opt builds, but if it seems like a good idea to strip release builds for mobile, as on iOS, maybe we should enable linker_fully_strip by default for opt builds, too?
   To explain my understanding: By default, no strip actions are generated for opt, and enabling stripping for opt builds would also strip debug builds. This never made a ton of sense to me, at least for mobile. (I assume that this is maybe an assumption held over from building for servers. Or maybe this is different for Blaze?) This means that the stripping of optimized (release!) builds doesn't currently take place by default, as one might think/hope. And further, the docs indicate a debug-symbols only strip, contrary to what seems to be going on here. Instead, those linked docs encourage instead passing "-Wl,--strip-all", equivalent to linker_fully_strip if you want stripped binaries for release, which does indeed work. Hence the proposal.
   I should note also, that some of the comments in the definition of linker_fully_strip and fully_strip seem a bit confused here, indicating that they apply in slightly different cases than they seem to. Either something's slightly different in Blaze or there's something a little off here. Or I'm misunderstanding something; I can't seem to get linker_fully_strip to apply via --features=linker_fully_strip, though I can get things working as I'd hope via the equivalent flags.
   [As a cross reference, I know stripping by default for mobile has been discussed some in the context of LTO over at https://github.com/bazelbuild/bazel/issues/13287. Looks like there's a fairly sophisticated thin LTO implementation here. I'd still advocating turning it on for opt builds by default!]
6. One fairly common problem porting code to the NDK is its nonstandard pthread behavior, and I bet could seamlessly fix this for Bazel users with some additional clever defaults.
   As background, the Android NDK is weird in that it bundles pthread's symbols into libc, rather than having a separate libpthread like other posix-type platforms. This breaks compatibility for build scripts designed to work across platforms; -lpthread can't find a matching library because android has put its symbols under a different name. An elegant solution we've found to just automatically provide an empty libpthread.a and then auto add it to the linker search path, solving things. Happy to contribute that solution if you want! And if so, I'd love to hear if you know how to add an automatic dependency via the cross tool.
   For more details, and an example of this breaking usage of protobuf, please see bazelbuild/bazel#7983.
   1. I see some dangling comments and references to a memmove fix for API level <=20, but not the libmemmove.a or readme section it references. It looks, though, like maybe there's a mechanism there to implicitly include a .a from the toolchain, like we'd need for pthread.
7. I think there're some trickiness still outstanding around libc++, maybe that we should discuss separately. But in a nutshell, my read from the code, link line, and dynamic symbols is that the toolchain statically links libc++ even when a dependency bundles libc++ as a shared library, which leads to subtle dangers if the interface of that library uses the stl. More at https://developer.android.com/ndk/guides/cpp-support. It seems like the build systems maintainer guide suggests letting Clang link the STL, rather than specifying manually, as is being done here. IMO the right behavior would be to link dynamically if a dependency links dynamically, and otherwise link statically unless the user has specified otherwise.

Again, thank you--both for reading and for all your great work.
Happy to help/PR these if you'd like. But I figured I should write in first.

Chris
(ex-Googler)

I have a working prototype of downloading the NDK directly in Bazel for both Linux and macOS. Would that be something interesting to contribute in rules_android_ndk?

I find providing the path of the NDK via an environment variable relatively brittle and it's much easier IMO to have Bazel download the toolchain when onboarding new devs.

I'm trying to upgrade a project to use rules_android_ndk (from the packaged one) and am facing some issues:

$ bazel build :cpuinfo --cpu=arm64-v8a --crosstool_top=@androidndk//:toolchain --host_crosstool_top=@bazel_tools//tools/cpp:toolchain 
ERROR: /usr/local/google/home/zhin/.cache/bazel/_bazel_zhin/6c29bbe1edd74d1c184bd5850967e7c9/external/androidndk/BUILD:9:6: no such target '@androidndk//toolchains/llvm/prebuilt/linux-x86_64:cc_toolchain_suite': target 'cc_toolchain_suite' not declared in package 'toolchains/llvm/prebuilt/linux-x86_64' defined by /usr/local/google/home/zhin/.cache/bazel/_bazel_zhin/6c29bbe1edd74d1c184bd5850967e7c9/external/androidndk/toolchains/llvm/prebuilt/linux-x86_64/BUILD.bazel (Tip: use `query "@androidndk//toolchains/llvm/prebuilt/linux-x86_64:*"` to see all the targets in that package) and referenced by '@androidndk//:toolchain'
ERROR: Analysis of target '//:cpuinfo' failed; build aborted:
INFO: Elapsed time: 0.126s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)

I've read a couple of related issues here:

1. cpuinfo is a cc_binary so i'm using --cpu and --crosstool_top instead of the --fat_apk_cpu and --android_crosstool_top based on #19 (comment)

I also tried passing --extra_toolchains=@androidndk//..., and after resolving something related to @rules_python:

INFO: Build option --extra_toolchains has changed, discarding analysis cache.
ERROR: /usr/local/google/home/zhin/src/cpuinfo/BUILD.bazel:176:11: While resolving toolchains for target //:cpuinfo: invalid registered toolchain '@androidndk//...': error loading package under directory '': error loading package '@androidndk//sources/third_party/googletest/test': Unable to find package for @rules_python//python:defs.bzl: The repository '@rules_python' could not be resolved: Repository '@rules_python' is not defined.
ERROR: Analysis of target '//:cpuinfo' failed; build aborted:
INFO: Elapsed time: 0.231s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 6 targets configured)
    currently loading: @androidndk//sources/third_party/googletest/test ... (2 packages)

by adding to WORKSPACE:

SHA = "84aec9e21cc56fbc7f1335035a71c850d1b9b5cc6ff497306f84cced9a769841"

VERSION = "0.23.1"

http_archive(
    name = "rules_python",
    sha256 = SHA,
    strip_prefix = "rules_python-{}".format(VERSION),
    url = "https://github.com/bazelbuild/rules_python/releases/download/{}/rules_python-{}.tar.gz".format(VERSION, VERSION),
)

load("@rules_python//python:repositories.bzl", "py_repositories")

py_repositories(

I get the same error about no such target '@androidndk//toolchains/llvm/prebuilt/linux-x86_64:cc_toolchain_suite'.

To reproduce:

git clone https://github.com/ngzhian/cpuinfo.git
cd cpuinfo
git checkout workspace
export ANDROID_NDK_HOME=/path/to/ndk/r25c # i'm using r25c
bazel build :cpuinfo --cpu=arm64-v8a --crosstool_top=@androidndk//:toolchain --host_crosstool_top=@bazel_tools//tools/cpp:toolchain  --fat_apk_cpu=arm64-v8a --android_crosstool_top=@androidndk//:toolchain

Bazel version 5.2.0, Linux, commit 81ec8b7 (as advertised)

I tried to build some project for an emulator. It appears to be impossible to run qemu based ARM64 emulator on Linux these days (it behaves rather weirdly and goes nowhere), so I wanted to use an AMD64 emulator, to the tune of:

bazel build --android_crosstool_top=@androidndk//:toolchain --host_crosstool_top=@bazel_tools//tools/cpp:toolchain --cxxopt=-std=c++17 --cpu=x86_64 --fat_apk_cpu=x86_64 //target

This failed with an error:

.../external/local_config_cc/BUILD:47:19: in cc_toolchain_suite rule @local_config_cc//:toolchain: cc_toolchain_suite '@local_config_cc//:toolchain' does not contain a toolchain for cpu 'x86_64'

Am I doing something wrong or is it not supported just yet?

I don't really need AMD64 support, so if there's some advice regarding running an ARM64 emulator on AMD64 it will be handy as well.

Currently if you attempt to use these rules with NDK 21, you get cryptic failures because of broken assumptions. This is expected to fail in general but it would be nicer if the rules reported a clear error for this case instead

Based on this https://github.com/android/ndk/wiki#release-schedule NDK 26 should be released sometime in Q3. I did some light testing and it seems like some files moved around that leads to everything failing today. I'm not sure if those types of moves are tracked anywhere? But I wanted to file this as a tracking issue for supporting the new version.

One open question I have is, should we be trying to maintain backwards compatibility in this case like bazel did before, or not?

Some Google projects like protocolbuffers or boringssl replies on checking crosstool_top value for whether it is an Android target or not.

Adding a default_crosstool or toolchain-libcpp alias could be a workaround for the problem.

https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/3341#_

Platform : MacOs, Windows, Ubuntu

Logs:

ERROR: --nouse_workers_with_dexbuilder :: Unrecognized option: --nouse_workers_with_dexbuilder

Culprit : bazelbuild/bazel@f2c11f7

CC Greenteam @Wyverald

At minimum they should build the example app (https://github.com/bazelbuild/rules_android_ndk/tree/main/examples/basic) and ideally the resulting apk would be tested on an emulator / virtual device.

See also
#7
bazelbuild/continuous-integration#1425

This might be useful as inspiration too:
https://github.com/DanAlbert/ndk-app-template/blob/main/.github/workflows/build.yml

Contributors must sign a Contributor License Agreement, and to check this we should set up the Google CLA bot on this repo

clang version 14.0.7
bazel 5.3.0

The minimal source code source.cc is

#include <iostream>

struct S {
  S() { 
    // std::ios_base::Init init;
    std::cout << "static cout" << std::endl; 
  }
};

static S var_;

int main() {
  return 0;
}

BUILD.bazel

cc_binary(
    name = "source",
    srcs = ["source.cc"],
)

build command:

build --repo_env="ANDROID_NDK_HOME=/**/android-ndk-r25c" --cpu=arm64-v8a --crosstool_top=@androidndk//:toolchain --host_crosstool_top=@bazel_tools//tools/cpp:toolchain --compilation_mode=opt --copt='-O3' --cxxopt='-std=c++17'

Running the binary in development board got Segmentation fault. Uncomment the line // std::ios_base::Init init;, running is successful.
It seems that the global object std::cost didn't initialized at that time. However, if I directly invoke clang by android-ndk-r25c/toolchains/llvm/prebuilt/linux-x86_64/bin/aarch64-linux-android23-clang --std=c++17 src/static-test.cc -o bazel-bin/static-clang.i -lstdc++, the Segmentation fault didn't happen.
related issues:
llvm/llvm-project#29324
WebAssembly/wasi-sdk#153

For simplicity, the top-level toolchains directory of the NDK is symlinked into the external repository directory, but this means that when android_ndk_repository creates BUILD files, they're created in the real NDK installation directory:

I'm building an app with Bazel and flutter (which sadly is not integrated at all) and was puzzled when I realized ANDROID_NDK_HOME is completely ignored by the latest version of the Android Gradle plugin.

It looks like the project has moved from using ANDROID_NDK_HOME to assuming relative paths within ANDROID_HOME, like so: https://github.com/android/ndk-samples/wiki/Configure-NDK-Path#introduction

Adding search paths like $ANDROID_HOME/ndk/$version would also let us specify a version in the repository_rule which would fail if the constraint is not satisfied on the host's machine.

The version of clang is hardcoded:

and it might be easy to auto-detect the clang resource directory (especially if there will only ever be one of them)

rules_android_ndk doesn't work with cc toolchain resolution enabled.

Example failure when building with Bazel@HEAD and --incompatible_enable_cc_toolchain_resolution:

Use --sandbox_debug to see verbose messages from the sandbox and retain the sandbox build root for debugging
java/com/app/jni.cc:15:10: fatal error: 'jni.h' file not found
#include <jni.h>
         ^~~~~~~
1 error generated.
Error in child process '/usr/bin/xcrun'. 1
(07:51:28) ERROR: /Users/buildkite/builds/bk-imacpro-6/bazel-downstream-projects/rules_android_ndk/examples/basic/java/com/app/BUILD:22:11: Compiling java/com/app/jni.cc failed: (Aborted): wrapped_clang_pp failed: error executing command (from target //java/com/app:jni)
  (cd /private/var/tmp/_bazel_buildkite/298ea2b5b89560eebdd96300ce1ca9e7/sandbox/darwin-sandbox/3/execroot/__main__ && \
  exec env - \
    APPLE_SDK_PLATFORM='' \
    APPLE_SDK_VERSION_OVERRIDE='' \
    PATH=/Users/buildkite/Library/Caches/bazelisk/local/-tmp-tmpmy5n7pkm-bazel/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin \
    XCODE_VERSION_OVERRIDE=13.0.0.13A233 \
    ZERO_AR_DATE=1 \
  external/local_config_cc/wrapped_clang_pp '-D_FORTIFY_SOURCE=1' -fstack-protector -fcolor-diagnostics -Wall -Wthread-safety -Wself-assign -fno-omit-frame-pointer -O0 -DDEBUG '-std=c++11' 'DEBUG_PREFIX_MAP_PWD=.' -iquote . -iquote bazel-out/android-x86-fastbuild/bin -MD -MF bazel-out/android-x86-fastbuild/bin/java/com/app/_objs/jni/jni.d '-DBAZEL_CURRENT_REPOSITORY=""' '-frandom-seed=bazel-out/android-x86-fastbuild/bin/java/com/app/_objs/jni/jni.o' -isysroot __BAZEL_XCODE_SDKROOT__ -F__BAZEL_XCODE_SDKROOT__/System/Library/Frameworks -F__BAZEL_XCODE_DEVELOPER_DIR__/Platforms/MacOSX.platform/Developer/Library/Frameworks -no-canonical-prefixes -pthread -no-canonical-prefixes -Wno-builtin-macro-redefined '-D__DATE__="redacted"' '-D__TIMESTAMP__="redacted"' '-D__TIME__="redacted"' -target x86_64-apple-macosx11.3 -c java/com/app/jni.cc -o bazel-out/android-x86-fastbuild/bin/java/com/app/_objs/jni/jni.o)
# Configuration: e6b2da1752e53cbfad1b0216cc4bf232e6229dc2fd3c621e1c4d2840d8603df2
# Execution platform: @local_config_platform//:host

Link to failure: https://buildkite.com/bazel/bazel-at-head-plus-downstream/builds/2641#01835443-ca23-4d89-b700-dd2ef89c8f7a

Accord to README, rules in this repo currently work with Android NDK version 25b , but I can't find download url of NDK 25b.

1. However, NDK r25c is accessible. Is r25c supported? Or is there anything I should pay attention to while using r25c?

2. Providing download url of NDK 25b is also thankful.

Thanks!

I have a project using the latest android_ndk_repository with NDK 25.

Everything builds fine, including large third party dependencies. I’m however unable to link to liblog.so, even when passing ‘-llog’, in which case lld can’t find the library.

if I revert to using the builtin Bazel NDK rule and NDK 21, the problem goes away.

android_ndk_repository in rules.bzl is currently hard-coded for Linux.

When I use bazel 5.2.0, the warning is :

 " The major revision of the Android NDK referenced by android_ndk_repository rule 'androidndk' is 25. The major revisions supported by Bazel are [10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21]. Bazel will attempt to treat the NDK as if it was r21. This may cause compilation and linkage problems. Please download a supported NDK version.".

Any suggestion? Thanks.

Presubmit tests were set up here:
#12

but it would be good to run the apk on an emulator too to make sure the artifact works, e.g. something like this:
https://github.com/DanAlbert/ndk-app-template/blob/f1558c77f4ac563ccfc1dbd41222d4616900b5ba/.github/workflows/build.yml#L63

With the way that the native version of android_ndk_repository structured / symlinked the NDK into bazel's external repository directory, the way to include things like cpu-features was

#include "ndk/sources/android/cpufeatures/cpu-features.h"

With the way the Starlark version of android_ndk_repository structures the NDK symlinks, the ndk/ prefix is not needed:

#include "sources/android/cpufeatures/cpu-features.h"

However this presents a migration issue for projects that use the native version of the rule, so a workaround was introduced to allow including the headers with the ndk/ prefix (by adding another symlink that results in the previous include path). We should migrate projects and remove this workaround.

Hi, all.

I am cross compiling android apps with the following bazel rc flags:

build --incompatible_enable_android_toolchain_resolution=true
# Use the following for building for actual device
build --android_platforms=//:arm64-v8a

working off of what is essentially bazel latest (but I was able to repro on bazel 6). Note that //:arm64-v8a is basically the same as the android pre-defined platforms.

I am noticing an issue when I try and compile an android binary with the following maven dependency:

        "com.arthenica:mobile-ffmpeg-min:4.4",

Specifically, this specific command fails with this error:

bazel-out/k8-opt-exec-2B5CBBC6/bin/external/bazel_tools/tools/android/aar_native_libs_zip_creator --input_aar external/maven/v1/https/repo1.maven.org/maven2/com/arthenica/mobile-ffmpeg-min/4.4/mobile-ffmpeg-min-4.4.aar --cpu k8 --output_zip bazel-out/android-arm64-v8a-fastbuild/bin/external/maven/_aar/com_arthenica_mobile_ffmpeg_min/native_libs.zip

with error:

AAR external/maven/v1/https/repo1.maven.org/maven2/com/arthenica/mobile-ffmpeg-min/4.4/mobile-ffmpeg-min-4.4.aar missing native libs for requested architecture: k8

It looks like the offending line is the --cpu k8, and indeed when I cd'd into the bazel sandbox and ran the command with --cpu arm64-v8a it ran without error. I tracked down the offending line to:

https://github.com/bazelbuild/bazel/blob/224d642a165c16eb0688168e2510b35c9beb5ef0/src/main/java/com/google/devtools/build/lib/rules/android/AarImport.java#L440

My code does work with:

build --fat_apk_cpu arm64-v8a
build --android_crosstool_top=@androidndk//:toolchain

However, I'd like to use android platforms since my specific application shares code with native C++ libraries that use the platforms and its a lot easier to specify a new platform os than to configure on the cpu values. If there is an analog of the platform_mappings API for android that would be good as well. For now I have a workaround, but if there's an easy way to fix this, I'd be happy to take on fixing this myself with some guidance!

Thanks :)