Are NDK features OS dependent? For example, if I have Gingerbread 2.3, can I only use NDK features for 2.3 and below, or can I take advantage of the latest fixes and features the NDK provides?
The main reason I'm asking is because it seems like the NDK is a completely different beast than the SDK, and due to the nature of C/C++ and the underlying internals of the OS should be cross version compatible.
Unfortunately it is as version-dependent as SDK. Each release of NDK bundles an ever-growing list of platforms. Typically, ndk-build chooses the platform according to android:targetSdkVersion as defined in AndroidManifest.XML.
Related
I'm using Fedora 27 as my Operating System, and I'm wondering if I could get the Xamarin toolset working on it to create cross platform apps with an IDE like monodevelop, VS Code or Rider.
I heard Xamarin get's new templates for Xamarin.Forms for Linux, but I can't find any recent development news about that.
Yes, as of mid-2018, it is somewhat possible to develop a Xamarin.Forms app under MonoDevelop on Linux. I successfully managed to do it.
Basically, you need to have at least two things:
A shared library project, containing all the cross-platform Xamarin.Forms code and Xaml files. For some reason, on Linux this library project have to be compiled with .NET Core toolchain and not Mono toolchain (otherwise there is some GTK issues at runtime later on). The target framework is .NET Standard 1.0 or .NET Standard 2.0, and the main dependency is the NuGet package "Xamarin.Forms".
A Mono/GTK# platform-specific project for Linux, containing all the platform specific code: initialize GTK and Xamarin.Forms.Platform.GTK backend, and start the Xamarin.Forms code. The dependencies are the NuGet package "Xamarin.Forms.Platform.GTK", references to locally installed GTK# of your linux distribution (gtk-sharp, atk-sharp, etc...), and obviously a reference to the shared library project. Note that only GTK2 is supported and not GTK3.
The shared library project may be developed with MonoDevelop, Visual Studio, or JetBrains Rider. Note that with MonoDevelop, there is no XAML designer... so this is easier to do the design stuff with Visual Studio on Windows.
The platform specific project may be developed using MonoDevelop or Rider on Linux.
Here is a picture of the project structure under MonoDevelop:
There is a "HelloWorldXamarin" library project. It uses the .NET Core toolchain targeting .NET Standard 1.0, and have a dependency to NuGet package "Xamarin.Forms"
There is a "HelloWorldXamarin_Linux" project. It uses the Mono toolchain targeting Mono/GTK# for Linux, and have dependencies to GKT# and HelloWorldXamarin library, as well as dependency to NuGet package "Xamarin.Forms.Platform.GTK". You can see the platform specific code on the right.
And a picture of the result:
So you can now develop cross-platform Xamarin.Forms GUI applications for Windows,Mac,Linux,Android,iOS...
Yes you can and how well it will work on Fedora I'm not sure, but it looks like development is still in progress for the GTK Backend on Linux. For more information, there's a Github repo here that shows how far along it is and how you can try it yourself.
I'm working on a project that is compiled using the arm-linux-musleabi toolchain which builds against musl libc. What are my options to use NDK features such as Android jni.h? Am I wrong when assuming that jni.h on Android NDK is not the same as standard jni.h that targets actual Java? I know porting the project to NDK could be the best approach, but let's assume that its not possible for my case. In other words, 'build using NDK' is not an option even though it would be the wiser path. Also note that JNI features are just used as an example, this question applies to any Android NDK c/c++ libraries that may be used as a drop in with non-ndk toolchains.
I'm testing a script to build a shared object from the command line. According to NDK Downloads, the latest download is android-ndk-r10e (I thought this was an old download).
However, when I check for android-23 I see there's nothing available:
$ echo "$ANDROID_NDK_ROOT"
/opt/android-ndk-r10e
$ ls "$ANDROID_NDK_ROOT/platforms"
android-12 android-15 android-18 android-3 android-8
android-13 android-16 android-19 android-4 android-9
android-14 android-17 android-21 android-5
Is the NDK for Android 6.0, which I believe is android-23, not available? Or maybe something else I don't quite understand.
(I'm concerned about the major version bump, and the breaking changes it encompasses, like when the rand function was changed and broke things).
There are no new native APIs in 6.0, so there is no need to have that target available in the NDK - it would be identical to the ones for 5.1 and 5.0.
When building with the NDK, the target platform is picked as the latest one that actually exists prior to the one you've chosen to target (and the earliest one, for ABIs that were introduced later).
Keep in mind that "target API" behaves quite differently between Java and native code. If you build your native code with one target API level, chances are that the code won't run on older versions at all - see e.g. https://stackoverflow.com/a/27338365/3115956 and https://stackoverflow.com/a/27093163/3115956.
So unless you want to try to manually load and use new functionality on some platforms if available, you should just set the target version (APP_PLATFORM in jni/Application.mk) to the lowest version that you want your code to run on, i.e. corresponding to minSdkVersion.
From my understanding, the NDK is in a separate "stream" of development with releases less or more frequent than the Android platform itself. You should be able to develop a NDK app for android-23 devices without any problem, Google probably just did not have time yet to update the NDK release for android-23.
Looking at the revisions, r10e was released a while ago, but the truth is that it is also the latest version as of today.
Here is the situation: I've built a native library for re-distribution in other apps. Because we're using ARMv7 NEON, we ship two versions of the library: One for most devices and a "fallback" limited capability version for ARMv5/ARMv6. So far so good and this has worked well.
However, for some reason a newly created app running on a Nexus S with Android 4.0.3 is picking up the wrong (armeabi rather than armeabi-v7a) version of the library.
If we dig into the device filesystem, we find that /data/app/my_app.apk contains the correct versions of the library. However, when Android extracts it to /data/data/my_app, we find that /data/data/my_app/lib/my_lib.so is the armeabi version. But, strangely, /data/data/my_other_app/lib/my_lib.so is the correct armeabi-v7a version.
So the questions are:
1) WTF??
2) How does Android decide which eabi to extract from the APK?
Yes, this is known bug in ICS - it chooses wrong library.
Read about it here:
http://www.moodstocks.com/2012/03/20/ice-cream-sandwich-why-native-code-support-sucks/
https://groups.google.com/d/msg/android-ndk/N8FLjvM81pg/2rYeClQZcckJ
I wanted to convert a small test application from Windows .NET 4 to MonoTouch but I am missing System.IO.MemoryMappedFiles.
Then I tried it with a plain Mono console app and the namespace isn't there either.
I tried Mono 2.10 in combination with MonoDevelop 2.4.
Is it supposed to be there or not? I'm kind of confused, as .NET4 compatibility was announced with Mono, as far as I know.
Mono 2.10 has some support for memory mapped file. However it is not 100% complete (and Windows-specific things like security are not likely to be ever included) so YMMV.
You can browser what's available from the GIT repository:
https://github.com/mono/mono/tree/mono-2-10/mcs/class/System.Core/System.IO.MemoryMappedFiles
Since this is a .NET 4.0 feature you'll need to use the 'dmcs' compiler to get your code to compile (and also reference System.Core.dll where the types resides).
As for MonoTouch it provides a subset of Mono (originally based on the 2.1 profile from Silverlight and extra, even some 4.0, features). Currently (for MonoTouch 4.x) this does not include any type from System.IO.MemoryMappedFile.* namespace. Future versions will offer more .NET 4.0 features (if they are available from iOS).