In this tutorial we will see how to call a C++ library from a Mono for Android app. Out of sheer curiosity and in the face of pragmatism, instead of resorting to P/Invoke we will make use of Cxxi, a framework that is still in development and aims to improve the interoperability between C++ and Mono.

Native library

The native library that we are going to use is Boost.Geometry and, as in the past, we will limit ourselves only to boolean operations on polygons. This choice leads to difficulties due to the heavy use of templates in the library so, in order to export the features that we need, we will use the following class (which is inspired by KBool):

//
// Wrapper.h
//

#if defined(_MSC_VER)
    #define EXPORT __declspec(dllexport)
#else
    #define EXPORT
#endif

namespace ClippingLibrary
{


class EXPORT Wrapper
{
public:
    Wrapper();
    ~Wrapper();
    
    void AddInnerRing();
    void AddOuterRing();
    void AddPoint(double x, double y);

    void ExecuteDifference();
    void ExecuteIntersection();
    void ExecuteUnion();
    void ExecuteXor();
    
    bool GetInnerRing();
    bool GetOuterRing();
    bool GetPoint(double& x, double& y);

    void InitializeClip();
    void InitializeSubject();
    
private:
    class Implementation;
    Implementation* _pImpl;
};


}

In doing so the real and proper implementation of the library is completely hidden and Cxxi will have to deal only with class members that at the most expect two parameters of type double.

Moreover, to build the library for Android, it is necessary to modify the file

$BOOST_ROOT\boost\detail\endian.hpp

in this way:

#ifndef BOOST_DETAIL_ENDIAN_HPP
#define BOOST_DETAIL_ENDIAN_HPP

// GNU libc offers the helpful header <endian.h> which defines
// __BYTE_ORDER

#if defined (__GLIBC__) || defined(ANDROID)
# include <endian.h>

For further details about Boost on Android:

https://github.com/MysticTreeGames/Boost-for-Android

Ndk

Ndk (Native Developement Kit) is a set of tools that allow to build C and C++ libraries so that they can be used on Android. In particular, through Ndk we can carry out a cross-compilation. So, for example, a library built on Windows can be executed on an Android device.

First thing, it is necessary to prepare an Ndk project creating a main directory with any name and then a subdirectory that must be called jni. Then, inside the jni subdirectory, we create two new files that are required to configure the project.

The first file is Application.mk:

APP_STL := gnustl_static

APP_ABI := \
    armeabi \
    armeabi-v7a

• APP_STL, specifies the C++ runtime to be used.

  Ndk provides several runtimes with different characteristics and licenses. Given that we have Boost as dependency, C++ exceptions support is required. At the moment, the only runtime that has such capability is Gnu Stl, which is under Gpl v3 license. Also, we use the static version since we want to create only one library.

• APP_ABI, specifies the hardware architecture on which our software will run.

  If omitted the default value is armeabi.

The second file is Android.mk:

LOCAL_PATH := $(call my-dir)

include $(CLEAR_VARS)

LOCAL_MODULE := Native
LOCAL_SRC_FILES := Wrapper.cpp

LOCAL_CPPFLAGS += -fexceptions
LOCAL_C_INCLUDES := W:\Boost

include $(BUILD_SHARED_LIBRARY)

• LOCAL_PATH, specifies the path of the current Android.mk file and must be defined at the beginning. The macro $(call my-dir) returns the path to Android.mk itself.
• include $(CLEAR_VARS), resets various global variables and must be used in case the project is composed of several modules.
• LOCAL_MODULE, specifies the module name.
• LOCAL_SRC_FILES, lists the source files to be built. It must not contain header files.

  Note that in this example, Wrapper.h and its implementation Wrapper.cpp must be inside the jni directory.

• LOCAL_CPPFLAGS, lists the flags to be passed to the C++ compiler. fexceptions enables exceptions support, otherwise the following error should appear:

  $BOOST_ROOT/boost/numeric/conversion/converter_policies.hpp:162: error: exception handling disabled, use -fexceptions to enable

