I am starting to work with stage fright frame work to implement hardware decoder in android prior to Jelly bean in my video conferencing application.
I have downloaded and built the android source code in Mac system. I am not clear with the whole idea of working with AOSP. And my questions are (with respect to stagefright framework)
Where can I find the libstagefright.so after AOSP build ?.
If I use the OMX codec in my class for decode, how should I link the libstagefright.so to native code of my application ? If I build my native code by copying the libstagefright.so and linking it via make file is that the way ?
How can I use it in my application ? If I load it via System.loadLibrary(" "), will it work ??
UPDATE:
I have tried the suggestion from Ganesh. But when I tried to build the project with NDK it is not taking the headers included as LOCAL_C_INCLUDES.
Here is my android.mk
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_LDLIBS := -llog
LOCAL_MODULE := custom_decoder
LOCAL_C_INCLUDES := $(LOCAL_PATH)\includes \
frameworks/av/media/libstagefright/include \
frameworks/native/include/media/openmax \
frameworks/base/include/media/stagefright
LOCAL_SHARED_LIBRARIES := \
libstagefright libstagefright_omx libstagefright_foundation libutils liblog
LOCAL_SRC_FILES := custom_decoder_jni.cpp custom_decoder.cpp
include $(BUILD_SHARED_LIBRARY)
the error is shown from custom_decoder.h when it is reading the includes of AOSP.
fatal error: DataSource.h: No such file or directory.
I haven"t included any AOSP .so in my project(as per Ganesh's suggestion in comment 2). Should I do that?
What else should I do to get it built......
You don't need to rebuild libstagefright.so to use it in your app. You can adb pull the library from your device, or even from an emulator.
Please note that libstagefright communicates with many components in /system/lib, some of which are specific to SoC vendor (e.g. Qualcomm) or ODM (e.g. Samsung). Some uses of Stagefright may require quirks specific to device. This is why OpenMAX IL has not been officially exposed on Android. On the otehr hand, OpneMAX AL has been officially supported since November 2011.
At any rate, libstagefright cannot be directly accessed from Java. If you are looking for a Java solution for video communication, you should first look at the excellent libstreaming library.
The advantage of using libstagefright comes usually when you have you your native (C/C++) library that only has to be connected to an efficient codec.
Here is a nice answer on a related question about Android hardware decoder.
To answer your specific queries,
libstagefright.so is built and installed at /system/lib
I presume you are employing the libstagefright.so in native code. With this assumption, you don't have to copy. I presume you are building your module as a loadable library i.e. .so file. Hence, if you can identify the dependency on libstagefright.so through LOCAL_SHARED_LIBRARIES as well as including the header files, it should be more than sufficient for building your module. Please refer to this example of building a FLAC encoder where similar dependencies have been handled.
By application, if you are referring to a Java application which interacts with a JNI layer, then point 2 should be more than sufficient. However, if you are creating a native layer application, I would recommend you to follow stagefright command line utility's makefile.
Related
I have developed an application and a native library for Android. The native library uses openSL ES for audio processing.
In my Android.mk file I have the following statement:
LOCAL_LDLIBS := -lOpenSLES
So I'm guessing that this means that the application will dynamically link in the openSLES library from the device's system/lib folder at the time when the application is loaded/executed on the device?
The problem I'm facing is that the libraries on the device are buggy and I have 3 updated libraries which contain the bug fix. If possible, how do I make sure that my native library is using the 3 libraries I have:
Libwilhelm.so
libOpenMAXAL.so
libOpenSLES.so
Do I just replace
LOCAL_LDLIBS := -lOpenSLES
with
LOCAL_SHARED_LIBRARIES := -lOpenSLES -lOpenMAXAL -lwilhelm
As long as you target a specific device or a very limited set of devices, the proposed solution is good enough. But if your aim is a public app, which will be installed on different platforms, including future 'N' version of Android, and customized ROMs, including e.g. Samsung, you should be careful with the system dependencies of these libraries.
While OpenSLES and OpenMAXAL are innocent (they only depend on liblog and libwilhelm), the latter requires more care.
Looking at its Android.mk, libwilhelm depends on liblog libutils libmedia libbinder libstagefright libstagefright_foundation libcutils libgui libdl libeffects and libstagefright_http_support.
Only liblog and libdl are "official" (i.e., part of NDK). The others depend on platform, and their exported functions may be incompatible for different devices running same platform level.
To be on the safe side, I would only introduce the fixes, and keep using the system version of libwilhelm when possible. I hope you can reduce your system dependencies this way.
I'm writing an app that should use functions from tinyalsa through ndk, I just want to call functions defined by tinyalsa like pcm_open() from my native functions implementations.
I have tried following the documentation about using prebuilt libraries in Android/ndk/docs/PREBUILTS.html but I can't get it working.
Could you please tell how could I do it?
Thanks
I could do it, the process is the next:
Copy tinyalsa.so to ~/Android/ndk/platforms/android-18/arch-arm/usr/lib
Copy asoundlib.h to ~/Android/ndk/platforms/android-18/arch-arm/usr/include
Platform-18 is the one I'm using. It can be specified in Application.mk with the line
APP_PLATFORM := android-18
After adding it to the ndk platform include it in the file where the native functions are implemented
#include <asoundlib.h>
Tell the compiler that we are going to need this library. In Android.mk
LOCAL_LDLIBS := -ltinyalsa
This worked for me :)
The problem:
I have a native Android application that is compiled for x86 and arm, armv7a.
The app also links to a pre-shared library.
That pre-shared library is also compiled for x86, arm, and armv7a. So there are 3 lib.so files.
What must I do in the Android.mk/Application.mk to link to the appropriate *.so file given the architecture it is being compiled for?
That is, when the build system is compiling for arm, it should link to the libs/armeabi/lib.so.
Likewise, when the Build system is compiling for x86, it should use the libs/x86/lib.so file.
I believe the alternative might be a more complex build script but I'm shooting for the simple solution first, if it exists.
Thanks!
The answer
Unfortunately my query skills were not very good and shortly after posting, I found the question and answer already on SO:
How can i Link prebuilt shared Library to Android NDK project?
To summarize:
Prebuilt shared libraries, compiled for different platforms, should all be named the same and go under the jni/${ARCH}/ directory.
That is, the structure should appear as so:
jni/x86/libtest.so
jni/armeabi/libtest.so
jni/armeabi-v7a/libtest.so
You should use the $(TARGET_ARCH_ABI) flag, for example:
include $(CLEAR_VARS)
LOCAL_MODULE := mylib-prebuilt
LOCAL_SRC_FILES := ../path_to_prebuilt_folder/libs/$(TARGET_ARCH_ABI)/libmylib.so
include $(PREBUILT_SHARED_LIBRARY)
I think this problem started when upgrading to the Juno Eclipse. I believe the C/C++ build environment was probably upgraded as well at the same time. The NDK was not upgraded.
We have a large mass of C code that compiles under several platforms. We are using the crystax-ndk (r6) to compile our C++ code. To know when we are compiling for Android, we have defined the following in the Android.mk
LOCAL_CFLAGS := -DANDROID_NDK \
-DDISABLE_IMPORTGL \
...
Then in some files we will include different headers depending upon the platform
#ifdef ANDROID_NDK
...
Our code compiles just fine and seems to run fine. However, when opening certain files the C/C++ code analyzer will find many errors. This appears to be because the analyzer doesn't know about the ANDROID_NDK defined variable.
Any idea why the code analyzer is not using the same #defines as the compiler? The code is almost uneditable with all the bogus errors the analyzer is reporting.
I saw you're comment about the analyzer you were refering to.
Eclipse CDT (C/C++ Development Toolkit) does not support parsing Android.mk yet neither does the NDK plugin add that functionality at the time of writing this.
Possible (ugly/annoying) workaround: Set up a header file setting the defines you are missing and include that header file to all files.
Use LOCAL_CPPFLAGS for C++ files and LOCAL_CFLAGS for C files in your Android.mk
I want to create a Player which uses Android system/lib/libmedia.so.
Directly use JNI to play a video.
In Android.mk, i add "-lmedia" for including the library, but i can't link this directly.
This is my process.
write a Cpp file which includes some header file in libmedia.so
add "-lmedia" in Android.mk of LOCAL_LDLIBS
such as..
LOCAL_LDLIBS -lmedia -lstagefright
use ndk-build to build .so
error occured!!
Does anybody have some answer to help???
libmedia.so and libsinstructionght.so are not part of the public API. This means that in theory, you should not rely on them. In practice, though, these libraries are present on all devices, but they are different.
You can extract this binary file from your device, or even from an emulator using command
adb pull /system/lib/libmedia.so C:/android-ndk/platforms/android-14/arch-arm/usr/lib
This will put ths file together with the public API so that using it with ndk-build is easier. On the other hand, you should be aware of fragmentation not lnly between different levels of Android, but also chipsets, manufacturers, and even models.
To handle this, I pull .so files from different devices into separate directories, and add one of them to the linker path, e.g.
LOCAL_LDLIBS += -Lc:/android/galaxys.4.1.2.system.lib
This instruction above can not resolve the big problem you are facing with your approach. libmedia.so is not intended to be linked to user apps. It assumes the context of a privileged user with access to protected devices, such as camera, codecs, and screen.
You can make full use of this library if you target a rooted device, or prepare a custom ROM. And know what you are doing, and how to avoid stealing essential resources from the system.
Otherwise there is very little gain in linking the media lib.
PREBUILT_SHARED_LIBRARY
Points to a build script used to specify a prebuilt shared library.
Unlike BUILD_SHARED_LIBRARY and BUILD_STATIC_LIBRARY, the value
of LOCAL_SRC_FILES must be a single path to a prebuilt shared
library (e.g. foo/libfoo.so), instead of a source file.
You can reference the prebuilt library in another module using
the LOCAL_PREBUILTS variable (see docs/PREBUILTS.html for more
information).
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := foo-prebuilt
LOCAL_SRC_FILES := libfoo.so
include $(PREBUILT_SHARED_LIBRARY)
Refrenced from NDK documentation.
PREBUILT_STATIC_LIBRARY
This is the same as PREBUILT_SHARED_LIBRARY, but for a static library
file instead. See docs/PREBUILTS.html for more.
Please read the NDK documentation for more details.