Android Studio's NDK builder is fetching the wrong header file.
I am using source from a recent revision of tinyalsa in my Android application, and when I try to build the project in Android Studio, the NDK builder fetches the header file pcm.h from my system at /usr/include/tinyalsa/pcm.h instead of the one in my project's source tree.
How can I tell the builder to not look for the file in my system directory? I've already specified an include for the intended directory in my Android.mk
LOCAL_CFLAGS := -Itinyalsa-master/include
I think you also need to set the path for the include files - you need to set LOCAL_C_INCLUDES.
Your flag is fine, but the "includes" that you specify are relative to your app's app directory.
Change your flag to:
LOCAL_CFLAGS := -Isrc/main/<intervening-directories>/tinyalsa-master/include
Related
I have created an application in Android Studio. Now I want to add that project in android_source_code/packages/apps/ folder and build the entire AOSP image so that my app will be a system app.
Now the problem is the application is having a folder structure of Android Studio which is entirely different from Eclipse and android_source_code expects it to be in Eclipse folder structure format. So how can I achieve that?
Will android_source_code accepts the Studio folder structure or Do I need to write a script to transform the Studio folder structure to Eclipse format while copying to the android_source_code?
Any help will be appreciated.
Thanks
Integrating an Android Studio project into the AOSP build is not a trivial task. As far as I know, there aren't any dedicated tools to convert an Android Studio project (that is using the Gradle build system) to AOSP project (that is using the make build system).
One of the approaches you might want to investigate is creating your own Gradle task that will build the Android.mk file based on the source structure of you Android Studio project (i.e. finding all the relevant source sets for your JAVA files, resources, manifests, AIDLs etc ... and creating an Android.mk file that will tell the AOSP build system exactly wher to find each and every file).
This approach might work for relatively simple projects, but as soon as you start using more complex features (i.e. Modules, Manifest/Resources merging and so on), you will find it extremely difficult to generate the Android.mk without the help of the Gradle build system.
I would consider a different approach:
As a pre-installed privileged application, you can get the same privileges as a system application and perform whatever tasks you might wish to perform with no restrictions.
To do so, you can build your application using Android Studio, and define the already built APK as a BUILD_PREBUILT component that will be placed in the priv-app folder of the device.
Here is an exsample of the Android.mk file that will take your pre built APK and install it on the device as a pre installed application:
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := your_app_name
LOCAL_SRC_FILES := $(LOCAL_MODULE).apk
LOCAL_MODULE_CLASS := APPS
LOCAL_MODULE_SUFFIX := .apk
LOCAL_PRIVILEGED_MODULE := true
LOCAL_CERTIFICATE := platform
include $(BUILD_PREBUILT)
In addition, depending on what your application needs to do, you might want to declare in your manifest that your application is a system app:
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
...
...
android:sharedUserId="android.uid.system">
I am trying to create an Android Studio wrapper around C code and am running into a problem with the NDK. Because the C code is from a 3rd party project, I am trying to not move the code location and have the project in a subdirectory of the repository and as such have to not use the build in call to the NDK and its autogenerated make file. The NDK call works correctly, but I get the following error:
make.exe: *** No rule to make target `C:/some_relative_path/jni/../../../../core.c', needed by `C:/some_relative_path/obj/local/armeabi/objs/my_module/C_/some_relative_path/jni/__/__/__/__/core.o'. Stop.
As you can see, the object path has been mangled such that : and .. have been turned into underscores.
I had to add a jni folder to my project and place the Android.mk and Application.mk files in it to satisfy the path appending of the NDK Gradle plugin. As a result the jni folder had no source files in it. Since I found several links on google talking about needing more than one source file, I added two dummy source files to the jni directory.
Among other things, my Android.mk file contains the following:
LOCAL_SRC_FILES := \
$(LOCAL_PATH)/NDKBug1.c \
$(LOCAL_PATH)/NDKBug2.c \
$(LOCAL_PATH)/../../../../core.c \
I'm looking to see if anyone can help me with either this path issue directly, or perhaps suggest an alternative way of setting things up.
The file names in LOCAL_SRC_FILES are supposed to be relative to the local directory, so you need to remove the $(LOCAL_PATH)/ prefix - then it should work.
I haven't heard about a bug requiring to have source files in the local dir though, so I think you can get rid of them.
im stuck with this problem and dont know what im doing wrong. Please help me out.
Im working on an android project where I have to use 2 native library(.so) file. These 2 files are not generated by me, i just have to use them in my project.
I have placed these .so files under libs->armeabi folder. In the code i have used System.loadLibrary("name") inside a static block to load these library files. After doing this, i clean the project and run the application. I get the following error
java.lang.UnsatisfiedLinkError:
What am i missing. I have unchecked the first two options in build settings as well.
Note: I am not developing the native library. I am just using it. It was being used in a previous version, so I am pretty sure there is nothing wrong in the way the .so files have been generated.
PS: My ultimate requirement is like this,
My android application will have a jar which I am developing. The methods in the jar will make use of these native functions. The main application will not directly access the native functions. Should i place the .so files in the jar or should it be in the main application. How should i package the jar and .so files.
Please help me out, this is my first time using native functions and im totally lost. Links to any materials would be great.
Set PATH to your NDK
Eclipse -> Window -> Preferences -> Android -> NDK -> set path to the NDK
Right click on an Android project and select Android Tools -> Add native support.
Make changes to your Android.mk file to include this .so file
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := <module_name>
LOCAL_SRC_FILES := <.so file name>
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../jni/include
include $(PREBUILT_SHARED_LIBRARY)
Clean project and build again
I configure ndk with eclipse in order to build my c++ code automatically. But i have two external .so file inside libs folder. Everytime, eclipse will delete these external .so file automatically when build project. Is it possible to tell eclipse not delete these external file.
The solution is here.
To summarize (and complement):
Copy your external (e.g., libexternal.so) library (or libraries) to another folder inside your 'jni' folder; for example 'myproject/jni/prebuilt'.
Add the following block to your existing 'jni/Android.mk' (one block for each external library):
include $(CLEAR_VARS)
LOCAL_MODULE := libexternal
LOCAL_SRC_FILES := prebuilt/libexternal.so
include $(PREBUILT_SHARED_LIBRARY)
Add 'libexternal' to 'APP_MODULES' in your existing 'jni/Application.mk'. 'APP_MODULES' should already list your JNI module (e.g., 'myjnimodule'):
APP_MODULES := libexternal myjnimodule
Confirm that the following block exists in 'jni/Application.mk'. Use the appropriate target architecture(s):
APP_ABI := armeabi-v7a
The result is that, as part of the invocation to 'ndk-build', the external library is copied to your 'myproject/libs/armeabi-v7a' folder.
The solution given by John Doedoe led me to another possibility, specific to Eclipse (tested on Mars 1 version):
Right click on your project in the project explorer.
Go into properties.
Go into "C/C++ Build".
Go into the "Builder Settings" tab.
Uncheck "Use default build command".
In the "Build command" text box type your target, e.g.: ndk-build APP_ABI="armeabi-v7a"
Apply / Ok
This will avoid changing behavior on a build machine for instance.
I have implemented a JNI android application. This application requires a few additional 'Shared Libs' to be packed as part of the APK. Using Ecplise, I have added these libs to the project's '/libs/armeabi' folder.
However, when launching the application (through the integrated debugger), my added 'Shared Libs' are removed from the 'armeabi' folder.
How can I prevent these additional libs from being removed?
How can I make sure the additional required SOs are packed in the APK?
You don't need to copy this libraries to libs folder yourself. This job should be done by the ndk-build.
These two steps should be enough:
Create mylibs (you can use any other name instead) folder on the root level of your project. And put your libraries into this folder.
For each library add the following lines before the include $(CLEAR_VARS) statement replacing mylib with you library name:
include $(CLEAR_VARS)
LOCAL_MODULE:=mylib
LOCAL_SRC_FILES:=../mylibs/libmylib.so
include $(PREBUILT_SHARED_LIBRARY)
(You might need slightly different path for LOCAL_SRC_FILES. It depends on your Eclipse configuration.)
One more note to add in this context is that the path to the external SharedLib MUST BE relative to the jni directory ( or to whatever spcified # LOCAL_PATH ), that is, "LOCAL_SRC_FILES := ../../../Android/ffmpeg/libavcodec/libavcodec.so" will work where the absolute path will not.