• LOCAL_C_INCLUDES, lists the paths where headers of dependencies like Boost can be found.
• include $(BUILD_SHARED_LIBRARY), specifies that the output must be a shared library.

At this point, the PATH system variable must include the path to the Ndk installation directory. We can open a shell or command prompt and go to the main directory of our Ndk project and, finally, launch the following command:

ndk-build

At the end of the build process, inside the main directory of the project there should be a subdirectory named libs, and this should be its content:

libs
+---armeabi
|       libNative.so
|
\---armeabi-v7a
        libNative.so

For every architecture specified in the Application.mk file there is a subdirectory with its version of the library. Note that the name of the file is libNative.so, where Native is the name of the module specified in the Android.mk file and lib is a prefix added for convention.

For further details it is advisable to refer to the documentation provided with the Ndk, expecially the html files OVERVIEW, CPLUSPLUS-SUPPORT, APPLICATION-MK and ANDROID-MK.

Gcc-Xml

Gcc-Xml is a tool that parses C++ code and generates an xml file containing a description of the parsed code. Then, the xml file can be used by other tools that need access to the structure of the C++ code, avoiding to tackle directly the complex parsing phase.

The development version of Gcc-Xml is still being updated. The source code can be checked out from the git repository according to the instructions on the download page, and it is ready to be used with CMake.

Note that Gcc-Xml requires the presence of a C++ compiler, the PATH system variable must include the path to the compiler, and if you choose to download pre-built binaries you must be sure that they support such compiler.

Once obtained the binaries for Gcc-Xml, we can execute the following command:

gccxml --gccxml-compiler gcc -fxml=Wrapper.xml Wrapper.h

• gccxml-compiler, specifies the compiler to be used.

  We opted for gcc but, for example, on Windows we could have used msvc10.

• fxml, sets the name of the xml file to be generated.
• Wrapper.h, in the end, is the name of the source file to be parsed.

Cxxi

Cxxi is a tool that enables the use of C++ libraries from managed code. In this regard, if you have not yet done so, it could be interesting to read this introduction that also lists some of the features that make Cxxi different from other solutions such as Swig:

CXXI: Bridging the C++ and C# worlds.

Here you can find the master branch:

http://github.com/mono/cxxi

However we are going to use this fork:

https://github.com/kthompson/cxxi

This is because some problems still present in the master have been solved in the fork, in particular with parameters passed by reference as in the GetPoint method seen in our Wrapper class.

The source code comes with a solution file (.sln) that can be opened with Visual Studio 2010 or MonoDevelop. As the result of the build process, we get two files:

• Generator.exe
• Mono.Cxxi.dll

But presently, in release mode, the name of the dll is CPPInterop.dll.

At this point we can feed Generator.exe with the xml file previously created by Gcc-Xml:

generator -abi=ItaniumAbi -ns=CxxiGeneratedNamespace -lib=Native -o=OutputFolder Wrapper.xml

• abi, specifies the abi used by our native library.

  The abi used on Arm seems to be based on the Itanium abi and moreover Ndk uses gcc as compiler so the value of the abi option must be set to ItaniumAbi. If we were trying to use a library built with Visual C++ from a Windows application, we should specify MsvcAbi.

• ns, specifies the namespace that encloses the files created by Generator.exe
• lib, is the name of the native library without the lib prefix.
• o, is the directory where Generator.exe puts the output files.
• Wrapper.xml, in the end, is the name of the xml file generated by Gcc-Xml

The first file obtained in our example is Lib.cs:

using System;
using Mono.Cxxi;
using Mono.Cxxi.Abi;

namespace CxxiGeneratedNamespace {

    public static partial class Libs {
        public static readonly CppLibrary Native = 
            new CppLibrary ("Native", 
                ItaniumAbi.Instance, 
                InlineMethods.NotPresent);
    }
}

The namespace is the same one specified in the previous command, and the name of the library and the choosen abi are passed to the CppLibrary constructor.

The second file is Wrapper.cs (slightly reformatted):

using System;
using Mono.Cxxi;

