Database Users

[UPDATED][INFO] ROM 101 + CWM Errors Solutions

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???
What is Root?
Android rooting is the process of allowing users of smartphones, tablets, and other devices running the Android mobile operating system to attain privileged control (known as "root access") within Android's subsystem.
Rooting is often performed with the goal of overcoming limitations that carriers and hardware manufacturers put on some devices, resulting in the ability to alter or replace system applications and settings, run specialized apps that require administrator-level permissions, or perform other operations that are otherwise inaccessible to a normal Android user. On Android, rooting can also facilitate the complete removal and replacement of the device's operating system, usually with a more recent release of its current operating system.
As Android derives from the Linux kernel, rooting an Android device is similar to accessing administrative permissions on Linux or any other Unix-like operating system such as FreeBSD or OS X.
The process of rooting varies widely by device, but usually includes exploiting a security bug(s) in the firmware (i.e. in Android) of the device, and then copying the su binary to a location in the current process's PATH (e.g. /system/xbin/su) and granting it executable permissions with the chmod command. A supervisor application like SuperUser or SuperSU can regulate and log elevated permission requests from other applications. Many guides, tutorials, and automatic processes exist for popular Android devices facilitating a fast and easy rooting process.
For example, shortly after the HTC Dream was released, it was quickly discovered that anything typed using the keyboard was being interpreted as a command in a privileged (root) shell. Although Google quickly released a patch to fix this, a signed image of the old firmware leaked, which gave users the ability to downgrade and use the original exploit to gain root access. Once an exploit is discovered, a custom recovery image that skips the digital signature check of a firmware update package can be flashed. In turn, using the custom recovery, a modified firmware update can be installed that typically includes the utilities (for example the Superuser app) needed to run apps as root.
The Google-branded Android phones, the Nexus One, Nexus S, Galaxy Nexus and Nexus 4, as well as their tablet counterparts, the Nexus 7 and Nexus 10, can be boot-loader unlocked by simply connecting the device to a computer while in boot-loader mode and running the Fastboot program with the command "fastboot oem unlock".[9] After accepting a warning, the boot-loader is unlocked, so a new system image can be written directly to flash without the need for an exploit.
Recently, Motorola, LG Electronics and HTC added security features to their devices at the hardware level in an attempt to prevent users from rooting retail Android devices.[citation needed] For instance, the Motorola Droid X has a security boot-loader that puts the phone in "recovery mode" if a user loads unsigned firmware onto the device, and the Samsung Galaxy S II displays a yellow triangle indicator if the device firmware has been modified.
Click to expand...
Click to collapse
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.
Dirty flash and Clean flash
A dirty flash is only wiping cache and davlik then flashing your ROM....
a Clean flash is at LEAST factory reset/data wipe + wiping davlik(factory wipe takes care of /cache also)... Maybe doing a format /system also.

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
Error Status 0
Well sometimes while flashing some ROMs especially the cooked ones we get Error status 0 in the CWM Recovery
this error is an indicator of Wrong Update Binary.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.
ADB-Android Debugging Bridge
Android Debug Bridge (adb) is a versatile command line tool that lets you communicate with an emulator instance or connected Android-powered device. It is a client-server program that includes three components:
A client, which runs on your development machine. You can invoke a client from a shell by issuing an adb command. Other Android tools such as the ADT plugin and DDMS also create adb clients.
A server, which runs as a background process on your development machine. The server manages communication between the client and the adb daemon running on an emulator or device.
A daemon, which runs as a background process on each emulator or device instance.
You can find the adb tool in <sdk>/platform-tools/.
When you start an adb client, the client first checks whether there is an adb server process already running. If there isn't, it starts the server process. When the server starts, it binds to local TCP port 5037 and listens for commands sent from adb clients—all adb clients use port 5037 to communicate with the adb server.
Click to expand...
Click to collapse
The server then sets up connections to all running emulator/device instances. It locates emulator/device instances by scanning odd-numbered ports in the range 5555 to 5585, the range used by emulators/devices. Where the server finds an adb daemon, it sets up a connection to that port. Note that each emulator/device instance acquires a pair of sequential ports — an even-numbered port for console connections and an odd-numbered port for adb connections. For example:
Emulator 1, console: 5554
Emulator 1, adb: 5555
Emulator 2, console: 5556
Emulator 2, adb: 5557
and so on...
As shown, the emulator instance connected to adb on port 5555 is the same as the instance whose console listens on port 5554.
Once the server has set up connections to all emulator instances, you can use adb commands to access those instances. Because the server manages connections to emulator/device instances and handles commands from multiple adb clients, you can control any emulator/device instance from any client (or from a script).
Note: When you connect a device running Android 4.2.2 or higher to your computer, the system shows a dialog asking whether to accept an RSA key that allows debugging through this computer. This security mechanism protects user devices because it ensures that USB debugging and other adb commands cannot be executed unless you're able to unlock the device and acknowledge the dialog. This requires that you have adb version 1.0.31 (available with SDK Platform-tools r16.0.1 and higher) in order to debug on a device running Android 4.2.2 or higher.
Syntax
You can issue adb commands from a command line on your development machine or from a script. The usage is:
adb [-d|-e|-s <serialNumber>] <command>
If there's only one emulator running or only one device connected, the adb command is sent to that device by default. If multiple emulators are running and/or multiple devices are attached, you need to use the -d, -e, or -s option to specify the target device to which the command should be directed.
LOGCAT
The Android logging system provides a mechanism for collecting and viewing system debug output. Logs from various applications and portions of the system are collected in a series of circular buffers, which then can be viewed and filtered by the logcat command. You can use logcat from an ADB shell to view the log messages.
-b <buffer> Loads an alternate log buffer for viewing, such as event or radio. The main buffer is used by default. See Viewing Alternative Log Buffers.
-c Clears (flushes) the entire log and exits.
-d Dumps the log to the screen and exits.
-f <filename> Writes log message output to <filename>. The default is stdout.
-g Prints the size of the specified log buffer and exits.
-n <count> Sets the maximum number of rotated logs to <count>. The default value is 4. Requires the -r option.
-r <kbytes> Rotates the log file every <kbytes> of output. The default value is 16. Requires the -f option.
-s Sets the default filter spec to silent.
-v <format> Sets the output format for log messages. The default is brief format. For a list of supported formats, see Controlling Log Output Format.

awesome thread to learn everything in a quick while

Again.? :good:
But highlight the Status error with big & bold font.

