I'm trying to bind to an objective-c library with the btouch tool. Should I be binding to a library (lib.a file) built for the iPhone or for the iOS simulator? And what is the difference if any?
Also, does it make a difference if I bind to a debug build vs. release?
Using the iPhone or the Sim version of the .a file really matters when you actually build and run. The sim version of the library is built for the intel x86 architecture and the iOS device version is built for armv6/arvm7 so it is important to link against the version of the static lib that matches what your are targeting. You can make one big library that has both the sim and iOS device .a linked together. If you lookup on Google there will be some walk throughs on how to link the two together.
Related
I want to build a dll from all my package dependencies using mtouch. I have tried different options and failed.
Giving the root-assembly as my dll plus all packages gives me MT0052: No command specified
I think mtouch can not do that . From doc of Using mtouch to Bundle Xamarin.iOS Apps , you can see :
The process of turning a .NET executable into an application is mostly driven by the mtouch command, a tool that integrates many of the steps required to turn the application into a bundle. This tool is also used to launch your application in the simulator and to deploy the software to an actual iPhone or iPod Touch device.
It just transfers a existed .NET executable into an application ,can not help you bind library into an application .
You also can see the COMPILATION MODE doc of mtouch , there are four mode :
--abi=ABI
Comma-separated list of ABIs to target. Currently supported: armv6, armv6+llvm, armv7, armv7+llvm, armv7+llvm+thumb2, armv7s, armv7s+llvm, armv7s+llvm+thumb2. Fat binaries are automatically created if more than one ABI is targetted.
To use the LLVM optimizing compiler code generation backend instead of Mono's default code generation backend target one of the llvm ABIs. Build times take considerably longer for native code, but the generated code is shorter and performs better.
You may also instruct the LLVM code generator to produce ARM Thumb instructions by targetting one of the llvm+thumb2 targets. Thumb instructions produce more compact executables.
--cxx
Enables C++ support. This is required if you are linking with some third party libraries that use the C++ runtime. With this flag, mtouch uses the C++ compiler to drive the compilation process instead of the C compiler.
-sim=DIRECTORY
This compiles the program and assemblies passed on the command line into the specified directory for use with the iOS simulator. This generates a standalone program that is entirely driven by the C# or ECMA CIL code.
-dev=DIRECTORY
This compiles the program and assemblies passed on the command line into the specified directory for use on an iPod Touch, iPhone or iPad device. The target directory can be used as the contents of a .app directory This generates a standalone program that is entirely driven by the C# or ECMA CIL code.
mtouch not supports binding library , it just compiles a existed executable which already binded library .
By the way , if want to bind a third party library , official doc recommands you to use Binding iOS Libraries .
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 developing an app for API level 15+ that has some jni code and i'm wondering if there are devices with armeabi ABI (ARMv5) and API level 15+
Can i include only armeabi-v7a and x86 libraries and skip the old armeabi?
Android itself doesn't support ARM versions below ARMv7 from Android 4.4 (API level 19). Since Android 4.0 (API level 15), it doesn't support ARMv5/ARMv6 by default but can be modified to build for those platforms (see https://groups.google.com/d/msg/android-building/Q_gU1zb6DLc/Bq5QryioQ_kJ), and there are custom builds that run on ARMv6. I'm not entirely sure if there are any official, certified compatible devices that run such a combination (Android 4.0-4.3) though - there should at least not be any such certified devices running Android 4.4, since the compatibility definition document strictly requires ARMv7 from that version.
So in practice you should be pretty safe to skip it, but you might exclude some fringe third party ROMs by doing that.
See https://stackoverflow.com/a/28926267/3115956 for a similar answer to a similar question.
Can i include only armeabi-v7a and x86 libraries and skip the old armeabi?
No, iff app is to be used on old cpu based architecture devices.
And Yes, if we are sure that no customer have older than ARM7 cpu based architecture device.
In our case we purchased the Chilkat licence for one year and they happily supported with ARMEABI .SO files. Hence it is upto the use case. It is affordable for and organisation.
Also wants to share the contact point for Chilkat if anyone wants to contact them for help. Email them at -> support#chilkatsoft.com
Thank you and Happy coding!!!
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 need to extend the functionality of the android.hardware.Camera class and so I have written my own class and companion JNI library to meet my needs. If I place my JNI code and Android.mk file in the Android source tree and build the OS, my library builds and I can use it and the Java class in an application without any problems (on an evaluation module at least).
The problem is that I would prefer to build my JNI library with the NDK but I need several libraries that are not in the NDK (e.g. libandroid_runtime and libcamera_client).
Is it possible to use the NDK to access hardware such as the camera? If so, what is the proper way to get access to OS libraries?
You can access non-standard shared libraries from NDK, but that is undocumented and is not guaranteed to work on different devices. Vendors like HTC, Samsung and other can simply implement them differently.
Only proper way how to use functionality not available in NDK is to wrap it with Java classe/functions, and then use them from native code.