Xamarin apk on Blackberry (>= 10.2.1) - android

To convert a native Android .apk to a Blackberry .bar does not seem to be a problem.
However, I have an Android .apk (API 15) that I implemented using Xamarin. I am able to convert the file to a .bar file using the BB10 Sideloading Tool, but when I run the app on the Blackberry simulator, I get the error messages:
android_update_LD_LIBRARY_PATH not found; .so dependencies will not work
and later
FATAL EXCEPTION: main java.lang.UnsatisfiedLinkError: Library cannot be found at java.lang.Runtime.loadLibrary(Runtime.java:361)
etc...
I am not really sure what steps can fix this errors.
Is it basically possible to run Xamarin-created .apk-files on Blackberry?
Would it maybe help to turn on the switch "Bundle assemblies into native code" in the Android Build options? For this, I would have to upgrade to Enterprise, but if it helps...

Correct me if I'm wrong, but I'm pretty sure Xamarin works with building your code as a native (as in NDK) library for Android, and a small Java glue to load and run the code from this library.
Two things to note here: the simulator runs a x86 instruction set, when your library is probably built for ARM. Won't work.
For a real device, you'll have to check that every library needed by yours is present on a BB10 device, which is not guaranteed as far as I understand: http://developer.blackberry.com/android/apisupport/android_native_support.html

Related

Delphi 10.4 Sydney: How can I build and run an Android application with SDK/NDK version different from the official one?

We are currently migrating from Delphi version 10.2 to 10.4.2.
We ran into a problem with an android application: apparently, Delphi 10.4 no longer supports android 4.4.2 kitkat.
Embrarcadero support suggested us to follow this blog and try to replace SDK and NDK with the older versions certified for Delphi 10.2: https://delphiworlds.com/2020/09/manual-android-sdk-ndk-install-delphi/
We have carried out several tests and have managed to build and run a simple application using Delphi 10.4 on a tablet with Android 4.4.2.
Unfortunately we still have a problem: when we tried to add a TClientDataset (or anything else that would need MidasLib) to our test application, we got a lot of compilation errors.
By following the tips found on "https://github.com/grijjy/JustAddCode/issues/2", we have managed to reduce the errors to six errors (You can see them in the second attached file "Post_fix_errors_log.txt"), but still cannot successfully build the application.
The last step with which we managed to reduce errors to just 1 was to replace the file "libmidas.a" located in "\Lib\android\release" folder, with the one we had on Delphi D25, but there is still that one error preventing us to successfully build the app.
The error is the following:
*
[DCC Error] E2597 C:\Work\PlatformSDKs\PlatformSDKs\android-ndk-r9c\toolchains\arm-linux-androideabi-4.8\prebuilt\windows\bin\arm-linux-androideabi-ld.exe: error: cannot find -lc++_static
C:\Work\PlatformSDKs\PlatformSDKs\android-ndk-r9c\toolchains\arm-linux-androideabi-4.8\prebuilt\windows\bin\arm-linux-androideabi-ld.exe: error: cannot find -lc++abi
[DCC Fatal Error] F2588 Linker error code: 1 ($00000001)
Does anyone have any idea how we could build an application using "MidasLib" with Delphi 10.4.2 and make it run on android 4.4.2?
Is that even possible?

Android NDK built library crahes on devices but runs fine in emulator

I want to make DSP calculations by native code. This works well within the emulator (Android 4.2.2). But on several devices (Android 7 and 9) the lib built by the NDK let the app crash directly on executing System.loadLibrary. But: a downloaded lib loads without problems when I put it into my APK.
I confess, for the main app I am using an old Eclipse IDE on Windows, targeting for API 26. My NDK is a small r7, running on Ubuntu. But my lib only makes calculations on byte arrays in standard c, no Android things are accessed here.
The native code compiles free of warnings and errors and is built for armeabi and armeabi-v7a. In the APK the libxyz.so files are in the correct folders. The names of the export functions should be correct. But even if there are no declarations for them in the Java class and nothing native is called, the crash directly occurs on static { System.loadLibrary("libxyz.so"); }
Can my lib binaries be incompatible?
Thanks for any help!
Update: The libs indeed were incompatible, see comments below.
Finally I could read the logcat from a device (by command line adb, in Eclipse this was not working). The problem seems to be caused by "text relocations" in the binaries.
Logcat: "java.lang.UnsatisfiedLinkError ... dlopen failed ... libxyz.so has text relocations"
Updating to a newer NDK (9) fixed the TEXTREL bug. Now System.loadLibrary and calling the native methods works on newer APIs. So I had to install 1,4 GB of NDK for calculating things in standard c.

