Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove build_tools_version and api_level #384

Merged

Conversation

ahumesky
Copy link
Contributor

Remove build_tools_version and api_level to let android_sdk_repository automatically select the latest installed version.

One of the fixes for bazelbuild/bazel#13409 (comment)

Remove `build_tools_version` and `api_level` to let `android_sdk_repository` automatically select the latest installed version.

One of the fixes for bazelbuild/bazel#13409 (comment)
@google-cla google-cla bot added the cla: yes label May 20, 2021
@brettchabot brettchabot merged commit 441049e into android:main May 20, 2021
@philwo
Copy link
Contributor

philwo commented May 20, 2021

This broke the tests on Bazel CI: https://buildkite.com/bazel/android-testing/builds/1283

Any idea how we could fix this?

@ahumesky
Copy link
Contributor Author

androidsdk/build-tools/30.0.1/zipalign: error while loading shared libraries: /usr/local/lib/libc++.so: file too short

Well, could be that removing api_level = 28 caused something to go wrong in native code generation (seems unlikely), or the zipalign tool in 30.0.1 behaves differently from the zipalign tool in 28.0.2, or something else... I'll try to see what's happening

@philwo
Copy link
Contributor

philwo commented May 20, 2021

I wonder if that's a missing dependency in our image. 🤔 Let me try manually running that file..

@ahumesky
Copy link
Contributor Author

Yeah, I didn't read the error closely enough, I thought it was complaining about a .so file in the apk, but it looks like this is the zipalign tool itself not being able to run

@philwo
Copy link
Contributor

philwo commented May 20, 2021

Seems to work:

buildkite-agent@bk-docker-239d:/opt/android-sdk-linux$ build-tools/30.0.1/zipalign
Zip alignment utility
Copyright (C) 2009 The Android Open Source Project
[...] 

buildkite-agent@bk-docker-239d:/opt/android-sdk-linux$ ldd build-tools/30.0.1/zipalign
	linux-vdso.so.1 (0x00007ffe7f7ce000)
	libc++.so => /opt/android-sdk-linux/build-tools/30.0.1/lib64/libc++.so (0x00007f069da68000)
	libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f069d755000)
	libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f069d536000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f069d198000)
	librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f069cf90000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f069cd78000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f069c987000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f069d959000)

It's interesting that it is dynamically linked against a bundled copy of libc++.so. Maybe this doesn't work when Bazel runs the tool for some reason?

However for build-tools 28.0.2 it looks the same (but maybe when using build-tools 28.0.2, our rules don't call zipalign? Sorry, I don't know the details of our Android support, just guessing here..).

@ahumesky
Copy link
Contributor Author

Yeah, we have a wrapper that's supposed to enable the tools to find their lib directories:
https://cs.opensource.google/bazel/bazel/+/master:tools/android/android_sdk_repository_template.bzl;l=199-225;drc=37ea3d53330acaa1ea27c8c426297b683ba0220a

@philwo
Copy link
Contributor

philwo commented May 20, 2021

Alex and me debugged this a bit more directly in the Docker container that's used on Bazel CI.

The problem is this:

  • The project configuration runs actions in the rbe-ubuntu16-04 container, which uses the JDK 8 by default.
  • build-tools 30.0.1 apparently is built against JDK 11, so it can no longer run with JDK 8.
  • We can switch the project config to use a JDK 11 that's apparently stored somewhere in the container, but this then breaks two emulator tests, because they try to use Qt which doesn't work and then they crash.

I'll have to think about how to fix this a bit more tomorrow.

How I switched the project to JDK 11:

# Replace the rbe_autoconfig(...) part in WORKSPACE with:
rbe_autoconfig(
    name = "rbe_jdk11",
    java_home = "/usr/lib/jvm/11.29.3-ca-jdk11.0.2/reduced",
    use_checked_in_confs = "Force",
)

@philwo
Copy link
Contributor

philwo commented May 20, 2021

I guess, in the worst case if I can't get the RBE stuff working, we might have to revert to enabling KVM support on our instances and running the emulator locally (at least temporarily).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants