Baseband si RIL

BaseBand is a piece of the low-level software that handles the "radio" in your
phone. Radio in here means components for WiFi, GSM (wherever really GSM, or
UMTS, or HSPA, etc.), BlueTooth, etc. This is quite important piece of soft and not
easily accessible, at least on LG (as far as I remember on HTC Desire it could
have been flashed via recovery). For different countries there could be different
BBs. Even for different operators I believe. This is why some of them work better
for some particular people and worse for other.
Now, the RIL is a Radio Interface Library - a piece of software which comes with
the system (ROM) and it gives you a "bridge" between system (kernel?) and Base
Band. For the phone to work in an optimal way you need matching version of the
BB and RIL. If you mix one BB with some different RIL your phone may not work
(in the sense that you will not be able to make any calls or connect to the WiFi or
whatever) or work in a faulty way.
Now, you'll get a phone with some BB already on-board and personally I do not
think there is any need for you to change it to any other version - if it works then
fine. But if you wish to flash some custom roms then they will come with some
RIL and the best thing to do is to change this RIL to the one that matches your
BB. There is GetRIL application on the market which makes it a piece of cake. For
example: CM7, Temasek Kangs were coming with the 218 RIL which I was always
changing to 725 RIL with the help of the aforementioned app as soon as I flashed
new Kang. In fact the GetRIL application makes it even easier - if you are on CM7
rom then there is "keep RIL after flashing" option which automatically keeps the
RIL in the version you want.
What is ADB

ADB stands for Android Debug Bridge. It comes as a part of the standard Android SDK,
which you can grab here. Basically, it provides a terminal-based interface for interacting with
your phones file system. Since Android platform is based on Linux, command-line is the only
way to obtain and manipulate root access often required to perform certain advanced
operations on your device using root access.

*.SBF android system backup file

Q: What is an SPL?

A: Secondary Program Loader, typically, a second stage bootloader. Not a term actually used
by Qualcomm for msm7k has a more complex boot path involving both CPUs.
Initial/secondary program loader is usually in reference to nand/onenand boot setups where
you have a very small initial bootloader (1k to 16k typical), that is just enough to load a much
larger secondary bootloader. Often there is something that runs first, in-rom, on-die (this is
true of omap and msm chips for example) that is responsible for getting the IPL loaded.

Q: What is Radio and SPL and recovery and ROM conection ?

Hey everybody is a noob at one time or another, asking is how we get to not be noobs
anymore. Based on your OP I had assumed that you have rooted your phone. If this is not
true, you'll have to root it first before you can even think about installing a custom ROM on it.
You can get your radio version by powering on your phone and then while holding the volume
down key in turn it back on (Volume down + power). you will get to a screen with three little
androids on skateboards at the bottom.
This is the information on your Radio and SPL (Secondary Program Loader)
Here is what shows on Mine
SAPPHIRE PVT 32A ENG S-OFF.H
HBOOT-1.33.2010 (SAPP50000)
CPLID-12
RADIO-3.22.26.17
June 2 2009,17:27:03
The line that starts with SAPPHIRE says that my hardware is a PVT 32A board and that I'm
running an (ENG) Engineering SPL and that (S-OFF) security is off
The line that starts with HBOOT gives you your SPL version, in my case it's 1.33.2010
The line that starts with RADIO is the radio version that I'm running, in my case it's
3.22.26.17

{The radio controls communication aspects of the phone (3G, Wi-Fi, Bluetooth, etc.)
It's the radio version that is going to determine which ROM's you'll be able to run and
it's the SPL version that will determine which Radio's you'll be able to use.
Are the radios posted the same. As far as I know, yes. The rom chefs do not (normally) cook
radios. They cook kernels and system images. Radio is a very very very very bad thing to
mess with. Messing with radio or the wrong radio will be the only reason why you will have a
bricked phone. All other stuff is generally fixable with a flash of this and a dash of that.}

IE: With a 1.33.X SPL you can run a 2.X or 3.X radio
With a 1.76.X SPL you can run a 6.X radio
When you wish to change radio's you have to make sure that you are using a matching SPL or
you'll end up bricking your phone (expensive paperweight). And it's not only the SPL/Radio
combination that you have to worry about, your recovery has to be matched to the SPL/Radio
combination as well.

The radioswitcher script I linked to in my first post is a way to switch between a 3.x and 6.x
radio without having to enter all the commands yourself, the script will actually check to
make sure that the proper files are available before attempting to flash a new SPL, Radio &
Recovery to your phone.
How about you get the information from your fastboot screen (volume down + power) and
we'll direct you to any guides that would be able to help you.

{ROM images will normally replace boot and system images at

the same time and often time, userdata and cache too; reseting
the phone completely.}

Android Partition, SPL etc.

Partitions:
Followings are a list of partitions on your android phone.
misc - misc partition recovery - Recovery Partition - This is where the original HTC recovery or
Amon Ra's recovery or any other Recovery would go. Basically if you reboot
into recovery it'll boot from here.
boot - This is your boot partition
system - This is where all your system information (ROM resides)
cache - cache (When you factory reset the phone, this area is wiped)
userdata - user data (like your login, your user settings etc) When you
factory reset the phone, this area is wiped)
So, if you replace the recovery image, you are pretty much set for updates
provided here at XDA. Note: By replacing your recovery image, you may not
be able to have OTA updates.
ROM images will normally replace boot and system images at the same time
and often time, userdata and cache too; reseting the phone completely.
Q:I have never experienced anything like this when I did a hard-spl on
my winmo phone. Radio versions are included with SPL's, right?
A: Official packages from HTC did come with nbh packaging, meaning it is a all
in one upgrader that will update Radio, ROM, System etc, it is very much
common for active development area here at XDA to get the radio or SPL or
ROM separately and independently of one another. And as such, you will most
likely flash them seperately (who wants to wait 6-8 months). Also, since this

phone is released by google, HTC will most likely not update any major Radios.
However, it is very likely that we will be hacking in Radio updates or any other
"updates" from HTC from their new device - HTC Bravo.
Q: Which step of the rooting / recovery procedure does it give root?
A: Root and Recovery are two totally different things. Recovery is a partition
that contain recovery information. Stock recovery is what allows OTA updates
etc. Normally it will search for update.zip in the root folder of the SD card.
Amon_RA's Recovery or any other recovery images are there to enhance the
traditional stock recovery. Amon Ra's Recovery for example, contains thing
such as ability to update from different zip files, and backup/restore of your
data/system.
Rooting is not done by recovery but is a kernel level access (simply put) that
will give root or "SU". It is done by patching the boot partition of the your
android device.

Q: When you do "flash zip from sdcard" or "fastboot flash

image" does this merge and overwrite the files in to the
partition?
A: When you update a software (via recovery), software my be merged.
However, if you fastboot flash, just like the word flash says, it will flash
and overwrite the partition.
Q: Which partition does "flash zip from sdcard" affect?
A: Depends on what you are flashing. It could be any or all of the partitions
such as SPL, Boot, System, Recovery, Radio. You should study first before
randomly flashing things.

