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
Related
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.
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!!!
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
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.
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.