Android/Boost.log application crashes at startup

I am trying to integrate Boost.Log in a QT/QML project that has to work on Windows, Linux and Android. While Win32 and Linux versions work like a charm, Android is giving me a few headaches.
I was able to build Boost library following instructions at https://github.com/moritz-wundke/Boost-for-Android.
However,
If I link my application statically to boost libraries, I get a bunch of linker errors, complaining that symbols are not found. Error messages are like: "error: undefined reference to 'boost::log::v2_mt_posix::core::get()', I get ~60 of them and I checked many times the file paths
If I link dynamically to boost, I can successfully generate my APK (the relevant .so files are included) but it crashes upon startup, both on a real device and on Android emulator
I'm new to Android development so it's entirely possible that I'm missing some key step here and I'm not really sure on what information may be relevant to provide here. Hope that someone can help.
I tried building with both ndk 20 and 21, Boost 1.70, Android SDK 26.
I plan to use QT 5.12 but did not add any QT code yet. I used QT Creator 4.10.2 (Windows) and 4.11.1 (Linux)

Android NativeActivity that references a dynamic library fails to deploy

The environment...
I have a brand new Visual Studio 2015 Android NDK Solution.
This contains 2 projects (the default template code that is generated by visual studio):
A native activity. This is where I want to put Android specific code. It has some default code which fades the screen colour between green and black.
A 'Packaging' project to help with deployment.
I have deployed this successfully to an Intel HAXM virtual device as well as to a real device connected via USB. All good so far.
I then added an Android dynamic library project (.so) - this is where I want to put core code (platform agnostic).
I added a reference to this Core library from the native activity project.
Everything compiles and links fine. I can still create an .APK file.
Other info:
Android SDK 5.1 (Android-22)
Android NDK 21
x86
Clang 3.8
C++ 11
Not using Make files or Gradle
The problem...
Now whenever I deploy to the virtual/real device I get the following error (taken from logcat)
java.lang.RuntimeException: Unable to start activity ComponentInfo{com.NATester/android.app.NativeActivity}: java.lang.IllegalArgumentException: Unable to load native library: /data/app/com.NATester-2/lib/x86/libNATester.so
Things I have tried...
changing the Core library to static (.a)
checked the android device to see if the file exists - it does exist.
Manually deploying the .APK to the android device.
Some articles have suggested using Java code to load the libraries - I want to avoid calling Java code e.g. System.LoadLibrary as this seems like a hack - I feel that it should be possible to to have a pure C++ application on android. I can't be the only person to run into this issue?!
This looks relevant but old and again an unnecessary hack for what must be very common situation
- Can't load native shared library with dependencies in a native activity app
- https://github.com/ikonst/android-dl
For what its worth, I am a seasoned C# developer with Visual Studio (15 years).
I therefore take a lot of things for granted when developing apps - this is my first project using C++/Android and it seems more of a manual battle to get everything to work!
Been struggling for a while but managed to deploy the libraries, quite easy in the end.
Right click on the project [theProject (Andorid-xx)] in the Solution Explorer and select add new item, add your .so library.
Right click on the newly added library and select properties, item type should be library, set Content to Yes, this will deploy the lib.

Generate core dump in android

I'm developping a android's aplication using some shared
libraries written by me and compiled with ndk-r5b. The application works,
y and the calls to the libraries works too, but I detected some errors,
segmentations faults, and I need to debug it, but, I don't know how debug
native code from android and I don't know if I can generate core dumps,
as in linux, for debug my libraries.
Any idea?
The ndk comes with ndk-gdb, which supposedly allows you to debug native applications. Also, if you download the whole andriod open source project, they also have some version of gdb used for debugging. Look in the docs/ folder of the ndk to learn about using it. This tutorial might also prove helpful: http://vilimpoc.org/blog/2010/09/23/hello-gdbserver-a-debuggable-jni-example-for-android/
However, as shown in a recent question I asked: Running ndk-gdb with package not found error on motorola phone I still can't get it to work.
Edit: You said in the comments you were using a Samsung Device: Samsung decide to wreck havoc on some of the crucial internals required for native debugging, but it's easily fixable if you have root access to the device. If you use the --verbose flag, you'll probably find that the error is different than that, a package unknown error. That's because it's looking in /data/system/packages.list, but samsung renamed that file to /dbdata/system/packages.list. So if you make a symlink to that file in /data/system/packages.list, (requires root access) it should work. Or at least so claims the ndk mailing list: http://osdir.com/ml/android-ndk/2011-03/msg00036.html

Categories

Resources