Develop Reference

How is /dev populated for Android

I have a driver compiled and running on hardware running Android 4.3. By running, I mean 'insmod gipc' loaded the driver and it ran through initialization. It assigned the major number 243 to the driver as evident in the /proc/devices files. The example code application is looking for the following two files
/sys/class/gipc/gipc1/name
/dev/gipc1
How should these files be created? Android does not have mknod and does not support udev. I do not really need the file in /sys/class, but without the file in /dev, I cannot access the driver.

I ended up using the following functions, class_create(), device_create(), and device_create_file() to accomplish this. Not sure if there is a more preferred way, or a way of having the files automatically created.

Redirecting Filesystem Paths via LD_PRELOAD

I am trying to set up a working Linux ecosystem inside an Android terminal emulator, but without actually having root access. This means that I need to adjust every reference to e.g. /bin/sh in the source code of every program I'm trying to compile and use.
Setting LD_PRELOAD before starting an application allows me to modify the behaviour of libc functions, just like fakeroot does; so I might just write a library which redirects all syscalls with absolute path names (except /dev, /sys, and /proc for example) to the folder I have write access to.
This library would have to:
Rewrite all path names so they stay inside the fake root directory
Nevertheless allow references from outside this directory, because e.g. procfs will still provide system-absolute path names
Ensure that a child process does not accidentally unset LD_PRELOAD
But how well would this turn out? I'm no expert when it comes to low-level code, so:
How consistently could I emulate such a "faked root directory"? Am I doomed from the beginning by the kernel which won't cooperate?
How easy would it be for a process inside the "fake root" to accidentally break out of it? I'm not talking about deliberately trying to escape via assembler code.
Edit: Maybe this library could even serve as a replacement for libc, as long as I link all software I compile on that system against it?

Changing some system file values in Android failing

I am trying to change some sys values but I don't seem to be having much success.
In my case I am trying to change values of files in the folder
"/sys/devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-0:1.0"
e.g. the file bInterfaceClass which currently has value 09
My tries:
(In shell, as root)
chmod 777 bInterfaceClass
echo 07 >> bInterfaceClass
I didn't receive an error but when looking up the value
cat bInterfaceClass
It is still 09
Now looking up this file in Root Explorer, I can see that the last modification date of the file has changed, so my guess: something resets the value of such a sys file as soon as it changes. Can anyone shine some more light on this issue? How can I change the value?
Many thanks!

THIS IS HACKERY, you have been warned! :)
Instructions here are not generally found on the Internet, but can be great for testing interfaces and capabilities without significantly changing system code. THESE CAN BE USED TO ADDRESS ANYTHING WHICH IS BEING OVERWRITTEN without warning or cause. Using these, you can sometimes see based off of using dmesg ps and logcatwhat exactly is causing you so many problems, while testing a solution.
The is likely in the Kernel with things like this getting written over, maybe a system service or script internally. A quality perm fix would be in the /drivers folder of the kernel. I can only assume this is on a Beagle or Panda Board, maybe a Moto device. If it is Beagle or Panda, this will be easier (yay Linaro, AOSP support, big community!).
If this is something that does not need to Hold USB open, but merely have the desired number present you can try below:
Open up your boot.img and open he Root Disk/Ramdisk and finally one of your init..rc files. You can use this tool: https://github.com/dsixda/Android-Kitchen - requires Linux and a few packages, great tool!
If you are lucky, this will appear as part of the init.rc files (which you can check in-system) or in the /system/etc folder as one of the class main or core scripts.
You can declare the value you want if you look for it in the:
on init
Section of the init.platform.rc and look where
/sys/devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-0:1.0
is initialized,
then in the .rc file
chmod 777 /sys/devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-0:1.0/bInterfaceClass
write /sys/devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-0:1.0/bInterfaceClass 07
Then if doing that and initializing it as such does not hold by that alone, open the normal init.rc and add
on nonencrypted
write /sys/devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-0:1.0/bInterfaceClass 07
and also
on property:vold.decrypt=trigger_shutdown_framework
write /sys/devices/platform/omap/musb-omap2430/musb-hdrc/usb1/1-0:1.0/bInterfaceClass 07
as those two properties or functions will cover you at the end of the inits to set that property again (you already gave it 777 privilages earlier as part of the on init)
If you want something you can play with without flashing new Boot.img files:
Declare your script in the system/bin as a service in the init.platform.rc (don't worry most every .rc file is linked and includes each other) using:
service usbchanger /system/bin/sh /system/bin/usbchanger.sh
class late_start
user root
disabled
Then in the normal init.rc
on nonencrypted
start usbchanger
on property:vold.decrypt=trigger_shutdown_framework
start usbchanger
Your script will then become a constantly running service (you can do the same with a binary). This is totally a desired trait when doing debugging and testing new features/fixes because you can change the values and running commands while the system is open and does not require you to re-flash after every change. However, for production you should not have this going. Its bad code to do that generally when really, it should be in the kernel or core.

Can I bundle a binary utility and call it from app?

Is it possible to create a app and call a command-line utility from it (bundled with the app), like it could be with a desktop application in linux?
Example:
My app wants to load some files but needs them to be converted, so first it calls an utility with command-line (like "jpgconv -r -t image.png") to create converted copies. Is it technically possible on Android?

What you are trying to do is basically call the Android shell from your application and pass it a binary.
Android's shell doesn't seem to accept Intents, in which case it's not possible, and it's anyway severely limited, which is why most users who need a shell (which is a very small subset of Android users) install a separate shell application, as well as tune their filesystem appropriately.
You could however try to embed your binary using the NDK, since, for exemple, BusyBox is straight C.

Cooking Android

Can someone consider and evaluate my approach to customization of Froyo? I'm a beginner.
I've download the sources from Android website and i've successfull recompiled and run it on my (study) device.
Let's consider a trivial customization: on Settings activity the last choice is something like 'Info about the phone' but... my device is not a phone so i want to replace this string.
Once moved to [my froyo]/packages/apps/Settings/res/values i've edited the 'string.xml' file with the right value. At this point my problems begin...
Considering that i've the Java compiler, how can i recompile only the (i.e.) Settings apk and not the entire operating system (my solution has been to recompile the whole operating system)???
Once obtained the NEW Settings.apk, how can i upload it to my device substituting the previous (system) one? I've tryed 'adb install' with all the options but it fails; i've tryed 'adb unistall' on the previous (system) one but it fails as well. (my solution was to upload again the whole operation system).
In conclusion, how can i change a string from 'phone' in 'squirrel' without spending an hour? I want only to customize a little bit the system applications. I'd like to edit the source, try it on device and only once that all the customizations have been done recompile the operating system.

Okay lets start with the first question. To recompile a specific package you can just type
make <PackageName>
in your case it should be make Settings.
Then after the new package was compiled you will find it in the build directory.
copy the apk directly to the /system/app folder in your device and delete the /data/dalvik-cache/ entry for it and reboot the device, the new package should be loaded.
For making the /system partition writable you need to type
adb remount
But note that some Packages may have dependencies which might be needed for your customization. Something like the framework_res.apk