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.
Related
I am trying to build a project using NDK media sdk, but I need it to run on older phones too (to support 90% of the market...). Now, I am able to include the libmediasdk.so & libOpenMAXAL.so manually, and it seem to link properly, but I am not sure this is a correct practice.
Moreover, the libraries (libmediasdk.so & libOpenMAXAL.so) are expected to be available on the target device, so unless I do copy them manually to the project/libs/arch-arm the application complains libraries are not found.
Have I gone too far ? :) hope not..
You can write code that optionally uses the new native media functions (libmediandk.so), but you can only use it on Android 21+. So if you want to support older android versions, you must make this codepath optional, allowing it to fail cleanly on other devices where libmediandk.so doesn't exist.
If the MediaCodec APIs are optional within your app and you are ok with them only being available on Android 21+, you can just make sure you build this into a separate lib (like libyourapp-media.so), and be ready to handle the case when System.loadLibrary() for this library fails.
However, if you want to use other native code components in your app, there's a few gotchas you need to know. If you build your app targeting android-21 and your native code uses certain functions (such as atof), it will only run on android-21 or newer (even if code using the function atof would build just fine for the older platforms). The reason for this is that the atof function didn't exist before, and calls to it were redirected to strtod. If you build your library targeting android-21, it will actually do the calls to atof instead, which doesn't exist in the older platform versions. This also goes for quite a number of other functions, not only atof. See http://b.android.com/73725 for details on this.
Therefore, if you want to use the new native media APIs in a library that should be loadable on older versions (except for the native media APIs that obviously won't work on older versions), you need to build your native components targeting an older android version. You'd need to duplicate the media/* headers from android-21, but instead of linking to libmediandk.so (-lmediandk in LOCAL_LDLIBS), you'd need to load this library at runtime using dlopen.
If you need to do the same on older platforms as well, you should use the MediaCodec API in java (which you can call via JNI). Then, there's little point in doing all of this extra work just to use the native version of the API on Android 21+, when you can use the java API on all versions (it works from Android 16, and more reliably since Android 18).
Finally, I've got my Mac and tried to re-compile and run my project with Xamarin.iOs
Since, PCL is not yet supported, I had to create a copies of .sln and .csproj and replace references to MvvmCross-Binaries and it works (thanks, Stuart). I hope Xamarin will give more elegant solution soon.
However, I couldn't compile and run unit tests on Mac - Mono 4.5 is not installed, and I didn't find Cirrious.MvvmCross.Test.Core.dll.
So, is it possible to run this kind of unit tests on Mac or we just test it in Windows platform?
I believe you should be able to build and run the 4.5 assemblies using the latest mono 3 releases. Further, the latest mono alpha release should also contain 'proper' support for portable class libraries.
Alternatively, if you'd rather work off of stable xam releases, then you'll probably need to create your own version of a .net4 core test assembly - there are only 2 small classes so this shouldn't be too hard to do - https://github.com/slodge/MvvmCross/tree/v3/Cirrious/Test/Cirrious.MvvmCross.Test.Core
As well as on mac testing, I know some people also use the on device test runners - especially for iOS where the aot compilation makes on-device testing important.
I have a Visual C++ library which I want to compile for a certain platform (I try to compile POCO for a Win CE ARM platform, but that might not be relevant to this question). I got a vendor-specific Windows CE SDK (including all common Windows include files e.g. winbase.h) which is set as target platform within the Visual Studio project files. However, when I compile the program, I can see from the error log that the default Windows 6.0A SDK is used, resulting in a bunch of compilation errors.
I guess the WindowsSdkDir ist not set accordingly - I thought this would be automatically overriden when setting the target platform within Visual Studio.
So my question is: can I modify the WindowsSdkDir for a single project explicitly?
Thank you in advance
Which CE version, which VS version and on which Windows version? I know that I had problems installing CE5 and/or CE6 SDKs and getting them recognized by Visual Studio 2005 running on Windows 7 (64 bit). I don't remember the exact symptoms and fix, but you can test that by simply creating a smart device project for the target SDK.
If that is not the issue, there is also the pitfall with the target in both the project file (.vcproj) and the solution (.sln). You can change both independently from each other, up to the point where you compile the x64 debug version of a project in the win32 release version of the solution. Verify that these setting match.
Then, if you adjusted the .vcproj file to use your target platform (for which I personally would use a text editor), things should work. If you need to adjust the build or some paths, you can sometimes get by with e.g $(Platform) in the compiler/linker settings.
Lastly, if all that doesn't work, there are property sheets, which can adjust certain settings. You then create a property sheet once and then load it into the project that you want to compile. I'm not sure if you can change the target platform or the SDK paths with that approach though, and I'd rather try to find out why the SDK doesn't work and how to fix it instead.
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.
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