isabella232 / dleyna-collabora-android Goto Github PK
View Code? Open in Web Editor NEWThis project forked from intel/dleyna-collabora-android
License: Other
This project forked from intel/dleyna-collabora-android
License: Other
+-------------------+ | dLeyna in Android | +-------------------+ This is (1) a collection of native libraries ported for use in Android applications, (2) an Android application that runs various unit tests of the native libraries, and (3) an Android application that demonstrates dLeyna functionality. Native Libraries ---------------- Dleyna depends directly or indirectly upon the following native libraries: gupnp-dlna gupnp-av gupnp gssdp libsoup libxml2 glib (glib, gio, gmodule, gobject, gthread) gettext (libintl) iconv libffi The remote locations of the library sources, the dependencies between them, how to configure and build them are all described using JHBuild. See modulesets/android-native.modules. The "standalone toolchain" from the Android NDK is used to build the libraries. A convenient script allows you to specify the target architecture (arm or x86) and Android API level you want to build for, as well as the version of the cross-compiler from the Android NDK to use: [ARCH=<arch>] [API_LEVEL=<level>] build.sh [<cmd>...] where <arch> is 'x86' or 'armeabi' (default 'x86') <level> is an Android API level: 3,4,5,8,9,14 or 19 (default '19') <cmd>... is a JHBuild command and args (default 'build gupnp-dlna') The result of the build will be left in a subdirectory named install-<arch>-android-<level> which might be, for example install-x86-android-19 Test Native Libraries --------------------- This is an Android app that incorporates a large number of the unit tests from the native libraries. It allows the user to select which tests to run, then sequentially runs them, each in a pristine process. While a test is running, the user can abort it and skip to the next one, or abort all the tests. Before building the test app, you have to make a copy of the configured library source code into a directory with a name that contains the target architecture and api level (because some of the unit tests include internal header files that aren't built out to the install directory). So for example if you're building for x86 and api level 19, you must do the following: cd NativeLibs cp -r sources sources-x86-android-19 After doing so, you need to check the correct architecture is selected in TestNativeLibs/jni/Application.mk You should be able to switch freely between armeabi and x86 (tested). Now, the building process is a several steps one (we might automate some of this in the future). First, you need to make sure the test app is correctly configured for your target Android's API version. Ideally you'd run this on TestNativeLibs/ each time you change API versions while building the NativeLibs (And for that, the first time you build). Although this is not always required, it certainly doesn't hurt: android update project --name testnativeapps --path . -s --target "android-19" Example above is for API level 19 as you might have guessed. The final step is building the application .apk install package. You do this from the TestNativeLibs/jni directory, issuing the following command: NDK_DEBUG=1 ndk-build The example above would generate debugable native code. You can (and maybe should) skip the NDK_DEBUG=1 for production builds. Last step is generating the Application's .apk package from the TestNativeLibs directory: ant debug (Again, this generates a debug apk) The resulting apk file can be found in TestNativeLibs/bin/ Some of the unit tests expect various resource files to be on the target device. So before running the test app for the first time on a given device, you must do cd TestNativeLibs ./InstallResourceFiles [<device>] where <device> is the name of the device as reported by "adb devices" (only required if more than one device is visible to adb). As a final step and for installing the application to a device, connect it and issue the following command: adb install TestNativeLibs/bin/<your application name>-debug.apk Notes on adding tests to the TestNativeLibs application ------------------------------------------------------- Here is an outline of what you would need to do to add a new unit test: 1) Copy the unit test source from NativeLibs to TestNativeLibs. For example: cp NativeLibs/sources/libsoup-2.40.3/tests/socket-test.c \ TestNativeLibs/jni/libsoup-2.40.3/tests 2) Edit the copied source to rename the function "main" to something unique. For example in socket-test.c you might rename it to "socket_test_main". 3) Add the test case to TestNativeLibs/jni/tests.c. Here you specify the renamed main entry point, that same name in Java style, and any args to pass to the main entry point: DEFINE_TEST(soup_socket_test, soupSocketTest, "--debug") 4) Modify TestNativeLibs/jni/Android.mk to add the new unit test. For example LOCAL_SRC_FILES := \ ... $(MY_LIBSOUP)/tests/socket-test.c \ Also, add a proper defintion for your static library module at the begining of the file. Like: # <modulename> include $(CLEAR_VARS) LOCAL_MODULE := <modulename> LOCAL_SRC_FILES := ../../NativeLibs/install-$(TARGET_ARCH_ABI)-$(TARGET_PLATFORM)/lib/... include $(PREBUILT_STATIC_LIBRARY) Use the ones already there as a basis and adapt it as needed 5) Still on TestNativeLibs/jni/Android.mk. Locate the module definition for dleyna_jni and add your library and library tests include paths to LOCAL_C_INCLUDES as: ../../NativeLibs/install-$(TARGET_ARCH_ABI)-$(TARGET_PLATFORM)/include/<library_headers_dir> \ ../../NativeLibs/install-$(TARGET_ARCH_ABI)-$(TARGET_PLATFORM)/include/<library_headers_dir>/... \ ../../NativeLibs/sources-$(TARGET_ARCH_ABI)-$(TARGET_PLATFORM)/$(MY_<MODULENAME>) \ ../../NativeLibs/sources-$(TARGET_ARCH_ABI)-$(TARGET_PLATFORM)/$(MY_<MODULENAME>)/tests The example above relies on you declaring a MY_<MODULENAME> var at the begining of the dleyna-jni module declaration so you can use it later and avoid having to repeatedly enter your library tests and library's top level include directory. Again, use the already present entries as a model. Last modification you need to perform to this file is to add your <modulename> to the LOCAL_STATIC_LIBRARIES list at the end of the deleyna-jni module section. 6) Modify TestNativeLibs/src/com/intel/dleyna/testnativelibs/Tests.java to add the new unit test: public static native void soupSocketTest(); ... SOUP_SOCKET_TEST("", new Impl() { public void exec() { soupSocketTest(); } }), 7) If the new unit test requires any resources on the device, add them to TestNativeLibs/ResourceFiles and run InstallResourceFiles as described above. Dleyna Demo App --------------- Work in progress...
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.