Bootloader / SPL (cod proprietarphone manufacturer (or chip vendor), nu e

public) un set de instructiuni specifice procesorului si placii de baza ce este rulat la
pornirea device-urilor si are rolul de a incarca kernelul S.O Pt. a scrie si aputea rula
ROM-uri custom(in vederea obtinerii dreptului de root printr-un kernel modificat)
trebuie deblocat bootloaderul(daca e lock), proces ce wipes(formateaza) mem
interna(adica Wipe will erase custom data on userdata.img) perzandu-se aplicatiile
si setarile cat si garantia producatorului datorita posibilitatii de a instala soft si S.O.-uri
custom cu drept de root ce fac ce vrei tu ..si nu numai...
Ex: Motorola a implementat eFuse o bucata de cod ce cerifica la inceputul
procesului de bootare versiune bootloader-ului, info despre kernel si versiunea
de firmware iar daca au fost alterate obtii probabil o caramida(nu-l mai vede
ca device ABD-ul laUSB debugging si nu mai booteza nici normal nici in
recovery mode nici in fastboot(bootloader mode) datorita probabil alterarii
unei partitii misc).
{ SPL/Bootloader/Radio/Bricking Phones:
SPL / Bootloader is like BIOS on a computer. At least I think of it that way.

SPL can be updated! SPL comes as either Security-On of Security-Off (S-ON/SOFF).

Note: It is my understanding that radio will boot first, followed by other
systems. So it is IMPORTANT that your radio image/version will work with your
SPL image/version. This is the one and only reason for phones being bricked.
You can not brick your phone by flashing a ROM or Boot image or recovery
image. Once you flash the wrong radio for the SPL, the only known method of
recovery is to send the phone back into HTC for repair.
How do I know the phone is bricked? A bricked phone can not boot into
bootloader, recovery, or into normal operation modes. You can not connect to
a bricked phone via adb or fastboot. You can only see one screen on the
phone and it will be the first splash screen.}

With locked bootloader, you can create custom ROMs, as has been created for Milestone.
But these ROMs will always have to use the old kernel that came with the phone, as they can't
put a new kernel in the ROM. This means hardware (GPS, bluetooth, etc) sometimes work,
sometimes doesn't work. It also means you can't take advantage of many of the new features
of later versions of Android, as they are not compatible with the old kernel.

A.What is a ROM(is essentially a custom version of Android)?

O imagine ROM este (firmware-ul) reprezentat de un fisier de date(binar) ce contine
informatii ce tre scrise intr-un cip Read Only Memory. adica pt smartphone e imaginea
sistemului de op. a device-ului si contine cod si fisiere(kernelu, GUI, apps ) pt a boota si a
incarcamai departe Androidul si contine :

i. Kernel Androidul ruleaza pe baza unui kernel Linux ce reprezinta interfata dintre
hardwareul si software-ul device-ului . Aplicatiile ruleaza intrun user-space separat de
kernel,etc oferind stabilitate(mai putin cand se panicheaza si el).
Intr-un ROM standard Android kernelul este impachetat (ingramadit laolalta)
impreuna cu un set de instructiuni ce determina modul in care este incarcat
kernelul si S.O. in procesul de bootare. asta este fisierul zip-uit boot.img ce
este extras in mem interna( intr-un RAMDISK) executand apoi scripurile init,
etc pt a incarca kernelul si alte functii ale S.O.

ii. The operating systemdupa ce kernelul este incarcat scripturile init incarca S.O.
Androidul este de fapt interfata userului (user interface) cu o masina virtuala(register-based)
Java numita Dalvik ce genereaza fisiere executabile (*.dex) ce sunt apoi interpretate de S.O.

iii. Core functionsun set de functii de baza, ex - dialer interface, the calendar, the
messaging system are core functions of the Operating System ce sunt executate deasupra

kernelului ca aplicatii separate. (Interfata ce lanseaza aplicatiile(launchere custom ale OEM)

MotoBlur, Sense, etc)

iv. Aplicatiile optionale (celelalte)

B. How is a ROM packaged? ROM-ul e arhivat zip iar dezarhivarea si copierea

continutului in locul potrivit e responsabilitatea kernelului din imaginea de Recovery.
In zip se gaseste (printre altele )
-

un director(META-INF\com\google\android\) ce contine un script preparat de ROM

cooker(tata romului) ce spune SO ce sa formateze, copieze si unde si operatiile cu fisiere
necesare.
directorul /system ce cotine corpul ROM-ului (fisierele SO, functiile de baza si ce
aplicatii sau utilitare mai decide coocker-u) este de fapt structura de fis si directoare ce
este scrisa la bootare un mem.
Un fisier boot.img ce contine kernelul si ramdiskul ce va fi decomprimat si executat la
bootare.
There is also another important file you should know about. In /system/recovery.img
there is a full copy of everything that is loaded on mtd1. This file is automatically flashed
onto mtd1 every time you shut down. That means two things: 1. Any changes you make
directly to /dev/mtd/mtd1 get blown away on reboot and 2. If you want to change
/dev/mtd/mtd1 you're probably better off just sticking the image in /system/recovery.img
and rebooting. When creating your own custom update.zip files (especially when
adapting the stock images), you can get tripped up if you forget to replace
/system/recovery.img and it ends up overwriting /dev/mtd/mtd1 unbeknownst to you.
Watch out.
1. Cum instalez un ROM custom(se pierd setari, apps !) ?
A. Got Root?({You have to understand that root (gaining SU) is done at
the boot.img} adauga aplicatia su pt a rula aplicatii cu permisiuni ridicate;
accesul la dir. /system, implicit acces la img de recovery ca apoi custom ROM)
- ROM-urile manufacturer-ului au un utilitar pe PC ce flash-uiesc si incarca
imaginea(ex RDS Lite pt Motorola). ROM-urile custom (3rd party) nu pot fi
incarcate pe device-uri ce nau drepturi de root. In teorie se poate semna un ROM
cu cheile din imagine Recovery ca aceasta sa il incarce dar....in teorie,..in practica
tre flash-uita o imagine Recovery custom pt a putea scrie apoi un ROM custom.
B. Imaginea Recovery custom ofera posibilitatea updatarii ROM-ului stock
cu unul custom si posibilitatea de backup and restore a starii curente a sistemului
pe SDCARD(nandroid set de scripturi continute in custom recovery)

where can I find more info on the code in the recovery program?

>>>>"Recovery"in term of android, there is complete set of code given in

