Is the .so files generated by Xamarin Monodroid (libmonodroid.so and libmonosgen-2.0.so) managed code or native code? From this SO post it appears they are actually .NET IL binaries (not native machine code). An answer even suggested the Xamarin.Android binaries is JIT'ed and can be opened in any .NET decompiler. However, this doesn't seem to work with dotPeak or ILSpy based on my investigation.
However, this other post on another SE site appears to contradict this. It should be noted that they are referring to Android NDK in general.
So, should the native library be opened on a .NET decompiler or dissembler such as Hopper and IDA Pro (giving you assembly code)?
Those files, libmonodroid.so and libmonosgen-2.0.so are native libraries and are the core libs of Mono and Xamarin.Android, these of course are based upon the ABI/ARCH types that you are supporting within your APP.
Xamarin.Android application packages have the same structure and layout as normal Android packages, with the following additions:
The application assemblies (containing IL) are stored uncompressed within the assemblies folder.
Native libraries containing the Mono runtime are also included and provide a parallel runtime to the Android Runtime (ART) and the bridge to talk from/to MONO <-> ART.
In Xamarin.Android 5.1 and above, you have the option to AOT your assemblies like Xamarin.iOS does always due to Apple's requirement of no JIT/dynimically generated code on iOS. This option for Android is defined in the Packaging Properties and by default is false. So for assemblies that have been AOT'd, machine code based on ABI/ARCH type has been generated and replaced the APPs C# IL.
Related
I always struggle to understand what is Mono Android and how it is was different from Xamarin.Android.
If Mono was there then why Xamarin.Android came into picture?
Thank you.
Xamarin.Android as a product name (formerly "Mono for Android") is the encompassing standalone package that includes an MSBuild-based build system not just for .Net/Mono compilation but also for the Android SDKs/Tools, Mono Linker, APK construction, .Net/CIL-based bindings for the Android APIs, etc...
This includes a mobile-optimized Mono runtime that is an Android-based NDK binary that supports the Android OS runtime on Intel and ARM processors.
Thus in this context, Mono is "just" the Android runtime for the CIL, JITter and supplier/host of the Java Dalvik/ART VM within the Xamarin.Android package.
Mono Android and how it is was different from Xamarin.Android.
Personally a lot of people I know still use the older "MonoDroid" product name as do I. Mono for Android, MonoDroid, Mono.Android, Mono Android, Xamarin.Native for Android, etc... again lots of semantics for the same thing. I still call Xamarin.iOS as its original MonoTouch name.
I built a library(.so) that is being called from JNI code in some android app. The JNI code is built using NDK.
If I build the library using android tool-chain, the library works well when called from JNI code.
If I build the library using another tool-chain (used on the same ARM device for none android applications), the library crashes when called from JNI code.
why do we need to use android tool-chain (or NDK) for compiling c/c++ code running in the context of an android app? why not use other tool-chains?
You can use other toolchains, but it requires special care.
Maybe a good starter would be to learn the UBERTC and Linaro Wiki.
The main difference is that NDK compilers are tuned for bionic (Android variant of C runtime libraries). Originally, bionic was a modest subset of Linux runtime. On latest platforms, most of the gap is closed, but now there are many extensions that you probably need.
Also, Android dynamic linker may require (depending on target platform) a set of ELF flags that are automatically delivered by NDK binutils, like PIC, id, and others.
It is quite possible to use arm-linux toolchain to build a statically linked executable that will run on Android, but for a library that must play well on the JNI environment the effort is probably not worth it.
Note that NDK provides tools to create a standalone toolchain, which behaves very similar to other toolchains you may be familiar with. This approach makes it easy to adopt 3rd-party libraries with sophisticated build scripts.
I am trying to create a shared library, using Embarcadero's C++Builder and RAD Studio 10.2. I created a C++Builder "Dynamic Linked Library" project. When I specify the target platforms to build for, the only options are 32-bit Windows, 64-bit Windows, and OS X. I need to be able to build the library for the Android (Linux) platform as well. How can I accomplish this?
At this time, RADStudio (including Delphi and C++Builder) does not support the creation of custom .so libraries for Android (only consuming them). Per the documentation, .so files can be created for Linux (and .dylib files for OSX/iOS) by creating a Delphi-style Package instead of a Dynamic-Link Library.
RADStudio-created Android apps are compiled as .so files (because they are based on the NDK, so the real app is just a small Java stub class that loads and executes the .so at runtime), but that is the extent of Embarcadero's .so generation on Android. Compiling custom .so libraries for Android is simply not supported yet.
I work for an existing C++ project. This project serves as a component of a larger software.
This project is supposed to support multi platforms. With all the source code and header files, the code can be built under windows, Linux and Mac. And I have .dll, .so and .dylib files for reuse.
But how about iOS and Android? I read pages and pages but I still have no idea. I cannot see how those SO Q&As and blogs relate to my problem.
I can cross-compile any C/C++ application, statically link it Linux libraries and run it on Android. What was the need of an Android-ndk then? Android-ndk limits us to bionic which has a small subset of gnu libc. Isn't it a better idea to straightaway cross-compile applications and run them through Android shell? Is there any limitation to cross-compiling that I can't see? This URL : Can Linux apps be run in Android? answers my question to some extent but eventually leaves me confused and without clarity.
I think this is enough for Android-NDK
The Android NDK is a companion tool to the Android SDK that lets you build performance-critical portions of your apps in native code. It provides headers and libraries that allow you to build activities, handle user input, use hardware sensors, access application resources, and more, when programming in C or C++. If you write native code, your applications are still packaged into an .apk file and they still run inside of a virtual machine on the device. The fundamental Android application model does not change.
The NDK provides:
A set of tools and build files used to generate native code libraries
from C and C++ sources
A way to embed the corresponding native libraries into an application
package file (.apk) that can be deployed on Android devices
A set of native system headers and libraries that will be supported
in all future versions of the Android platform, starting from Android
1.5. Applications that use native activities must be run on Android 2.3 or later.
This thing you can not find in other cross-compilation with arm toolchain..
As mentioned in the link http://developer.android.com/sdk/ndk/index.html NDK is a companion for App development folk to create performance sensitive native code. NDK exposes some of the native implementation of Android which could not be found in the general Linux environments. Some of them include the Android/Bitmap, Android/nativeWindow etc. Using these Android natives applcation can speed up CPU intensive processes like some compression or decompression of images.
Even though the externally cross-compiled executables may run in the Android there no guarantee that versions of the standard library implementaions are the same. NDK provides a easier and Android compatible toolchain and other resources, using which is much easier to application developers than having to find a compatible cross-compiler for their usecase.