namespace CxxiGeneratedNamespace.ClippingLibrary {
    public partial class Wrapper : ICppObject {

        private static readonly IWrapper impl = 
            Libs.Native.GetClass<IWrapper,_Wrapper,Wrapper> (
                "Wrapper");
        public CppInstancePtr Native { get; protected set; }

        public static bool operator!=(Wrapper a, Wrapper b)
        { 
            return !(a == b);
        }
        public static bool operator==(Wrapper a, Wrapper b)
        {
            if (object.ReferenceEquals(a, b))
                return true;
            if ((object)a == null || (object)b == null)
                return false;
            return a.Native == b.Native;
        }
        public override bool Equals(object obj)
        {
            return (this == obj as Wrapper);
        }
        public override int GetHashCode() 
        { 
            return this.Native.GetHashCode();
        }

        [MangleAs ("class ClippingLibrary::Wrapper")]
        public partial interface IWrapper :
        ICppClassOverridable<Wrapper>
        {
            [Constructor] CppInstancePtr Wrapper (
                CppInstancePtr @this);
            [Destructor] void Destruct (CppInstancePtr @this);
            void AddInnerRing (CppInstancePtr @this);
            void AddOuterRing (CppInstancePtr @this);
            void AddPoint (CppInstancePtr @this,
                double x, double y);
            void ExecuteDifference (CppInstancePtr @this);
            void ExecuteIntersection (CppInstancePtr @this);
            void ExecuteUnion (CppInstancePtr @this);
            void ExecuteXor (CppInstancePtr @this);
            bool GetInnerRing (CppInstancePtr @this);
            bool GetOuterRing (CppInstancePtr @this);
            bool GetPoint (CppInstancePtr @this, 
                [MangleAs ("double  &")] ref double x, 
                [MangleAs ("double  &")] ref double y);
            void InitializeClip (CppInstancePtr @this);
            void InitializeSubject (CppInstancePtr @this);
        }
        public unsafe struct _Wrapper {
            public IntPtr _pImpl;
        }




        public Wrapper (CppTypeInfo subClass)
        {
            __cxxi_LayoutClass ();
            subClass.AddBase (impl.TypeInfo);
        }

        public Wrapper (CppInstancePtr native)
        {
            __cxxi_LayoutClass ();
            Native = native;
        }

        public Wrapper ()
        {
            __cxxi_LayoutClass ();
            Native = impl.Wrapper (impl.Alloc (this));
        }
        public void AddInnerRing ()
        {
            impl.AddInnerRing (Native);
        }
        public void AddOuterRing ()
        {
            impl.AddOuterRing (Native);
        }
        public void AddPoint (double x, double y)
        {
            impl.AddPoint (Native, x, y);
        }
        public void ExecuteDifference ()
        {
            impl.ExecuteDifference (Native);
        }
        public void ExecuteIntersection ()
        {
            impl.ExecuteIntersection (Native);
        }
        public void ExecuteUnion ()
        {
            impl.ExecuteUnion (Native);
        }
        public void ExecuteXor ()
        {
            impl.ExecuteXor (Native);
        }
        public bool GetInnerRing ()
        {
            return impl.GetInnerRing (Native);
        }
        public bool GetOuterRing ()
        {
            return impl.GetOuterRing (Native);
        }
        public bool GetPoint (ref double x, ref double y)
        {
            return impl.GetPoint (Native, ref x, ref y);
        }
        public void InitializeClip ()
        {
            impl.InitializeClip (Native);
        }
        public void InitializeSubject ()
        {
            impl.InitializeSubject (Native);
        }


        partial void BeforeDestruct ();
        partial void AfterDestruct ();

        public virtual void Dispose ()
        {
            BeforeDestruct ();
            impl.Destruct (Native);
            Native.Dispose ();
            AfterDestruct ();
        }

        private void __cxxi_LayoutClass ()
        {
            impl.TypeInfo.CompleteType ();
        }

    }
}

Here, again, we can note the namespace to which has been added ClippingLibrary, the namespace of the native library. Furthermore, the class takes the name of the respective native class, Wrapper. If there were more classes, there would be a file for each class.