Disturbed™ said:
Again.? :good:
But highlight the Status error with big & bold font.
Click to expand...
Click to collapse
I think he's trying to take over XDA
But just to keep this on topic, great thread for those who are learning and aren't sure what certain things are for.
I guess I'll have to make another thread in this forum just so other RCs don't take all the ideas
SGS2 FAQ | HTC One FAQ

KidCarter93 said:
I think he's trying to take over XDA
But just to keep this on topic, great thread for those who are learning and aren't sure what certain things are for.
I guess I'll have to make another thread in this forum just so other RCs don't take all the ideas
SGS2 FAQ | HTC One FAQ
Click to expand...
Click to collapse
Lolzzz.. Yes buddy. He is something else.
Collecting Informations & useful stuff for all users. May be in near future, he will take over XDA.

It's all your love guys. Sometimes even my guides correct my mistakes!
Started from the bottom

Guys if you like this thread please press the tip us button so that more and more people who are willing to learn about android phone and how they work can get help.
I will be grateful to you all.
Started from the bottom

Very nice write up TechnoCrat :good::good::good:
TEAM MiK
MikROMs Since 3/13/11

Long way to go mate!
Congo! This thread got featured on XDA Portal
http://www.xda-developers.com/android/android-101-how-it-all-fits-together/

Thank you very much. I needed this definition thread. I kinda understand but it'd nice to hear official language that's understandable.
Sent from that FBI van parked down the street.

Thanks for the CWM errors write up and another bookmark.

Tha TechnoCrat said:
i. The kernel.
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
Click to expand...
Click to collapse
What. The. Hell. Are you talking about?
If you mean booting the device's kernel on the PC, unless the device uses an x86 processor, it flat out will not boot, let alone mount the device's system, to display the bootanimation.zip
/snarkieness
Sorry, I had to let that out.
Also, init is called/started after the kernel has started, and generally after it has setup most of the hardware.
so I’ll simply say that DalvikVM is a register-based machine versus true JavaVMs which are stack based.
Click to expand...
Click to collapse
I don't even truly understand that, so could add a little more detail, or remove it?
I'm speaking mostly from my implied knowledge, gained from tinkering with android/linux for a few years.

ADB and Logcat added

Hey, Thanks for the article. Can you talk about root? There is some mis-leading information and I really want to learn about it. Thanks again.

ak700 said:
Hey, Thanks for the article. Can you talk about root? There is some mis-leading information and I really want to learn about it. Thanks again.
Click to expand...
Click to collapse
Okay buddy
Editone! !!
"Thanks button is just to avoid "THANKS" posts in threads. Nothing more than that. Don't ask in signature or post for it and defeat the purpose why it was introduced"

Bump to update newbies
"Thanks button is just to avoid "THANKS" posts in threads. Nothing more than that. Don't ask in signature or post for it and defeat the purpose why it was introduced"

★★★★[INFO]ANDROID ROM & How they Work★★★★

