I've noticed that I have some directories inside my android phone which look the same.
What the different between /sbin, /system/sbin, /system/bin, /system/xbin?
/system is the main Android directory for storing immutable components generated by the build of the AOSP. This includes native binaries, native libraries, framework packages, and stock apps. It’s usually mounted read-only from a separate image from the root file system, which is itself mounted from a RAM disk image.
Android also includes many directories commonly found in any Linux system, such as /dev, /proc, /sys, /sbin, /root, /mnt, and /etc. These directories often serve similar if not identical purposes to the ones they serve on any Linux system, although they are very often trimmed down, as is the case of /sbin and /etc, and in some cases are empty, such as /root.
More than 150 command-line utilities are scattered throughout Android’s root file system. /system/bin contains the majority of them, but some “extras” are in /system/xbin, and a handful are in /sbin.
/sbin: In Linux, this would hold binaries essential to the system administrator. In Android, it contains only ueventd and adbd.
/bin: All native binaries and daemons built as part of the AOSP. All modules built with BUILD_EXECUTABLE are here. The only exception is adbd, which has the LOCAL_MODULE_PATH set to /sbin and is therefore installed there instead.
/xbin: “Extra” binaries generated by some of the packages that are built within the AOSP but aren’t essential to the system’s operation.
Thanks goes to Mr: Karim Yaghmour , The great ; The author of Embedded Android tutorial.
Related
I have C Linux based application and now I want to port it to Android.
I figured out, that I can extract the toolchain from Android NDK and build my application, but how to make the APK such that I can install it on the android devices without the need of root access.
In Linux, I used to install it using a bash script which used to put my application related files in different folders like /opt, /etc (files shared with other applications) and /var . How can we handle this in Android. Is there a folder similar to /etc in Android where I can put files that other applications can read.
Thanks
-M
First of all, you are lucky if your project compiles "as is" with NDK standalone toolchain. Often, bionic is not enough, and people need to tweak the build environment (from libpthread to full-blown buildroot alternate toolchain with static C runtime).
As for the shared files location, on Android it's named "external storage". Your app and other app may require special permissions to write and read to this location. Directory /opt does not exist here. You don't have write access to /etc, but files like /etc/hosts are available for read.
Regarding the APK. You are right, this is the ultimate way to distribute and install apps on Android. But you can, even without root, to locally install and run a command-line executable. Usually it's done with Developers Options turned on, and enabled USB debugging. Now you can open an adb shell, install and run your program. The trick is that external storage (see above) is marked as 'non-executable'. Therefore, you must find another place for your binary. Usually, /data/local/tmp will be a good choice.
Instead of adb, you can use a terminal emulator on the device.
If you choose to build an APK, you will probably prefer to convert your app to shared library that will perform actions for Java via JNI. But it is also possible to package your command-line binary as part of the APK and use Java Runtime.exec().
Good day for you. I just started to learn and work with android kernel development or internals. I purchased a development board on-line that uses AM3359 - TI Processor. Works fine with factory Images and I booted from SD_CARD.
Later I read the documentation and I tried to compile the kernel. Everything went well as expected. I do have a little questions that I would like to clear it regarding the files that were created.
I had a section in documentation in which I was asked to Create a Root FileSystem which gave me a file called ubi.img - What is this file ?
Later I was asked to create a tarball file providing the roots path which created me an other file rootfs.tar.bz2 - What is this file ?
My question is... both the files used the files from rootfs directory to create these files. What are these files for? What exactly ubi.img does and what is it used for? Is it used for flashing it to nand and rootfs.tar.bz2 is to boot if I am booting from SD_CARD ???
Thanks & Regards
I don't know much about AM3359 - TI Processor, but on most smartphones and also in the linux kernel requires a ramdisk which is usually compressed mostly it's a .gz file.
According to my experience when the file is decompressed and usually it contains hardware initialization routines which the kernel runs first during startup.
The .img files are where everything is stored.
Most commonly :
BOOT.img - Read Only Contains ramdisk and
the rootfs this are usually zImage + rootfs.tar.bz2
System.img- Also read only although can be remounted as read+write Contains
the operating system files e.g binaries like su, busybox etc.
Userdata.img- This is where all the users data and settings are stored.
The above are all that's necessary to get a system up and running.But we might have others such as Uboot.img Preloader etc, it varies depending on the platform.
Environment
Windows (x64) Host
Android 5.0 USB connected to the Windows machine
Un-rooted Samsung Galaxy 5
Use-case
Java APK Application
Native C++ executable packed as a raw resource part of the APK
Upon startup executable is to be ~extracted~ to a temp folder where it would execute
Questions/Discussion
Is the above use-case supported by the Android OS?
To the best of my knowledge, '/data/local/tmp' is not accessible to a running app ( but to shell & root ), Is there a directory where the file can be extracted too and executed? ( dir must have execution rights )
What would be the best approach to achieve the above mentioned?
Yes, you can do this. You will need to make sure that the native executable is for the appropriate target architecture (some type of ARM processor, usually).
But you shouldn't extract it to /data/local/tmp. You will need to extract it to /data/data/application.package.name/lib, which is a directory to which your app has read/write permissions.
There are more details in this question and its accepted answer. It looks as though you can have the executable extracted automatically for you if you name it as if it were a library file rather than a standalone executable.
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.
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.