Today I run into the same issue like you. I also followed the blog post you mentioned. Whatever. I'm happy to report you: I fixed it and found a "solution"!
The funny part is: The solution so dumb as simple. The only thing you have to do is to unset
(or remove) the NDK environment variable (or directory).
The magic line is:
- unset ANDROID_NDK_HOME
Which means that my final bitbucket-pipelines.yml
looks like:
image: uber/android-build-environment:latest
pipelines:
default:
- step:
script:
- unset ANDROID_NDK_HOME
- ./ci/accept_android_license.sh
- ./gradlew :app:testDebugUnitTest
Why does it fix the issue?
To be honest. I don't know . But I found out that the uber
s android-build-environment
install the NDK for you.
I found some answers - like here - to install the NDK separately again. But I thought about the following: Why the hell should I install/update the NDK if my project doesn't use it? So I tried to remove the NDK folder (which according to the Dockerfile
located at /usr/local/android-ndk
) and everything works .
Why unset
ting then?
You can't remove the android-ndk
dir because you don't have permission to do it. But you can delete the content from it. That is the reason why it worked with rm -rf /usr/local/android-ndk
. But then - with the setting of ANDROID_NDK_HOME
but without any content in there you got the error message (while building):
./gradlew :app:testDebugUnitTest
NDK is missing a "platforms" directory.
If you are using NDK, verify the ndk.dir is set to a valid NDK directory. It is currently set to /usr/local/android-ndk.
If you are not using NDK, unset the NDK variable from ANDROID_NDK_HOME or local.properties to remove this warning.
unset
the environment variable fix that warning as well.
Important:
Obviously that is not the best solution. If your App uses the NDK this solution will not help. To remove some environment variables "from a Docker image" in a CI
script is also not the best solution. Maybe the image need the variable later (don't know if that is possible in Docker... but you know what I mean ). But it will "temporary" fix the problem and since the android-build-environment
is unmaintained (not update since a year) anyway I would not put to much effort in fixing the image...
Note: The link to the uber:android-build-environment
GitHub page refers to a single (currently the last) commit. If someone read that in the future the link is still active and correct but maybe the master
branch have changed.