Related
As a tentative newcomer to the world of flashing ROMs, I've searched the forums but not found clarification on the following:
If I was to flash a cooked ROM onto a Windows Mobile device (say a Touch HD on the UK T-Mobile network), would the phone still have access to the settings/configuration it needs in order to access the T-Mobile network for data, SMS, etc without any further work or reconfiguration required on my part?
If so, where are those settings held such that they are unaffected by flashing?
If not, would I need to locate and back up the necessary settings prior to flashing? How is this generally done to ensure that no settings are missed?
Thanks in advance to those taking the time to reply.
most new roms have the major networks info built in.. so it should set your network up automatically both for SMS and phone usage.. about data connections.. I don't think it would be set up automatically unless the rom is already setup for a specific network.
Everything is affected by flashing. all your data and configuration will be erased thus you will have to setup the data connection again.
you can backup your data prior to flashing
you can find a backing up guide in my signature under the GUIDES thread
I see - thanks. I've noticed a few mentions of ExtROM - is this the part of the ROM where such settings are stored?
Also, when using a device such as the Touch HD which (unless I am mistaken) has no onboard storage, when a user installs a new program onto the device, where are the new files (DLLs etc) actually installed to? And where is the registry held so that it can be updated during installation (or when editing manually)?
If I understand correctly, the installed ROM cannot be changed unless you replace it completely by flashing. So if the ROM contains the operating system (including the registry) then how is it possible to edit this?
clockworktangerine said:
I see - thanks. I've noticed a few mentions of ExtROM - is this the part of the ROM where such settings are stored?
Also, when using a device such as the Touch HD which (unless I am mistaken) has no onboard storage, when a user installs a new program onto the device, where are the new files (DLLs etc) actually installed to? And where is the registry held so that it can be updated during installation (or when editing manually)?
If I understand correctly, the installed ROM cannot be changed unless you replace it completely by flashing. So if the ROM contains the operating system (including the registry) then how is it possible to edit this?
Click to expand...
Click to collapse
The Touch HD actually has 512 MB of ROM memory (on-board memory)...
As far as the ExtRom, this is a part of memory that most device carriers use to put their "junk" in. These are normally either hidden, or otherwise not accessible by normal means. Anyways, the settings (as nir36 pointed out) are in the ROM itself, so whether you have an Extrom or not is irrelevant as far as network settings.
Just to put it in simple terms, flashing a device means completely wiping out everything you have in there... kinda like formatting a hard-drive. The only thing that is left is the bootloader, which is not located in the rom memory, so this doesn't get wiped out with an OS flash.
Lastly, the registry is part of the OS. Therefore, when you wipe out your OS by flashing, the registry goes bye bye as well...
Hope this helps some...
egzthunder1 said:
The Touch HD actually has 512 MB of ROM memory (on-board memory)...
As far as the ExtRom, this is a part of memory that most device carriers use to put their "junk" in. These are normally either hidden, or otherwise not accessible by normal means. Anyways, the settings (as nir36 pointed out) are in the ROM itself, so whether you have an Extrom or not is irrelevant as far as network settings.
Just to put it in simple terms, flashing a device means completely wiping out everything you have in there... kinda like formatting a hard-drive. The only thing that is left is the bootloader, which is not located in the rom memory, so this doesn't get wiped out with an OS flash.
Lastly, the registry is part of the OS. Therefore, when you wipe out your OS by flashing, the registry goes bye bye as well...
Hope this helps some...
Click to expand...
Click to collapse
Thanks for this reply
I understand that the ROM is on-board memory and that a flash replaces all of it, including the OS.
What I don't understand is how registry edit tools (e.g. Resco) work. Since the registry is part of the OS and resides in the ROM, how can the registry be edited, i.e. written to, so that the changes are still there even when the phone is turned off and back on?
(I am presuming that the registry editing tools don't do any kind of flash operation.)
ok, first of all, registry settings are not saved on the ROM but on the internal storage.
the ROM files CAN be replaced but only "apparently" not "really".. that is, when you flash a rom, the files from the rom will stay on the device whether you replace them or not.. but if you copy over them, the device will read from the new files WHILE still keeping the other rom files (since they can not be deleted).
the touch HD has 512megs of ROM memory and 256megs of RAM memory..
nir36 said:
ok, first of all, registry settings are not saved on the ROM but on the internal storage.
the ROM files CAN be replaced but only "apparently" not "really".. that is, when you flash a rom, the files from the rom will stay on the device whether you replace them or not.. but if you copy over them, the device will read from the new files WHILE still keeping the other rom files (since they can not be deleted).
the touch HD has 512megs of ROM memory and 256megs of RAM memory..
Click to expand...
Click to collapse
Alright I'm getting closer to fully understanding! Here's a couple of statements and follow-up questions, please correct me where I'm wrong.
Statement:
So when copying over a file that is in the ROM, the original file remains in the ROM but the system somehow knows to read from the replacement file, which is held elsewhere on the device.
Question:
How does it know when a ROM file has been replaced, and where to look for the replacement file?
Statement:
If the replacement file is installed to the device, but cannot itself be in the ROM, then presumably it must be in the RAM. If so, then I would expect that turning the phone off or removing the battery would clear the RAM, causing the replacement file to be lost, effectively resetting the changes.
Question:
Is this the case or is there some internal battery which keeps the RAM alive, and only an explicit hard reset can clear the RAM?
Please can anyone help with my follow up questions?
Thanks
1. yeah.. it stays.. dunno how the reading is done tho
2. when a rom is replaced all those files which you replaced are erased. flashing a rom is like performing a format, nothing is kept and the OS is reinstalled.
3. flash memory is not like computer ram.. it uses capacitors to reserve data.. and it takes years before it is erased
Ah so it's Flash memory, right!
So the internal Flash memory is used both as a RAM workspace and for storage space for stuff installed to the device...apps etc.
Thanks Nir!
Hi everyone! I'm new to Android. I recently bought a T-Mobile G2X / LG-P999, flashed the recovery partition with NVFlash (ClockworkMod) and installed CyanogenMod 7 (nightly). It's working great so far. My question is this: is it possible to flash only the /system partition at a later time with a newer build of CM7? For example, there is a Netflix app available that allows non-approved devices to connect to Netflix. I've tried installing this, but am suffering from the "chipmunk" problem where both the video and audio play back too fast. I read somewhere that an update the the media layer may fix this. It would be convenient to update the entire system partition once newer releases / fixes come out to address problems like this, without wiping out my data.
Also, I've noticed that most of the partitions are listed as ext3 when running mount to view mounted partitions. This seems to be in conflict with what apparently should be the yaffs2 file system. Is CM7 using ext3 instead of yaffs2? I found some source code I compiled that allowed the extraction of the factory G2X ROM dumps, which seemed to be yaffs2 (I did this because I wanted to reinstall the NFS Shift game that ships with the G2X). I suppose it's possible that the original ROMs could be in yaffs2 format, while CyanogenMod defaults to ext3.
Sorry if these are easy questions, but I am really excited about learning more about this OS and doing a little development of my own!
No advice, eh? Well, I'll simplify the question.
If I'm flashing nightly CyanogenMod builds, I'd like to be able to update them every few days, weeks, etc. However, I don't want to have to erase my data so I'd like to only flash the /system partition without touching anything else.
The CyanogenMod zip file contains a system.img, which is what I need to replace /system on my device. However, Clockwork Mod Recovery only has options for flashing complete zip files. Is it possible, perhaps, to just take system.img and zip it? Will ClockworkMod Recovery then only flash the /system partition?
I figured it out, so I'll post my findings:
CyanogenMod nightly zip files contain only boot (kernel) and system files. So, by booting into ClockWorkMod Recovery and choosing "install zip from sdcard," you can update to a new nightly without affecting user data. I assume only the boot.img and /system files are updated. This is what I did, and it seemed to work fine. None of my data was affected!
conclusion first: it was possible.
i searched for custom mtd info for chacha on google, and i found some info in chinese suggested it was possible to apply custom mtd on chacha.
http://wenku.baidu.com/view/b029ab6027d3240c8447ef67.html
i don't speak chinese, but google translation helped. i used Mikevhl's recovery (http://forum.xda-developers.com/attachment.php?attachmentid=749943&d=1318622558), and also FR-Custom-MTD-v1.5.6-boot.zip (http://115.com/file/aqvgn30z#) and FR-Custom-MTD-v1.5.6-recovery.zip (http://115.com/file/aqvgnzmc#) as the chinese instruction said although i don't know where these files came from (maybe somewhere here?)
the procedure itself was the same as desire (bravo) or any other devices, and after the process, i got;
Filesystem 1K-blocks Used Available Use% Mounted on
tmpfs 214004 32 213972 0% /dev
/dev/block/mtdblock4 5120 1624 3496 32% /cache
/dev/block/mtdblock3 153600 150292 3308 98% /system
/dev/block/mtdblock5 307200 2560 304640 1% /data
yay!!
unfortunately, adlx.xda's v5.0.2.8 didn't work with these patches... sorry, if this info is already around here.
p.s. as usual, this patch automatically mounts /cache to /sd-ext when /cache partition is smaller than 20mb. however, /cache/download won't be created automatically which means vending.apk (market) fails to start. when you set /cache less than 20mb, you'd need create sd-ext partition on your sd card and either add init.d script to create /cache/download ot do it manually.
Interesting, but sorry I don't read chinese :-(. I understand it's for changing the default partition layout on the Chacha.
Isn't it easier to use App2SD?
What are the patches? Do you why it doesn't work with my CWM build (maybe we can improve it so it work).
adlx.xda said:
Interesting, but sorry I don't read chinese :-(. I understand it's for changing the default partition layout on the Chacha.
Isn't it easier to use App2SD?
What are the patches? Do you why it doesn't work with my CWM build (maybe we can improve it so it work).
Click to expand...
Click to collapse
hi adlx.xda,
i don't read chinese, either;-)
it is sure easier for most people to use app2sd or data2sd, but i prefer to keep everything in the internal memory because it is possible if you change the partitions and don't install millions of apps. it is kinda a surprise to me that you didn't know about custom mtd...
anyway, the patches were originally created for htc desire, and adopted to other htc devices with low internal memory capacity like chacha/wildfire/etc.
http://forum.xda-developers.com/showthread.php?t=806321
there were two patches in the package; one for recovery partition and the other for boot partition. the recovery patch allows you to burn a custom rom according to the designated partition info. the boot patch allows you to change the boot image so that the device recognize the new partition info on boot.
when i use your recovery and the recovery patch together to burn a custom rom, chacha does not boot. i guess the patch does not modify something in your recovery correctly. on the other hand, this patch correctly modifies Mikevhl's old recovery. it is strange the patch can be used for the latest recovery for htc desire...
thx for your attention.
qt
could also be the repackaging of the kernel if it's patched. I tried for weeks unsuccessfully to unpackage and repackage a kernel for the status/chacha and had no luck. I was wanting to do some clocking tweaks.
bedwa said:
could also be the repackaging of the kernel if it's patched. I tried for weeks unsuccessfully to unpackage and repackage a kernel for the status/chacha and had no luck. I was wanting to do some clocking tweaks.
Click to expand...
Click to collapse
How do you try to unpack/repack? I wonder why it would fail.
I'll have to look at my setup on my netbook and get back to you. May be a few days. :-\ Kinda swamped ATM.
My Tab makes calls Yo! GT-P6800
i do read chinese, i saw this fews mths back but i dont have time for it... you will left with 24x~26xmb of free space.
I just wanted to update and say that I replied to this thread:
http://forum.xda-developers.com/showthread.php?p=35367602#post35367602
Basically, I'm wondering if the CustomMTD patches might be more compatible with a newer version of CWM compiled for our phone. I built a copy of 6.0.1.5, which mostly works, so if someone wants to give it a try, please do.
I managed to see custom partitions from CWM (not with the patches, but manually altering the recovery). 312MB /system and ~120MB /data (as an example just to try)
Apparently no problem with /system, but /data is not "working":
It appears as Read Only (it shouldn't actually event mount after moving/resizing it). Also not only it mounts, but it appears as 100%full, and won't allow me to do anything. I can't reformat it, remount rw,... I don't know why to be honest.
Now that I think about it, I should check dmesg.
dead links
it looks like all the links are dead.
here are the files you need.
qtotter said:
it looks like all the links are dead.
here are the files you need.
Click to expand...
Click to collapse
I managed to have it working, but I posted on another thread: http://forum.xda-developers.com/showpost.php?p=38029256&postcount=9
adlx.xda said:
I managed to have it working, but I posted on another thread: http://forum.xda-developers.com/showpost.php?p=38029256&postcount=9
Click to expand...
Click to collapse
so what files do we need, and what exactly do we do with them? I'd love to do the same as what you got working.
kronflux said:
so what files do we need, and what exactly do we do with them? I'd love to do the same as what you got working.
Click to expand...
Click to collapse
IIRC I used no files/patch,... It was more a matter of doing the partition table right. I took some notes and made an excel spreadsheet to help me with the conversions.
I'm on holiday starting today, I probably won't be able to review my notes and write anything related to this this month. Ping me again in Septembre so I review my notes and write a post about it .
kronflux said:
so what files do we need, and what exactly do we do with them? I'd love to do the same as what you got working.
Click to expand...
Click to collapse
it came from this thread originally http://forum.xda-developers.com/showpost.php?p=8578368&postcount=1, and it is very common among HTC Desire users.
it is quite easy to change partition sizes, and all the files you need are the three files that i uploaded.
recovery_chacha.img: Mike's old recovery that is compatible with this method. Don't use other recoveries!!
FR-Custom-MTD-v1.5.6-recovery.zip: This will patch recovery so that it can handle new partition sizes.
FR-Custom-MTD-v1.5.6-boot.zip: This will patch boot (kernel) in NAND so that the system can handle new partition sizes.
Procedure for ChaCha:
Make sure your phone is S-OFFed
**Make a backup in recovery first**
Place FR-Custom-MTD-v1.5.6-recovery.zip & FR-Custom-MTD-v1.5.6-boot.zip on SD card
Create mtdpartmap.txt on SD card with size of system & cache like "mtd 125 5". For example, I wanted to use ajeevlal's cm10.1 with Japanese IME and other system apps built in /system, I needed 330MB on /system and only 5MB on /cache (because I didn't need large /cache to use int2ext+.) So, my mtdpartmap.txt was "mtd 330 5". if you want to do this by shell command, it's gonna be like: echo "mtd 330 5" > /sdcard/mtdpartmap.txt
Flash Mike's old recovery above in fastboot like "fastboot flash recovery recovery_chacha.img"
Reboot into recovery
Wipe system, data, and cache
Flash FR-Custom-MTD-v1.5.6-recovery.zip, this patches recovery to use the new partition sizes
Reboot into recovery
Wipe system, data, and cache again just in case
Flash ROM, or restore from backup, and it will be flashed to NAND based on new partition sizes
Prior to rebooting, flash FR-Custom-MTD-v1.5.6-boot.zip, this patches boot (kernel) in NAND to load with the new partition sizes.
Reboot
unless you change mtdpartmap.txt on SD card, you don't need to repeat 1 - 8 every time. once you have decided your favorite partition sizes, you can start from 9. also, if your backup includes a patched boot image already, you can even skip 12 as well.
if you do this with any other newer recoveries, your phone simply does NOT boot. Mike's old recovery cannot backup sd-ext partition, but you can always do it manually like "dd if=/dev/block/mmcblk0p2 of=/sdcard/ext-bkup.img bs=4096" or something anyway.
kronflux's recovery
by the way, i tried your CWM 6.0.1.5 Built From Adlx http://forum.xda-developers.com/showthread.php?t=1989839, but it does not patch boot correctly. so the phone won't boot.
as i repeatedly keep saying, you need mike's old recovery to do this. i have tried so many recoveries, and this old one is the ONLY that is compatible with these patches.
qtotter said:
by the way, i tried your CWM 6.0.1.5 Built From Adlx http://forum.xda-developers.com/showthread.php?t=1989839, but it does not patch boot correctly. so the phone won't boot.
as i repeatedly keep saying, you need mike's old recovery to do this. i have tried so many recoveries, and this old one is the ONLY that is compatible with these patches.
Click to expand...
Click to collapse
it's also too large to fit in the recovery partition properly I believe. would be great if we could come up with a partitioning table that has enough space for it, as well as a little more space for app/rom storage.
so what are you saying, that we need this other recovery to actually do the partitioning? or that only that recovery will work on a custom partition table?
Adlx was just saying above, he doesn't think he used any custom files or patches. naturally we'll see in september what he has to say about it.
I did it with my recovery, not Mike's, and it worked, but again, I did it manually.
Sent from my Galaxy S4 running CarbonRom "Adlx Edition"
kronflux said:
so what are you saying, that we need this other recovery to actually do the partitioning? or that only that recovery will work on a custom partition table?
Click to expand...
Click to collapse
basically, this process patches recovery and boot to rewrite the partition table. Only Mike's old recovery can do both correctly.
talking about other recoveries, the reason why the phone doesn't boot is either recovery patch failure or boot patch failure. because i know Mike's one works and am not a recovery dev, i didn't even try to find which part is not working.
however, you can easily check it by switching the recovery between patching recovery and patching boot. i guess the former part is not working correctly because the latter part is rather straight forward and simple.
i just don't understand what you want, actually. changing the partition sizes or learning the mechanism of changing partition table??
qtotter said:
i just don't understand what you want, actually. changing the partition sizes or learning the mechanism of changing partition table??
Click to expand...
Click to collapse
Essentially, changing the sizes of partitions to accommodate a larger recovery image(so that my CWM6 could be flashed and work properly), as well as add more space to the system partition so that we don't have to worry about flashing lite versions of Gapps, or slimming down roms so that they fit.
kronflux said:
Essentially, changing the sizes of partitions to accommodate a larger recovery image(so that my CWM6 could be flashed and work properly), as well as add more space to the system partition so that we don't have to worry about flashing lite versions of Gapps, or slimming down roms so that they fit.
Click to expand...
Click to collapse
i have already explained how to do it above... now, my /system is 330 MB, and /cache is 5MB to cooperate with ajeevlal's cm10.1, full gapps, additional system apps and int2ext+. i am quite happy with my chacha setting not worrying about free space of /data, and battery lasts almost forever during sleep.
well, it is such a simple procedure, but i don't need to promote it to other people myself. i simply wanted to share the info that i learned over one year ago with people who want to make /system smaller for stock rom or make /system larger for cm10 and above.
I suppose I'm thinking of radio, touchscreen drivers and other drivers/stuff that doesn't come with a custom ROM.
thanks!
Don't think so.
TWRP tells you what it is capable of backing up:
System
Data
Boot
Recovery (default unchecked)
cache
.android_secure (default unchecked)
If you're making that large of a jump, say CM10 etc back to sense, I've found it works best to flash the target rom, boot it, then go back and do a restore. That way you get the items that TWRP doesn't backup.
mrjayviper said:
I suppose I'm thinking of radio, touchscreen drivers and other drivers/stuff that doesn't come with a custom ROM.
thanks!
Click to expand...
Click to collapse
If you're on hboot 1.14 and S-ON then twrp doesn't backup or restore your boot
Pretty sure it does not do drivers
thanks everyone!
If you back up /boot you are backing up the drivers as that term refers to the pieces of the kernel itself that talk to specific hardware.
However many hardware parts also have their own code called "firmware" that handles the really complex low-level hardware control but doesn't run as part of the OS kernel. In this case the kernel driver talks to the firmware on a simpler level and firmware does the really dirty work. The radio and touch screen are examples of hardware that relies on extra firmware, and these particular files are not backed up by TWRP because they are stored in other partitions*
*note: CM stores it's own copy of the radio in /system which means the CM radio would get backed up. But changes to that won't affect the radio that Sense uses, and vice versa.
Hi guys .You all know me.
I have created this thread for the sole purpose educating every newbie and noob about ROM and it's components...
Here goes
Parts of a ROM
i. The kernel.
Android (like many other Smartphone operating systems) runs on the Linux kernel. The Linux kernel was created in the early 1990’s by a gentleman named Linus Torvalds in Helsinki, Finland. It’s incredibly stable, incredibly friendly, and incredibly difficult for the layman to understand and modify. Thankfully it’s also very popular so it has been ported on to a multitude of hardware, including our Android devices.
Think of the kernel as an interface layer between the hardware and software on your device. The kernel decides when things happen, such as the LED indicator gets lit or when the soft button's LED gets lit. An application sends a request to the operating system to blink the LED. The operating system then sends the request to the kernel, which makes the light flash for the amount of time requested by the OS.
What sounds like a round-about way to get things done is also what makes the system so scalable and robust. Application developers only have to code in a way the operating system understands and the kernel makes it work on the hardware. This also keeps the application running in it’s own user-space and separate from the kernel. That means when you run the latest uber-cool app that wasn’t designed for your particular OS version, or is still very beta and it crashes, the kernel gives you the option to Force Close the application and the kernel can run untouched.
In a standard Android ROM (we will leave developer images and the like for another discussion) the kernel is bundled along with a set of instructions that tell the device how to load the kernel and the OS during boot. This is the boot.img that you see inside a zipped ROM that your not able to easily open. The device knows to extract this image to internal memory (the ramdisk) and follow a series of scripts (init scripts) to load the kernel and then the other portions of the OS. That’s what’s happening while you’re watching the boot animation. Interestingly enough this is done the same way for a PC, your smartphone, an Android tablet, or even a smart Linux powered toaster. If you’re feeling exceptionally geeky, plug your Android phone into the USB port on your PC and let the PC boot from the USB device. No, it doesn’t actually load, but you can watch the animation while it tries to match up the hardware support with what’s inside your PC. As I said, Linux is amazingly scalable and as a result so is Android.
What is a kernel? If you spend any time reading Android forums, blogs, how-to posts or online discussion you'll soon hear people talking about the kernel. A kernel isn't something unique to Android -- iOS and MacOS have one, Windows has one, BlackBerry's QNX has one, in fact all high level operating systems have one. The one we're interested in is Linux, as it's the one Android uses. Let's try to break down what it is and what it does.
Android devices use the Linux kernel, but it's not the exact same kernel other Linux-based operating systems use. There's a lot of Android specific code built in, and Google's Android kernel maintainers have their work cut out for them. OEMs have to contribute as well, because they need to develop hardware drivers for the parts they're using for the kernel version they're using. This is why it takes a while for independent Android developers and hackers to port new versions to older devices and get everything working. Drivers written to work with the Gingerbread kernel on a phone won't necessarily work with the Ice Cream Sandwich kernel. And that's important, because one of the kernel's main functions is to control the hardware. It's a whole lot of source code, with more options while building it than you can imagine, but in the end it's just the intermediary between the hardware and the software.
When software needs the hardware to do anything, it sends a request to the kernel. And when we say anything, we mean anything. From the brightness of the screen, to the volume level, to initiating a call through the radio, even what's drawn on the display is ultimately controlled by the kernel. For example -- when you tap the search button on your phone, you tell the software to open the search application. What happens is that you touched a certain point on the digitizer, which tells the software that you've touched the screen at those coordinates. The software knows that when that particular spot is touched, the search dialog is supposed to open. The kernel is what tells the digitizer to look (or listen, events are "listened" for) for touches, helps figure out where you touched, and tells the system you touched it. In turn, when the system receives a touch event at a specific point from the kernel (through the driver) it knows what to draw on your screen. Both the hardware and the software communicate both ways with the kernel, and that's how your phone knows when to do something. Input from one side is sent as output to the other, whether it's you playing Angry Birds, or connecting to your car's Bluetooth.
It sounds complicated, and it is. But it's also pretty standard computer logic -- there's an action of some sort generated for every event. Without the kernel to accept and send information, developers would have to write code for every single event for every single piece of hardware in your device. With the kernel, all they have to do is communicate with it through the Android system API's, and hardware developers only have to make the device hardware communicate with the kernel. The good thing is that you don't need to know exactly how or why the kernel does what it does, just understanding that it's the go-between from software to hardware gives you a pretty good grasp of what's happening under the glass. Sort of gives a whole new outlook towards those fellows who stay up all night to work on kernels for your phone, doesn't it?
Click to expand...
Click to collapse
ii. The operating system.
Once the kernel is loaded, the init scripts tell the Operating System to load. Android is the user interface for a custom built Java virtual machine called Dalvik. Dalvik was written by Dan Bornstein, who named it after the fishing village of Dalvik in Iceland, where his family originated from. The debate of which Java VM is superior is best left for another discussion, so I’ll simply say that DalvikVM is a register-based machine versus true JavaVMs which are stack based.
The Dalvik machine creates executable files (.dex files) which can be interpreted by the OS and run by the end user. These .dex files are OS version dependant. That simply means that applications and core functions built to work with one version of Android may or may not work well with other versions. Google provides the tools through it’s Software Development Kit (SDK) for applications to communicate with the OS.
Click to expand...
Click to collapse
iii. Core functions.
No smartphone would be complete without a set of functions that allow the device to be used as intended. Things like the phone and dialer interface, the calendar, the messaging system are core functions of the Operating System. In Android, these are run on top of the kernel as separate applications. The merits (or lack of) of providing these needed functions as separate applications is once again best left for another discussion, but this is what allows developers like HTC or Motorola to replace the standard functions with alternatives that provide a different look and feel from stock. HTC’s onscreen keyboard or Motorola’s MotoBlur contact list are great examples of this. The “little guy” isn’t left out of the mix either. Handcent SMS or Chomp SMS can integrate into the OS very well, as most of us already know.
An additional set of Core Functions are provided by Google. Popularly called GoogleBits, things like Gmail, sync, Gtalk and the Android Market are applications written by Google that give an extra set of useful functions to the OS. You’ll find these on all smartphones, as well as many other Android devices.
Click to expand...
Click to collapse
iv. Optional applications.
These are applications provided by the manufacturer to give the device even more usability. Things like the Amazon MP3 store, PDF readers, Corporate Calendar etc. allow you to do even more with your device. Remember - Droid Does
Click to expand...
Click to collapse
B. How is a ROM packaged?
In most cases a ROM will come packaged in a .zip file. The recovery image’s kernel (yes, it has one too!) has the ability to unzip and copy the contents into the correct place. Inside this zip file is a folder (META-INF\com\google\android\) that contains a script prepared by the ROM “cooker” (another of those techie terms - it means the person(s) who developed the ROM) that tells the system what to format, what to copy and where, and any file operations that need to be done. Each device does things a bit differently, but this script is where it all gets done. More on this folder later.
You’ll also see a /system folder. This is the meat of the ROM. It has the necessary OS files, the Core functions, and any optional applications the cooker decided to include. The folder is structured the same way it is on your device - /system/app, /system/framework, etc. The whole tree is usually copied over and the existing /system folder is overwritten. The cooker uses the script to tell the kernel to erase the existing system folder, copy the new folder over, and set the file permissions.
Sometimes you will also see a data folder. This usually is space set up for optional applications, including optional system tools like busybox or SuperUser white list. These applications could be placed in the /system folder, but placing them in the data folder makes it easier for the end user (you and I) to remove or update them as needed.
You’ll also notice a META-INF folder. This contains the update script we talked about earlier, as well as secure keys that need to be provided so the device knows the update can be trusted. A special note needs made here. Trusted means that the update is trusted to be in the correct form to load the device. It in no way means the ROM is safe from malicious code. Anyone is able to use a set of test keys and create a ROM that will flash and run your device - even those people with bad intentions. Flashing and running a custom 3rd party ROM is putting faith in the cooker that he or she not only knows what they are doing, but are honest as well. Also, some Motorola custom ROMs will have a small update.zip stored inside this folder to be run on first boot of the device.
Finally we are left with the boot.img file. This is the kernel and ramdisk image we discussed earlier. Your phone copies this over to be decompressed and run when the device boots.
Click to expand...
Click to collapse
2. How do I install a ROM?
In this section we’re discussing how to install a custom 3rd party ROM. ROMs from the manufacturer usually have a utility that runs on your PC to flash and load the new image.
A. Got Root???
Yes ?:good:!!!
Custom ROM’s simply will not load on devices that aren’t rooted. In theory, it may be possible to sign a 3rd party ROM with the keys that the stock recovery image will flash, but for the most part you need to have flashed a custom recovery image before you can change your device’s ROM. Instructions and tutorials on how to root your device are all over the internet. Some are good, some are bad. The hacking forum is a great place to go and learn more about rooting and how to successfully get it done on your device.
Click to expand...
Click to collapse
B. Recovery
Most Android devices have had a custom recovery image written for them. This will overwrite the stock recovery image, allowing you to flash 3rd party ROMs as well as giving extra functionality. Help with finding and flashing the custom recovery image for your device can also be found in the hacking forum. The installation of a custom recovery image also allows for a very important function. Backup and restore.
Click to expand...
Click to collapse
.C. Nandroid
Nandroid is a set of bash scripts and code written by that copies the state of your system and stores it in a folder on your SD card. You can then use the restore function of Nandroid to restore to this point at any time. This is a priceless feature and reason enough to root your phone. It’s included by default in most custom recovery images, and the code is freely available to use if you’re inclined to write your own recovery image.
Click to expand...
Click to collapse
In most situations, using Nandroid to back everything up is easy:
1. Verify you have a memory card with enough free space (~300MB to backup, ~500MB to restore).
2. Reboot your device into recovery. It’s slightly different for each device, once again hacking forum FTW!
3. Navigate through the menu and select the Nandroid Backup function.
4. Apply your choice and wait for the device to tell you it’s finished.
It’s always good practice to copy the entire nandroid folder from your SD card to a safe place. You can then copy it back to the SD card if the card is ever damaged, lost or erased.
D. Copy and Flash
You’re rooted, have downloaded a custom ROM, have your system backed up and are now ready to flash your device. This is not nearly as scary as it sounds.
1. Mount your SD card to your PC, and copy the .zip file to the root folder of the card. Don’t unzip the file, and don’t look for a folder called root. The root folder in this case means the base folder, what you will see when you mount your card to a PC or the device.
2. Reboot your phone into recovery.
3. Navigate through the recovery menu and select the flash update option. Depending on your recovery image, the file may need to be named update.zip, or you may be able to select any zip file on your card as long as it’s the correct format. The cooker knows this as well and if the ROM needs to be named update.zip it will be.
4. Apply your choice and wait for your device to tell you it’s finished.
5. Reboot.
Click to expand...
Click to collapse
It’s worth noting that many times a new ROM will require that you wipe and factory reset your devices data. While inconvenient, it’s often necessary to get rid of the old data as it may be incompatible. As long as you’re using the cloud for calendar and contacts, they will be re- downloaded and stored back on your device automatically.
Credits
The internet
And other sites related to android development
And of course me
My Galaxy R forum friends !!
ERRORS encountered in CWM Recovery
.
What is CWM Recovery ?
ClockworkMod Recovery is a custom recovery for many Android devices. It is considered to be the most popular recovery for Android due to its easily-ported nature, and integration with ClockworkMod ROM Manager by Koush(Koushik Dutta). The easiest way to recognize it is by the printed name when it first starts, and the background logo of a gear and hat.
Click to expand...
Click to collapse
ERROR STATUS 6
This is usually caused by CR/LF EOL(Windows style End Of Line) in updater-script. Change it to LF EOL(Unix Style EOL) using Linux command: dos2unix updater-script, then re-signing the ZIP, will usually fix this error.
Click to expand...
Click to collapse
ERROR STATUS 7
This is usually caused by a corrupt download, or bad file signature. Re-downloading (or re-signing) the ZIP will usually fix this.
Click to expand...
Click to collapse
We have been consistently seen and heard people facing error “Status 7″ error while trying to flash or install
custom ROMs or firmware packages on their Android smart phones or tablets with ClockworkMod Recovery. Many
of the users are nowadays facing this problem with CWM Recovery while flashing .zip files of modded or custom
Ice Cream Sandwich (ICS) or Jelly Bean (JB) ROMs on their devices. So, you have also downloaded a custom ROM,
placed its .zip file in your phone’s or tablet’s SD card, booted into ClockworkMod Recovery, selected – “install zip
from sdcard” and then chosen the .zip file of the ROM to get it installed on your device. But instead of getting
flashed successfully, if you are facing the issue mentioned below, then just keep reading this article to find out
what’s wrong and fix up the problem :
Finding update package…
Opening update package…
Installing update…
Error in /sdcard/custom-jelly-bean-rom.zip (Status 7)
Installation aborted
Click to expand...
Click to collapse
or the following error right after CWM recovery shows –
Installing update…
assert failed: getprop(“ro.product.device”) == “I9103″ || getprop(“ro.build.product”) == “I9103″ || getprop
(“ro.product.board”) == “I9103″
Error in /sdcard/android-4-1-1-ics-rom-latest.zip (status 7)
Click to expand...
Click to collapse
So, if you are facing any of these errors while trying to install the desired custom ROM package on your Android
phone or tab, then you may try a various things or steps which may turn out to be the workaround of this
problem. Here are a few tips to get this “Status 7” error fixed in ClockworkMod Recovery and flash the ROM
successfully on your device :
(1) First of all, make sure your device’s bootloader is unlocked. If it is already unlocked but you are still
not able to flash the ROM, then just extract the .zip file of the ROM into a new folder, find the boot.img file from
that directory and flash it up on your phone or tablet via fastboot on your PC.
(2) Make sure that you are having the appropriate Radio or Baseband version installed on your device which is
supported by the custom ROM you are trying to flash. Most of the ROMs requires the latest version of Baseband, so
just update or upgrade your device to the latest Baseband version and then try to install the ROM once again.
(3) Update your device to the supported / latest build of official firmware before trying to install the ROM. You can
do it from – Settings > About Phone / Device > Software Update.
(4) Make sure you are having the supported or required kernel installed on your phone or tab. If it’s not, then flash
a new kernel right away and try to install your custom ROM once again.
(5) Is the ROM which you are trying to flash really works ? Find out whether it is working for other users or not.
Click to expand...
Click to collapse
NOW
ERROR STATUS 0
This is usually caused by an incompatible update-binary in edify ZIPs. Replacing it with a compatible one, then re-signing the ZIP, will usually fix this error.
Click to expand...
Click to collapse
Now it's time for the partitions :good:
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 kernel and the ramdisk. 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 ramdisk. 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.
Nice thread, maybe add error status 0 for CWM
Sent from my C6603 using xda app-developers app
krabappel2548 said:
Nice thread, maybe add error status 0 for CWM
Sent from my C6603 using xda app-developers app
Click to expand...
Click to collapse
Done !!!!
Great thread, You are seriously doing well.:good:
MY thanks just ended
will use the mob app to thank u bro !!
After all you inspired me for this thread not
Moved to android general as per OP request.