I have ported a few useful free/open source tools to Android. One is Octave and the other is gnuplot. They work together in unison to provide Matlab like capability for free (as in speech) and free (as in beer). I have packed them inside apps in an interesting way. Specifically,
1) I include the executable and shared libraries inside the libs/armeabi directory. Have to give them funny name because of android naming conventions.
2) I create directories bin/ and mylib/. I give them full permissions.
3) I create links from bin/ to the executable in the unpacked lib/ directory. I give them the correct names and full permissions.
4) I create links from mylib/ to the shared libaries in the unpacked lib/ directory. I give them the correct names and full permissions.
5) I then use ld-linux.so.3 which is one of the libraries now in the mylib/ directory and the--library-path option to point at the mylib/ directory to launch the executable from the Android Terminal Emulator.
Octave works perfectly in all version of Android doing this, but gnuplot gives this error when I attempt to launch it when running Jelly Bean only:
error while loading shared libraries: gnuplot: failed to map segment
from shared object: Operation not permitted.
So, why would I have this error for one of these two executables made the same way? Why only in Jelly Bean? Also, on JB, if I make myself the super user, it all works again.
Any thoughts on how to debug? I have confirmed that all files are there and have the permissions that I intended they have.
Please help. You would be helping a free, open source, educational and useful app if you do.
The issue was with how the executables were compiled. They needed to be compiled with a cross compiler that properly supported newer arm devices. The compiler I used generated executables that would only work on a subset of arm devices. The issue was not with the different versions of android.
Related
My Android app includes a set of executables that are extracted to app directory (/data/data/%package%/) on the first run. It worked just fine if targeted to Android 28 (targetSdkVersion). Since November 2, 2020 it not allowed in Google Play and all the apps must target to 29. So it stopped working with permission exception.
What directory should executables be put to now?
PS. Some similar apps have the same issue.
https://developer.android.com/about/versions/10/behavior-changes-10#execute-permission
When targeting API 29 (Android 10 / Q) or above, it is not possible anymore to have execute permission for files stored within the app's home directory (data), which is exactly what you are describing (/data/data/%package%/).
This Android 10 modification was introduced in commit: https://android-review.googlesource.com/c/platform/system/sepolicy/+/804149 and was then confirmed officially by Google here: https://issuetracker.google.com/issues/128554619
This significant change is being discussed by various projects, in termux/termux-app#1072 for instance. One recommended and (hopefully) future-proof way is to extract program binaries into the application's native lib directory (with android:extractNativeLibs=true), where files can still be executed but are stored read-only for improved security.
Here are examples showing how to handle this change, in Termux with commit f6c3b6f in the android-10 branch or in this other project showing how to run the Erlang runtime on Android by exctrating all the files from a .zip archive into the jniLibs/"abi" subdirectory ("abi" being arm64-v8a for 64-bit ARM, armeabi-v7a for 32-bit ARM, etc.) with the imposed lib___.so filename format expected by the Android platform. Executable files can simply be moved in the right project folder manually, the important part is to use the lib___.so format for the filenames.
In the Android Manifest file, setting the attribute android:extractNativeLibs="true" will get these lib___.so files extracted at installation time in the right native lib directory, with support for execute permission. Symlinks can finally be created if needed in the usual app directory to use the regular executable names, instead of the harder-to-manipulate lib___.so versions.
Thanks, Jérôme
When I install my app on a genymotion simulater device,it can not be installed well,on console I got "INSTALL_FAILED_CPU_ABI_INCOMPATIBLE"
I trid another app,it installed fine.I do not know why.
The application (certainly a game) must be ARM only.
Genymotion is a x86 platform, so compile the application to target x86.
You may be able to install ARM support manually :
http://forum.xda-developers.com/showthread.php?t=2528952
If you are using IntelliJ it may be related to the project's default configuration. IntelliJ will assume, unless otherwise specified, that Native libraries will be stored in the Libs folder. This is usually where developer store their JAR libraries. IntelliJ build process will package up the JAR file into the Native file folder in the APK.
If you experiencing this problem, you can find a good How-to:
INSTALL_FAILED_CPU_ABI_INCOMPATIBLE Intellj
This helped to resolve the issue I had.
You might want to check out my answer here:
INSTALL_FAILED_CPU_ABI_INCOMPATIBLE on device using intellij
I know it's written for IntelliJ, but you could be running into a similar issue with Eclipse where it thinks that some normal Java files or jar libraries are native code and including it in the compiled APK. A quick way to find out is to open up the final APK (it's just a jar file, so most utilities should be able to decompress it) and make sure that the only things you see are META-INF, res, AndroidManifest.xml, classes.dex, and resources.arsc. It's possible that there are other valid files in a normal Java Android application, but in general if you see anything else in there, particularly a libs folder, it's probably the result of the compilation process thinking that those other things are native libraries (compiled C/C++ code using the JNI).
If this is the case, you'll need to configure Eclipse to not interpret the Java libraries you're using as native code. Now, I don't personally use Eclipse so I don't know where the proper settings would be, but based off of this answer, it looks like Eclipse automatically assumes that the libs folder in the root of your project contains native libraries. The easiest solution may be to move any Java libraries you are using into a different folder (such as libraries).
http://blog.iteedee.com/2014/02/android-install_failed_cpu_abi_incompatible-intellj/
The INSTALL_FAILED_CPU_ABI_INCOMPATIBLE error is generated when you attempt to install an android application on a device with an unsupported CPU architecture. This error is usually related to the native libraries that are not packaged up for the device’s CPU architecture (ie: x86, ARMv6, ARMv7, etc).
Now, if you have an application that doesn’t use any native libraries or *.so file you might be scratching your head on this one. If you use IntelliJ IDEA IDE for your android development it might be packaging all of your related .JAR file in to the Native Library file location in your APK.
The cause of the same problem was different in my case.
I had added some dependency jars in /libs directory of my Android app project. One of these jars had exported library in jar format; i.e. a jar within a jar file. I've noticed that the apk created using jars with such structure are incompatible with x86 based devices (don't know why).
I have two executables, both cross compiled to run in Android. I have put both on the device in the same directory. I have put all the shared libraries that they are dependent on in the same directory, including ld-linux.so.3. I run the executables by using:
ld-linux.so.3 --library-path /path/to/libraries executable_name
both work on older versions of Android when running as any user. The both work on the latest version of Android if running as root. Only one works on the latest version of android when running as any user. Instead it gives:
failed to map segment from shared object: executable_name operation not permitted
How can I find out what is different with the executable that won't run?
I read a lot online and most people that get this error, either:
A) don't have execute permissions for one of the libraries they are dependent on or the executable itself.
or
B) are trying to run from a directory that is mounted as NOEXEC.
both of these don't appear to be the case. It can find all libraries and I can load any library by itself and see what other things it is dependent on being resolved. Also, I can run basic scripts from the directories of interest.
The newer version of Android, Jelly Bean, is a different linux kernel version and I wonder if that is related.
What give? How do I debug?
Permission issue. Need to remount /tmp. The following command works for me (Centos 7):
sudo mount /tmp -o remount,exec
I had this error in a different context. For some reason it causes an error when trying to use the /tmp folder.
To solve this I simply:
mkdir tmp
export TMPDIR=`pwd`/tmp
The TMPDIR is a constant that tells where the temporary folder of the system is.
This solutions resolves by creating a directory where we are allowed to and settings this directory into the system. Therefore we can now write to the new system default temporary folder.
The issue was with how the executables were compiled. They needed to be compiled with a cross compiler that properly supported newer arm devices. The compiler I used generated executables that would only work on a subset of arm devices. The issue was not with the different versions of android.
SELinux is enabled by default on Android 4.3, however it is supposed to be "permissive" [0]. Maybe your phone vendor added more restrictive rules.
[0] https://source.android.com/devices/tech/security/se-linux.html
I have downloaded the android source code. And i want to make some modifications to the source code to embed some functionality which currently does not exist. But the problem here is that i am not able to understand how the source code is organised, what kind of files could be find where. So if someone could help me understand that it would be really helpful.
Here is short version of what you will find when you download the Android source. I will leave out some minor directories and dig deeper into a couple of the important ones. Basically what you will get (based on the current Ice Cream Sandwich release), in alphabetical order:
Bionic - the C-runtime for Android. Note that Android is not using glibc like most Linux distributions. Instead the c-library is called bionic and is based mostly on BSD-derived sources. In this folder you will find the source for the c-library, math and other core runtime libraries.
Bootable - boot and startup related code. Some of it is legacy, the fastboot protocol info could be interesting since it is implemented by boot loaders in a number of devices such as the Nexus ones.
Build - the build system implementation including all the core make file templates. An important file here is the envsetup.sh script that will help you a lot when working with the platform source. Running this script in a shell will enable commands to setup environment variables, build specific modules and grep in source code files.
Cts - the compatability tests. The test suite to ensure that a build complies with the Android specification.
Dalvik - the source code for the implementation of the Dalvik Virtual Machine
Development - projects related to development such as the source code for the sdk and ndk tools. Normally not a folder you touch when working with the platform for a target.
Device - product specific code for different devices. This is the place to find hardware modules for the different Nexus devices, build configurations and more.
External - contains source code for all external open source projects such as SQLite, Freetype and webkit.
Frameworks - this folder is essential to Android since it contains the sources for the framework. Here you will find the implementation of key services such as the System Server with the Package- and Activity managers. A lot of the mapping between the java application APIs and the native libraries is also done here.
Hardware - hardware related source code such as the Android hardware abstraction layer specification and implementation. This folder also contains the reference radio interface layer (to communicate with the modem side) implementation.
libcore - Apache Harmony.
libnativehelper - Helper functions for use with JNI.
(Kernel) - not part of the default source download but you can get access to this code either by downloading it manually or by adding the repository to the repo tool. Contains the sources for the Android version of the Linux kernel.
Out - the build output will be placed here after you run make. The folder structure is out/target/product/. In the default build for the emulator the output will be placed in out/target/product/generic. This is where you will find the images used by the emulator to start (or to be downloaded and flashed to a device if you are building for a hardware target).
Packages - contains the source code for the default applications such as contacts, calendar, browser.
Prebuilt - contains files that are distributed in binary form for convenience. Examples include the cross compilations toolchains for different development machines.
System - source code files for the core Android system. That is the minimal Linux system that is started before the Dalvik VM and any java based services are enabled. This includes the source code for the init process and the default init.rc script that provide the dynamic configuration of the platform
tools - Various IDE tools.
Beyond the above you also have the hidden .repo directory that contains the source for the repo utility. It also holds the manifest specifying what git repositories you want to track for this Android source project. If you have your own additions you could automatically track them by adding a local manifest here.
For modifications of the platform framework there are some instructions available in the device/sample folder of the source code tree. That will show you how to add APIs to Android without having to modify the core framework.
As a follow up to an earlier question (Android ioctl - root permissions and usage), is it possible to create a separate native executable and package it in an APK?
The app needs root access and isn't going into the Android marketplace, but I'd like to be able to install it without using a script that pushes an extra executable onto the device.
There is an easy way to package an executable into an APK, and let the system installer take care of unpacking this executable, see How to package native commandline application in apk?.
The trick (tested up to Jelly Bean 4.3) is to name the file "libmyexecutable.so" and put it into libs/armeabi of your Android project (I assume an ADT or ant build). The Package Manager will unpack the file to /data/data/your.package.full.name/lib (it's a symbolic link, for backwards compatibility reasons, so maybe in some future version of Android this will not work anymore) on the device, with executable permissions.
Note that the file has all read-and-execute permissions, so you can use Runtime.getRuntime().exec() or system() from other apps, too.
Update:
These days, you should use libs/armeabi-v7a for 32 -bit ARM executables, and you probably need to prepare 64-bit ARM version of the same executables, too.
You can put it into assets and copy it to the app's private directory on first run. After you set the executable bit, you should be able to run it.