I have a binary in Android that links to a static library A. Static library libA depends on multiple shared libraries.
The binary does not do anything except it imports a class from the static library and executes a simple function.
However, the binary fails to build except I link against the same shared libraries to which the static library A is linked because the compiler tries to recompile libA with the build config of the binary.
Here is my Android.bp of the static library:
cc_library_static {
name: "libA",
relative_install_path: "hw",
vendor: true,
rtti: true,
cflags: [
"-Wall",
"-Wextra",
"-g",
"-DUNIT_TEST",
"-fexceptions"
],
srcs: [
"libA.cpp",
],
shared_libs: [
"libhidlbase",
"libhidltransport",
"libutils",
"liblog"
],
header_libs: [
"lib_a_stub_headers",
],
whole_static_libs: [
"lib_a_stub",
],
export_include_dirs: ["."]
}
Here is my Android.bp for the binary:
cc_binary{
name: "simplebinary",
relative_install_path: "hw",
vendor: true,
cflags: [
"-fexceptions"
],
whole_static_libs: [
"libA"
],
shared_libs: [
"vendor.test.hal#1.0",
],
srcs: [
"simplebinary.cpp",
],
}
The build of the binary fails with:
libA.hpp:4:10: fatal error: 'lib/lib.hpp' file not found
I'm building using the command mm
According to the error message, the compiler cannot find a header file in its header search path. Header includes are resolved during the preprocessor stage, therefore this is not a linking problem. The preprocessor runs at the beginning of compilation, the linking is done at the end.
From your description, I understand that the code for simplebinary includes the header libA.hpp, provided by libA. I understand that libA.hpp is contained in the same directory as the Android.bp that defines the libA module. Because of the export_include_dirs: ["."], this directory is added to the header search path for the compilation of simplebinary. Therefore, the compiler can find libA.hpp when compiling simplebinary.
Now libA.hpp includes CommonAPI/CommonAPI.hpp. I do not know to which library this header belongs. I assume the header belongs to some library libB, and libA links against libB. I further assume that libB has export_include_dirs set to point to the folder containing CommonAPI/CommonAPI.hpp. You can then make libA re-export this header by adding export_shared_lib_headers: ["libB"] to the module declaration of libA. If libB is not a shared library, you would have to use export_static_lib_headers or export_header_lib_headers instead (reference).
Related
I'm trying to build an ASOP build which uses some external libs like Firebase. (In ASOP source code)
While adding Firebase plugin in Android.bp getting error like "depends on undefined module "com.google.gms.google-services"
Is there any alternative to use "apply plugin: 'com.google.gms.google-services'" in Andorid.mk or Android.bp other build system?
android_app {
name: "FirebaseService",
vendor: true,
certificate: "platform",
privileged: true,
srcs: ["java/**/*.java",],
resource_dirs: ["res"],
manifest: "AndroidManifest.xml",
static_libs: [
"firebase-analytics",
"androidx.appcompat_appcompat",
],
plugins: ["com.google.gms.google-services"],
optimize: {
enabled: false,
},
sdk_version: "system_current",
dex_preopt: {
enabled: false,
}, }
This plugin is to use refer google-sevices.json file which we get while integrate application with Firebase.
error: vendor/frameworks/FirebaseService/Android.bp:20:1:"FirebaseService" depends on undefined module "com.google.gms.google-services"
I have been dealing with this issue for a couple of days now. I Built the .so library using cmake under visual studio using the fallowing settings:
CMakeList.txt:
cmake_minimum_required (VERSION 3.8)
set(ANDROID_STL c++_static)
set(CMAKE_TOOLCHAIN_FILE C:/Microsoft/AndroidNDK/android-ndk-r21d/build/cmake/android.toolchain.cmake)
project("GetValsDudeLib").
So far I have been unable to find any examples online
set(CMAKE_SYSTEM_PROCESSOR x86)
set(CMAKE_ANDROID_ARCH arm)
set(CMAKE_SYSTEM_NAME ANDROID)
set(CMAKE_ANDROID_NDK "C:/Microsoft/AndroidNDK/android-ndk-r21d")
set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang5.0)
set(CMAKE_SYSTEM_VERSION 23) # API level
set(CMAKE_ANDROID_ARCH_ABI x86)
file(GLOB GetValsDudeSRC ${CMAKE_CURRENT_SOURCE_DIR}/*.cpp ${CMAKE_CURRENT_SOURCE_DIR}/*.hpp)
add_library (GetValsDudeLib STATIC ${GetValsDudeSRC})
CMakeSetting.json
{
"configurations": [
{
"name": "x86-Debug",
"generator": "Ninja",
"configurationType": "Debug",
"buildRoot": "${projectDir}\\out\\build\\${name}",
"installRoot": "${projectDir}\\out\\install\\${name}",
"cmakeCommandArgs": "",
"buildCommandArgs": "",
"ctestCommandArgs": "",
"inheritEnvironments": [ "gcc-arm" ],
"variables": []
}
]
}
I added the the reference to the android native activity project:
Added headers folder path. Project properties C/C++ => Additional Include Directories.
Added library (.so) folder path. Project properties Linking => input=> Additional Library Directories.
Specified Library. Project properties Linking => input=> Library Dependencies (set that to "GetValsDudeLib").
After that I am able to create an instance of the class provided by the Library (GetValsDude) and build. It runs with no issues. But if I try to use a method of the object (AddOne(int)) it fails with the fallowing exception:
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Application Type\Android\3.0\Android.Common.targets(119,5): error MSB6006: "clang.exe" exited with code 1.
1> 263 Warning(s)
1> 1 Error(s)
1>
Looking into the logs I found the following:
...
1> C:\Microsoft\AndroidNDK\android-ndk-r21d\toolchains\x86-4.9\prebuilt\windows-x86_64/lib/gcc/i686-linux-android/4.9.x/../../../../i686-linux-android/bin\ld: Opened new descriptor 10 for "x86\Debug\libRevEngineAndroid.so"
1> undefined reference to 'GetValsDude::AddOne(int)'
...
So obviously there is a failure Linking GetValsDude header to the .so library.
Any help will be greatly appreciated.
I am trying to build an Android application inside of AOSP.
I have defined the Android.bp file as follows
cc_prebuilt_library_shared {
name: "libPrintString",
target: {
android_arm: {
srcs: ["lib/libPrintString.so"],
},
android_arm64: {
srcs: ["lib64/libPrintString.so"],
},
},
strip: { none:true, },
}
java_import {
name: "stringutils",
jars: ["libs/stringutils.jar"],
}
android_app {
name: "HelloWorld",
srcs: ["src/**/*.java",],
platform_apis: true,
product_specific: true,
certificate: "platform",
privileged: true,
static_libs: [
"com.google.android.material_material",
"androidx-constraintlayout_constraintlayout",
"stringutils",
],
jni_libs: ["libPrintString"]
}
I have put my application in the /packages/apps folder, the project has the following structure
+ HelloWorld
- Android.bp
- AndroidManifest.xml
+ lib
- libPrintString.so
+ lib64
- libPrintString.so
+ libs
- stringutils.jar
+ res
+ src
When I am calling make I am getting an error
FAILED: ninja: 'out/target/product/mydroid/product/lib64/libPrintString.so', needed by 'out/target/product/mydroid/product.img', missing and no known rule to make it
Can someone please help me to find a solution?
Your app HelloWorld definition has this property product_specific: true which means the app will go to /product partition and will search for the libraries in /product/lib*/.
But your library libPrintString definition don't have product_specific: true which means the library goes to system/lib*/.
So error makes sense.
To solve your problem, You have to add this property product_specific: true to your library definition.
cc_prebuilt_library_shared {
name: "libPrintString",
target: {
android_arm: {
srcs: ["lib/libPrintString.so"],
},
android_arm64: {
srcs: ["lib64/libPrintString.so"],
},
},
strip: { none:true, },
product_specific: true
}
After long fights with the build system, I finally found a solution and wrote a small article to describe in details how to build an application with system privileges
How to Build an Android Application with System Privilegies
I still did not fully understand why it was not working in the beginning, most probably because somehow my build system was not cleaning old libraries, but now everything is working correctly.
I put react-native.jar to tensorflow android's directory and add configuration to tensorflow/examples/android/BUILD file like this:
java_import(
name = "react-native",
jars = [
"react-native-0.39.2-sources.jar",
],
)
Now run bazel build //tensorflow/examples/android:tensorflow_demo work well. But then use import com.facebook.react.*; in java file and run bazel build ... again, it throws a nonexistent error, can't find com.facebook.react.* package.
In order to expose the classes in the JAR to the Java code in the Android build, you need to add a dependency in the android_binary that you are building on the java_import you have created.
For example:
# tensorflow/examples/android/BUILD
java_import(
name = "react-native",
jars = [
"react-native-0.39.2-sources.jar",
],
)
android_binary(
name = "tensorflow_demo",
srcs = glob(["src/**/*.java"]),
deps = [
":tensorflow_native_libs",
"//tensorflow/contrib/android:android_tensorflow_inference_java",
":react-native",
],
)
I'm building an Android library based on Tensorflow with Bazel.
Here the BUILD file
cc_binary(
name = "libfoo.so",
srcs = glob([
"jni/**/*.cc",
"jni/**/*.h",
]),
copts = [ "-fexceptions", "-DEIGEN_AVOID_STL_ARRAY",
"-mfpu=neon", "-std=c++11",
"-DMIN_LOG_LEVEL=0", "-DTF_LEAN_BINARY",
"-O2", ],
linkopts = [
"-llog",
"-lm",
],
linkshared = 1,
deps = [
"#org_tensorflow//tensorflow/core:android_tensorflow_lib",
"#boringssl//:crypto",
],
)
The linker complains about not finding -lpthread, while I didn't add this flag to linkopts.
I've checked the executed command, and in fact there is extra flags on it: -lz -lpthread ...
Where did they came from ? Is there a workaround for this ?
I got the answer from the tensorflow's issue tracker.
#jart
Since copts and linkopts are viral and propagate to dependencies, -lpthread is most likely being inherited from #boringssl//:crypto
#andrewharp
-lpthread is not necessary or possible on Android, so it sounds like the solution would be to add another condition for the select statement as in the linked commit google/protobuf#1386:
...
The only other workaround I know of that doesn't require editing the other repository is to create a dummy libpthread.so target, but that's pretty hacky.