android ndk: cannot find android_runtime - android-ndk

I have a problem when compiling JNI. It returns the error message like
that "arm-eabi/bin/ld: cannot find -landroid_runtime".
I think libandroid_runtime.so is the android's own lib. Why ld can't find the
lib. Can somebody help me.
My develop environment as follow:
OS: Ubuntu 9.10
SDK: Android2.2
NDK: r4b

libandroid_runtime.so is in fact one of the Android system libraries, and as such is not available for NDK apps.
Check the file docs/STABLE-APIS.txt for a list of supported libraries, or even better, check the folder build/platforms/android-#/arch-arm/usr/lib where # is the Android platform level, for the definitive list of libraries you can link against.
As they say on the NDK lists, even if you manage to link against one of the other Android libraries, it likely won't work on some (or possibly even most) phones, even if it works on the one you're testing.

To solve your problem build a emulation of every android possible and recompile a version for each android and put it on the market with specific compatibility.
EDIT: Try using: adb pull /system/lib
EDIT 2: There also should be a egl folder in /lib so you know to look for it.

Related

macOS cannot verify the developer of "clang"

I updated to macos-catalina and I am trying to crosscompile c++ code for android using android-ndk-r18b
macOS cannot verify the developer of “clang". Are you sure you want to open it?
It asks me for all different executables/compilers (e.g arm-linux-androideabi-ranlib). I got around this by got around it by going to Security & Privacy and allowing all executables that show up there. Is there a more generic way to authorize everything within the android ndk?
Open `System Preferences/Security & Privacy/Developer Tools.
Allow Terminal app to run software locally that does not meet system's security policy
This was essentially answered in the comments by Dan Albert, but to add an actual answer, as per android ndk issue 1060:
For macOS, the SDK manager is the most reliable method of acquiring the NDK for most use cases and should be preferred until something else changes. That is not viable for all users, but if it is an option for you that's your best option.
In other words, if you install/reinstall an NDK using SDK manager, you should end up with a version that gatekeeper will be happy about, e.g.:
android/Sdk/tools/bin/sdkmanager --install "ndk;18.1.5063045"
The best way is to update the ndk to R21. if your Macos version is catalina.
"No Mac NDK before NDK r21 was signed or notarized."
Download and install the Mac App Bundle version of the NDK available since r21 from this page.

Which (if any) NDK libraries/headers are compatible with other toolchains

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.

How to use NDK with Android Studio to compile a Linux .so to Android .so platform

I have installed Android Studio and would like to use Linux .so to
recompile and make it Android .so.
I have searched around and all examples show a ready make .c compile to .so and reuse that .so, in the Android Studio. This is not in my situation, I only have Linux .so without the .c file.
By referring from multiple websites, I made a JNI folder and put it along with gradle/build folder OR under app\src\main. It is OR because many developers put them at either location. I have no idea which is the correct version both the locations I have tried and it does not make any change to the project (no libs folder generated).
Some suggested that the Linux .so cannot be reused for Android .so because of platform difference, however, some also suggested it is possible without further explanation or example.
Would anyone here know how to do it?
Specifically:
Steps for creation of JNI folder and its location (I know how to create JNI folder, just not sure about the location)
How to call the .so and write codes to re-compile it? (Need
MainActivity or not, how does the code looks like)
ndk-build setup and the path/project settings
Thanks. Lee
You can't. The people that told you that platform differences will prevent it were right.

Running J2me apps on Android phones

Is it possible to run J2ME apps on Android phones? If so, what is the installation procedure?
Otherwise, is it possible to convert .jad files to .apk? In this case, what is the procedure.
(I have already tested the procedure offered by netmite but it doesn't seem to work.)
Using this site http://www.netmite.com/android/srv/2.0/getapk.php you can convert your J2ME application in to Android Application. You need to just supply your .Jad & .Jar file in it and it will generate Android's executable file .apk for you.
However in it doesn't able to convert all the feature of Java ME to Android, but basics can be easily converted.
You can try phoneME, netmite j2me app runner, jblend, jbed like jeme emulators in android. For now, phoneME is the best. you can get various version of phoneME here http://davy.preuveneers.be/phoneme
You also need OI file manager to select files in phoneME.
A complete guide can be found here http://w3epic.com/run-java-apps-j2me-on-android-devices-guide/ for rest of other emulators (if you want to try).
#dennis
I got it, thanks.
MicroEmu open source project hasn't been mentioned yet, and here it goes: https://code.google.com/p/microemu/
I searched for a good JavaME emulator for Android for a long time, and finally found one. This here is what you need:
http://davy.preuveneers.be/phoneme/
No doubt the best there is for Android.
Added 15th January 2016:
Reply from the author of phoneME, Davy Preuveneers, in regards to the Android 5.0+ issue commented by Álvaro Gutiérrez:
Hi,
I am testing on a Samsung Galaxy S4 running Android 5.0.1, and the
"phoneME Advanced - Foundation Profile + MIDP FullHD Resolution" build
seems to run just fine on this device.
Also, following this thread
Position Independent Executables and Android Lollipop,
I ran:
$ readelf -l libcvm.so | grep -i "file type"
and it reports:
Elf file type is DYN (Shared object file)
So according to the website this is OK.
However, for the CDC and Foundation profiles (console like
applications), there is indeed an issue where you get this error:
"Error: only position independent executables (PIE) are supported"
However, for those 2 profile I call a native executables and redirect
the native stdout/stderr streams to Android, whereas for the MIDP dual
stack I load a library and create a complicated wrapper to get things going.
I can recompile with -fPIE and -pie options but will then end up with
binaries that are no longer backwards compatible with devices running
Android 4.0 and below. That is why I added some additional builds to my
website for Android 5+ devices:
http://davy.preuveneers.be/phoneme/?q=node/10
Best regards,
Davy

Android 4.0 unpacks the wrong eabi for included library

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

Resources