Switch commoncpp2 to ucommon to solve dependency conflicts.
libccrtp was depending on commoncpp2, and have been replaced by a version
depending on ucommon as well.
diff --git a/jni/libucommon/sources/README b/jni/libucommon/sources/README
new file mode 100644
index 0000000..873b2f9
--- /dev/null
+++ b/jni/libucommon/sources/README
@@ -0,0 +1,82 @@
+GNU uCommon C++ is meant as a very light-weight C++ library to facilitate using
+C++ design patterns even for very deeply embedded applications, such as for
+systems using uclibc along with posix threading support. For this reason,
+uCommon disables language features that consume memory or introduce runtime
+overhead, such as rtti and exception handling, and assumes one will mostly be
+linking applications with other pure C based libraries rather than using the
+overhead of the standard C++ library and other class frameworks.
+
+GNU uCommon C++ by default does build with support for the bloated ansi
+standard c++ library unless this is changed at configure time with the
+--disable-stdcpp option. This is to assure maximum portability and will be
+used to merge UCommon with GNU Common C++ to form GNU Common C++ 2.0. Some
+specific features are tested for when stdc++ is enabled, and these will be used
+to add back in GNU Common C++ classes such as TCP Stream and serialization.
+
+GNU uCommon C++ introduces some Objective-C based design patterns, such as
+reference counted objects, memory pools, smart pointers, and offers dynamic
+typing through very light use of inline templates for pure type translation
+that are then tied to concrete base classes to avoid template instantiation
+issues. C++ auto-variable automation is also used to enable referenced objects
+to be deleted and threading locks to be released that are acquired
+automatically when methods return rather than requiring one to explicitly code
+for these things.
+
+GNU uCommon C++ depends on and when necessary will introduce some portable C
+replacement functions, especially for sockets, such as adding getaddrinfo for
+platforms which do not have it, or when threadsafe versions of existing C
+library functions are needed. Basic socket support for connecting to named
+destinations and multicast addresses, and binding to interfaces with IPV4 and
+IPV6 addresses is directly supported. Support for high resolution timing and
+Posix realtime clocks are also used when available.
+
+While GNU uCommon C++ has been influenced by GNU Common C++, it introduces some
+new concepts for handling of thread locking and synchronization. GNU uCommon
+C++ also builds all higher level thread synchronization objects directly from
+conditionals. Hence, on platforms which for example do not have rwlocks,
+barriers, or semaphores, these are still found in uCommon. A common and
+consistent call methodology is used for all locks, whether mutex, rw, or
+semaphore, based on whether used for exclusive or "shared" locking.
+
+GNU uCommon C++ requires some knowledge of compiler switches and options to
+disable language features, the C++ runtime and stdlibs, and associated C++
+headers. The current version supports compiling with GCC, which is commonly
+found on GNU/Linux, OS/X, BSD based systems, and many other platforms; and
+the Sun Workshop compiler, which is offered as an example how to adapt UCommon
+for additional compilers. GNU uCommon C++ may also be built with GCC cross
+compiling for mingw32 to build Microsoft Windows targets natively. The cmake
+build system can also be used, to create project files for various platforms
+including xcode for OS/X and various Microsoft Visual Studio project file
+formats.
+
+The minimum platform support for uCommon is a modern and working posix pthread
+threading library. I use a subset of posix threads to assure wider portability
+by avoiding more specialized features like process shared synchronization
+objects, pthread rwlocks and pthread semaphores, as these are not implemented
+on all platforms that I have found. I also eliminate the practice and
+dependency on pthread automatic cancellation behavior, which otherwise
+introduces much greater complexity to user applications and can often lead to
+defective coding practices.
+
+The first three releases of uCommon were introduced in 1999-2000 as a pure "C"
+library for embedded targets, and had not seen an update in 7 years. Hence I
+have had the package name in use for a very long time. Work on what became
+uCommon C++ 0.4 was originally intended as a refactoring effort for GNU Common
+C++ to better support IPV6, and became something different as entirely new code
+was written in 2006. I originally hoped to release GNU uCommon C++ in March of
+2007 as a new package under the GNU GPL V3, but the license was unavoidably
+delayed. GNU uCommon C++ will merge code from and replace GNU Common C++ in
+future releases.
+
+GNU uCommon C++ is a linkable library distributed under the GNU General Public
+License, Version 3 or later. As of version 2.0, we are now using the GNU
+Lesser General Public License, Version 3 or later, to remain consistent and
+compatible with past GNU Common C++ licensing. A new release series of GNU
+uCommon C++ is 2.1 involved refactoring the abi release from prior 2.0.x
+releases, offering greater clarity, consistency of use, and some new features
+that were migrated from Common C++.
+
+To better focus on standardizing secure and runtime services, uCommon was
+somewhat simplified in release 3.4. ccscript is now part of GNU Bayonne,
+and ccaudio has been separated again.
+