Develop Reference

Can monodroid .so files be managed .NET code?

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.

Recompile shared Android library for Linux

I'm trying to use an SDK (provided by a third party, not Android SDK) for Android (ARM) that implements functionality in native code, unfortunately what I'm trying to do requires a central server as well. All I have is the compiled .so file (and a jar that interfaces to it), I know this is a reach but is it possible to recompile it to run on a normal Linux (x64) box?
I figure it probably wont work cuz of differences between JNI and Android NDK interface but I thought I'd ask here before I throw in the towel on the idea.

First of all Android sdk contains .jar files only and no .so files.
The .so files to which .jar is linked to is already present in devices as a part of Android OS.
So for linux, compile the Android source code for x86 and you will get all the .so for x86.
Once you compile the android source code it also creates sdk for the respective architecture.
But I think .jar should be same for all architecture as java is architecture independent.

Android app is native or JavaVM code?

Probably an stup!## question.
I dont know nothing about developing apps for Android, but I was wondering if the applications for Android, when they are compiled, the code generated is PURE ANDROID NATIVE CODE, or is Java Virtual Machine compatible code.
Thanks a lot.

It has its own virtual machine, Dalvik.

Most apps for Android are Java apps. They are compiled to .class files by the Java compiler, then the dx compiler takes the .class and compiles them to .dex files, which are executable by the Dalvik VM on Android (which is the Java VM).
Although the Dalvik VM is made to run Java code, it is significantly different than the standard Java VM on your computer. The standard VM is a "stack based" machine, whereas the Dalvik VM is "register based".
You can also make apps with the NDK, and write them in C or C++. This is not Java compatible in any way (although you can interface the native C code with the Java code with JNI).

There are at least three ways to do it:
All Java
All Native
Half Java, half native. Android libraries can be written in C and compiled into native code, then called from Java. Your application could be a mix of both, if you wish.
More info: http://en.wikipedia.org/wiki/Android_software_development#Native_development_kit

Android-Ndk vs Cross-Compile? Both work, but what was the need of Android NDK then?

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.

What is Android and why did they create a new VM?

Android's embedded OS relies on the
Linux kernel for core system services
but is not embedded Linux and thus
standard utility libraries like for
example GNU C are not supported. The
Java framework is used to write
Android applications but Android is
not Java. Standard Java libraries such
as Swing are not supported.Android has
a Virtual Machine known as Dalvik, so
when the Java class files are
generated, this are translated to
Dalvik Executable files known as .dex
files. From this point this files are
not treated as java bytecode but as
.dex files.
So I have three questions:
Now I know what Android is not,
so, what is Android?
What are
core system services?
Why did they choose .dex files
upon Java bytecode? I mean why did
they took the work to translate or
combine .class files to .dex files?

The What is Android? article on the developer site describes best what Android is.
Why did they choose .dex files upon
java bytecode? i mean why did they
took the work to translate or combine
.class files to .dex files?
That is because they needed a more efficient virtual machine. Their virtual machine called DalvikVM was optimized for low memory requirements.
You can read more about the DalvikVM in this Wikipedia entry. Make sure to checkout the external links section on that page.