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 phone’s 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.HHBOOT-1.33.2010 (SAPP50000)CPLID-12RADIO-3.22.26.17June 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 offThe line that starts with HBOOT gives you your SPL version, in my case it's 1.33.2010The 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 radioWith 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 partitionsystem - 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/S-OFF).

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 system–dupa 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 functions–un 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 androidsource( bootable/recovery/* code , just go through it, it is very basicsimple "C" code .

Recovery code will work as your rootfs for making recovery image. and thatimage u need to write in a partition. which will be a combination or zImageand 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 disheHow 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.

Let’s 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. Let’s 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 user’s 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 doesn’t 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 device’s 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 you’re losing and what not and thus, you’ll 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 S-OFF, 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 reverse-engineering 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 read-only (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:

sumount -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 you’re 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:

sumount -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 don’t 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. That’s 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. It’s wasted space. Cache, of course, will show mostly free space, but it’s 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 /sdcardmount|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/app-secure 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/dalvik-cache. 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. Don’t do both.

http://androidforums.com/evo-4g-all-things-root/278898-android-partitions-kernels-explained.html

http://www.addictivetips.com/mobile/how-to-install-a-custom-recovery-to-an-android-phone-device/

How To Backup Your Android Phone’s Boot, Recovery And System Partition ImagesBy Haroon Q. Raja on Dec 30 2010 10 Comments

One can’t 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 can’t 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 phone’s 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 phone’s 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, let’s proceed to actually getting things done.

Before you proceed:

Make sure that your device is rooted. If it isn’t, 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 isn’t, 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 you’re 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 phone’s storage card.

2. Launch Android Terminal Emulator (or any other terminal app of your choice) on your Android phone and enter these commands:

3. su4. 5. cat /sdcard/install >/data/local/install6. 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 you’re 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 you’re 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. dev: size erasesize name5. mtd0: 000a0000 00020000 "misc"6. mtd1: 00480000 00020000 "recovery"7. mtd2: 00300000 00020000 "boot"8. mtd3: 0fa00000 00020000 "system"9. mtd4: 02800000 00020000 "cache"

mtd5: 093a0000 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

That’s 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 SPLsThis 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.3000ZIP: splhard1_update_signed.zipMD5: 6502af25b9e9fbe1322cc405559af1caSHA1: 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 progrămelele 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_tableConcluzia 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 stand-by (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 făcut update la 2.3.4, root, am scos tot bloatware-ul, am schimbat launcher-ul cu Zeam, setat rețeaua 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 porcării pe el, după care îți bagi un “Task killer”(cea mai mare prostie pe Android) că așa ți-a spus nu știu ce expert, normal că îl sufoci și dup-aia te plângi că e prost deși el săracul 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