★★★★[INFO]ANDROID ROM & How they Work★★★★
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.
Dirty flash and Clean flash
A dirty flash is only wiping cache and davlik then flashing your ROM....
a Clean flash is at LEAST factory reset/data wipe + wiping davlik(factory wipe takes care of /cache also)... Maybe doing a format /system also.
***Odin***
Odin is the ROM Flashing Tool for SAMSUNG smartphones. ROM files flashable with Odin come with .tar extension.
Most of the ROMs you are going to flash with Odin are the official stock Samsung ROMs (or leaked stock ROMs). Custom ROMs are rerely flashable by Odin because they come with .zip extension that Odin does not recognize (it recognizes .tar files).
Custom kernels, however, are sometimes provided in .tar format by their developers (e.g. CF-Root kernels), so that they can be flashed by Odin. When your phone is new and running official firmware you most often cannot flash a custom ROM to it because a Samsung phone often requires a custom recovery and root rights that are included in a custom kernel to be able to flash custom ROMs. That's why Odin often comes in handy in rooting and flashing a custom firmware to your phone because you (often) can flash a custom kernel with it that already includes root and custom recovery and enables you to flash custom firmware (custom ROMs). I use the word "often" very frequently in the previous sentence because every Samsung smartphone is different and requires various procedures for rooting it and flashing custom ROMs (see the section about using Odin below).
If it comes to stock ROMs, the best source of stock (official) Samsung ROM files is located at this excellent website: SamMobile.com/firmwares (link). It requires registration (it's free) and I encourage you to set up an account there because you will most likely use this site several times during your stay at XDA. You will most likely come across 1 .tar or 3 .tar file ROMs there, flashable by Odin. Refer to the Odin flashing guide below for more info.
Click to expand...
Click to collapse
****Heimdall****
What is Heimdall?
Heimdall is a cross-platform open-source tool suite used to flash ROMs onto Samsung Galaxy S devices.
How does it work?
Heimdall uses the same protocol as Odin to interact with a device in download mode. USB communication in Heimdall is handled by the popular open-source USB library, libusb-1.0.
Why “Heimdall”?
The flashing software Odin is named after the king of gods in Norse mythology. Loke, the software component on the Galaxy S that provides functionality to flash, may also to be named after an important character in Norse mythology, often translated as Loki. As such I have named my flashing software Heimdall, after the Norse god, and guardian of the Bifrost Bridge.
What platforms does Heimdall run on?
Linux, OS X and Windows (XP, Vista, 7 etc.)
Why use Heimdall when we can use Odin?
Odin is generally unreliable and only runs on Windows systems. Furthermore, Odin is leaked Samsung software that is not freely available or well understood by the community.
Is Heimdall safe?
No matter what method you chose, flashing firmware onto your phone has a lot of potential for disaster. We have tested Heimdall with a variety of phones flashing several different firmware versions resulting in a 100% success rate. As such we believe that Heimdall is generally reliable. However keep in mind, just like any flashing software, Heimdall has the potential to brick your phone if not used correctly.
How do Galaxy S phones get bricked when flashing?
Besides the inherent risks like power outs, accidental removal of the USB cable etc. The Galaxy S appears to be running extremely unreliable USB control software.
A failure to flash does not automatically equate to a bricked phone. However if you're extremely unlucky and the flash fails whilst transferring the primary boot-loader, secondary boot-loader or params.lfs (all quite small) than you've got yourself a paper weight that you're hoping Samsung will replace.
Please be extremely careful mixing files from different firmware releases. Don't do so unless you're certain it will work!
What Galaxy S variants has Heimdall been tested with?
We’ve tested Heimdall with a Galaxy S GT-I9000 (8 GB) from the United Kingdom and Galaxy S GT-I9000 (16 GB) from Australia. We don’t personally have access to any other devices to test with, however users have confirmed Heimdall functions correctly with the AT&T Captivate, Bell Vibrant, Telstra GT-I9000T, Epic 4G and the Galaxy Tab.
Click to expand...
Click to collapse
^

CWM Errors and Solutions
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
Error Status 0
Well sometimes while flashing some ROMs especially the cooked ones we get Error status 0 in the CWM Recovery
this error is an indicator of Wrong Update Binary.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

Partitions
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.

You should at least post the source of such a large copy paste post.
Sent from my GT-N7100 using Tapatalk 2

Source? How do you post a source for an article which is compiled from 10+ sites? Plus my own addition?
Started from the bottom

Good job man, this saves me the time to do all this researches.
Keep it up
Best regards
Sifou
Using a Samsung N7100

sos_sifou said:
Good job man, this saves me the time to do all this researches.
Keep it up
Best regards
Sifou
Using a Samsung N7100
Click to expand...
Click to collapse
DO tell me if you have some suggestions for the thread.
"Thanks button is just to avoid "THANKS" posts in threads. Nothing more than that. Don't ask in signature or post for it and defeat the purpose why it was introduced"

I think that this is a pretty good summary of the basics. I even converted it to epub and stocked it on my e-reader for reference
You can get to the details if you want? Adding some info about flashing softwares like odin and the Linux based one (i don't remember it name)
The different recoveries available and their advantages vs désavantages
How to protect yourself from malicious applications, starting from knowing what are permissions...
Keep it up mate
Best regards
Sifou
Using a Samsung N7100

sos_sifou said:
I think that this is a pretty good summary of the basics. I even converted it to epub and stocked it on my e-reader for reference
You can get to the details if you want? Adding some info about flashing softwares like odin and the Linux based one (i don't remember it name)
The different recoveries available and their advantages vs désavantages
How to protect yourself from malicious applications, starting from knowing what are permissions...
Keep it up mate
Best regards
Sifou
Using a Samsung N7100
Click to expand...
Click to collapse
Heimdall?
"Thanks button is just to avoid "THANKS" posts in threads. Nothing more than that. Don't ask in signature or post for it and defeat the purpose why it was introduced"

Tha TechnoCrat said:
Source? How do you post a source for an article which is compiled from 10+ sites? Plus my own addition?
Started from the bottom
Click to expand...
Click to collapse
I guess you have a point, it's just the scientist in me with source-referral-ocd.
Sent from my GT-N7100 using Tapatalk 2

adytum said:
I guess you have a point, it's just the scientist in me with source-referral-ocd.
Sent from my GT-N7100 using Tapatalk 2
Click to expand...
Click to collapse
DO tell me if you have any problems or if you want something to be added.
"Thanks button is just to avoid "THANKS" posts in threads. Nothing more than that. Don't ask in signature or post for it and defeat the purpose why it was introduced"

Thread updated with Odin and Heimdall information.
"Thanks button is just to avoid "THANKS" posts in threads. Nothing more than that. Don't ask in signature or post for it and defeat the purpose why it was introduced"

Tha TechnoCrat said:
Source? How do you post a source for an article which is compiled from 10+ sites? Plus my own addition?
Started from the bottom
Click to expand...
Click to collapse
By listing ALL the different sources? And obviously crediting yourself with bits you've added.
Sent from my GT-N7100 using xda premium

You should make the title of the thread more presentable though.

Simone said:
You should make the title of the thread more presentable though.
Click to expand...
Click to collapse
Would like some suggestions.
"Thanks button is just to avoid "THANKS" posts in threads. Nothing more than that. Don't ask in signature or post for it and defeat the purpose why it was introduced"

Tha TechnoCrat said:
Would like some suggestions.
"Thanks button is just to avoid "THANKS" posts in threads. Nothing more than that. Don't ask in signature or post for it and defeat the purpose why it was introduced"
Click to expand...
Click to collapse
You should think of your own. That would be the best
Make it more professional looking, though.
Everything else is good.

Guys I have got my Note 2 finally. Will compile some guides for it too.
Sent from my GT-N7100 using xda app-developers app

You bought a note 2? Congrats mate !
Best regards
Sifou
Using a Samsung N7100

sos_sifou said:
You bought a note 2? Congrats mate !
Best regards
Sifou
Using a Samsung N7100
Click to expand...
Click to collapse
Thanks buddy. Get ready for more guides
Sent from my GT-N7100 using xda app-developers app

[INFO][Guide][Noob] [Android] [ROM][Kernel][Recovery][Development]

Hello all,
I know there are many people who are curious about android or/and are about their new device. With this in mind, I have decided to give a brief idea about Android and its different aspects. I will use as simple words as possible.
Every highlighted word is a term that is used often at XDA or just refers to the word in FAQs in case you cannot find it.
ANDROID is an open-source (thus possibilities endless) mobile operating system (OS) based on the Linux kernel and currently developed by Google
With a user interface based on direct manipulation, Android is designed primarily for touch screen mobile devices such as smartphones and tablet computers, with specialized user interfaces for televisions (Android TV), cars (Android Auto), and wrist watches (Android Wear).
ANDROID is usually based on these four major components:
ROM :
It is the system on which phone works (like windows for PC). Or simply called an Operating System. Can be Custom/Stock. Usually you need a custom or official tool to install/ repair a STOCK rom.
KERNEL is a part of ROM which is a programmed code that tells the phone how to function in accordance to the ROM & hardware capabilities. It can also be Custom/Stock. Sometimes they are used to enhance user experience, performance, battery life by small changes made to them. Some kernels are specific to ROMS.
DIFFERENCE BETWEEN CUSTOM/STOCK
When you buy your phone/tablet from a retailer, you are on STOCK ROM and STOCK KERNEL. (its from your mobile manufacturer and in this case straight from Google as it is a nexus device. Thus it is called a STOCK ROM/ STOCK KERNEL.
The STOCK ROM & KERNEL is usually an all-rounder to fit most of the users. However, some people are not happy with the limited option available on their devices. As Android is open sourced, and thus easily customized, they want to explore different options by tweaking their devices
In other words, some people like gaming on their devices while other want to increase the battery time, speed, performance etc and the possibilities are very vast as what we want from our devices. Like a person who likes to read books on his device would not care for heavy gaming performance but appreciate if he can get more juice out of his device so he can read more on a single charge.
Therefore, we can say we all need different flavours and thus there is a need for customisation. However, there could be some minor disadvantages too that come with some advantages like overclocking can result in heating and quick battery drain while it increases performance. Also, increased battery life might slow down your device if you are tweaking or under-clocking it too much Therefore, most of the developers try to find the best combination of both performance and battery. However, some custom ROMS/Kernels are developed with specific functions in their core like they might focus only on performance and gaming while other might just ignore heavy gaming and focuses on battery usage. Therefore, it is to your advantage to use your device how you like want it to function according to your preference.
By customisation, we run our devices to our needs and get the most out of it in accordance to how we want to customise it.
SOME CONSIDERATIONS
All devices ROMs and KERNEL are specific. This means stock/custom ROM for every device is specific so you cannot flash a ROM which is made for other device. This can permanently damage your phone. A famous Custom Rom is CyanogenMod which is currently on version 12.1. Although the ROM would be same for many devices, but you can not flash CM12.1 for Xperia M to Xperia M2 etc. In the same way, you can not flash custom/stock kernel of one device to another.
Rom can be installed via official tools provided by manufacturer or by using custom tools. Usually when you flash a STOCK ROM, it flashes SYSTEM+KERNEL+RECOVERY. However, some unofficial tools can help you flash any one component of the ROM. It could be Kernel/ Recovery or System.
RECOVERY
Recovery is also a part of ROM which is basically a backup mechanism of your device which lets you install stock ROM to your device if something has been corrupted in your device software. However, many CUSTOM recoveries are available which are necessary for flashing CUSTOM ROMS, MODS to modify your ROM and also you can backup your ROM(called nandroid backup), partition your sd card amongst many other uses. Recoveries could also be flashed via kernel as they are preinstalled.
BOOTLOADER is basically a lock in your device which doesn't allow modifications to your phone by the Manufacturer. Unlocking bootloader voids your warranty and stops automatic updates of your STOCK ROM. However, you can easily lock your bootloader again any time or manually install STOCK Updates.
Remember you should usually unlock bootloader before rooting unless you are installing a custom rom which is pre-rooted and allows locked bootloader.
ROOTING
This is basically a powerful exploit to take over your system and kernel of your device. It simply means that some system files which couldn't be modified can be changed now. It is as if you have complete power of your ROM and hardware. There are no restrictions from your manufacturer and thus you can change values , overclock your processor or put your hardware in hibernation to increase battery life, turn on/off your cores , speed or enforce 3D gaming cards to play HD games which you couldnot play before. However, this is a very tricky business so if you mess it up and not sure what you are doing, you can really end up with a bricked phone.
Usually apps are used to change these values or it could be done via SDK tools/ programming. To be sure if you are rooted or not, you can install ROOTCHECKER app from PLAYSTORE.
ADVANTAGES OF ROOTING
- You get full access to your phone's Hardware and software
- You can Overclock CPU clock speed and make phone faster
- You can Install many mods to improve camera, audio and video playback quality
- You can Install Beats Audio Drivers/others to enhance audio output
- You can increase speaker / earphone volume using volume hack
- You can Install Custom ROMs and Apps
- You can take the hell out of your device and Improve user experience
Rooting is safe and reversible, You can unroot your phone if you want. It won't void you're warranty etc
DISADVANTAGES OF ROOTING
-Chance to brick your device if the wrong software gets flashed. This can be EASILY reversible
-Warranty is void. You can flash STOCK ROM again and no one will have a clue you did that. So it can be reversible.
-Because, after Rooting you give permission (apps prompt, it's not by default) to apps to change values so if you give it to a malicious app, it can result in Viruses or security/privacy breach.
In all honestly, I am using rooted devices for over 5 years now and I never had any problem with viruses however, I have bricked my device innumerous times by accident. (I have flashed and rooted my device almost every one to two weeks and I have bricked my devices so many times in testing phase of Roms). I was always able to retrieve back the device with some tools and thus it was not much of a problem.
DIFFERENCE BETWEEN GOOGLE NEXUS DEVICE AND A NON NEXUS DEVICE
GOOGLE NEXUS DEVICES give you vast freedom to install custom roms and it is comparatively very easy to unlock bootloader of these devices so a custom Rom can be flashed. (Flashing rom is equivalent to installing windows in PC). You can understand that a Nexus device only needs one command to unlock its bootloader while others could trouble you a lot for that.
Also, Google is very quick with updates on their devices which mean that you will get the latest software updates officially as they come out. Thus, even staying on STOCK ROM is not a bad choice for many users. Every update increases stability and gets rids of bugs. And of course, sometimes the bugs are not ironed out well and come back
NON NEXUS DEVICES do not give you as much freedom as a Nexus device. It is usually much harder to unlock their bootloader, develop on these devices and usually some exploits are needed to run custom ROM/root/kernels. Manufacturers or these devices try their level best
to narrow down the exploits as in other words, the more exploits a device has, the less secure it tends to be.
SOME CUSTOMISATION DIFFERENCES
As it is a nexus device so Asus has no say on any customisation at all. Thus, Nexus devices are said to run the PURE ANDROID and give you the best android experience in my opinion. However, usually manufacturers customise pure android from Google. To understand better, Google is responsible for development of the android OS so every new version is made by Google and then it is open sourced to manufacturer of different devices. Manufacturers like Samsung/Sony/Motorola/HTC customize the code provided by Google to customize it to their likings. This can result in some added options but can also result in slow performance if there has been too much customization from a device maker. Google itself is only responsible for the software and DOES NOT make any hardware itself.
Also, many manufacturers take a small fee from some app developers and install their apps with every device they produce. It is good news for app developer and manufacturer but usually a burden for users as not only they hog RAM, diskspace, and slow down the device they also are useless to many users. Referred to as BLOATWARE
SUPPOSE YOU HAVE DECIDED TO INSTALL CUSTOM ROM/ KERNEL.
This is a short synopsis of steps which are explained in details later in the post :
1.Unlock your bootloader
Some phones have unlocked bootloaders out of box (Not anymore)
2.Root your phone , which can be done via flashing a custom prerooted kernel or by binary method. There are innumerous ways now actually so usually visiting your device forum will help you find it.
3. Flash a recovery. This step can be done before or after unlocking your bootloader. Even you can root your phone via flashing SuperUser in recovery. However, sometimes, you need a rooted device before you can install a custom recovery using exploit/ scripts method.
SOME COMMON MISTAKES AND PREREQUISITES:
1. Make sure what ever you do, do it as administrator on your PC.
2. Make sure drivers are installed properly for your device.
3. Make sure, USB debugging is ON
4. Unknown Sources is ticked as well
5. Windows 7 is usually quick to install drivers itself. In windows 8 however you have to manually install drivers.
6. There are tools like SDK which is about 500mb which can help you to install drivers/fastboot etc but this is the long route. I suggest you just find platformtools in attachment which would be enough for cmd commands.
UNLOCKING BOOTLOADER :
I will give you a rough idea and it is NOT a guide to unlock your bootloader !
Basically, when you buy your phone it is locked from the manufacturer so no changes can be made to the software(STOCK ROM & KERNEL ) and thus this way, they can stop users to modify their software which might damage the device and they do not want to be responsible for that. So unlocking bootloader voids your warranty. However, this can be reversible.
ROOTING :
What you do in rooting is either flash a kernel via fastboot or exploit your device using binary method. This gives you permenant root, however there are ways to get temporary root too.
ROMS & KERNELS :
You choose a rom to your likings and then flash it via recovery. Usually the instructions are given on every rom as there is slight change as to how to flash it.
There many Roms & Kernels made by developers after lots of hardwork and testing. Thus every rom that surfaces might not be good for you but best for another user. Thus, it is never good to compare roms. What might work for you might not work for another.
I hope this helps!
MORE TERMS CLICK HERE

DEVELOPMENT PROCESS
INTRODUCTION
I am starting this forum in hope of educating my readers about ROM development according to my experiences. Further, I will highlight what is the usual developers' thought process before they decide to build a ROM for a specific device. The reasons why they usually choose a certain device or why they prefer one device over another would also be stated briefly. I also have intention of looking into ways how we can speed up ROM productions for any device and what you can do to play your part.
I UNDERSTAND YOUR FRUSTRATION FOR NO CUSTOM ROMS EVEN AFTER SOME MONTHS BUT THIS DOESNOT GIVE YOU THE RIGHT TO SPAM
I am sure many of you must be really disappointed by the lack of development for your device and I know this must be frustrating when we see other devices are getting ROMS so quickly. I know many are too excited when they find a little about any OTA/ Custom ROM and sharing such news is fully justified. However, it's beyond my logic & thinking why the forums are SPAMMED for any little information they might find anywhere regardless of their sources or if it has been ALREADY POSTED. I reckon many of these threads could have been avoided by simply searching in the forum.
ROM DEVELOPMENT
I can assure you that many develoeprs are working very hard to PORT and develop different ROMS for a device. However, the reason we can not see any CUSTOM roms till yet is due to complicated nature of a device itself.
Usually developers prefer a device which is :
1. Easy to work with, less complicated to code with or in other terms DEVELOPER friendly. For example, for a while I had a real issue with HTC phones as they have too many things to work with like Bootloader, S Lock, Radios, Hboot version etc while in Nexus devices you only need to unlock your device with one fastboot command. That's all and you are ready to flash ROMs.
2. Personal preference of Device. This simply means that we all have different tastes and thus we choose different devices. A certain developer might only work for a certain brand while other might work with few brands. This has nothing to do with anything but a personal choice.
3. A device that promises reward in terms of money/self satisfaction. Developers usually go for devices which have most active users so if their intention is also to get some money out of it in terms of donation, this will work well with devices which are more in number.
4. Knowledge about a certain brand more than another.
5. MONEY TO BUY A CERTAIN DEVICE/DEVICES. Suppose a developer wants to make ROMS for Xperia L/ SP/Z and Xperia U. Yet he only has 500 dollars to choose from. He then will have to make a choice between devices and this will eventually mean that not all of the devices get the same treatment. Money is the most decisive factor why a developer doesnot chose your device but rather another. For example purpose only, if I have to choose between devices, I might prefer SP over Xperia L as I can see more future of SP than Xperia L(I might be wrong).
6. Simply he bought a device or it is gifted/donated to him
SOME REQUESTS
Please STOP bugging developers by trivial questions. Just think how many other people ask the same question and it gets very frustrating to actually work on the device itself.
Every developer has a LIFE apart from developing ROMs. They also have a family, school, work, hobbies, bad days and so much like us. So they will do it when they feel like doing it. Just sit back and relax. Enjoy your device until developer releases the ROM for your device. Asking a REASONABLE question seems plausible but asking same questions/useless questions without using brains is just STUPID. Kindly refrain from that.
If you have seen a developer who has taken the initiative to work on your device , the best thing to do is to be patient. Let him concentrate. Spamming and spamming again won't help really.Yet some users start SPAMMING developers, their twitters, blogs and accounts. That's really sad. You can discuss on the forum what you think about it but IRKING developers isnot really cool.
WHAT CAN YOU DO TO HELP DEVELOPERS AND SEE CUSTOM ROMS.
1. Search the form first and look for answers. DON'T start new posts/questions/threads when it is ALREADY mentioned in some other section.
2. STOP PMing/SPAMING developers but rather ask a question WHICH havenot been asked before in the forum. Do not engage in the habit of making a new forum for everything. Try to keep threads as little as possible.
3. Follow developers and see what they have updated about on their official twitter,facebook,etc rather than bugging them on different forums/social websites.
4 DONATE THEM. DONATE THEM . DONATE THEM!
The amount of efforts they put, sitting for hours in front of their PCs and I know how frustrating it gets when you try to run commands and everything seems to work yet you can not boot up your ROM. And worse, you can not find WHY really. Just a change in line in build.prop results in failure of ROM to boot up and specially working from source to build ROM is really really tough. The best thing you can do is being supportive and patient !
A ROM development requires not just EXCESSIVE amount of hardwork, time, energy and dedication but also they need MONEY to actually buy devices and try it on. They are happy and encouraged to keep on developing ROMs when they see their efforts are not wasted and they are rewarded and respected for what they do.
SOME BASICS OF ROM DEVELOPMENT
Usually this is required to make a full custom ROM
Blobs which contain hardware information which comes from hardware manufacturer like Qualcomm in case of Snapdragon processors
A fully functional device tree
Latest Android source (Or the android version source you want to build for)
Specific Custom ROM coding which is based on Android Source
Usually a device tree and kernel tree is needed before custom roms can be made available. This is a long trial and error process in which every component of hardware is made functional as usually manufacturers do not provide any code for their devices and thus new code is to be written which is very frustrating and long process!

FAQs :
BRICKED : Two types. hard or soft.
Hard bricked is when your phone hardware information is damaged. Now it is an expensive paper weight and it would only revive if you either send it to a JTAG technician or change motherboard of your device.
Soft is when your device ROM/kernel is damaged and thus it can be easily revived.
NOOB FRIENDLY : A guide that anyone with no knowledge of android can use
TWEAKINGimprove performance by making fine adjustments to it.
BLOATWARE Useless apps which come preinstalled in a stock rom from a manufacturer.
Sometimes, developers PORTone particular feature of a phone to another. This means, a function specific to one phone can be used in another but bear in mind, the hardware should support it. Like LG has knox feature which means that you can tap on the screen to wake it up or turn off the screen. Now it is a common feature of many kernels. LG was first to introduce it officially in their stock rom but the feature is a bit old. Even Asus Zenfone 2 uses tap to wake feature.

Nice One Brother

ARGHA_DAS said:
Nice One Brother
Click to expand...
Click to collapse
I am glad this was of help to you

What's in the 'boot' partition?
Sent from my Nexus 7 using Tapatalk

AbyssBreak said:
What's in the 'boot' partition?
Sent from my Nexus 7 using Tapatalk
Click to expand...
Click to collapse
This guide should be of help
/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.
All credits to the writer Haroon Q Raja
Click to expand...
Click to collapse

[Tutorial] Installing Cyanogenmod for the Sprint Galaxy S4 - WIP

I recently got into tinkering with my Sprint Galaxy S4 and spent quite some time going through the whole process to get to Cyanogenmod, then back to stock, the reasons which I hope to share with you throughout this tutorial. I went to multiple sources from all over the web to answer all the questions I had, so I'm hoping to gather everything in one place so you can too learn the intricacies of playing with the OS on your phone.
This will be a work in progress for a bit, as I plan on going back to stock and working through the process again to capture everything I had to learn in order to get my phone to where I wanted it.
Hopefully once complete, this guide will help you do that same thing.
Thanks.
PS; I am placing the phrase "<link>" where I will eventually will insert the actual links, but until I leave new status, Google searches will have to do.
Overview​In general, installing Cyanogenmod (or any other ROM, specific quirks notwithstanding) should consist of the following steps;
Pre-installation setup
Gathering Tools
Installing a custom recovery
Backing up your device
Flashing your custom ROM
Step-by-Step Walkhrough​
Pre-installation setup
When installing a custom ROM, or conducting any sort of flashing/recovery/rooting etc, you may mess up your phone somehow. Sometimes this will void your warranty, leave you with a brick, or somehow otherwise go belly up. Before you start doing anything to your phone, you should make sure you understand what you're doing, read through all of the steps, and familiarize yourself with the process. Sometimes you may need to gather additional information, software, tools, etc. Google is your best friend! When you encounter a block, stop what you're doing and investigate what happened, and see what the consensus is on the subject of that error, so you can tread carefully. In the end, this will make you a better tinkerer in general. Also, if you mess your phone up, I'm not responsible for your environment conditions, actions, or mistakes.
With all of that being said, if you're going to blaze forward anyways, welcome to the path of making things do what you want them to do, regardless of what someone said you could or couldn't do with said things! Before you get started, you're probably going to want to gather basic info first;
What do I want out of my custom ROM?
There are many types of ROMs out there; Cyanogenmod is one of the most popular, but millions of people have created or assembled their own favorite OS' for Android devices. This particular ROM offers you more control over your phone. You can install custom apps, use established apps, execute root/admin tasks on your phone, and much more. Custom icons? Custom boot screen? Remove all of the carrier/manufacturer bloatware? All of these and much more are at your disposal.​
Where can I find the model for my phone? What Android build do I have?
Before choosing to undertake a particular endeavor, make sure you know what phone you're actually working with. Using the wrong software or tool can brick your phone, or increase the time it takes to finish dramatically since you're going to have to go and find all of the fix information. In some cases, a phone may come with a certain version of Android, or a certain firmware. You should consider what may happen if you upgrade it, maybe you'll find you can't go back!​
Do I want to use this phone with service?
This was irritating for me when I first was flashing my phone; I found out that when I called Sprint to switch the phone over from my HTC One, they said they couldn't port the new modded phone onto their network. This required me having to search down the original firmware, which is a hassle in and of itself. I'm sure there are ways to get your phone onto a network that I don't have any knowledge of, but why not save yourself the trouble and make sure you take care of things before starting.​
Windows or Linux?
What operating system you are most comfortable with may vary, and your intentions with regards to flashing a custom ROM also will vary; do you just want to get something installed? Do you like to learn? Traditionally most folks will say that if you want the most control over the process, use Linux. It's open-source and gives you the most freedom to do as you wish, and in addition, untold numbers of tools exist for the platform that you have access to for free. Not that there's anything wrong with Windows, but if you want to flash a ROM, chances are you're interested in technology as a whole. Throughout this tutorial, I will do my best to provide options for both OS' where possible. In my case, I'm not interested in this process on a Mac environment, but you'll find most of the concepts here can be mirrored on the Mac OS, you'll just have to search for specifics on your own.
​
How comfortable am I with things like command lines?
Understanding how to use the command line, as opposed to graphical programs, will enable you to undertake the flashing process with much more control than otherwise allowed. Learning the command line is outside the scope of what I'm trying to teach you, but you can find information all around the web. Search for a cheatsheet for the Windows Command Line, or maybe if you're interested in learning about Linux, you can find information all over the web. With Linux, there can be a bit more variance on command lines as different flavors of Linux use different command lines.One such flavor of Linux is Ubuntu, which comes bundled with bash, a rather common and popular command line shell.
Again, where possible, I will try to provide options between the command line and GUI choices, but I will off the bat recommend that you familiarize yourself somewhat with the command line. You'll be a better person for it.
​
​
Gathering tools and info
Before you get started, it's a good idea to ensure that you have everything you're going to need at your disposal before getting started. I will do my best to document whatever I think is necessary to know on each tool/item you need;
Workspace
Sort of a no brainer, I would suggest creating a folder that you can store everything in the flash process, ideally one where you possess admin/root privileges. I will conduct this tutorial as if you were working from a folder titled 'Cyanogenmod.'
​
Phone Information
For the purposes of this tutorial, I am using the Sprint Samsung Galaxy S4 in black, which has the model number SPH-L720 (I don't think color influences model at all). At the moment, the phone is known as JFLTESPR at http://cyanogenmod.org/ specifically, though much of the process is the same across int'l/US carriers, so the phone also falls under the JFLTE family.
You'll want to have a few other pieces of info on hand as well. Most of these can be found either on the phone physically, or in the "About device" section in the Settings menu.
To get your model number, you can either remove the plastic rear panel, then the battery to find the model number written on the sticker underneath. Otherwise, you can go to Settings > About device > scroll to Model number.
In the same menu as above, you can also get the Android version, Baseband version, and the Build number. All of these help determine what features are available to you, what Android OS you have if you want to know about specific differences between numbers, what radio type you may have, and so on. Having these handy will let you look things up with a higher degree of accuracy.
​
Check Your Knowledge, or Are You Listening?
Did you make sure and go find the above information? If you care about your phone's warranty or you know, your freedom to mess with your SPH-L720 as you see fit, you should care enough to make sure you have this info!
Why does it matter? See your Baseband version and or Build number? Check those last 3 letters on there, they represent the firmware version you have installed on your phone. Certain firmwares have certain characteristics, but there are two in particular that you, as someone following this tutorial should care about; Whether or not the firmware comes with the Knox bootloader, and if you want the ability to downgrade/upgrade as you see fit. I also believe that the firmware can affect your hardware in sometimes undesirable ways. If you've recently flashed and your Wifi or radio (interface into the carrier's ecosystem for voice, messaging, and data) isn't working, research about the firmware is usually the first place to start looking.
The Knox bootloader contains a flag that is tripped if you install a custom recovery/bootloader, which doesn't affect any operation on your phone, however this flag, as of this writing, is not un-trippable. That's right, this is how Samsung will know if you've gone all rogue on the device. With this tripped, they can deny you warranty service, force you to pay for repair, and any other number of irritating things. Not knowing what firmware you can cost you dearly.
As to being able to change firmware freely, you can change between the Android 4.2.2 firmwares as you like, but if you move to 4.3, you cannot go back to 4.2.2, and 4.3 includes the Knox bootloader (though you can still move between 4.3 firmwares). Same for the firmware based on 4.4.2; if you move to this firmware, you cannot go back. In addition, as far as I know at the time of writing this, there's only one firmware in the 4.4.2 family.
For reference, here's a list of the firmwares;
MDC - This was the first firmware for the phone and was based on Android 4.2.2, and was pre-Knox bootloader
MDL- Based on Android 4.2.2, and was pre-Knox bootloader
MF9 - Based on Android 4.2.2, and was pre-Knox bootloader
MJA - Based on Android 4.3 and includes the Knox bootloader
MK2 - Based on Android 4.3 and includes the Knox bootloader
NAE - Based on Android 4.4.2 and includes the Knox bootloader
Besides influencing the above characteristics (and whatever other features are available per version), the firmware type also influences what software you might need in some cases. For instance, flashing back to stock requires you to use a firmware with the same 'class' of version, aka 4.2.2, 4.3, or 4.4.2. If you accidentally use the wrong version, you may regret it. Of course, if you're off warranty, or just don't care, you can go about this as you see fit. Just don't come to me if you fail to go learn what you need to know before flashing your phone. With all that being said, you can still install ROMs based on other versions of Android, just not a full flash.
I'm not sure of the correct XDA way to thank someone, but cruise350 provided me with this information directly, so if this helps, kudos goes to him.
​
Cyanogenmod ROM/OS
You can find everything you need to know (including the direct tutorials) for Cyanogenmod on their site <link>.
From the main page, you can get to the SPH-L720 by going to http://http://wiki.cyanogenmod.org/ > Devices > Hit 'show all devices' > enter 'JFLTE' in the search query to get to the landing page for our phone. From that page you can read more about Cyanogen and what you can do with it and our phone together. For now, we can just download the ROM.
Go to the download page at http://download.cyanogenmod.org/, where you'll find a list of devices and their various ROM builds. Since developers around the world are working on Cyanogenmod at any given time, there are many different builds/versions of the ROM. If this is your first time with Cyanogen, you will want to stick with the 'Stable' build. This is considered the latest 'finished' build, or represents the latest release the developers consider complete. The other builds represent ROMs which are nearing completion and moving to Stable (Release Candidate), a build at a particular point in time (Snapshot), builds which were created at a certain point in the development history of Cyanogen (Milestone), the absolute latest and greatest build as it's uploaded (Nightly), or just plain random (Experimental). Some of these builds are more fully featured than others, and others may be missing features, may be buggy, or somehow undesirable to us at this moment. As I said, for now, stick with Stable.
Remember how I mentioned that the SPH-L720 is called JFLTESPR by Cyanogen specifically? That's the download we're searching for. Click Stable under the Type menu, and scroll down to JFLTESPR. At the time I'm writing this, there are 3 versions of Cyanogen available to us; 10.1.3, 10.2.0, and 10.2.1. As a beginner, the differences between versions may be minimal, or minimally noticeable. I'd suggest getting the latest build for now, then futzing around with versioning later in your tinkering career.
In addition to Cyanogenmod, if you look on the installation page at http://wiki.cyanogenmod.org/w/Install_CM_for_jflte, under the heading 'Installing CyanogenMod from recovery' (we will get there), they mention the 3rd party app 'GApps,' which provides an interface into the Google ecosystem, so you'll have access to stuff like Gmail, Calendar, and the freakin keyboard! If you find your keyboard constantly failing, remember to go back and make sure you have the correct GApps version based on your Cyanogenmod version. The Cyanogen wiki provides a handy-dandy chart at http://wiki.cyanogenmod.org/w/Google_Apps to help you choose what GApps version you need.
​
Custom Recovery Mod
Cyanogenmod's wiki also provides you with info on what a recovery mod is at http://wiki.cyanogenmod.org/w/All_About_Recovery_Images.
Basically, when you receive a stock phone, the recovery/boot mode is limited in scope. As they say, it's mainly for installing manufacturer updates, and not much else of use to us. With a custom recovery, you gain access to many more features and things you can do outside the manufacturer's original intent. In the scope of this tutorial, we are using our custom recovery mod to first back up our phone's data, and second, actually install Cyanogenmod.
Just like the fact that there exists a large number of custom ROMs, so does there exist custom recovery mods. I'm choosing to use ClockWork Recovery Mod (CWRM) because it looks pretty and gets the job done. The specifics of a particular recovery are left up to the curiosity of the reader.
You can download CWRM at http://clockworkmod.com/rommanager; just scroll down to the Sprint GS4 and pick the version that is shown. Again, other versions may exist, but for the intrepid reader who's made it this far, stick with the latest, greatest, and easiest.
​
USB Cable
"Hurr durr no **** I need a USB cable" you say, but you wouldn't believe how irritating it is to attempt to diagnose a faulty cord issue. Sure, maybe you're the type of person who actually tries the easiest fixes first, this isn't revelatory, but if you're like me, I feel sorry both you and I.
Ensure you have a nice clean, un-kinked and untangled USB to Mini-USB cable on hand, preferably the cable that came with your phone. This will have the best chance of working properly. In addition to a cable, keep in mind that if you're using a USB hub, you may encounter errors. I've not used a powered USB hub in this process, but again, trying to diagnose the USB hub as the point of failure is annoying too. Save yourself the irritation.
​
Heimdall
Heimdall is a powerful open source program that lets you interface with the file structure of your phone and flash custom firmware, Heimdall was created by Benjamin Dobell of Glass Echidna and was designed specifically for Samsung devices. You can find a list of the phones they test on at the Heimdall page at http://glassechidna.com.au/heimdall/.
Some of you may have heard of Odin, another program used to flash firmware onto Samsung devices. Odin was an internal tool developed by the manufacturer that made it's way into the wild somehow, and can achieve the same effect as Heimdall (more or less), however there are a few reasons I suggest using Heimdall if you have a choice;
Heimdall is open source
You can freely access the code for Heimdall and make changes if you ever needed to, but the fact that the code is transparent and for all to use means an easier time flashing for you. The fact you can use Heimdall on Windows, Linux, and the Mac OS' is just a whole bunch of whipped cream on the flash-cake.
Odin is an internal Samsung tool
This means you don't have a way to go ask the maker of the tool for help, or explanations on how to use it. Samsung will offer customer support for this tool equal to the amount of existence that flash-cake has; none. There is documentation from all the smart people out there who have dug into Odin if you do want to use Odin. Also, it's Windows-only. You might not care about this fact, but if you're a tinkerer, Linux would be nice no?
Support!
In my flashing journey, I've had to troubleshoot a few things as far as Heimdall goes, and many times on some pages, I've seen Benjamin reply to people with information that he and only he can provide as the maker of Heimdall. I don't know him personally or really at all, but at least we can go ask him for support if necessary.
In order to use Heimdall, you just need to unzip the contents of the download into the Cyanogenmod folder, in our case, create a folder titled 'Heimdall' inside of Cyanogenmod.
​
Android SDK
The Android Software Development Kit (SDK) is the software Google provides for developers to create things in the Android ecosystem. The kit contains the code editor Eclipse, a plethora of support tools and tricks to create the best apps/ROMs/whatever you can think of, as well as interface with your phone in manners beyond ordinary users. There is a lot of stuff in the SDK, but we are specifically interested in the Android Debug Bridge (ADB) tool, which allows you to send data back and forth from your phone.
You can find the SDK at https://developer.android.com/sdk/index.html, but keep in mind you will most likely need admin/root privileges in order to use the SDK (and Heimdall). From that page, you can choose the Android Developer Tools (ADT) bundle, which comes with Eclipse, or you can choose to download an SDK kit without the IDE. For the scope of this tutorial, you only require the SDK. Once downloaded, you can unzip the SDK into the Cyanogenmod folder (the first thing to come out the SDK zip is a folder titled sdk, plus the SDK manager).
Open up the SDK Manager program (if you're on Windows, if running SDKManager.exe briefly shows a command prompt window, then disappears, you can go to sdk > tools > android.bat. This will open the SDKManager for you). The SDK will provide you with a list of packages you can download for various parts of Android development, but the ones we care about are the Android SDK Tools and the Android SDK Platform-tools. Check the box by each one, then hit install packages. The SDK Manager will prompt you for some license agreementing, then install the software for you. I believe that the manager installs the software in the sdk folder that the manager also resides in, so keep this in mind.
​
Installing a custom recovery
Backing up your device
Flashing your custom ROM

Reserve 1
For more info.

Reserve 2
Just in case.
If you happen to be reading this for the content, can you answer this; should I include the basics such as installation processes and whatnot? Or just skim the basics?

is it possible to dual boot multi custom rom on mi 9t?

I googled a lot but not succeed to find a way to install several rom on my mi 9t phone, have we a way to do that?

any idea friends?

can anyone tell me is it possible or not please?

Hello m-Khadem,
the only tool I know who can do this is called DualBootPatcher.
This tool is no longer in development.
Here's why:
Due to recent changes in Android P, as well as upcoming changes in Android Q, DualBootPatcher is no longer being developed. These two releases change some fundamental assumptions that DBP makes about the host device.
With devices that ship with Android 9.0+, the system-as-root partition layout is mandatory. This means that the system partition includes everything that traditionally went in the boot image's ramdisk. DBP relies on being able to modify the ramdisk to add its binaries as well as some config files that specify the ROM ID and device specific information (eg. partitions). To switch between ROMs, DBP simply flashes the ROM's patched boot image.
With the system-as-root partition layout, most of the files could potentially live on the system partition, but the ROM ID must be stored in the boot image. With some devices, like Google Pixels, a ramdisk can be added back by including it in the boot image and patching the kernel image to ignore the skip_initramfs cmdline option. However, on other devices, like the Samsung Galaxy S10 series, the bootloader will always ignore the ramdisk section in the boot image. Storing the ROM ID in the cmdline field is also not feasible because many devices' bootloaders ignore the whole field.
With the Android Q preview builds, some devices, such as the Google Pixel 3 series, switched to using dm-linear for handling the partition layout of the read-only OS partitions (system, vendor, etc.). With this setup, a single GPT partition is split up and is mapped to device-mapper block devices by a userspace tool. With Android's /init, this is done via the liblp library, which parses the metadata on disk and configures dm-linear. DBP would have to implement something equivalent to this to be able to mount the Android partitions. It currently assumes that the kernel will provide a mountable block device after going throug the uevent device probing phase.
Neither of these changes are impossible to work around, but I have simply lost any interest in doing so. I have not used DBP on my primary devices for a couple of years now. Those interested in continuing development are free to fork the project. Any work that had been done for the 10.0.0 release has been pushed to the 10.0.0-staging branch.
All downloads have been moved to SourceForge at https://sourceforge.net/projects/dualbootpatcher/files/. I will work on splitting out some of the more useful parts of DBP, such as libmbbootimg (boot image parser) and libmbsystrace (syscall injection/modification library), so that they can be used in other projects, but DBP itself will no longer be developed.
Huge thanks to everyone who helped out with this project the past six years!
Click to expand...
Click to collapse
Source : Github

AlexCmb said:
Hello m-Khadem, the only tool I know who can do this is called DualBootPatcher. This tool is no longer in development. Here's why it's no longer possible (and why this is no longer possible at all)):
Source : Github
Click to expand...
Click to collapse
Dear Alex
Thanks for your reply, I saw this thread and unfortunately this solution will not work anymore