Hello everyone. I see a lot of very basic android questions floating around the forums, so I figured I'd give a VERY basic rundown of the android filesystem for those who don't know. (If you're even slighty experienced, this'll seem like a "duh" thread, you should skip this. This is for new people.)
Ok, to understand android, first thing you need to understand are the basic partition structures. There are 5 android partitions.
boot
cache
recovery
system
data
Before I get into the partitions, you'll have to understand what a mount point is. When you "mount" a drive, you are making it available to the system. On linux (and by extension, android), you need to have a mount point. This is a directory somewhere that serves as a path for the mounted filesystem. So for example, let's say I wanted to mount mmcblk0p1 to a temp directory to edit it. For this example I'll create a directory /data/temp. Now you'd mount mmcblk0p1 /data/temp. When you read the contents of the directory temp under the directory data, you'll see all the info stored on mmcblk0p1. Even something as simple as a flash drive needs to be mounted under linux. If you're an ubuntu user, usually it automounts to /mnt/name of device.
Now, when you boot android, the first thing it does is boot up the linux kernel (when you see the tmobile splashscreen, that's when the kernel is loading.) Next, it loads up the ramdisk. Both of these files are on the boot partition. (When you open up a cwm zip file, you'll see boot.img in there, that's where these reside.) There are two files on the boot partition. zImage (the linux kernel), and initrd.gz (the cpio archive containing the ramdisk.)
What is the ramdisk you ask? Well, very simply, it's the place where the root file system is loaded, and where the init.rc resides. The init.rc is the android startup script (again, basic analogy). If you'd really like to learn about android and how it works, this is the first file I'd start reading.
On to the partitions:
boot - Described above, containing the zimage and initrd.gz
recovery - this is where either the stock recovery or clockwork recovery is located. This is only accessed when entering recovery mode.
cache - You guessed it, this is where some parts of android cache it's file. (Not to be confused with the dalvlik cache, that's located on the data partition.)
system - this is where the system is located. (Esentially the rom you're flashing.)
data - this is the partition where all your installed apps go, as well as the location of a couple parts of the system, like the dalvik-cache and the batterystats.bin file. (Quite a few more, just givinig examples.)
So what does all this mean to you? Well, I see a LOT of people asking about wipes before installs, or asking about flashing kernels, this is why I took the time to explain this.
When you enter cwm, and do a backup, it creates 5 .img files on your sdcard. (One for each of the partitions mentioned above.) When you flash a kernel, it only replaces the boot.img, and a couple files in the system folder. Usually these are kernel modules like the wifi module, and any other modules that aren't compiled into the system. (Although most kernel builders build cifs.ko and all that right into the kernel so the modules aren't needed.)
When you flash a rom, it will always replace the /system and /boot partitions. The rest, that depends on the rom. If you'd like to know what your rom is doing, open up the cwm zip file, and go to meta-inf/com/google/android and you'll see 2 files. Updater-script and update-binary. Updater-script will tell you what it does on install. (You'll see it mounting the partitions it needs, what it does and doesn't format, and also it does a whole bunch of simlinks.) Simlinks, or symbolic links, are either files or directories that point to somewhere else. For example, let's say you are a user who uses ext-sd. What you do is create a simlink for /data that points to the ext3 partition on your sdcard. This way, anytime the system goes to /data it writes somewhere else. Most of the simlinks created in android are more for busybox commands, but that's for another post
If you'd like to see what your mount points are, from an android terminal emulator (or of course adb, but if you are experienced with adb chances are you don't need any of this info in the first place ), type mount. (You might need to type su first, hit enter, then mount). This will list all your mount info. If you'd like to know the actual device name of the mount point, you'd look here. On ours, for example, it's:
mmcblk0p24 is /system
mmcblk0p26 is /cache
mmcblk0p25 is /data
and so on.
Ok, finally, a couple other questions I see often:
Why does my system "hotboot"?
When a system hotboots, it means that zygote has crashed. This is the virtual machine that android runs in. So if you are using your phone, and you all of a sudden go back to the boot animation (NOT the splashscreen with the kernel logo), you just hot-booted. When an application allows you to hotboot all it does is the following command from inside linux: pkill zygote (or pkill -9 zygote).
How do I calibrate my battery?
The batter calibration is a file called batterystats.bin. This is located in /data/system. When you get to 100% charge, if you delete this file, it'll start over on the battery calibration. (There are also market apps to do this for you for the squeamish.)
Other notable files:
gps.conf
Located in the /system/etc folder. This has all the gps configuration, nameservers, and things like this.
build.prop
Located in /system
A lot of device info is stored in here. For more info, google it.
Hopefully this wasn't too mashed together and confusing. I tried to follow a logical order, but I've had way too much turkey and beer today, so I'll post this and let it fly.
Have a happy thanksgiving everyone!
Good stuff, thanks OP.
Powered by the SGSII....
Very very useful for someone like me who knows a bit here a bit there but not sure of the whole picture.
Thanks!!
this should be useful for alot of noobs!
Thanks so much for this, being new to android this is incredibly useful. Bookmarking!
Sent from my SGH-T989 using xda premium
This thread should help alot of new people that just joined this forum and that are new .
Very informative, thank you.
Related
I'm new to whole linux\android stuff. Didn't really used lunux, so my knowledge of shell scripting is around 0.
Anyway the stalling issue of galaxy is quit annoying. Fortunately Paul at Modaco has found a fix for that (beleve he had also had script for that to). http://android.modaco.com/content/s...298/got-the-stalling-problem-rooted-try-this/
The faster section\mount of the memory where the apps data should be copied is not so large, so you shouldn't place games or apps that use a lot of space. So you want only copy only a specific set of data.
I managed to create a shell script that will seek unlinked apps data directories in /data/data/ move them to faster storage partition /dbdata/data/ and link it back in /data/data. The apps directories that are exists in a ignore_list.txt will be skipped and not moved to /dbdata/.
!!! Be aware, use it at own risk !!!
Requirements:
Rooted SGS
ADB or terminal on SGS
SU
Busybox
how to:
1. download app_data_hack01.zip
2. copy context of app_data_hack01.zip to /sdcard/sd/Scripts
Remove or add directories that should remain in /data/data using in ignore_list.txt file
Execute using adb:
Code:
adb shell
su
sh /sdcard/sd/scripts/app_data_hack.sh
Using terminal on SGS
Code:
su
sh /sdcard/sd/scripts/app_data_hack.sh
in the terminal: "To proceed type [yes]:" type "yes" or "y" (without the quotes) to proceed..
To recover (move from /dbdata/data back to /data/data) use
Code:
su
sh /sdcard/sd/scripts/app_data_hack_recover.sh
Any feedback is welcome!!
tried it on XXJG3
systems runs much faster now with tons of applications installed
great work and nice instructions
Agree GREAT work, thanks
If I install new apps, they will be stored in the original /data/data right? And if I wanted to move them to /dbdata/data I just add them to the text file and run the script again?
psychedelic'd said:
If I install new apps, they will be stored in the original /data/data right? And if I wanted to move them to /dbdata/data I just add them to the text file and run the script again?
Click to expand...
Click to collapse
You can just run the sript again. You add to ignore text file directories that shouldn't be copied.
It would be great if everyone will post the directory names of apps that shouldn't be stored in /dbdata/ (apps that occupied a lot of space or somithing...)
wow this is good. much more friendly for newbies and linux illiterates like me than those bits and pieces found at modaco.
cheers!
Development
Often we have people post rubbish in the development section because the simply carnt be bothered to go to where their information belongs, e.g. Q&A... however in this case i think a very fine peice of developing has been done and would be seen my many more if used to the development section. Therefore i am asking if a mod could please move this thread, and also well done
Just a thought BTW, instead of everyone messing with this dbdata partition, why done we just increase the size of the partition so we done have to SQUEEZE our big apps in a very small space? Seems much more simple...?
sunwee said:
wow this is good. much more friendly for newbies and linux illiterates like me than those bits and pieces found at modaco.
cheers!
Click to expand...
Click to collapse
Glad it helped and found easy to use!
bratfink said:
Often we have people post rubbish in the development section because the simply carnt be bothered to go to where their information belongs, e.g. Q&A... however in this case i think a very fine peice of developing has been done and would be seen my many more if used to the development section. Therefore i am asking if a mod could please move this thread, and also well done
Just a thought BTW, instead of everyone messing with this dbdata partition, why done we just increase the size of the partition so we done have to SQUEEZE our big apps in a very small space? Seems much more simple...?
Click to expand...
Click to collapse
I wasn't sure where to post as it's not really an development of something new but only a tweak of existing...
As for increasing the partition size, it would be indeed great, but how and if it's possible? Could it be done PIT file using Odin 3?
Yes
Yes from what i know the PIT file contains the partition structure so if this file can be adapted to create a larger /dbdata partition then this should in theory be possible.
bratfink said:
Yes from what i know the PIT file contains the partition structure so if this file can be adapted to create a larger /dbdata partition then this should in theory be possible.
Click to expand...
Click to collapse
That's interesting, but kind off-topic.. Odin seems to be able to interpret pit files, so on web should also be more info available...
Didn't see much on this as I was looking around today, so I decided to post my eventual fix:
After first setting up froyo on my Rhodium 400, I was having alot of issues with the phone running out of memory and crashing, so I ended up adding a swap partition. Below is an easy way to do this and have the swap mounted at boot without having to use an external app like swapper:
NOTE - before doing this I suggest that you copy rootfs.img from your SD card onto your computer, and then copy it back once you're finished. I also suggest you make a backup copy of rootfs (rootfs.img.backup etc) before trying mods like this so you can recover your file system if something goes wrong.
on a linux machine, make a mount point and mount the kernel image as a loop device:
Code:
mkdir /mnt/mounthere
mount -o loop rootfs.img /mnt/mounthere
cd into mount point you created (ie, cd /mnt/mounthere) and list the contents with ls. You'll see something like this:
Code:
acct dbgfs init.cfg mnt shared_prefs
bin default.prop init.etc proc sqlite_stmt_journals
cache dev init.rc res sys
config etc installer sbin system
d init lib scripts tmp
data init.android lost+found sdcard ueventd.rc
you want to open the script init with a text editor like nano and add the following lines just before the line that says exec /init.android:
Code:
modprobe ramzswap
swapon /dev/block/mmcblk0p2
where /dev/block/mmcblk0p2 is a pre-created linux swap partition on your SD card.
Once you're done, simply unmount rootfs.img and copy it back onto the SD card you're using for android
Its a pretty simple solution that I've found to make my own phone much more stable and responsive, and you only have to worry about it once. The downside is that on slower sd cards, the phone may slow to a crawl when installing apps, but hey, it beats the phone locking up and crashing back to windows mobile, right?
This really is not needed if you are running the latest versions of everything (and using XDANDROID). If you are experiencing problems with the full official latest version of everything (all info is in the thread in my sig) make sure you post in the ANDROID section
This guide is based on a guide by Candanga on the i9000 forums, and some commands from supercurio
Please hit thanks on their posts and show them some love for the write up.
-----------------------------------------------------------------------------------------------------------------------
I’ve compiled a quick guide to instruct how to make a copy of the /efs folder. I’ve found in many threads suggestions about backing up this folder but the methods itself are very general. Most of the times they suggest to “root and copy the folder” with Root Explorer or similar, but usually it’s not that easy or it just doesn't work for everyone.
This guide ASUMES you have read this Excellent Guide by Darkstrikerfirst:
H E R E <-- Make sure to read the ADB Guide.
I recommend doing this with a Mobile just taken out of the box or with any Official ROM of its Service Provider. If you have already Flashed your phone with another ROM but its working fine, then you can use that /efs also.
Why the /efs folder?
This is a very sensitive system folder that contains Phone-specific information such as the IMEI (encrypted in the nv_data.bin), wireless devices MAC addresses, product code (also in the nv_data.bin), and much more. Often users trying to change product codes or trying to unlock the mobile will end up corrupting data in this location.
Why back it up?
Well, let’s resume it saying that backing-up this little folder will keep you away from Samsung service centres.
***WARNING: I take no responsibility to any damage caused by the methods cited and/or written here. Their sole purpose is to back-up data and not to alter in any way the integrity of the original files of the mobile***
What you will need:
Rooted SGS II to get permissions as a SU (Super User) and perform the backup
I would suggest learning a little about the terminal commands used (in case you are not familiar with them), as it’s better to know what you are doing rather than typing strings like a little chimp without knowing what they are; if you are a little lazy, then you have a good chance bricking your mobile. <- Busybox Commands(or Google them)
Terminal Emulator by Jack Palevich (available from the market) <-Terminal Emulator or use ADB which is included in the SDK Development Tools
The standard prompt of terminal (adb) is a $ sign. Once you enter “SU” it will become a # Sign.
***NOTE: Make sure to keep an eye on the screen of your SGS II during this process, because it may request SU permissions [currently doesn't on CF-root]; else, you will get an error (just if it’s the first time). In Terminal Emulator you will need to reset the app after granting permissions cause it usually freezes***
*Remember: to use ADB you need to enable USB DEBUGGING under Applications/Development in your SGS II.
Here are 3 methods, I recommend that you do both Clean and RAW.
Basic, unix permissions lost :
Code:
su
busybox cp -a /efs /sdcard/efs/
Clean :
Code:
su
busybox tar zcvf /sdcard/efs/efs-backup.tar.gz /efs
After this, you will end up with the file efs-backup.tar.gz in your INTERNAL SDCARD in sdcard/efs/, which is a “tarball” or a ZIP of the /efs folder. That file is your backup. You can expand it with Winrar.
You can also back up the mmcblk0p1 (where /efs is stored) under /dev/block which can greatly support in recovering your IMEI in case of a screw-up:
RAW :
Code:
su
cat /dev/block/mmcblk0p1 > /sdcard/efs/efs_dev-block-mmcblk0p1.img
Same thing, the target is the INTERNAL SDCARD in sdcard/efs/, so go ahead and copy the file.
+1 just do it....
Can this not be tasked by using a root file explorer and copying efs folder as i have always done .
jje
JJEgan said:
Can this not be tasked by using a root file explorer and copying efs folder as i have always done .
jje
Click to expand...
Click to collapse
From the thread:
I’ve found in many threads suggestions about backing up this folder but the methods itself are very general. Most of the times they suggest to “root and copy the folder” with Root Explorer or similar, but usually it’s not that easy or it just doesn't work for everyone.
Click to expand...
Click to collapse
And just copying the folder won't preserve permissions etc.
JJEgan said:
Can this not be tasked by using a root file explorer and copying efs folder as i have always done .
jje
Click to expand...
Click to collapse
As long as you don't copy it to /sdcard, because it's VFAT and you'll lose the permissions settings on the files. If you copy it to /data or something then that's fine.
bumpity bump
RyanZA said:
As long as you don't copy it to /sdcard, because it's VFAT and you'll lose the permissions settings on the files. If you copy it to /data or something then that's fine.
Click to expand...
Click to collapse
Thanks the SGS 1 EFs i copied was copied to external sd card and then copied off to PC . Did likewise on SGS 2 using Super Manager .
So according to what you are saying that was not going to back up if needed .
jje
JJEgan said:
Thanks the SGS 1 EFs i copied was copied to external sd card and then copied off to PC . Did likewise on SGS 2 using Super Manager .
So according to what you are saying that was not going to back up if needed .
jje
Click to expand...
Click to collapse
It would probably have worked, but it would have made your EFS files readable and writable by any app that tried - not the end of the world since it's unlikely that any apps would try, but you still might as well avoid it if you can. I don't think there are any executables in EFS or anything that this will actually break though.
Thanks i did lose IMEI at one flash on SGS1 but a second flash recovered it .
I do like full backup of original firmware and anything else before playing with phone .
jje
I've done all 3 forms of backup myself. . Clean, raw and basic
thanks for the info. have had close calls previously and having backups would have helped ease the stress
Updated first post
Vodafone Fimrware backup BUKE1
Guys,
Have got a new samsung from Vodafone UK , but the firmware kernel seems a bit different, BUKE1. Is this something now and is the above method correct to backup the entire firmware so that it might be useful for vodafone samsung users. Is there an easy guide to backup the firmware ?
Regards
VJ
Guys can someone give me a bit of advice pleeeease
I followed this guide but am a bit worried i might have messed it up, i'm comfortable with command prompt as i'm a software dev but haven't used linux commands much.
Anyway i used the ADB shell from the Android SDK tools and entered the first command to backup the efs directory to the internal sdcard....
Basic, unix permissions lost :
Code:
su
busybox cp -a /efs /sdcard/efs/
Click to expand...
Click to collapse
And i got a lot of
Code:
cp: can't preserve ownership of 'sdcard/efs/...' : Operation not permitted
messages flashing up?
However i checked to see if the backup had been made and it had? What does this mean?
Next i compressed it using...
Clean :
Code:
su
busybox tar zcvf /sdcard/efs/efs-backup.tar.gz /efs
Click to expand...
Click to collapse
Which seemed to work as i have the file in the place i expect
When i did the next step...
You can also back up the mmcblk0p1 (where /efs is stored) under /dev/block which can support greatly to recover your IMEI in case of a screw-up:
RAW :
Code:
su
cat /dev/block/mmcblk0p1 > /sdcard/efs_dev-block-mmcblk0p1.img
Same thing, the target is the INTERNAL SDCARD in sdcard/efs/, so go ahead and copy the file.
Click to expand...
Click to collapse
It completed really quickly, with no messages telling me it was done but when i checked root explorer i couldn't find /dev/block/mmcblk0p1?
What has it done with it? I have dev/block/ but there is no mmcblk0p1? Although i do have /sdcard/efs_dev-block-mmcblk0p1.img. Should i have both?
From what i understand cat concatenates files and prints them to standard output, so i'm assuming the > is piping the std output to the internal sdcard?
Sorry for the questions but i thought i understood what i was doing but the last step and the "can't preserve ownership of.." messages from the first step threw me
Could someone explain this to me a little ;p
These aren't steps but rather separate methods achieving different things. Don't bother about the first one - it notes unix permissions lost , which is why you are seeing the can't preserve ownership messages. The files still backup but correct r/w permissions do not. You may as well chuck the files really, since you managed the tarball (second instruction). Just grab this and backup to external storage, in case you ever need it.
The raw backup will be under sdcard as you have found - stash this away somewhere safe too. You won't find mmcblk0p1 in root explorer as it is a partition, not a folder.
Thanks for the swift reply simion_levi
These aren't steps but rather separate methods achieving different things. Don't bother about the first one - it notes unix permissions lost , which is why you are seeing the can't preserve ownership messages. The files still backup but correct r/w permissions do not. You may as well chuck the files really, since you managed the tarball (second instruction). Just grab this and backup to external storage, in case you ever need it.
Click to expand...
Click to collapse
Do if i move the tarball to the external drive i can get rid of the sdcard/efs directory i copied to the internal card? The tarball has all the correct permissions?
The raw backup will be under sdcard as you have found - stash this away somewhere safe too. You won't find mmcblk0p1 in root explorer as it is a partition, not a folder.
Click to expand...
Click to collapse
Ok i didn't realise it was a partition, so i've just created an image of the partition that the efs folder resides on? Should i copy this to my external sd card as well?
Cheers brother
No problem! Yes, you've got it - backup the tarball and the partition image to computers, external drives etc so you can recover back to the phone in case of future catastrophe. The sdcard/efs directory can be deleted as the tarball contains exactly the same files (but with correct permissions).
Awesome, will get it done later. Out of interest how do you recover the partition image in the event of a disaster occurring?
Sent from my GT-I9100 using XDA App
One question please, since i stumbled on this one almost by luck.
Is there anything else to save before departing from stock?
Thanks.
Okay, so this guide assumes I already rooted my phone, but as a newbie I am completely in the dark about what does and what does not potentially harm the /efs. I would rather backup EVERYTHING before I flash/change anything, but from what I have read so far I need at least root to do backups.
Would it be safe to flash the Lite'ning Rom v1.1, coming from stock I9100XWKE2/I9100XENKE1/I9100XXKDJ/I9100XWKE2, and then backup mmcblk0p1?
Thanks!
how to make rom to work without sd-ext
i gonna make the rom smaller and might fit to the 1giga rom
thx
This is the wrong section probably, but ill answer just for the sake of me replying to tell you its the wrong section anyway.
Its not straight forward. You probably should let them do what they do, the builds work right? An sd ext is an inconvience 'if' you are a t-mo owner. Not that its the biggest deal, its really not, make the partition 1GB on your SD, and forget about it. You probably wont even notice it.
WARNING: Moving stuff around in these folders will most likely cause you a bootloop. You can adventure, but just be fore-warned! Deleting wrong files will cause it to not install.
Anyway, if it really bugs you, heres a rough breakdown:
1. Go here: http://developer.android.com/sdk/index.html (you may need java, make sure you have this as well)
2. Get the SDK
3. Extract to a folder that wont get lost, like C:\Android is usually good.
4. Now, open the .zip file of your rom you want to shrink, using winrar or winzip or 7zip
5. Extract the folders/files to your desktop.
6. Go into the sd-ext folder, and move the folders to their respective locations (so apps goes under /system, framework goes under /system, weather under /media, etc.). Once no more files/folders reside in the sd-ext folder, you can delete it.
7. Go into the 'app' folder [now under /system] and delete some of the APK's that you dont want. Be VERY careful though, deleting wrong files WILL cause it to bootloop.
8. You can also find other delete-able files in the media folder under system.
Delete files that you know what they are. Example: VoiceSearch.apk will obviously delete the voice search. FriendsStream.apk, will obviously delete the friends stream app. Just stick to common sense.
Now, last step, the trickiest. MAKE A BACKUP OF THIS FILE (probably the easiest way)
9. Go into META-INF\com\google\android\ and right click updater-script and choose open with notepad.
10. Go through, and delete all sd-ext related entries.
11. Double check all necessary 'unpacking' entries are there. So, typically these:
-package_extract_dir("system", "/system");
-package_extract_dir("boot","/boot");
-package_extract_dir("data", "/data");
12. Some mount stuff for the sd-ext. can be removed, same with mkdir sd-ext. as we dont need anything related to sd-ext. this is the point.
Once done with the files/folders, rezip the files/folders like how you see them in any other roms zip file.
Dont make it a zip like this:
Pyramid_HTC_Europe_v1.x_Tmous.zip>Pyramid_HTC_Europe_v1.x_Tmous/data, system, meta-inf, boot
Make like this:
Pyramid_HTC_Europe_v1.x_Tmous.zip>/data, system, meta-inf, boot
It wont read it unless those 3/4 folders are not in any other folder.
Now that you have the new rom file, LAST step, and I promise, its the last. You have to go to that C:\Android folder, and go to the autosign.bat file. Follow the instructions. For more info on this part, you can search this site. There are a few guides on re-signing files.
But, you are done
________
As long as you make sure you did all that, it 'should' work. But please, do the necessary reading! This is not a walk in the park. For the script, you should look at working ROM's file, compare. See how they work. Understand them.
As proof. I actually JUST converted dungs new mytouch 4g rom that required even t-mo us to have an ext, to NO ext. I dropped the whole package by 100MB, did what I just posted, re-worked the script, and resigned. Just flashed fine, its much quicker now .
Hope this wasnt confusing. Probably was, but thats why I tried to be as detailed as I could be without going overboard. Anyway, let me know if you have questions.
I am not understand the question. Which rom bigger than the 1Gb Hd2 t-mobile rom?
thx theslam08 that what i wanna do
make the mytouch 4g rom of dungs sd-ext lesss if u could upload it and link me i will very grateful
@ntluan
i just want that rom will use only the ROM space not sd-ext too
Sure, I got permission from dung, so I posted it in that thread. Compare my updater script with the one he has for his sd version. You will see what I changed, what you need to do.
Hey guys,
For a few days, I was wondering what could happen if we could compile the Standard C library (not trimmed one like Bionic) and compile some linux applications for ARM processor (say, Desire). I successfully compiled the GlibC, and now do have the .a and .so files.
The problem is, I don't know where to put them, so the dynamically linked applications can reach them! I could put them to /system/lib, but I don't want to overwrite the files already there (I don't want to crash the working parts of the system). I was thinking to put them to (say) /data and create symbolic links to /system/lib, but - as I said - what about the libraries which have the same name?
Questions or Problems Should Not Be Posted in the Development Forum
Please Post in the Correct Forums and Read THIS
Moving to General
Sorry for the wrong section post. I found the solution though..
The thing is to be done is editing the Ramdisk/init.rc; changing LD_LIBRARY_PATH variable, accordingly (say, /data/lib). Once you do that, the system loads libraries from the folders, in specified order.
However, you must be cautious because since at the boot time, Data might not be mounted yet, the libraries that are installed there could not be read. Ergo, don't delete (or move) the system libraries (like I did ) - the phone won't boot without them.
Another issue is libc. Since bash shell is compiled with bionic, it requires bionic version of libc; not glibc. I'm going to try to overcome this by recompling shell; yet still there might be other problems (there might be other native executables need Bionic Libc)
I'll update this thread as I try new things.
theGanymedes said:
Sorry for the wrong section post. I found the solution though..
The thing is to be done is editing the Ramdisk/init.rc; changing LD_LIBRARY_PATH variable, accordingly (say, /data/lib). Once you do that, the system loads libraries from the folders, in specified order.
However, you must be cautious because since at the boot time, Data might not be mounted yet, the libraries that are installed there could not be read. Ergo, don't delete (or move) the system libraries (like I did ) - the phone won't boot without them.
Another issue is libc. Since bash shell is compiled with bionic, it requires bionic version of libc; not glibc. I'm going to try to overcome this by recompling shell; yet still there might be other problems (there might be other native executables need Bionic Libc)
I'll update this thread as I try new things.
Click to expand...
Click to collapse
I just put glibc in /lib, at boot /lib is empty, but then I mount the contents of /lib aftwards. Ideally it would mount from a custom init.rc script. I suppose if you put the libc in /data/lib you could sym link that to /lib during boot. I am pretty sure that /lib needs to be in the root dir and its contents must be executable. I found I had to edit some header file somewhere, I'll get back to ya once I start poking my head round Android again, syncing back up atm.