android
source( bootable/recovery/* code , just go through it, it is very basic
simple "C" code .
Recovery code will work as your rootfs for making recovery image. and that
image u need to write in a partition. which will be a combination or zImage
and recovery c code as rootfs.
and if you want to do any recovery stuff, boot this image instead of
normalandroid kernel.

C. Copy and Flash cu drepturi de su (root), o imagine ROM custom si backup

facut se purcede :

Se copiaza fisierul *.zip (ROM-ul custom) in dir root (/) pe SDCARD

Se rebooteaza telefonul in recovery mode
Se selecteaza din meniu optiunea flash update si se alege fis
*.zip(update.zip) se da apoi apply si restart.

- Structure of boot and recovery images

-

The boot and recovery images are not proper filesystems. Instead, they are a custom
android format consisting of a 2k header, followed by a gzipped kernel, followed by a
ramdisk, followed by a second stage loader (optional, we have not seen these in the wild
yet). This structure is outlined in mkbootimg.h:
+-----------------+
| boot header | 1 page
+-----------------+
| kernel
| n pages
+-----------------+
| ramdisk
| m pages
+-----------------+
| second stage | o pages
+-----------------+
n = (kernel_size + page_size - 1) / page_size
m = (ramdisk_size + page_size - 1) / page_size
o = (second_size + page_size - 1) / page_size
0. all entities are page_size aligned in flash
1. kernel and ramdisk are required (size != 0)
2. second is optional (second_size == 0 -> no second)
A ramdisk is basically a small filesystem containing the core files needed to initialize the
system. It includes the critical init process, as well as init.rc, which is where you can set
many system-wide properties. If you really want to know more about it, here is the
documentation. Here's a list of files on a typical ramdisk:
./init.trout.rc
./default.prop
./proc

./dev
./init.rc
./init
./sys
./init.goldfish.rc
./sbin
./sbin/adbd
./system
./data

- The recovery image typically has a few extra files, which constitute the
recovery binary and supporting files (the application that gets run if you
hold down home+power when rebooting). These files are:
-

./res
./res/images
./res/images/progress_bar_empty_left_round.bmp
./res/images/icon_firmware_install.bmp
./res/images/indeterminate3.bmp
./res/images/progress_bar_fill.bmp
./res/images/progress_bar_left_round.bmp
./res/images/icon_error.bmp
./res/images/indeterminate1.bmp
./res/images/progress_bar_empty_right_round.bmp
./res/images/icon_firmware_error.bmp
./res/images/progress_bar_right_round.bmp
./res/images/indeterminate4.bmp
./res/images/indeterminate5.bmp
./res/images/indeterminate6.bmp
./res/images/progress_bar_empty.bmp
./res/images/indeterminate2.bmp
./res/images/icon_unpacking.bmp
./res/images/icon_installing.bmp
./sbin/recovery
Unpacking, Editing, and Re-Packing the images
Note: below I give you the details for unpacking and repacking manually, but I created
two perl scripts that do most of this for you (unpack-bootimg.pl, repack-bootimg.pl).
If you are good with a hex editor, you can open up any of these images and strip off the
first 2k of data. Then, look for a bunch of zeroes followed by the hex 1F 8B (which is the
magic number of a gzip file). Copy everything from the first line of the file, through the
zeroes, and stopping at the 1F 8B. That is the kernel. Everything from the 1F 8B through
the end is the ramdisk. You could save each of these files separately. In order to see the
contents of the ramdisk, you need to un-gzip it and then un-cpio it. You could use a
command like this (ideally after creating a new directory and cd'ing into it):
gunzip -c ../your-ramdisk-file | cpio -i
That will place all of the files from the ramdisk in your working directory. You can now
edit them.
In order to re-create the ramdisk, you need to re-cpio them and re-gzip those files, with a
command like the following (remember, cpio will include everything in the current
working directory, so you probably want to remove any other cruft you might have in
there):

find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz

The final step is to combine the kernel and your new ramdisk into the full image, using
the mkbootimg program (which you should download and compile from the git
repository):
mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel your-kernel-file
--ramdisk newramdisk.cpio.gz -o mynewimage.img
Now, there's a lot of hassle in pulling apart files in hex editors and remembering all of
these commands, so I wrote unpack and repack perl scripts for you. Hooray.
Alternative Method
Download split_bootimg.zip . This Zip file contains one Perl file, split_bootimg.pl, which
reads the boot.img header (according to the bootimg.h of the Android source code) to
extract the kernel and ramdisk. The script also outputs the kernel command line and
board name (if specified).
(Note: Do not use a boot.img image extracted directly from /dev/mtd/mtd2. This image
may become corrupted during the read process.)
The following example uses the boot.img from the full TC4-RC28 update:
% ./split_bootimg.pl boot.img
Page size: 2048 (0x00000800)
Kernel size: 1388548 (0x00153004)
Ramdisk size: 141518 (0x000228ce)
Second size: 0 (0x00000000)
Board name:
Command line: no_console_suspend=1
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.
Extract the ramdisk.
% mkdir ramdisk
% cd ramdisk
% gzip -dc ../boot.img-ramdisk.gz | cpio -i
% cd ..
Make any changes necessary (e.g., set ro.secure=0 in default.prop).
Recreate the cpio archive using the mkbootfs binary produced from building the Android
source code (The cpio utility in OS X does not recognize the newc format, therefore
mkbootfs is the best option for OS X users).
% mkbootfs ./ramdisk | gzip > ramdisk-new.gz
Recreate the image file using the mkbootimg binary produced from building the Android
source code.
% mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel boot.img-kernel
--ramdisk ramdisk-new.gz -o boot-new.img
For Nexus One : Add --base 0x20000000 to mkbootimg command-line.
(Note: the console=null command line option was introduced in the TC4-RC30 boot
images to remove the root shell (TODO: add link))
Flashing your new image back onto the phone
You will probably only ever be flashing boot images directly to the phone, given the fact
that /system/recovery.img automatically flashes the recovery device for you (as noted
above). If you have created a new recovery image, just stick it in /system/recovery.img
and reboot. If you are flashing a boot image, stick it on your phone via adb (a tool
included in the Android SDK):
adb push ./mynewimage.img /sdcard

Then, open a shell to your phone via 'adb shell', get root, and do the following two
commands to flash your new boot image:
# cat /dev/zero > /dev/mtd/mtd2
write: No space left on device [this is ok, you can ignore]
# flash_image boot /sdcard/mynewimage.img
Reboot.
If your phone starts all the way up, congratulations. If not, you did something wrong and
you'll need to boot into recovery mode and apply your update.zip file (reboot while
holding down home+power, when you get the recovery screen press alt+L and then
alt+S).
Something fun to do with your new found power
If you place a file titled initlogo.rle in the root directory of your boot image, the phone
will display this image upon boot (after the "G1" image and before the Android
animation). In order to create this file, you need to create a 320x480 image in Photoshop
or Gimp and save it as a "raw image" file. You then need to compress that image with the
program to565. More details on that here.
This is not the same thing as applying an update.zip
You will see other places on the forums that describe how to create customized update.zip
files, as well as update.zip files that people are sharing. For example, there is a recent
update.zip which is a modified version of rc30 (with the anti-root aspects disabled). The
update.zip files include new boot images, recovery images, and typically replacements for
the entire system/ directory as well as other updates. If you are creating a custom boot or
recovery image, it is typically a good idea to start with the image distributed with the
most recent update you have applied (flashing an image from an older release could have
unintended consequences).

Questions?

How do I "reboot into recovery mode"? What does that even mean?
Think of your device as a computer. When you reboot your computer it will automatically
start up windows, right? Well, you're able to stop that the usual reboot process and get
into the "guts" of the computer by pressing F6 (I think it's F6).
It's the same thing with your device. It you power off / on or just do a regular reboot you'll be directed to your lock screen and then your home screen. In order to install
custom ROMs or get into the "guts" of the device you need to bypass the usual start up
process and get into what's known as recovery mode.
This is accomplished by pressing certain buttons while the device is powering up. Here
are the steps:
-- While the device is on and running open the physical keyboard
-- Press and hold at the same time the control, alt, and the delete keys. (note: the "control"
key is the one to the left of the "Z". The one with the arrow on it)
-- Your device will power off.

-- As soon as it starts the cycle of powering on (you'll see the screen slightly brighten)
press and hold the "X" button on the phyical keyboard AND the power button on the top
at the same time.
-- Keep holding the buttons down until a new screen comes up. This will be a rather plain
looking screen with some typed prompts on it.
-- The recovery mode is NOT a touch screen. You will navigate this screen by using the
volume up down buttons, the camera button, and the power button. Just follow the
prompts on the screen.

Sync datele cu contu de google before rooting

your contacts & all other data (calendar,stocks,news,weather,etc) in your gmail account can
be manually sync'ed (menu>accounts & sync> sync all). they don't necessarily sync when you
turn on the phone--it's safest to perform this manual Sync BEFORE you root your phone to
ensure all of your contact info & calendars are updated onto google server so that when you
load them again AFTER root, they're just the way you were accustomed to.
if you're concerned about syncing them AFTER you have rooted--it shouldn't be a problem. if
you don't see them appear immediately, simply perform the manual-sync steps above and give
it a few minutes (as over 300 contacts can take several minutes to sync).
did this answer your question--or have i overlooked something?
Quote:
Originally Posted by dishe
How about call logs and text messages? Those aren't synced with google AFAIK.
And if I use Titanium Backup to back up app data, can it be restored on a new rom?
For example, if I don't want to lose my place in Angry Birds after flashing a new rom, can I
just install Angry Birds from the market, and use Titanium Backup to restore the app data
(which contains which level I'm on)?
There is a free app called SMS backup that will back up your messaging to a folder in your
Gmail account. It can then be restored. It has a setting for continuous backup as well.
There is also an app called CallLog backup that should help as well. I ahven't used it myself
before, but it is well rated. It is a $0.99 app.
Titanium Backup can backup and restore apps AND data. This will for instance restore your
progress in Angry Birds.

I use "reware's 'My Backup Pro' " $1.99, It backs up sms, call log, app data, everything to
your sd card or online it works great !
##################

Unless you have been using your Android phone just for calls, SMS, browsing and basic apps,
you should know that Android uses several partitions to organize files and folders on the
device. Each of these partitions has a distinct role in the functionality of the device, but not
many Android users know the significance of each partition and its contents. In this guide, we
will take you on a tour of Android partitions, what they contain and what can be the possible
consequences of modifying their content.
Lets start with a list of standard internal memory partitions on Android phones and tablets.
These are:

/boot

/system

/recovery

/data

/cache

/misc

In addition, there are the SD card partitions.

/sdcard

/sd-ext

Note that only /sdcard is found in all Android devices and the rest are present only in select
devices. Lets now take a look at the purpose and contents of each of these partitions.
/boot
This is the partition that enables the phone to boot, as the name suggests. It includes the
bootloader and the kernel. Without this partition, the device will simply not be able to boot.
Wiping this partition from recovery should only be done if absolutely required and once done,
the device must NOT be rebooted before installing a new one, which can be done by installing
a ROM that includes a /boot partition.
/system

This partition basically contains the entire operating system, other than the kernel and the
bootloader. This includes the Android user interface as well as all the system applications that
come pre-installed on the device. Wiping this partition will remove Android from the device
without rendering it unbootable, and you will still be able to put the phone into recovery or
bootloader mode to install a new ROM.
/recovery
The recovery partition can be considered as an alternative boot partition that lets you boot the
device into a recovery console for performing advanced recovery and maintenance operations
on it. To learn more about this partition and its contents, see the About Android Recovery
section of our guide to ClockworkMod recovery.
/data
Also called userdata, the data partition contains the users data this is where your contacts,
messages, settings and apps that you have installed go. Wiping this partition essentially
performs a factory reset on your device, restoring it to the way it was when you first booted it,
or the way it was after the last official or custom ROM installation. When you perform a wipe
data/factory reset from recovery, it is this partition that you are wiping.
/cache
This is the partition where Android stores frequently accessed data and app components.
Wiping the cache doesnt effect your personal data but simply gets rid of the existing data
there, which gets automatically rebuilt as you continue using the device.
/misc
This partition contains miscellaneous system settings in form of on/off switches. These
settings may include CID (Carrier or Region ID), USB configuration and certain hardware
settings etc. This is an important partition and if it is corrupt or missing, several of the
devices features will will not function normally.
/sdcard
This is not a partition on the internal memory of the device but rather the SD card. In terms of
usage, this is your storage space to use as you see fit, to store your media, documents, ROMs
etc. on it. Wiping it is perfectly safe as long as you backup all the data you require from it, to
your computer first. Though several user-installed apps save their data and settings on the SD
card and wiping this partition will make you lose all that data.
On devices with both an internal and an external SD card devices like the Samsung Galaxy
S and several tablets the /sdcard partition is always used to refer to the internal SD card. For
the external SD card if present an alternative partition is used, which differs from device
to device. In case of Samsung Galaxy S series devices, it is /sdcard/sd while in many other
devices, it is /sdcard2. Unlike /sdcard, no system or app data whatsoever is stored
automatically on this external SD card and everything present on it has been added there by
the user. You can safely wipe it after backing up any data from it that you need to save.

/sd-ext
This is not a standard Android partition, but has become popular in the custom ROM scene. It
is basically an additional partition on your SD card that acts as the /data partition when used
with certain ROMs that have special features called APP2SD+ or data2ext enabled. It is
especially useful on devices with little internal memory allotted to the /data partition. Thus,
users who want to install more programs than the internal memory allows can make this
partition and use it with a custom ROM that supports this feature, to get additional storage for
installing their apps. Wiping this partition is essentially the same as wiping the /data partition
you lose your contacts, SMS, market apps and settings.
With this, we conclude our tour of Android partitions. Now whenever you install a ROM or
mod that requires you to wipe certain partitions before the installation, you should be in a
better position to know what youre losing and what not and thus, youll know what to backup
and what not.
Android partitions, kernels explained

This is a rewrite/repost, condensed and updated with information that I think is

useful to a lot of rooted users. Partitions and kernels aren't frequently discussed.
Most of us know that they exist but don't really know how they work. Hopefully it
all becomes clear after reading this
The phone's internal memory (not the SD card) is solid-state (flash) memory, AKA
NAND. It can be partitioned much like a normal hard drive can be partitioned. The
bootloader exists in its own partition. Recovery is another partition; radio,
system, cache, etc are all partitions.
Here are the standard partitions on an Android phone:
/misc - not sure what this is for.
/boot - bootloader, kernel
/recovery - holds the recovery program (either clockworkmod or RA recovery for a
rooted Evo)
/system - operating system goes here: Android, Sense, boot animation, Sprint
crapware, busybox, etc
/cache - cached data from OS usage
/data - user applications, data, settings, etc.
The below partitions are not android-specific. They are tied to the hardware of the
phone, but the kernel may have code allowing Android to interact with said
hardware.
/radio - the phone's radio firmware, controls cellular, data, GPS, bluetooth.
/wimax - firmware for Sprint's flavor of 4G, WiMax.

During the rooting process, a critical piece of the process is disabling a security
system built into the bootloader that protects these partitions from accidental (or
intentional) modification. This is what's referred to as "unlocking NAND." The
security system can be set to active or inactive. S-ON means the security is in
place (NAND locked). S-OFF means the security is off (NAND unlocked). When SOFF, you have the ability to modify all partitions. With S-ON, you only have write
access to /cache and /data. Everything else is read-only.
When you flash a custom ROM, that ROM typically includes a kernel and an OS.
That means the /boot and /system partitions will be modified at a minimum.
Some ROMs require a clean install, so a format of the /data and /cache partitions
is sometimes built into the .zip that you flash. This is essentially doing a factory
reset. See next paragraph.
When you do a factory reset (AKA: wipe, hard reset, factory wipe, etc.), you are
erasing the /data and /cache partitions. Note that a factory reset does NOT put
your phone back to its factory state from an OS standpoint. If you've upgraded to
froyo, you will stay on froyo, because the OS lives in /system, and that is not
touched during a factory reset. So "factory data reset," as it says under Settings
> SD & phone storage, causes confusion. It's not a factory reset. It's a factory
DATA reset. Now you know the distinction.
The SD card can also be partitioned to include a section dedicated to storing user
apps. To create the partition, your SD card needs to be formatted. Typically a user
will copy all the contents in the SD card to a PC hard drive, wipe the card and
partition it, and then copy everything back.

Onto kernels....
A kernel is a layer of code that allows the OS and applications to interface with
your phone's hardware. The degree in which you can access your phone's
hardware features depends on the quality of code in the kernel. The homebrew
(rooting) community for HTC has made several kernel code improvements that
give us additional features from our hardware that the stock kernel does not.
When you flash a custom ROM, you automatically get a kernel. But you can also
flash a standalone kernel ROM on top of the existing one, effectively overwriting
it. These days, the difference in custom kernels is less about new features and
more about alternate configurations. Choosing a custom kernel is basically
choosing one that works best with your ROM.
Kernel developers are typically responsible for a small, specific feature in the
kernel. For example, netarchy's contribution to custom kernels mainly revolve
around removing the framerate restriction that was present in the stock HTC
kernel. However, because of the open-source philosophy of all the devs, each
kernel "distribution" contains the work of several devs. They openly share new

code that they deem will benefit everyone. Basically the best features stay in,
and the distributor of the kernel will give credit where credit's due. This means
that for any custom kernel you try, you might be using netarchy's FPS fix. It's all a
team effort. A new improvement will make it to most if not all of the various
kernel distributions in a short amount of time.
For the Evo, the hot features of custom kernels are:
-- a fix to remove the 30fps cap imposed by HTC and improve touch tracking
sensitivity (HTC finally fixed this in their stock kernel late last year)
-- disabling perflock to enable CPU throttling. Great for increasing the
performance of your phone and/or improving battery life
-- iptables firewall to enable wifi-tethering via the wifi-tether app
-- 3 or 5 point multitouch support (not too many practical applications)
-- HAVS, a control system that dynamically adjusts the voltage based on CPU
load. This has proven to be a battery saver, but it can actually have the opposite
effect when multiple control systems are operating (like setCPU).
-- BFS kernel task scheduler as an alternative to the standard CFS
-- SBC (the ability to charge your battery beyond the default safe limit). The
concept is similar to overclocking a processor: you're overriding the safety limits
established to achieve additional performance. The benefit here is that you may
gain more use of your battery per charge. The drawback is that you can damage
the battery and significantly reduce its longevity. Some kernels claim they are
using a safe technique to prevent battery damage. Just be aware of the potential
risks.
Note about 4G and HDMI:
AOSP ROMs (ROMs based on pure Android without 3rd party manufacturer's code)
are currently lacking robust 4G and HDMI support. This is because 4G and HDMI
are hardware-specific features, not Android-specific, so there is no existing kernel
code in the Android Open Source Project (AOSP) that is specific to 4G or HDMI
support.
HTC is the manufacturer of the phone, so it has intimate knowledge of the
hardware it uses in the phone; therefore the kernel that HTC has written does
support HDMI and 4G. The problem is that the kernel is also tied in with their
Sense UI that it's not possible to simply extract the portions of the code
governing 4G and HDMI. Therefore, Sense-based ROMs support 4G because they
simply borrow the existing HTC code. Meanwhile AOSP ROMs have to write their
own code for 4G and HDMI in order to support it. Their ability to do this depends
on how much info they can obtain about the hardware components in the phone

and any drivers they may be able to find. Otherwise, it's really a task of reverseengineering the hardware, which can be a thankless, time consuming task.

For a more in-depth read into how partitions work in Android/Linux, take a look
here, courtesy of Akazabam:
More information about Android partitions

I. The Basics
Every operating system has a way of viewing and manipulating the filesystem(s) available to
it. In the case of Windows, you have designated drive letters which represent the physical
drives or partitions on a drive. Under each drive, you have folders and files. Those folders and
files are data on each one of those specific drives. It's all very concise and obvious as to what
data exists on what drive. There *are* things you can do complicate this, but this is not a
discussion about Windows.
Android does not work anything like Windows, however, as it is a Linux based system.
Linux/UNIX type systems have one top level file structure. The top level is called root, and is
designated by /. There are no drive letters, and the files and folders under / are not necessarily
all stored in the same physical location. Let me just take a very brief detour here. The top
level file system is called root. When we say root in this case, we are not talking about the
root user or root level permissions. When you root the phone, we're talking about have
permissions to do things as the root user and make changes we couldn't otherwise do. The
word root is used for different things. When you hear the word root used with filesystems, we
mean the top level.
From this point on, the root of the file system will just be referred to as /. There really isn't
much under / by itself. It's generally a small partition. In order to use other partitions, Android
must make these partitions available under /. There is a special directory called /dev. Under
this directory, you will find logical representations of partitions and resources available to the
system. These, on their own, are just device files. These files exist solely so that the system
knows they exist. You cannot try to view anything in them. So, in order to use partitions found
in /dev, the system must mount them under /. This means the system must take a physical or
logical media where you have some data stored, and make it available.
II. Mounting
When the system (or the user) initiates this process of mounting, a directory (folder) must
exist somewhere under / for the partition to be mounted to. It can be directly under / or in a
nested directory under /. We call this a mountpoint. What it means is that an empty directory
will be designated to show the contents (data) of a partition. So, we say that internal storage is
partitioned with various partitions such as /boot, /system, /data, /cache, etc. What this really
means is that these partitions are all a part of internal storage, but have been logically
separated so that the system sees them as separate as different physical media (i.e. partitions),
but are then all mounted (made accessible) in one logical location. If you browse files on
/system, then browse file on /data, you're under the root filesystem in both cases, but are
looking in two different actual locations.

This type of thing is certainly not limited to partitions on internal storage. Any time you have
a different physical media, it must be mounted under / just like any other partition. For
example, you have a directory under / called /sdcard. That is a symlink (shortcut) to
/mnt/sdcard, which is a mountpoint for the sdcard. More information on symlinks and how
they work later. For now, just understand that it's basically a shortcut. Anyway, its partition
can be found in /dev, as well, albeit in a different location. It is mounted under /mnt,
accessible under /, all the same. The reason it's mounted under /mnt rather than / is because
Linux based systems usually use /mnt for external device mounts. It doesn't have to, though. It
could be mounted directly under / as /sdcard. It would still work. In any case, think of viewing
the sdcard this way in the same manner that you would connect a usb flash drive to a
Windows computer. When you do that, Windows sees the physical drive, then creates a letter
drive for you to view it's contents. The principle is the same in that Android sees the physical
media, but it mounts it in the same logical location (/) as all the other mountpoints. From a
user's perspective, on Android, all the mountpoint directories look like they may as well be on
the same media, even though they are not. On a Windows computer, when you are done with
a flash drive, you have to tell it to safely eject the hardware. On Android (Linux), you have to
do something similar, called unmount. If you do that to the sdcard, you will no longer be able
to view /sdcard. Though you could create a directory under / called sdcard, it wouldn't have
anything in it, and would be just a directory on internal storage until you remount the sdcard.
Typically, the system mounts and unmounts partitions automatically when necessary.
There are two very important conclusions made from the above:
1) The system mounts and unmounts partitions at boot and shutdown. If you pull the battery
out while the system is running or use a poorly written app to reboot the phone, partitions are
still mounted, and if the system is writing to them, you could easily corrupt something.
Granted, sometimes this is necessary if the phone becomes unresponsive. It's more likely to be
a problem if repeatedly done.
2) Ever wonder why you cannot access the sdcard while the phone is connected to a computer
as a disk drive? It's because the computer is mounting the sdcard partition so that you can see
it there. What does that mean? It means Windows, Linux, etc. (whatever OS you have on your
computer) has *direct* access to that physical media. No two operating systems can have
direct control over physical media at the same time. It would result in massive data
corruption. You may be wondering how it's possible to share drives or partitions in the
networking world. You can do so because the Computer that has the physical media is still the
only host that can physically read and write to the media. Sharing of the data is done at a
much higher level and is controlled by the operating system.
III. Mount Options
Linux based systems have a file called fstab. That file is a mapping of physical partitions and
their mountpoints, along with options it needs to know when mounting said partitions. It uses
this file to mount partitions at boot time. So, the fact that you don't have to mount /system,
/boot, /data, etc. yourself is because the system does it for you. It uses options it's told to use,
though. There are various options that can be specified, but it is out of the scope of this
explanation. What is important, though, is the designation between read/write (rw) and readonly (ro). This option is specified at boot time for automatically mounted partitions.

The partition mounted as /data is mounted as rw. It has to be, otherwise the system would be
all but unusable. You wouldn't be able to install apps, change settings, etc. Do not confuse this
with file permissions. That is a different discussion for a different time, but at least understand
this - file and directories have certain permissions that allow the file owner, the group the file
owner belongs to, and everyone else specific access to said file. Those permissions can be
either the ability to read the file, write (modify) to the file, or execute it. The same goes for
directories (though executing a directory doesn't make sense). The point is that a partition
must be mounted as rw in order for write permissions to work. If you have permission to write
to a file on a partition, but it is mounted as ro, it will not work.
IV. The System Partition
The partition mounted as /system is automatically mounted as read only. It's like this because,
even with root (the unlocked ability to make changes to the partition mounted as /system) it's
dangerous to make changes there if you do not know what you are doing. When you flash a
ROM from recovery, it wipes that partition, and writes new contents to it. Recovery scripts,
however, are smart enough to mount this partition in rw mode. If you are going to make
changes to /system while booted up in Android, you must have /system mounted as rw.
Otherwise, you will just get permission errors even thought you have root level permissions.
To do this, you must remount the partition under /system as rw. There are many ways of doing
this. All of them are system-wide. What that means is, if you use an app to remount /system as
rw, the entire system and any other app will see it such until you reboot the phone or remount
it as ro. Root explorer, for example, has an option in the top right corner to mount whatever
file system you are currently browsing as either rw or ro depending on what it's currently
mounted as. Basically, it toggles between rw and ro. There is also an app in the marketplace
called "Mount /system (rw /ro)", which will do that as well if you don't have root explorer.
Let's look at it in a little more detail, though.
Should you want to remount the partition mounted under /system as rw using the command
line from a terminal emulator, you would run this:
su
mount -o remount,rw -t yaffs2 /dev/block/mtdblock4 /system
The "su" command is how you get root level permissions at the command line. You cannot
change how a partition is mounted without it. Let's break down the second command:

mount is the generic command used to view or modify currently mounted partitions or
any media for that matter.

-o is the option used to specify certain special mount options.

a comma separated list following -o are the options you want to specify for mounting.

remount means that the file system you are mounting is already mounted, and you
want to specify some other options. You would leave this out if the filesystem was not
mounted yet. As /system has to be mounted by virtue of the fact that you're using the
system, you must specify the option to remount.

rw means that you want /system to be mounted in read/write mode. By default, it is

read-only, as previously explained.

-t yaffs2 is the filesystem type of the partition. It's not that important for this
explanation. Just understand that a partition must be formatted with a particular file
system, which basically means how files are stored. Each operating system has the
ability to understand certain file system types. More on this later.

/dev/block/mtdblock4 is the logical location of the partition itself under /dev as

previously explained. Should you want to mount a different partition, you would
replace this line with it.

/system is the location under / where the files belonging to the mtdblock4 partition
will be made accessible. In the case of a remount, these last two strings should not
change from how it is currently mounted. For example, if /system was mounted as
/asdfasdf (just an example), you should not use remount to then mount it as /system.
You'd stick with /asdfasdf. Just a point to remember; it will always be /system in this
case. This is not the case if youre mounting something for your own use, but
changing the mount point of /system would be detrimental.

Once the above is done, a user can then make changes to /system, but only as the root user, of
course. This requires using the terminal emulator after having typed "su" OR using an app that
can run as the root user and browse all partitions. An example is Root Explorer.
Once the user is done making changes, /system should be remounted in ro mode, again, to
avoid making unwanted changed. It's the safe thing to do. Rebooting will take care of it, but it
can be done much quicker by reverting the change manually. Root explorer has the toggle, as
does the other mentioned app. To do it from the terminal emulator, type:
su
mount -o remount,ro -t yaffs2 /dev/block/mtdblock4 /system
The only difference between the two commands is that rw changed to ro. That's it.

V. Current Mounts

If you want to see how the system is currently using various partitions, you can run the mount
command from the terminal emulator by itself, with no arguments or options. It will list
several things including the partition itself, the mountpoint for said partition, and options used
while mounting it (such as rw or ro). If you are interested in only a particular partition, run:
mount|grep /whateverpartition

where whateverpartition is the partition you want to see. For example, to see how /system is
currently mounted:
mount|grep /system
You will see something like:
/dev/block/mtdblock4 /system yaffs2 ro 0 0
All of that information should look familiar now. The 0 0 at the end are other options that you
dont need to be concerned with outside or real Linux administration.
Having an understanding of how this works will help you determine ways of saving space and
making the most of your available storage. The three major partitions are /data, /system,
and /cache. A majority of your 1 GB of internal storage is used by these. The partitions sizes
are set when the partitions are created. By default, this is how they are partitioned:
/system 350 MB
/data 430 MB
/cache 160 MB
As you can see, you only have 430 MB for apps and data. Thats less than half of the
advertised space. There are numerous apps on the market that will display the free space
available on each partition, but it can be done from the command line as well by typing this:
df -h
That will show all mounted partitions, how big they are, and how much free space you have.
You can check the same for just one partition by doing something like:
df -h /system
You can, of course, replace /system with whatever partition you want to see. You will
probably notice that both /system and /cache have a lot of free space. As it turns out, most of
that free space rarely gets used, and cannot be used by you for apps, at all. Its wasted space.
Cache, of course, will show mostly free space, but its necessary for things like OTAs, which
will download to that directory. It does need to be somewhat large, but not *that* big. In any
case, there are ways of having more space available than just 430 MB. The best place to start
is a2sd.
VI. A2sd, Apps2sd, and File System Types
With all of this knowledge in mind, you can probably get a better understanding
of how something like a2sd works. A2sd is a system devised to move all installed
applications to the sdcard. This is by no means the same thing as the built-in

froyo apps2sd.
With Froyo apps2sd:

The developer of a certain app specify that it is allowed to be moved to the

sdcard.

Even when it is, if the app has widgets, those widgets will not be available
once the app is on the sdcard. Why? Because the sdcard is unmounted
once the phone is connected to a computer as a disk drive. If widgets
belonging to such an app were on the homescreen at that time, they would
stop working. Google designed Android to avoid such a case by just
making those widgets unavailable.

Only a part of the app is moved, not the entire thing. If you've ever looked
at at an app that has been moved to the sdcard in manage applications,
you will see that it still is taking up space on internal storage (in /data). The
reason this happens goes back to file system types.

Linux based systems have a certain number of file system types that it can use.
Windows has its own as well. The sdcard needs to be formatted in a file system
that is basically universal. This means that no matter what kind of computer you
plug the phone into, plus the phone itself, you need to be able to view/modify the
contents of the card. That file system is fat32. Both Linux and Windows can
view/modify said contents. BUT, Linux (Android) can't execute anything off of a
fat32 partition. Its use of it is somewhat limited. That being said, Android cannot
move an entire app to the sdcard in its stock condition, as it would be moving it
to a fat32 file system, where it would not be able to execute it.
A2sd has none of these issues, and gets around them in a fairly creative way. The
sdcard, in stock state, has one partition, which is this fat32 partition. You still
need a majority of the card to have this fat32 partition for the purpose of using it
*normally*, but a2sd must use a partition type that is native to Linux. So, the first
thing you must do to use a2sd is partition the card into two separate partitions.
This can be done in recovery. Once it is done partitioning, it formats the two
partitions using a particular file system. The bigger partition, which the user will
continue to see as /sdcard and keep all of there data, remains fat32. The smaller
partition (usually made between 512 MB and 1 GB) is formatted in the ext3 file
system. This ext3 file system type is native to Linux. What does this mean? It
means that Android can use that partition on the sdcard the exact same way it
could internal storage.
Now, You might be asking yourself at this point, doesn't Android have to mount
this new ext3 partition just like it does internal storage partitions and the normal
fat32 sdcard partition? Why, yes it does. It mounts the partition just like any other
partition, but it makes the mount point /system/sd. Once you've created the ext3
partition, you can browse /system/sd. It will look just like a directory in internal
storage, but since it's a mountpoint, when you view it, you're looking on the

sdcard, just in the smaller, ext3 partition. Having done this, you've basically
fooled the system into thinking you have more internal storage. The issue is that
Android will look for apps in two main places - /data/app and /system/app. if you
just stuck an apk (Android application) in /system/sd, Android system would
never find it, as it will never look there. For those interested in seeing how the
sdcard partitions are mounted, run these two commands:
mount|grep /sdcard
mount|grep /system/sd
The output for /system/sd, for example, looks like:
/dev/block/mmcblk0p2 on /system/sd type ext3
(rw,noatime,nodiratime,errors=continue,data=writeb ack)
Both of those commands, though, will show how the fat32 sdcard partition is
mounted (/mnt/sdcard) and how the ext3 sdcard partition is mounted
(/system/sd). As you can see, mmcblk0p2 is the ext partition, while the majority
of the card (the fat32 partition) is mmcblk0p1. Another quick important point is
that /system/sd is mounted as rw so that you can make changes. Remember this
- if a partition is mounted as ro (/system) but a directory under it is used as a
mountpoint (/system/sd) you will still be able to write to whatever is mounted
under that second directory as long as the partition is mounted as rw. That being
said, you can leave /system mounted as ro, and still always make changes to
/system/sd.
Anyway, a2sd is how you use this new ext3 partition. The first thing a2sd does is
move all applications from /data/app and /data/app-secure to /system/sd/app and
/system/sd/app-secure. Remember that with *just* this step, the system would
not see apps anymore. At this point, a2sd makes use of something called a
symlink. Think of a symlink as a shortcut in Windows. When you create file in a
particular folder, then make a shortcut to that file from a different folder, it exists
in the first folder, but is accessible from the second folder. The same holds true
for folders. A symlink is basically the same thing. So, a2sd removes the /data/app
and /data/app-secure directories, then creates symlinks (shortcuts) called
/data/app and /data/app-secure that point to directories in /system/sd for apps.
This means that the system will continue to look in /data/app and /data/appsecure for apps, but will be directed to /system/sd. Basically, the system doesn't
care where files actually are. It only cares that it can find them where it knows to
look.
A2sd can also be used to move dalvik cache to the sdcard. It does this in exactly
the same manner as moving apps. Dalvik cache is normally stored in /data/dalvikcache. A2sd creates a directory in /system/sd for dalvik-cache, then creates a
/data/dalvik-cache symlink that points to the real location.
As dalvik cache is stored in /data by default, it takes up your usable storage,

needlessly. That is why it can be moved to the sdcard ext3 partition. If you
choose to, though, it can also be moved to the /cache partition. /cache is
normally just unused space on internal storage that is way bigger than it needs to
be. Thus, dalvik cache can be moved there instead, too. The idea is the same, but
it doesn't use symlinks. It does some creative work with the mount command to
make the system look there for it. How it actually works is out of the scope of this
information.

VII. Other Space Saving Options

Some people do not want to use a2sd, as they do not have good enough sdcards
and are not interested in buying a new one. A2sd will not work well with a slower
card, such as the one that comes stock with the Evo. However, it is possible to
reclaim some of the unusable internal storage. If you remember, /data, /system,
and /cache make up a majority of your internal storage. They can be resized with
this mod.
That process is only recommended for advanced users and only under certain
circumstances. Should you decide to move all apps and app data to the sdcard
using a2sd, there is no purpose in resizing the partitions. Very little else goes in
/data. Basically, either use a2sd to its fullest extent or resize partitions. Dont do
both.

http://androidforums.com/evo-4g-all-things-root/278898-android-partitionskernels-explained.html
http://www.addictivetips.com/mobile/how-to-install-a-custom-recovery-to-anandroid-phone-device/

How To Backup Your Android Phones

Boot, Recovery And System Partition
Images
By Haroon Q. Raja on Dec 30 2010 10 Comments

One cant stress enough on the importance of backups and when it comes to tinkering with
your Android phone, a backup of your system, recovery and boot partitions can save you a lot
of hassle that you might otherwise have to go through if you mess things up and need those
stock images. In this guide, we will tell you how to take these backups using a free tool called
RomDump.
Although you can find these backups on the
internet, those have been taken by other users
and you never know if they have been
modified to contain malicious code or not.
Secondly, you cant be too sure if they would
work with the exact specifications of your
phone or not, as even for the same phone
model, there can be differences depending on
the phones regions, intended carriers and other similar factors, and flashing a wrong boot,
system or recovery image to your phone can most likely brick it. Therefore, it is always a
great idea to take backup images of these partitions of your device yourself before you
attempt to modify them, so that they can be recovered later if anything goes wrong.
RomDump is a free tool that lets you do just that. It is quite easy to use for anyone who is
comfortable with typing a few commands, and effectively creates backup images of your
Android phones boot, recovery and system partitions. It requires your phone to be rooted first
and you will either need ADB installed on your computer or a terminal application installed
on your Android device.
Now that we have had an overview, lets proceed to actually getting things done.
Before you proceed:

Make sure that your device is rooted. If it isnt, do a quick search on our site for root
phone_name without the quotes, replacing phone_name with the name of your
device. You will find an easy to follow guide on rooting your phone.

In case you are using the ADB method, make sure you have ADB installed on your
computer. If it isnt, refer to our guide on what is ADB and how to set it up on your
computer.

On the other hand, if you are going to use a terminal application, download and install
Android Terminal Emulator which is available for free in the Android Market.

Now proceed according to the method that you chose.

ADB Method:
1. Download RomDump from the link given below, extract the file named install from
the downloaded zip archive to your computer and copy it to the tools folder of your
Android SDK installation folder.
2. Connect your phone to your computer via USB and make sure USB debugging mode
is enabled in Settings >> Applications >> Development.

3. Open a command prompt window and enter the following commands:

4. adb push install /data/local/
5. adb shell chmod 04755 /data/local/install
adb shell /data/local/install

6. You might see some output of the above command. Wait until it finishes.
7. Enable and then disable Wi-Fi on your Android phone. If it was already enabled,
disable, enable and then disable it again.
8. Type this command in the command prompt window on your computer:
adb shell romdump

9. Wait patiently for the process to finish and youre done. You may now exit the
command prompt.
Terminal Method:
1. Download RomDump from the link given below, extract the file named install from
the downloaded zip archive to your computer and copy it to the root of your phones
storage card.
2. Launch Android Terminal Emulator (or any other terminal app of your choice) on your
Android phone and enter these commands:
3. su
4.
5. cat /sdcard/install >/data/local/install
6. chmod 04755 /data/local/install
/data/local/install

7. You will see some output of the above command. Wait till the output finishes.
8. After this last line has appeared, enable and then disable Wi-Fi on your phone. If it
was already enabled, disable, enable and then disable it again.
9. Type this command in Terminal Emulator:
/system/bin/romdump

10. Wait patiently till the process finishes and youre done. You may now exit Terminal
Emulator.
If you have completed the above steps for any of the two methods successfully, you will find
a folder named romdump on the root of your SD card that contains a subfolder by the name
of your device model. This folder will contain the boot, system and recovery partition images.
Alternative Method If The Above Does Not Work:

If this method does not work for you and all you need to backup is your recovery and boot
images, you can simply do so as follows.
Note: Do NOT attempt to backup the system partition using this method as the system image
it produces this way will NOT be a valid system image to be used later to restore your system
partition. Use it only for the recovery and boot partition images.
1. If you are using ADB, connect your device to your computer via USB, launch a
command prompt window on your computer and enter the following command:
adb shell

If you are using Terminal Emulator instead, just launch it on your Android phone and
enter the following command and agree to grant any permissions youre prompted for:
su

The remaining process will be the same for both ADB and Terminal Emulator.
2. Enter the following command:
cat proc/mtd

3. You will get an output similar to this. Note that your result may differ from this one
and you must proceed according to the output that you get, rather than the example
that you see here.
4.
5.
6.
7.
8.
9.

dev:
mtd0:
mtd1:
mtd2:
mtd3:
mtd4:
mtd5:

size
000a0000
00480000
00300000
0fa00000
02800000
093a0000

erasesize name
00020000 "misc"
00020000 "recovery"
00020000 "boot"
00020000 "system"
00020000 "cache"
00020000 "userdata"

10. To dump the recovery image to your SD card, make note of the first word of the line
which says recovery in the end. It is mtd1 in case of this example but may be
another entry for you. Now use this command, replacing mtd1 with the term that
applies in your case, if different:
dd if=/dev/mtd/mtd1 of=/sdcard/recovery.img bs=4096

11. Similarly, to dump the boot image to your SD card, make note of the first word of the
line which says boot in the end, which is mtd2 in our case but may differ for you.
Use this command now, replacing mtd2 with the term that is applicable in your case,
if different:
dd if=/dev/mtd/mtd2 of=/sdcard/boot.img bs=4096

Thats it you now have recovery.img and boot.img backed up on the root of your SD card.

Installing the Radio Update

Next you will want to confirm your Radio Baseband.

To Confirm this Press Menu - Settings - About Phone - Scroll down till you see
Baseband version.
Compare the Baseband value to the table below to see if you are using the
correct radio for your build or if you need to update.
To update the Radio:
1 Download the Radio zip.
2 Rename it to "update.zip".
3 Copy it to the root of your phone's SD card.
4 Turn your phone off.
5 Start up in recovery mode by holding Home and pressing Power.
6 Press ALT+S to apply the update.
7 Once the update is applied press Home+Back to reboot the phone. The Phone
will start to boot up and then continue applying the update. Once this is
completed the Recovery menu will ask you for the second time to reboot the
phone via Home + Back

Once this is done double check the Baseband has been updated properly via:
Press Menu - Settings - About Phone - Scroll down till you see Baseband
version, you should see the radio version on this row if not you will need to
update the Radio again.

fiecare ROM buid are o veersiune de

radio baseband

About SPLs
This page contains information about SPLs for the HTC Dream (aka T-Mobile G1 and ADP1).
What is a SPL? The SPL, or Second Program Loader, in conjunction with the IPL comprise a
device's bootloader. Aside from bootstrapping Android, the bootloader also fulfills various
diagnostic functions. One of these functions is the manipulation of data in the device's internal
flash ram. Depending on the SPL installed, the user can apply a signed NBH file, flash nand
images, and more. Note that the SPL is installed and operates independently of the Android
build that runs atop it.

HardSPL (recommended)
VER: HSPL10.95.3000
ZIP: splhard1_update_signed.zip
MD5: 6502af25b9e9fbe1322cc405559af1ca
SHA1: 59485b21f69acb6e9f70a4cd5ff4aefea722fc50
HardSPL is a modification of the Engineering SPL by cmonex. In addition to the functionality
of the Engineering SPL, HardSPL also allows NBH files to be used without matching the CID
(carrier ID) check. At the current time the main benefit of this is to allow European G1s flash
American NBH files and vice versa. All other features and attributes of the Engineering SPL
(such as the ability to flash the mtds from nand backup images) are present. Using the
Nandroid backup scripts to create nand backups for this purpose is recommended.
LG Optimus 2X
--->ROM: CyanogenMod 7 Nightly (link)
->Kernel: Default CM7 Kernel
->Theme: Aerish GTX CM7 (link) + Go Aerish GTX (link)
->Other mods: ext4 (link)
--Bitdefender Mobile Security (support thread) (download link)
Pasul trei: dezinstalarea unor programe despre care se stie ca ar creea probleme
MARI Car Home si F-Secure, programe preinstalate.
In 2-3 zile am urmarit cu ajutorul programului Advanced Task Killer Froyo toate
progrmelele care rulau in background fara ca eu sa le activez si cele de care nu
ma folosesc niciodata dezinstalate. Toate procedurile de dezinstalare au fost
facute cu Titanium Backup.
Recomand ca imediat dupa root si dezinstalarea tuturor programelor
nefolositoare si mancatoare de resurse si baterie sa se efecueze un Master Reset.
Un sfat extrem de important: cititi biblia acumulatoarelor (cum imi place mie sa
o numesc )
http://batteryuniversity.com/learn/article/how_to_charge_when_to_charge_table
Concluzia pe scurt a articolului din link-ul de mai sus:

1. nu descarcati complet telefonul!

2. Nu incarcati full niciodata telefonul!
3. Incarcarile scurte si dese, cheia marilor succese!

Programe care ajuta in mod REAL la economisirea bateriei:

1. APN ON-OFF (inchide si deschide legatura la internet prin 3G, legatura care
trebuie inchisa cand nu se foloseste).
2. POWER CONTROL scoasa pe ecranul telefonului din Widgets (puteti vizualiza
direct WI-FI, Bluetooth, receptie sateliti, SYNC ON si luminozitatea display-ului).
3. SYNC SETTINGS cu care puteti vizualiza dintr-un singur click starea
Background data una dintre cele mai mari consumatoare de baterie in standby (trebuie bifata exclusiv la vizitarea site-ului Android Market si a altor aplicatii
care o solicita, debifati imediat dupa!!).
4. Advanced Task Killer Froyo.

-am fcut update la 2.3.4, root, am scos tot bloatware-ul, am schimbat launcher-ul cu Zeam,
setat reeaua pe GSM/2G only + alte mici tweak-uri i bateria ine exact ca la orice
smartphone Android modern configurat corect(1 zi de folosire normal-intens, 2 zile de
folosire mai lejer, poate chiar i 4-5 de stand-by).
Dac instalezi 1000 de porcrii pe el, dup care i bagi un Task killer(cea mai mare prostie
pe Android) c aa i-a spus nu tiu ce expert, normal c l sufoci i dup-aia te plngi c e
prost dei el sracul nu are nici o vin.
su
# mount -o remount,rw -t yaffs2 (your device /system path) /system
remontare partitie system in rw pt a scrie in ea
# cat /sdcard/flash_image > /system/bin/flash_image
# chmod 755 /system/bin/flash_image
# mv /system/etc/install-recovery.sh /system/etc/install-recovery.sh.bak
# flash_image recovery /sdcard/(your device recovery.img name)
# sync