Mono for Android

Through Mono for Android, C# developers can write apps for Android without the need to learn Java. The trial version has no time limits but only allows to deploy to the Android emulator. The installer downloads all the necessary, Android Sdk and MonoDevelop included.

To test our library we can execute the following steps (the description refers to MonoDevelop but the steps for Visual Studio are similar):

1. Create a new Solution called TestMonoDroid. Select a Mono for Android project type (actually only available under C#).
2. Add a new project to the solution and name it Cxxi. Select a Mono for Android Library Project type (only available under C#).

   We can't use the previously created Mono.Cxxi.dll, the project must be rebuilt to target Mono for Android.

3. Inside the Cxxi project add the same files found in the Mono.Cxxi project, in the original Mono.Cxxi source code.
4. Under Project Options, Build, General, check Allow 'unsafe' code.
5. Inside the TestMonoDroid project add a reference to the Cxxi project.
6. Add the files Lib.cs and Wrapper.cs, previously obtained with Generator.exe, to TestMonoDroid.
7. Add the libs folder, previously obtained with Ndk, to TestMonoDroid.
8. For every libNative.so file go to Properties, Build, and set Build action to AndroidNativeLibrary.
9. Modify Activity1.cs and add code for testing the library (see below for an example).
10. Build All.
11. From the Run menu, select Upload to Device.
12. Start an emulator and once the upload is done launch the TestMonoDroid app.

    Some problems could arise in this phase, in that case these resources may be of help:

    MonoDroid: Not connecting to Emulator

    MonoDroid: Running out of space on fresh Virtual Device?

    Unsupported configuration: ... armeabi-v7a-emu.so in Mono for Android v4.0

This is an example of how to use the library:

// ...

using CxxiGeneratedNamespace.ClippingLibrary;

// ...

        private static string RunTest()
        {
            var w = new Wrapper();

            w.InitializeSubject();
            w.AddOuterRing();
            w.AddPoint(0, 0);
            w.AddPoint(0, 1000);
            w.AddPoint(1000, 1000);
            w.AddPoint(1000, 0);
            w.AddPoint(0, 0);
            w.AddInnerRing();
            w.AddPoint(100, 100);
            w.AddPoint(900, 100);
            w.AddPoint(900, 200);
            w.AddPoint(100, 200);
            w.AddPoint(100, 100);
            w.AddInnerRing();
            w.AddPoint(100, 700);
            w.AddPoint(900, 700);
            w.AddPoint(900, 900);
            w.AddPoint(100, 900);
            w.AddPoint(100, 700);

            w.InitializeClip();
            w.AddOuterRing();
            w.AddPoint(-20, 400);
            w.AddPoint(-20, 600);
            w.AddPoint(1020, 600);
            w.AddPoint(1020, 400);
            w.AddPoint(-20, 400);
            w.AddInnerRing();
            w.AddPoint(100, 450);
            w.AddPoint(900, 450);
            w.AddPoint(900, 550);
            w.AddPoint(100, 550);
            w.AddPoint(100, 450);

            w.ExecuteDifference();

            return GetOutputString(w);
        }

// ...

Note that rings must be closed and outer rings must be clockwise while inner rings must be anti-clockwise.

Not very choreographic but it runs:

Conclusion

We have seen how to use a native library from a MonoDroid app. A more pragmatic approach would have excluded Cxxi in favour of a more mature solution (and in this specific case we could have avoided a lot of issues by using the C# version of Clipper). However Cxxi is an interesting project that can offer more than what we have seen here, and in the future it could become the standard solution for interoperability between C++ code and Mono so keep an eye on it.

Download

Support files (also contains Wrapper.h and Wrapper.cpp).

Notes

• Android 3.1 (Emulated)
• Android Ndk r7b
• Boost 1.49.0
• Cxxi kthompson-cxxi-1a9c3a8
• GCC_XML cvs revision 1.135
• Mono for Android 4.0.4.264524889 (Evaluation)
• MonoDevelop 3.0.1