Related
I'd like to toss this out for discussion. This might already exist, it might not.
Microsoft had system builders use a Disk Differencing technique to extract what exactly had changed after installing applications and customizations.
First, we'd install the OS and create a base image.
Second, we'd install the apps & customizations we wanted for our customers.
Third, we'd create another image. An app would then compare these two images and determine what files were added/changed and what registry additions, deletions, alterations were performed.
I'm hoping we can do the same for ROM upgrades.
1. OLD ROM - Base image.
2. Install apps and customizations - Image "Apps". This will give us our customizations.
3. Install new ROM - NEW base image created. Compare to OLD ROM base image to see what has changed (that we need to look out for that our APPs image might adversly change).
4. Apply Apps image to restore all customizations & applications.
Ideas anyone?
The theory sounds good.
Maybe buzz can comment?
The theory is very feasable, ive used similar building Win PE rescue disks, you have a app that gives you the base bootable image made from a Win XP install CD. then you add home made "modules" ie, your installed apps or networking capabilities etc. then it makes an image for you to use,
that cant really be that difficult to do the same for Win CE,
Ive also seen a M$ webcast thing where the guy took 45 mins to build an entire image for a win ce device,
so yer, it is very feasible that such dev apps exist, after all, they were made and then sold to the hardware vendors before ever being a rom image.
check in msdn for win ce 5 stuff, its a very intresting read, :shock:
it is a good idea, but only for linear ROMs, where each file has always it's own and same place in the rom and such rom is not compressed.
hmm...
but you can do partial rom upgrades with wm5 roms...
...and it would be possible to make registry diff + DOC Storage partition backup, where you actually install programs (so called \Device) and userdata.
buzz
buzz_lightyear said:
it is a good idea, but only for linear ROMs, where each file has always it's own and same place in the rom and such rom is not compressed.
hmm...
but you can do partial rom upgrades with wm5 roms...
...and it would be possible to make registry diff + DOC Storage partition backup, where you actually install programs (so called \Device) and userdata.
buzz
Click to expand...
Click to collapse
Ok...Since I'm not a programmer and somewhat of a noob with respect to WinCE, I am NOT constrained by what might be a logical limitation to a programmer or someone in the "know". So, below is my thinking ... outside of the box (er, PDA) style.
But first, I need to grasp further Buzz's post above about the locations of things in ROM. Does this mean that there isn't, for lack of a better example, a FAT for the ROM? That every individual thing is expected to be at some specific, static location that can't change? If so, I see your point. But that tells the system that this location is static? Also, doesn't that make bug fixes difficult as the fix might exceed the designated space in ROM? Or do bug fixes always get re-applied after each reset? Patching in memory is how I'm looking at this. (Remember, I'm a non-programmer...deal with me, please.) LOL
Ok..out of the box time.
1. Can a shim be used to capture calls to a certain location in the ROM and redirect to another location (within the ROM or even the storage card. Linux builds anyone?). Like what HD disk managers did to get around LBA limitations or even boot sector viruses did.
2. Can an emulator be used to simulate/backup/build/test the ROMs on a PC before wiping the PDA? Don't laugh, but if not, could something be done with Virtual PC? Oh..Ok, laugh.
(Should I go hide somewhere?)
If you ever used CWM, CWMT or other non factory recoveries to wipe your data, you probably noticed that you lost the ability to encrypt your phone. Or maybe you did not even realize this is why encryption does not work.
For the Android phone encryption to work, it needs the /data (usrdata) partition to have a little bit of unused space between the end of the filesystem and the end of the partition. And as soon as you use CWM to wipe, it actually reformats using all space, and encryption does not work anymore.
User lolo250612 brought this to my attention, and together we created a update.zip that shrinks the /data filesystem by 1MB
In fact, we created 2 patches: One to shrink, and one to first repair the filesystem. The first will refuse to shrink if the file system is not clean and healthy. They will automatically find the correct usrdata partition device and its size. The shrink will then resize to 1MB less then the partition size (which means it could also be used to grow if you somehow had a filesystem a lot smaller, for example because you restored an smaller image from somewhere).
Both patches are created with statically linked e2fsprogs binaries and its own static copy of busybox shell interpreter. So they should work on all Android devices that use ext file system (probably all V2.3.1 Gingerbread and higher androids), and you should not lose any data because of this. But it is always good to make a backup.
We tested this on 2 phones, both ICS phones, and with both CWM and TWRP type recoveries, and are fairly certain it is safe to use. But to repeat, you should always take a backup of your phone.
Both patches can be found on my shared drive:
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
Procedure:
- Make backup of your phone
- Place files on SD card
- Boot into recovery
- Apply the shrink update
- If it tells you the filesystem is damaged apply the fix-fs update first
The patch only shrinks the filesystem, nothing is actually installed or removed on the phone. But if you use encryption, you could leave this patch on your SD card so that every time you wipe data, you can run the shrink patch again afterward to enable encryption again.
If you do use this, please report back in this thread, possibly mentioning your phone model and ROM you are using.
Quick encryption guide (and more)
I won't go deep into useless details as everything has already been described about Android phone protection somewhere on the internet. I will just give some meaningful links and tips by illustrating how I have protected my phone. Really nothing new or innovative, just a compilation of a few hints that I have put in practice to protect the numerous pieces of information that are on my phone.
Step 0: awareness
----------------------------
Why bother with phone security?
In short, I am clearly paranoid. Well, in fact, I don’t really feel at ease when I know all the information, both personal and professional I have on my phone. Over the month, my Androphone has become a real digital Swiss-knife and personal secretary. This includes:
Personal and professional contacts
Personal and professional agendas
Personal and professional digital exchanges (SMS and email)
Personal and professional photos
Banking account information
Trails where I run
Etc… etc…
Don't want someone looks at them. Not you?
Fist step: on-line protection
----------------------------------------
The first step in protecting your data consists in making hard to access indirectly the data that lay on your phone memory. This access consists in using the system when the phone is on, either via the GUI and the phone controls, or remotely (essentially by network connections, or phone basic functionalities like sms). So, basically, you need to lock efficiently your phone from preventing someone else to unlock the user interface that allows interactions with the system, and protect all communication channels.
To lock efficiently your phone, you must use a pin code of at least 4 digits (6 is better) or a pass-phrase. The latter is much less practical without improving online security that much. Above all, you must avoid those silly locking solutions like face recognition unlocking, or pattern lock. Those are toys for naive young boys. Not for those concerned seriously by security.
For protecting remote access to your phone, I would suggest:
1) Double check that USB debugging is disabled. This a major security hole.
2) Turn on data connections (bluetooth, wifi and 2/G/3G/4G) only when required (email checking, web-surfing session, data synchronising), and off rest of the time.
3) Avoid install cracked unofficial apks, or applications that asks for permission far beyond their obvious and principal utility
4) Install a software security app, if possible, open source and recognised by xda members. Once an adept of Droiwall, I have switched to Avast mobile security because of its extra features. But it is not opensource and it is a question of taste. But do this carefully, see that for instance before making a choice: http://download.cnet.com/8301-2007_4-57391170-12/dont-get-faked-by-android-antivirus-apps/ and http://www.av-test.org/fileadmin/pdf/avtest_2012-02_android_anti-malware_report_english.pdf.
But, you must be rooted (which is in itself a security hole if not mastered) and one must have a kernel with netfilter functionalities activated. This is the case with the stock kernel of the phone I use at the present time (Lenovo A789). But was not the case of 2 Samsung phones I used before. You have to either install a custom kernel adapted to your phone, or make your own if you have access to its sources (see tutorials as: http://forum.xda-developers.com/showpost.php?p=22941057&postcount=1)
5) Personally, I would feel more at ease if I could find an easy to use firewall solution that could close, and better, make stealth all the local ports of my phone, especially when I am not behind a wifi router. But I haven’t found one yet. Droidwall, nor Avast, addresses this functionality, whereas it would be fairly easy to implement it with the netfilter system layer underneath.
Second step: offline protection
-------------------------------------------
Here we are. Now your phone is protected when it is on. But, what if you switch it off, or remove its sdcard? The data lay on the internal memory, unprotected (at best obfuscated). Really easy to find a custom recovery for almost all phones, write a script to dump /data on a sdcard and then make whatever you want with the copy.
Don’t like that? The only solution to prevent /data from being read by someone else is to encrypt the /data partition. To do that, your phone or tablet internal storage partitions must be seen by your system as block devices. This is the case with eMMC but not with Yaffs. So beware, if you want encryption you need to buy a device that answers this requirement. This is not always true and almost never documented. Notes on the implementation of Android encryption are there: http://source.android.com/tech/encryption/android_crypto_implementation.html
Now, as me, if you are reading these lines, you are certainly looking for extra information about your Android device and probably extra functionalities.
Certainly, the most frequent way to install extra functionalities and custom ROMs to your phone is to use an update zip file. With stock recovery, this zip file needs to be signed, otherwise it is rejected. For maximum flexibility and ease of use, alternative boot recovery have been developed, of which CWRP is certainly the most famous.
Usually, for 99% of users and operations, CWRP operates great. Sometimes, as nothing is perfect, a bug may occur. This is the case for built in ICS encryption process. As Cybermaus indicates in the first post, to be able to perform this encryption the /data filesystem must be slightly smaller than the underlying partition. But CWRP, at least up to the version 5.5, formats all the corresponding partition leaving no place for Android to store the required information to be able to start the encryption process. This is clearly described in the following links: http://forum.xda-developers.com/showthread.php?t=1792101 and http://rootzwiki.com/topic/25652-fixing-galaxy-tab-2-encryption/
I have discovered that by using aLogcat to track down the origin of the failure. The interesting part revealed to be: E/Cryptfs ( 87): Orig filesystem overlaps crypto footer region. Cannot encrypt in place.
To circumvent this problem, you will find in Cybermaus first post, two CWM update zip files that will do the trick in a simple and secure way. After flashing your ROM and wiping data with CWM, apply them, go to system encryption as described here:http://support.google.com/android/bin/answer.py?hl=en&answer=1663755, and after waiting one or two minutes (not more), the system should restart automagically to encrypt your /data partition.
Third step: making your phone even more secure and practical at the same time
-------------------------------------------------------------------------------------------------------------------
Android built-in encryption is in fact more or less Linux LUKS (http://en.wikipedia.org/wiki/Linux_Unified_Key_Setup). Plus, it is open-source so that everyone with the required skills can make an audit of the code to see if no security hole is present in the Android implementation. The underlying mechanism is strong and secure, as long as you use a strong password. I mean by strong, at least 12 characters that includes at the same time lower-case letters, upper-case letters, numbers and symbols. And it must be something impossible to guess for others while easy to remember for yourself. You will find a lot of resources on the internet on how to create such a password. For instance: https://help.ubuntu.com/community/StrongPasswords .
The problem with Android, in its attempt to keep the system not too complicated to use, is that the GUI (I insist: only the GUI, not the system) does not distinguish between the PIN or passphrase that you use to lock your phone when it is on, and the password used to encrypt the data that lay physically on your phone storage. So the casual user is in front of a paradigm: either he chooses a strong password for its data, but this will rapidly become tedious to type at least 12 characters to unlock his device several times a day; or he decides to use a PIN code, which is more practical to unlock the phone, and consequently uses a really weak password to encrypt its data which contains only digits, and thus may be cracked in a breath by any PC.
Fortunately, this paradigm is addressed and solved by small tools like EncPassChanger or Cryptfs Password (both requiring that your phone be rooted, which is by the way, paradoxically, a security hole if not used with caution ). See: http://nelenkov.blogspot.fr/2012/08/changing-androids-disk-encryption.html for complete notes about that. So for me, the only way, both secure and practical, to secure your phone is by using a PIN code of at least 4 numbers (6 is better). Then use a handy tool like EncPassChanger to have a true complex password for decryption at boot time.
Fourth step: increase security, without sacrifying practicability
-----------------------------------------------------------------------------------------
As I am paranoid, but at the same time don’t want my phone to become a source of annoyances, the previous “basic” steps were not enough for me.
So I decided to improve security in two ways:
1) By following the following tip, which I find great and is itself self-explaining: http://forum.xda-developers.com/showpost.php?p=26730989&postcount=2
2) By encrypting the photos I take with my phone, because these are linked with my private life and I won’t like that somebody gain access to them.
3) By encrypting documents I scan with CamScanner, for home and work, which may be sensitive.
4) By automating the action that disables USB debugging in case I forget to put it off after using it .
For point 2 and 3, documents lay on your sd card uncrypted. Android built-in encryption does not deal with both internal and external sdcard (just to be clear, by sdcards I mean partitions mounted as /mnt/scard or /mnt/scard2). To encrypt them you have to use once again an external tool. As I am an opensource fanatic for all that deal with security, I would recommend to use LUKS Manager (https://play.google.com/store/apps/details?id=com.nemesis2.luksmanager&feature=search_result and http://forum.xda-developers.com/showthread.php?t=1141467) which is based on dm-crypt module (yes, the same that Android uses for its build-in encryption), or Cryptonite (https://play.google.com/store/apps/details?id=csh.cryptonite&feature=search_result) which is completely open-source and implements the rock-solid Linux encfs on Android.
The latter is my personal choice. I do not use Crytonite in itself, except for creating the initial .encfs6.xml file. For everyday use, I use directly the Android port of the binary file encfs that comes with Cryptonite, and embed it into shell scripts. Up to now, no flaw, no problem. The password to open my encfs encrypted volumes is stored in a text file located on the /data partition. It is thus encrypted by Android and made accessible on boot when you decrypt this partition. So nothing more to remember.
To make things usable and practical, I use Tasker to automate the following things:
- Mount encfs volumes on start-up, by reading directly the password in the file located on /data
- Umount encfs volumes when usb is plugged
- Copy photos on a regular basis from the unencrypted /mnt/sdcard/DCIM to the safe place I created with encfs, delete AND wipe the original ones
Fifth step: be coherent about security
-----------------------------------------------------
Some people, torn apart by the paradigm described in Third step, by negligence or by lack of knowledge, strongly secure one part of the system, but make other parts big security holes.
Concretely, I am thinking about two examples: mixing encryption with pattern lock (or, even worse, with face unlock), or mixing encryption with usb debugging. Face recognition is just a jock. It is not reliable and fails very often. Moreover it is really easy to crack, with a photo for example. One of my colleague even achieved to unlock my phone with its own face, just because we are morphologically close enough. Pattern lock is not much better. (See: http://forum.xda-developers.com/showpost.php?p=37649447&postcount=6 and https://www.google.fr/search?q=smudge+attack).
So always ponder over (two times rather than one) each action you take that may touch system security.
Thanks lolo
I'm trying to use this on my VZW Galaxy S3 16Gb and this is what I'm seeing in TWRP v2.2.0:
Mounting System
Extracting system fixes
Update script starting...
Update script started
Disk /dev/block/mmcblk0p15: 13.1GB, 13140754432
4 heads, 10 sectors/track, 401024 cylinders
Units = cylinders of 64 * 512 = 32768 bytes
ERROR: unlikely size of KB
aborting operation!
Update script ended
Unmounting system...
Update Complete
Click to expand...
Click to collapse
edit: The same thing happens with both scripts.
I need to enable device encryption because my employer requires it for email and other Google Apps for Business apps. Thank you for your help!
Anyone know why full disk encryption isn't available on some (if not most roms)? Is it something that needs to be added with intent aside in the building process, or dependent on how the stock rom was set-up to work with?
I was hoping this would help get encryption working on an EVO ics rom which has encryption available, but when you click "encrypt phone" it just hangs on an android screen and doesn't actually do anything.
i was really happy to find your solution to enable encryption on my HTC desire S (ICS, rooted), but unfotunately it doesn't work. the same thing happen to me as it happened to mushu13, only different numbers in lines 5 and 6. same result whichever script i choose. please help, i really need system encryption.
thanky you very much!
First thing you should know, I am not an Android Guru. And unfortunately, if your phone is not an A789, I won't be able to help you deep in technical details. Cybermaus is the most skilled of the two of us, technically speaking, and he may lack time to answer correctly every request he is regurlarly faced with.
Okay, I do not know your phones and don't own them. So, distant debugging is much harder in these conditions. But the first things you should check, before applying Cybermaus' patches, are :
1) if encryption works with stock rom
2) follow thoroughly all steps I described in "Second step: offline protection" of the second post of this thread :
- your phone or tablet internal storage partitions must be seen by your system as block devices. This is the case with eMMC but not with Yaffs. If you don't have this information from the manufacturer, install Terminal Emulator from the Play Store and type 'mount' in it. You should see lines beginning with /[email protected] and /[email protected] If this is not the case, I fear encryption won't be able to work on your device.
- use aLogcat to track down the origin of the failure (see resources on the internet to learn how to use it, and links I have put in the second post)
3) Be sure that required modules are built into the kernel you use, especially dm-crypt
4) Post your results and cross your fingers that either this is a problem I have already encountered (in this case I may help you further), or Cybermaus see your posts.
While this script did allow me to encrypt my phone, it also shrunk my /data partition to roughly 1.1 GB.
Any ideas on how to expand it back to a reasonable size? I supposedly have 4 GB of ROM, and I assume more than 1 GB ought to be available for data.
Sent from my HTC Sensation using xda app-developers app
Thank you for your nice guide.
Only one thing is missing: baseband security.
Attacks on the baseband system requires very skilled people. Such as government agencies. It is believed they use baseband attacks to break into almost every mobile device. And there is only little you can do. Some vendors like Cryptophone have mobile devices with a hardened Android system. All others have no way to protect their device against baseband attacks.
Is this patch and reasoning still valid for newer android releases.
I am running a custom kitkat rom and twrp on a note 3 and can't encrypt so im looking for a fix.
I have been looking around for fixes but different posts blame different things.
Sometimes its the fact its a custom recovery, sometimes its that root is on the device and then there is this reasoning
Is there a way to find out the cause and fix for kitkat?
Virus
Hi, i tried to download your files
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
But the file are exe files with viruses.
Any ideas?
u2funker said:
Hi, i tried to download your files
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
But the file are exe files with viruses.
Any ideas?
Click to expand...
Click to collapse
Maybe false alarm.
Lossyx said:
Maybe false alarm.
Click to expand...
Click to collapse
no, but if you search for these file, you will find some which work and which are without viruses. Check the link..it is not an zip file..it is an exe file
@cybermaus: just tried flashing the two *.zips on my Galaxy S 4 Mini running CM 12 (Android Lollipop) because my logcat tells me I'm getting the described cryptfs error. It seems my /data partition doesn't have that 1 MB of unused space needed for encryption. Now I would love to encrypt my phone using CM's integrated function without having to completely format the internal storage (because that's the other workaround I found: flash stock rom, wipe data (factory reset), flash Custom Recovery, flash CM again)
Do you have the time and device to update your script so it works with Android Lollipop as well? I see a lot of people come across this issue recently so there would be definetly use for such a nice script like yours!
Thanks for sharing this with us!
-Teutone
no available for download any mirror ?
Or write the script on the thread.
Thanks
Can you post the scripts? links are dead!
---------- Post added at 16:33 ---------- Previous post was at 16:32 ----------
cybermaus said:
If you ever used CWM, CWMT or other non factory recoveries to wipe your data, you probably noticed that you lost the ability to encrypt your phone. Or maybe you did not even realize this is why encryption does not work.
For the Android phone encryption to work, it needs the /data (usrdata) partition to have a little bit of unused space between the end of the filesystem and the end of the partition. And as soon as you use CWM to wipe, it actually reformats using all space, and encryption does not work anymore.
User lolo250612 brought this to my attention, and together we created a update.zip that shrinks the /data filesystem by 1MB
In fact, we created 2 patches: One to shrink, and one to first repair the filesystem. The first will refuse to shrink if the file system is not clean and healthy. They will automatically find the correct usrdata partition device and its size. The shrink will then resize to 1MB less then the partition size (which means it could also be used to grow if you somehow had a filesystem a lot smaller, for example because you restored an smaller image from somewhere).
Both patches are created with statically linked e2fsprogs binaries and its own static copy of busybox shell interpreter. So they should work on all Android devices that use ext file system (probably all V2.3.1 Gingerbread and higher androids), and you should not lose any data because of this. But it is always good to make a backup.
We tested this on 2 phones, both ICS phones, and with both CWM and TWRP type recoveries, and are fairly certain it is safe to use. But to repeat, you should always take a backup of your phone.
Both patches can be found on my shared drive:
ICS_usrdata_fix-fs.zip
ICS_usrdata_shrink.zip
Procedure:
- Make backup of your phone
- Place files on SD card
- Boot into recovery
- Apply the shrink update
- If it tells you the filesystem is damaged apply the fix-fs update first
The patch only shrinks the filesystem, nothing is actually installed or removed on the phone. But if you use encryption, you could leave this patch on your SD card so that every time you wipe data, you can run the shrink patch again afterward to enable encryption again.
If you do use this, please report back in this thread, possibly mentioning your phone model and ROM you are using.
Click to expand...
Click to collapse
links are dead. Can you post the scripts?
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★★★★
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
Note from the Author -
I am moving on to the N5 now and ditching my S3. I will continue to maintain this thread, however - please do PM me if you think that something needs to be changed or updated in this thread as I doubt I will be answering questions within the thread as much. Please don't PM support questions to me. Only PM updates that need to be made in the thread.
It's been a blast!
Regards
Dan
efs | backup your efs | backup your efs | backup your efs | backup your efs | backup your
Understanding the basics before rooting your S3 (GT-i9300/i9305)
This thread is intended to give you (as someone considering rooting your device) an overview of some of what I deem to be, really important information. Many people blindly follow guides and end up in trouble because they break their phones and don't really know what they were even doing at the time.
This may seem a bit overwhelming at first, there is a lot of text, but please do take the time to read it. It may save you further down the line.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Before we get started...
Here are a couple of threads you should get familiar with before posting on XDA.
Forum Rules - use Search before posting
Post Questions or Support queries in Q&A, NOT General
What is root access?
"root" is (but not exclusively) a Linux term. As you may or may not know, Android is based on a Linux Kernel.
The term "root" refers to the root of the device. All devices with an operating system use a series of directories (or folders) nested within one another. If you think of windows, your documents folder would be C:\users\username\documents.. Well, "documents" is a directory. It is within another directory (username).
Imagine "documents" being the top of a tree (A folder tree). You climb down the tree to username, past there to "users" and down to the root, in this example "c:". You cannot go beyond this level, because nothing exists beyond the root. To save a file directly on C: (not within any folders) would be to save a file to the root of your c: drive.
In Linux (unlike Windows), these root locations are completely locked down. A user of normal priviledges cannot edit any file or create files in these locations. They can only do this in their "home" location, which is the equivelant of username on windows. To gain access to these locations, you would need to be an administrator of the machine. Linux calls this Super User (su), and this user is said to have "root access".
This applies to Android in the same way. To root your Android device, is to have superuser access to the root locations of your phone, that you normally could not have access to.
Is it Risky?
There is always a risk having access to locations on your phone that are supposed to be locked down. You can easily delete things that your phone needs to boot up, which could lead to you losing all your data or even breaking your phone. This is why it is good have an understanding of your device and root access BEFORE you root.
It is worth noting that although many say rooting shouldn't void your warranty (it does in many places) even where that is supposed to be true, in practice, it isn't really. Even in the EU, I've seen many warranty claims rejected due to root so do think of your phone as out of warranty when you root.
The advantages of rooting
Why root?
More control over how the CPU acts. This can increase performance or battery life
More control over power consumption (undervolting)
More control over how apps start up. Prevent apps from starting up when they don't need to
Baseband. Try different basebands with the possibility of reducing drain or imporving signal strength
De-bloat. Remove or freeze system apps that you don't use
Access to community driven bug fixes that Samsung haven't released
Custom ROMs. Add additional functionality and controls over and above the stock experience
Increase redundancy. The ability to backup apps and entire phone
Theme. Don't be stuck with Samsung driving aesthetics.
Innovations. Use community driven features that improve your day to day experience
Better RAM management. Change the values of "Out of memory". Decide yourself when android should kill unused apps. Increase mutlitasking capabilities
Custom kernels. With kernels you can bring support for better audio features, better graphics performance and support for stock unsupported files systems
Google Android. Use android as it was intended before Samsung got their hands on it.
The Disadvantages of rooting
Why not root?
For all intents and purposes, rooting voids warranty.
Dangerous. You can break your phone and need the warranty you probably just voided
You open the doors for more mistakes. These mistakes may cause you to panic and further damage your phone
Lack of understanding. Blindly following guides and not understanding what you're doing.
No more official updates. Updating is a more manual process
Basic layout of /root on the GT-i9300
I'm not going to go into too much detail here. I just need you to know the basics. The GT-i9300 has an embedded Multi Media Card. This is the internal memory that everything on your phone you need to run it, is insalled on. It is the "internal memory" of the device.
Like windows and linux, there is a root to this memory, which has a few basic partitions that you need to know.
/efs - This is REALLY important. This is where your IMEI is stored, which you need to connect to your provider's network. Unfortunately it is the easiest partition to corrupt and impossible to restore without a backup so ensure you have a recovery or application to backup your efs cause if it goes (likely) you'll be sending your S3 to Samsung for repair.
Please read THIS THREAD for more info on EFS and IMEI issues.
/system - This is where the ROM is installed. Within /system are many important folders that you normally cannot get to.
For example, you have /system/app where all the important ROM apps are located. Things like the phone app and the messaging app. /system/bin, where all the important binaries are located that allow android to execute commands that it needs to, so it can function as an OS and /system/framework, where the crucial policies that control how things the user and processes interact with - act.
/data - This is where apps you install are kept. This is also where your data is kept, eg your SMS and e-mails. It also stores settings. If you change the wallpaper, it is stored here. What ringtone you have chosen... etc. The important directories here are /data/app and /data/data. These are what get wiped when you choose to wipe data\factory reset
/data/media is an important directory in /data. This is what is known as your "internal storage" or your "internal sdcard". /sdcard maps to here.
When you have root access to android, you can browse these partitions with a root explorer / file manager with root functionality.
There are also some hidden partitions you cannot browse like this. These are the partitions that contain recovery, bootloader and kernel
What are those things?
Kernel - This is always supplied with a ROM. It is the beating heart of Android. The ROM cannot function without the kernel. Since all ROMs include a kernel, if you're using a custom Kernel then flash a ROM, you will need to reflash the kernel again.
Please note, unlike the Galaxy S2 (and like almost every other modern android device) the kernel and recovery are independent. There is no link between recovery and kernel. Kernels are boot.img files.
Bootloader - this is what handles what you boot into. When you see the black Galaxy s III text, thats the bootloader. Its job is to handle the boot. It is responsible for booting into android, or if you manipulate the buttons in a certain way, it will boot into recovery or download mode. PLEASE NOTE, i9300/5 Bootloader is NOT LOCKED. DO NOT TRY TO UNLOCK IT. Only some US variants have a locked bootloader...
When you see this screen, you're looking at the bootloader:
Download mode is part of the bootloader itself. Again, it is a mini OS. It is designed for flashing stock (official) ROMs onto the phone (Which you can do using Odin). It is also used by Samsung to detect the status of your phone (if you have modified it or not).
If you have (or had before rooting) an official ROM above 4.1.1, Your bootloader flash counter in download mode will change to "1" at every boot, if you have a custom kernel or recovery - even if you reset it with Triangle Away. See the return for warranty link later in this post to get around this.
To access download mode, turn off your phone. Home volume down + home then press power. You will get to the screen below:
Press volume up to continue into Download mode:
Recovery - a secondary, min operating system designed to offer a few "drastic" options to recover when you cannot boot into android. For example, factory reset. Recovery isn't part of android. It is a seperate operting system. You can either boot into android or boot into reocvery.
To access recovery (custom or stock), turn of you phone. Hold volume up + home then press power.
The intial use of Stock recovery was to allow a user whose phone does not boot, to wipe their device to "recover" it to a booting state. It could also flash official updates from the sdcard. Custom recoveries do so much more, such as allowing you to flash custom rom.zip or kernel.zips from sdcard or backing up your device with a nandroid recovery.
Here is an example of a custom recovery (Philx Touch 5):
Please note, unlike the Galaxy S2 (and like almost every other modern android device) the kernel and recovery are independent. There is no link between recovery and kernel.
Some other stuff you may have heard about
Baseband / Modem / Radio - This is the software that manages your connection to wireless networks, be that voice or data. Unlike unrooted users, you can download and flash any number of i9300 (Versions for other models WILL BRICK YOUR PHONE) or i9305 radios pulled from official ROMs. I wouldn't waste too much time on them. Usually what your official ROM comes with in your country / for your carrier, is the most optimised for you. Try a few by all means but don't waste time testing every last one.
Be aware that Samsung official ROMs come with a baseband. Often this means Samsung based custom ROMs may also do so. Some ROMs which install using the Aroma installer (A kind of set-up wizard) may give the option to not flash the baseband. AOSP ROMs almost never come with a baseband. When you flash a ROM withotu a baseband, the previous baseband remains. You can by all means, mix and match ROMs and basebands. You are not tied to the baseband with the same build number as the ROM. For example, if you are on XXEMB1 ROM, you definitely do NOT have to stay on the XXEMB1 baseband.
RIL - RIL is Radio Interface layer. It's what sits between the radio (above) and the android telephony services. Each Radio is supposed to have a specific RIL. Every ROM comes with RIL as it's a requirement to function. Again, although the best pair is a matched RIL and Radio version, if you do change your Radio, it's not the end of the world. You may notice a little difference flashing the right one, but it's not something to get bogged down with. Personally, I very rarely try a new Radio. I almost never change my RIL.
It's worth mentioning that the above is only really valid for Touchwiz ROMs. AOSP ROMs use OpenRIL and are not compatible with Samsung RILs. Do not use apps like GetRIL or flash Modem+RIL packages on AOSP ROMs. You would have to reflash the ROM if you do this because using a Samsung RIL on your AOSP ROM will likely break your signal.
Also note, Nandroid backups generally don't backup the Radio. Some recoveries may give you a separate option to do so however. The RIL (as part of the ROM itself) is backed up in a Nandroid.
ROM - ROM really stands for "Read Only Memory" which refers to memory that cannot be overwritten. When we talk about an Android ROM, we are really talking about the Android OS which is installed ON the Read Only Memory, of course since rooting, the /system partition where the ROM is installed is no longer read only. It is read / write. Flashing a ROM will over write the entire /system partition with whatever is in the ROM.zip or ROM.tar. Any mods, scripts, themes or apps will be replaced. You can only have one ROM at a time, unless you use one of those funky dual boot kernels.
More advanced layout of the GT-i9300
Here we have a lovely MS paint diagram of the eMMC layout of the GT-i9300/5. Some of this you don't need to know, some of it you do.
1 BOTA0 - mmcblk0p1 - 4 MB
2 BOTA1 - mmcblk0p2 - 4 MB
3 EFS - mmcblk0p3 - 19.7M
4 PARAM - mmcblk0p4 - 8 MB
5 BOOT - mmcblk0p5 - 8 MB
6 RECOVERY - mmcblk0p6 - 8 MB
7 RADIO - mmcblk0p7 - 33 MB
8 CACHE - mmcblk0p8 - 1 GB
9 SYSTEM - mmcblk0p9 - 1.48 GB
10 HIDDEN - mmcblk0p10 - 587 MB
11 OTA - mmcblk0p11 - 8 MB
12 USERDATA - mmcblk0p12 - 11.4 GB
The above sizes are approximate and the diagram is not to scale.
Rooting the phone
When you go through the process of rooting the phone, you have to alter the ROM. Although the risks of this are very minimal, we couldn't technically say it was risk free. The process of rooting puts a binary (called "su") in /system/bin (remember we talked about that earlier?). This binary is what allows the user (you) to run things at an elevated privilidge (super user). That in itself would be quite risky, so rooting also gives you one of the superuser apps (there are 2 - SuperSU and SuperUser, both very good). These apps install to /system/app and act as a gateway. Essentially, these apps prompt you when another application wants "root access" so you can allow it or deny it. It's a form of protection against malicious intent.
Root is often enough for most people who simply want to run a few root apps, but many people will need to replace their stock recovery with a custom recovery. This is because you cannot flash custom roms from the stock recovery. Some methods of rooting give you root AND recovery. Some just give you root, but you can flash a recovery yourself using Odin and download mode. Technically you do not need root to flash a recovery and then flash a custom ROM as the rom will include /system/bin/su and /system/app/SuperSU anyway.
Odin is a useful Windows tool. You'll be using this to return your phone back to stock too by flashing a stock "firmware"
Please read Samsung Galaxy S3 General Sticky Roll-Up Thread ***Stickies found here!** to find all the rooting and flashing guides you need for the GT-i9300
If I were asked my opinion on how to root, I would recommend one of the 2 scenarios.
1) You want root only. No custom ROMs, kernels etc. Just root, just to use root apps.
CF Auto Root Via Odin
Why? Tried and tested method, simple to use. No need to choose what exploit you want to use as it's tailored for your device.
What does it do? It gives you a stock recovery (so can't flash things) and roots the Android OS
The Steps:
1) Download the Latest Odin
2) Download CF-Auto-Root for your model
3) Follow These steps to root
2) You want to flash custom ROMs / Kernels
If you want root on your existing Android ROM, you can do 1) first. Then flash a recovery of your choice (CWM, Philz, TWRP) via Odin
However, if you immediately plan on flashing a ROM, there's no need to root your existing ROM. Simply skip straight to installing a recovery. Backup then flash what you like.
The Steps:
1) Download the Latest Odin
2) Download recovery of your choice CWM, Philz, TWRP
3) Follow The steps to Flash Philz recovery (But for the recovery of your choice)
These steps can also be followed to update recovery to newer versions
Official Updates
Once you have rooted your phone, the phone is classed as "modified" and no longer qualifies for Official Samsung OTA updates.
It is possible to receive official updates (whilst rooted) via Kies, however this will remove root (just like flashing a full stock rom) and if you have any custom themes, kernels or /system modifications, this could really cause some problems to the ROM so it is best to avoid. Of course if you have flashed a custom ROM (even TouchWiz based ones) Official updates are a big, fat No-No.
If you do run custom ROMs, it's best to use their OTA method if they have one, or download from the threads on XDA and flash via recovery.
Flashing - Good practice
Recovery - Custom recoveries are very handy tools. Unlike the stock recovery, they have lots of options. Not only do they allow you to flash custom ROMs, but you can backup your current ROM too. This is called a Nandroid backup. Its a snapshot in time. It backs up your entire device, from the ROM to the Kernel and all your data too. If you restore a nandroid backup, your device will be extactly the same as it was when you took the backup. This means if you took a backup 2 weeks ago and restored it today, you could have lost 2 weeks worth of SMS.. but it is very handy. As soon as you have a custom recovery, a Nandroid backup should be the FIRST thing you do. You should take one before you flash any Mod, kernel, ROM or theme. It really is important, incase you manage to break your device.,
The RIGHT files - Always be careful that you know what you're flashing is for your device and you know what it is. Flashing files (ROMs, kernels etc) for other devices could BRICK your phone. Bricking means that it is beyond normal levels of repair, often meaning it needs the internal memory (which equates to the motherboard) being replaced. very expensive.
NEVER remove power - When flashing something, be it from your computer or from recovery (or mobile Odin), do NOT remove the power. It can corrupt not only what you're flashing but also what you're flashing to. If you corrupt any of your eMMC partitions, you could have Bricked the device.
Read, read and read - Read the development threads before you flash anything. Ensure you understand what you are flashing. Ensure you know the specific procedure layed out by the developer and you follow it closely. Do not ad lib. If you are unsure, ask.
DON'T PANIC - Think you've bricked your device? Dont panic. Stay calm. Dont google "unbrick S3" and flash lots of files you dont understand. There are many types of S3 "brick" (they're not bricks if you can easily recover) and many varients of the S3. Flashign these files could further break your phone and actually brick a not already bricked phone. Nothing for any other variant than the GT-i9300 should be flashed on it. The same goes for the i9305. Never flash for another model number.
Search and Ask - Unsure of something, read the stickies Samsung Galaxy S3 General Sticky Roll-Up Thread ***Stickies found here!** and do a search. Can't find your answer? Ask. It is easier for us to help you understand something before you do it than to fix something after you've broken it.
Provide details - ALWAYS tell us exactly what happened if you are requesting help. Always describe in detail what is happening.
"Flashed my phone now it doesn't work" is useless information.
"I rooted my phone 3 months ago and flashed a custom ROM. I decided today to flash ROM X from recovery Y. I booted into recovery and flashed from my internal SD card. I rebooted the phone and it is not starting up. It is looping at the boot animation" is GOOD information. We need to know What, when, how. We need to know if you followed a guide and which one (links where possible)
Backups
Backups are really important. This is how you can mitigate the risk of losing all your important data. Without these you could have to start again from scratch or worse, need to send your device for repair.
Your entire phone - Nandroid - Recovery
[*]efs - Recovery - EFS backup aapplications
[*]Your apps and data - Titanium backup
[*]SMS - SMS backup+
[*]Photos - Dropbox
[*]sdcards - FolderSync
The reason we backup is multifaceted.
A Nandroid will backup your entire phone. This is usually taken immediately before you flash a mod or a new ROM. Nandroid restores /system and /data. Usually when you flash a mod (kernel, theme, some system app or libs etc) and it causes a bootloop, a simple restore of Nandroid will return your phone as it was and booting again. In fact, you can use an advanced restore in recovery and choose ONLY to restore /system if appropriate
Titanium backup would often be done on a schedule. Every 2nd night or something, maybe once a week if you're daring. These are important for a number of reasons but the most important is if you are flashing a new ROM.
Remember earlier, we talked about all your data and apps being in /data/data and /data/app? Well, Titanium backs that up. When you flash a ROM, you have to perform a full wipe / factory reset before it will boot up properly. This is because you have settings stored in data/data for apps in /system/app that may have changed or no longer exist, or settings different to the settings in the new ROM. These are incompatibilities and these incompatibilities often will prevent a new ROM booting. Of course, a factory reset doesn't fully restore it to it's factory condition. It cannot restore the bootloader, rom, baseband etc because you overwrote these by flashing a new one.
We wipe, we install titanium and we restore all the data/apps and the /data/data related to /data/apps, but none of the data/data related to /system/apps (because that would restore the incompatibilities)
Here is how I restore using titanium backup after a wipe and flash....
Remember if your backup is on external sd, you need to point titanium to the location using preferences > backup folder location...
Go to backup / restore tab and press "click to edit filters" and deselect "system" and press the done tick icon to apply. Then from the previous backup / restore screen, go into the batch screen (another tick icon top right).
From this batch screen, select "restore missing apps with data" by pressing "run". Manually go through every app (yes, even if you have 300 apps) ensuring there's nothing samsung or rom specific there, unticking anything that is...
This should ensure a clean, user only app and settings. You will then need to manually set your system settings (ring tones, email etc)
Warranty
So, as we have discussed, warranty should be considered void once rooted. Technically in the EU, the OEM must prove root damaged your phone to reject warranty, however this is almost never the case.
When the S3 was released, it came with android 4.0.4 (ICS). The bootloader with ICS was normal. If you used Triangle Away once rooted, it would reset your binary counter forever. You may have kept status: Modified until you factory reset but that is not so much a problem.
When the S3 was upgraded to 4.1.1 Jelly Bean, a new bootloader was introduced. You could still reset with Triangle away, however on the next boot, if you had a custom recovery or kernel, the binary counter went back up to 1 again, which can present a problem.
Please see the following scenarios.
1) You just want root. No custom Kernels, no custom ROMs, no custom recoveries.
This is fine. If you root with CF-Auto Root it gives you a stock recovery. Once you reset the flash counter with triangle away, you should be fine.
2) You want root and recovery on a 4.1.1+ S3.
If you have a custom recovery or kernel, you can set triangle away to reset at every boot. The problem is if your phone breaks in such a way that you can never boot into android, but download and recovery mode still work, you're screwed, It goes back up to 1 on boot, fails to boot then you can only reset it with triangle away, which you can't use because it needs you to boot into Android. You see the risk?
3) You want root and recovery on a 4.1.1+ S3.
The alternative to the above is to flash This 4.0.4 bootloader via cwm. It can be reset by Triangle Away, and stays reset forever. Well why aren't we all using this? Because it is NOT SDS safe. This means if you ahev the unsafe internal memory, if you use download mode to flash anything, you risk bricking your device. Read [Important] Sudden Death Fix - Are you covered? for more information.
So it's a choice between:
I risk that under certain conditions, I may not be able to reset the binary counter for a warranty return
or
I have my binary counter at 0 always, but I cannot use download mode.
Please note, you need to run a TouchWiz ROM to use triangle away
Popular misconceptions
USB Debugging is always required for flashing.
Incorrect. USB debugging is an Android setting. It is only applicable within android. This setting does not work in recovery or download mode, so obviously anything done in those modes does not require USB debugging.
When rooting, all your data is lost.
Incorrect. Rooting adds a binary and application to your phone. It does not wipe it.
I need to root to fix my battery by wiping battery stats.
Incorrect. No one needs to wipe battery stats. Please read the wiping battery stats thread linked below:
Battery stats
What's good for you is good for me!
Incorrect. Everyone's usage is different. Everyone's set-up is different. Everyone's environment is different. There is no "Best" ROM. There is no "Best kernel for..." There is no "Most battery efficient baseband". All these things may acti differently for you than they will for me. What I like isn't what you like. Please do not create any "Best" threads.
If I ask the question "Blah blah blah for custom ROMS?", everyone will know what I am talking about
Incorrect. "Custom ROM" and "AOSP ROM" are NOT synonymous. People imagine when they ask about "Custom ROMS" that we know they really mean "AOSP ROMS". We don't. There are TouchwIz based custom ROMs too. We assume nothing.
B]I need yo be on a certain ROM to flash certain other ROMs[/b]
Incorrect. You're overwriting the ROM so why would ot matter what ROM you're overwriting?!
Important threads and resources
A list of important threads and resources...Please read ALL of these threads before rooting.
Mskip's unified toolbox(Root, drivers etc)
Index of Roms, recoveries and kernels
Guide for flashing roms, backups etc
Returning to stock for warranty
Odin flashing guide
Sammobile.com - stock firmwares
Be prepared ahead of time to fix a Brick
rootSU recommends
A few recommendations from me...
RootExplorer
Titanium Backup
Philz Recovery (CWM advanced)
Odin
Heimdall (Linux / Mac odin equivelant
That's it for now. I know this is a lot of information, but I believe this info to be the very least you should know before deciding to go ahead with rooting your S3. Please read it and read it again. Anything doesn't make sense, please ask in this thread and I will gladly help.
If any other seasoned rooters / flashers think there is something salient missing, please post her too. happy to add to it.
Glossary of terms
adb - Android Debug Bridge. This is a Windows or Linux command line tool that can be used to push files to a device, pull them, create directories. Very handy with a custom Kernel if you can't boot and need to get data from the device. This can be downloaded as part of the Android SDK or mskip's unified toolbox mentioned earlier.
AOSP - Android Open Source Project. This is google's code base. This is Android in it's pureset form. Anyone can download this code and build a ROM. It will take some work to build for a specific device however. Even Samsung start with this code at some point.
AOKP - Unofficial development team building ROMs based on AOSP accross a range of devices. AOKP stands for Android Open Kang Project. A play of the AOSP it is based on. Kang means to find / use (or even steal, although not in this case) source code.
baseband - The software responsible for controlling the radio hardware. Essential for network connectivity. Also referred to as "modem" or "radio"
bash - bash is a shell script language. Natively used in unix and linux, it can also be used within terminal emulators on android and scripts. Most mods that are scripts, use bash.
binary - a binary file is the opposite of a text file. It may contain data to be read by the OS rather than a human. It usually contains instructions on how a particular function should be handled.
binary counter - also referred to as flash counter. This is in part of the bootloader, viewed in download mode. The Binary counter increases as you flash non-stock (custom) recoveries and roms and kernels not "signed" by Samsung. The app, triangle away can help a little
boot.img - the kernel is contained within an .img file named boot.img. Not to be confised with sboot.img (bootloader)
bootloader - Bootloaders exist on almost any multi-OS bootable system. Windows has one, linux has one and android has one. It is how the device "decides" which OS to boot into. the user can manipulate hardware buttons during boot to alter which OS the bootloader boots into. It boots into Android by default but it can also boot into recovery or download mode. The bootloader is within an .img called sboot.img
brick - brick refers to a device that has been "bricked". A bricked device is beyond repair. In other words, your phone may as well be a brick, because it cant be a phone any more. A bricked device must be sent to the manufacturer / carrier / service centre for repair. You cannot repair a brick yourself. If you have something that can be repaired, it is not a true brick.
There are 2 types of brick referred to..
Soft brick, where the phone bootloops. These can sometimes be repaired, so for that reason it is not a true brick and I prefer to never use the term "Soft Brick".
Hard Brick. This is what I call a true brick. The phone cannot be repaired by a user. This of course does not extend to replacing parts. Sure, a brick can be replaced by replacing parts. It can't be fixed with external hardware or software however.
busybox - A set of tools to be added to android. Many root apps require busybox to run. It can be installed using an installer from the market. Similarly, most custom ROMs will contain busybox by default
clockwork mod - clockwork mod is a custom recovery
cfq - this is a scheduler (see scheduler). There is some info that can be read here: http://www.alliance-rom.com/community/wiki/i-o-schedulers/
checksum - see md5 checksum
cm - abbreviation for cyanogen mod. See Cyanogen
CPU - central processing unit. This is the brains of the operation. the CPU is what translates all the instructions and processes them. This is the main "power" behind any device. The better the CPU, the faster these instructions can be processed
custom ROM - A Custom ROM can be based on Touchwiz (Samsung stock), or it can be built from AOSP code. It really just means "unofficial" and will usually contain tweaks, fixes and imporvements for your device. A Custom ROM is a complete android replacement.
cwm - abbreviation for (see) Clockwork Mod.
cyanogen - a team of developers spanning multiple devices. Probably the most famous of development teams releasing heavily modified AOSP based ROMs. If there's any AOSP ROM thread for any Android device forum, there will be credits to cyanogen in there.
dalvik-cache - Dalvik-cache is a way of optimising applications. Its a way of ensuring all the dependencies an app requires are "at hand" to speed up use. It is rebuilt at start up when wiped. A de-odexed system will have more dalvik-cache than an odexed one.
de-odex - The act of removing odex from a stock ROM. On Stock ROMs, instead of using a dalvik-cache for system apps, we use .odex files instead. Generally custom ROMs prefer de-odexed configurations as it's easier to wipe and maintain when you make changes to your system.
deadline - this is a scheduler (see scheduler). There is some info that can be read here: http://www.alliance-rom.com/community/wiki/i-o-schedulers/
download mode - Samsung's own mode accessible via the bootloader. Hold Vul down, Home and power (from off) to boot here. Also referred to as "Odin Mode". This replaces the "fastboot mode" that most other devices have.
efs - Important partition / directory on the root of your phone. Ensures the IMEI number is present in the software. Back this up, because if it breaks, it's gone for ever. You need Samsung to repair.
eMMC - Embedded MultiMedia Card. This is like an SD card, but it's embedded in a device. the eMMC is a NAND flash memory chip which acts as internal memory (storage) on the S3.
exFAT - exFAT is a Microsoft proprietary (closed source) file system, used for media (sdcards, USB flash memory, HDD's etc). ExFAT is not natively supported in Linux and AOSP ROMs
ext - ext2, ext3 and ext4 are file systems created specifically for Linux. Our internal memory is ext (or "extended" as it is known). This can sometimes be used to refer to an ext partition, an old school method of partitioning your sdcard to link the internal ext partitions to to increase app space on low memory devices. Ext file systems cannot be read on Windows machines without special applications / drivers installed.
extSdCard - This is referring to the removable Micro SD card. Samsung ROMs mount the rremovable sd card in Android as /extSdCard. Recoveries such as CWM will mount it as external_sd. Both of these terms are valid, but it depends if the phone is booted to Android or Recovery. In AOSP ROMs, the removable SD card is often mounted as /sdcard1
FAT32 - another file system which is quite old now but still a good one. This is the only file system that is compatible with all devices unconditionally. The downfall is a maximum file size limit of 4 GB. Windows disk management GUI can only format up to 32 GB. Windows command lien tool "diskpart" can format up to the max volume size of 2 TB, as can many 3rd party tools such as easeus.
flash - Flash means a few things. It can refer to the fact that our internal memory is NAND Flash (Solid state) memory. It can also be the act of "flashing", or "to flash", meaning to install to flash memory. This doesn't really refer to installing an .apk. Rather, it refers to bigger, OS, System or device wide altering modifications (Kernels, recoveries, ROMs etc). Always back up before flashing.
Custom ROMS are usually flashed from your SDcard via recovery, as are kernels and basebands however, kernels and basebands usually can come in .tar format which means odin/mobile odin can flash them too from your computer/sdcard respectively. Rule of thumb, .zip from sdcard via recovery. .tar from sdcard via mobile odin or from computer using odin
flash counter - See binary counter
framework - The android frameworks are a standard structure within android that the OS is built around. It determines things like policy (how the OS should manage an event). It controls everything from notification behaviours to the theme. Anything visual within Android with exception to the notification area is controlled by framework-res-apk. AOSP and most manufactured ROMs only have 1 frsamework-res, however Samsugn Touchwiz ROMs alsu have a twframework-res.apk for Samsung only visuals.
gapps - Google Apps (gapps). AOSP ROMs like Cyanogen, have been asked by google to not include the google apps packages, which are proprietary to google (meaning not open source). This means that when you download these roms, you need to flash a gapps package separately. They are usually available as link in the ROM thread
governor - governors are included with kernels. I will not go into too much detail but essentially, the governor is a set of instructions which tell the kernel how to manage the CPU. It can control when the CPU ramps up or down, or how long it stays at a certain frequency. Most custom kernels come with a selection of governors to choose from using things like Set CPU. The governor settings for each can also be fine tuned or tweaked to y7our liking.
hotplug - this is a governor (see governor). Governors are explained in great detail here: http://www.alliance-rom.com/community/wiki/governors-explained/ - not all these governors are valid for our device, but it's a good technical read.
jig - a small usb device that plugs into the USB port of the S3. Designed to provoke "bricked" S3's to boot to download mode in an attempt to help recovery the device.
kernel - The kernel, it is said - is the "beating heart" of Android (or any OS for that matter). It sit's between the application layer (Android, applications etc) and the Hardware (CPU, Memory) and handles all transactions between the physical and the virtual. It passes information and instructions inbetween and translates. Very important stuff!
lulzactive - this is a governor (see governor). Governors are explained in great detail here: http://www.alliance-rom.com/community/wiki/governors-explained/ - not all these governors are valid for our device, but it's a good technical read.
md5 checksum - md5 checksum is a way to verify that a zip (or file) is not corrupt. A developer or uploader may provide a hexidecimal string called an md5 checksum. This checksum is a test done on the files that gives it a unique string based on it's contents. If you download the file and check the checksum and it does not match, it means the contents of the file have altered, usually meaning it is corrupt and shouldn't be flashed.
An md5 checksum is easy to check on android. My preferred method is using an android terminal emulator. Lets imaging I have a file on my external sd card called "rom.zip"...
In terminal emulator, type "md5 /mnt/extSdCard/rom.zip" and the terminal will give you an md5 string, If this matches the uploader's string, you're good to go.
If you're downloading something on Windows and then transferring it to your phone, it's a good idea to check md5 on both.
Linux is pretty much the same except the command is "md5sum"
For windows: http://www.winmd5.com/
modem - see baseband
NAND - NAND is a type of Flash memory. If anyone say's "NAND" to you, they are talking about the internal memory (Storage) of your device.
nandroid - nandroid refers to a backup taken or restored via custom recoveries. This is a universal term, although nowadays most recoveries simply say "backup" or "restore", but it is a nandroid backup they will be taking or restoring, which got it's name from the NAND flash memory that Android devices use internally. Nandroids are often only compatible with the variant of recovery you have. For example, a backup taken with CWM may not be compatible with TWRP, unless they introduce a compatibility setting in the future, which Philz recovery has done.
noop - this is a scheduler (see scheduler). There is some info that can be read here: http://www.alliance-rom.com/community/wiki/i-o-schedulers/
oem - Original Equipment Manufacturer. The OEM ROM for us is teh one the Manufacturer (Samsung) shipped with the phone.
overclock - overclocking is to set the CPU clock speed (frequency) higher than intended by the manufacturer. For example, the S3 has a 1.4 GHz (1400 MHz) maximum clock speed. With the use of a custom kernel and an application such as Set CPU, you can set this higher, to 1.6GHz or maybe even higher.
The risk is that the higher clock speed uses more voltage and voltage = heat. A higher clock with higher heat can permanently damage the CPU. Overclocking is usually paired with undervolting for these reasons. Another risk is instability. Each individual CPU has different tolerances due to imperfections in the manufacturing process. My CPU may be stable at 1.6 GHz, yet yours may be stable at a higher or lower clock. The side effects you will see here will be random reboots when the phone is under load.
pegasusq - this is a governor (see governor). Governors are explained in great detail here: http://www.alliance-rom.com/community/wiki/governors-explained/ - not all these governors are valid for our device, but it's a good technical read.
radio - see baseband
RAM - Random Access Memory. Great explanation here: http://www.androidcentral.com/ram-what-it-how-its-used-and-why-you-shouldnt-care
scheduler - built into kernels, there are schedulers to determine how CPU load is spread across different tasks. There are also read / write schedulers that spread out read and write operation priorities across the internal memory. Like Governors, there are different types of scheduler available.
sio - this is a scheduler (see scheduler). There is some info that can be read here: http://www.alliance-rom.com/community/wiki/i-o-schedulers/
stock - Imagine your phone is on a shelf in a shop. The phone is "stock" of that shop. If anything is referred to as "stock", this means standard for the device / as it was when shipped / as per factory set up. It is the opposite of custom. Some people refer to AOSP ROMs as "Stock Android". This may be the case for some phones, like the Nexus devices, but generally this is incorrect. Stock is whatever the phone came with as standard.
triangle away - an application designed to reset the binary counter. Warning, newer bootloaders (4.1.1+) now re-increment the binary counter at boot, so some trickery is required to get the counter to remain 0. This can be troublesome if you need to return for warranty.
undervolt - to undervolt is to lower the voltage used, either by the CPU or the GPU. Kernels assign a static voltage to each clock speed. For example, 200 MHz = 900 mV, 300MHz = 925 mV. Undervolting is the process of lowering this voltage staticaly for each clock speed, which potentially will save battery, although many people think it wont have much affect. Beware, undervolting too much can cause instability. When a clock frequency hasn't got enough power to sustain, the device will likely reboot or power off.
vanilla - meaning plain. Often used to refer to the "pure" android. AOSP without OEM skins, UI's and Launchers etc. The people who incorrectly use "Stock" to describe AOSP, really mean vanilla.
zzmove - this is a governor (see governor). Governors are explained in great detail here: http://www.alliance-rom.com/community/wiki/governors-explained/ - not all these governors are valid for our device, but it's a good technical read.
Every phone specific section needs something like this.
Very well done!:beer:
abaaaabbbb63 said:
Every phone specific section that can be rooted needs something like this.
Very well done!:beer:
Click to expand...
Click to collapse
Now you need the difficult part, people to actually read it.
Nice work @rootSU
Needs to be stickied and a humongous "READ ME" sticker attached! :thumbup::thumbup:
Edit........Reported©®™ so it gets stickied!
Its getting noobs to actually bother to read is the problem .
jje
True but i'll start with the "read my sig" method. At least if it's here, thats a small part of the battle. Anyone anything to add to post 1? Slappy? jje?
Sent from my GT-I9300 using Tapatalk 4 Beta
Add backup EFS first ??
jje
Some of the stickies in the roll up thread are badly out of date, you also might want to link to Mike Skip's toolbox, which reduces the chances of bricking considerably.
rootSU said:
True but i'll start with the "read my sig" method. At least if it's here, thats a small part of the battle. Anyone anything to add to post 1? Slappy? jje?
Sent from my GT-I9300 using Tapatalk 4 Beta
Click to expand...
Click to collapse
Seeing as this may well attract lots of attention, possibly add a reminder about reading the rules and link? I know it's not relevant particularly, but any chance to ram the message home is good :thumbup:
rootSU said:
True but i'll start with the "read my sig" method. At least if it's here, thats a small part of the battle. Anyone anything to add to post 1? Slappy? jje?
Sent from my GT-I9300 using Tapatalk 4 Beta
Click to expand...
Click to collapse
Instead of [REF] you should write [BOOBS]. That would attract attention.
Added:
Link to forum rules and "post in Q&A" threads
Important links and resources
efs (in partitions)
backups
I'm sure there's still loads missing, I just can't think of much so all suggestions welcome.
Added "The advantages of rooting". Miss anything?
EDIT > added disadvantages too.
OP, I have moved your thread to the q&a section and stuck it. It is a great FAQ type thread and will serve a good purpose being stuck where people go to ask these types of questions. :good:
Towle
XDA Moderator
Towle said:
OP, I have moved your thread to the q&a section and stuck it. It is a great FAQ type thread and will serve a good purpose being stuck where people go to ask these types of questions. :good:
Towle
XDA Moderator
Click to expand...
Click to collapse
Thanks @Towle
Sent from my GT-I9300 using Tapatalk 4 Beta
I've updated the following to sections to read as below:
Bootloader - this is what handles what you boot into. When you see the black Galaxy s III text, thats the bootloader. Its job is to handle the boot. It is responsible for booting into android, or if you manipulate the buttons in a certain way, it will boot into recovery or download mode. PLEASE NOTE, i9300 Bootloader is NOT LOCKED. DO NOT TRY TO UNLOCK IT.
Download mode is part of the bootloader itself. Again, it is a mini OS. It is designed for flashing stock (official) ROMs onto the phone. It is also used by Samsung to detect the status of your phone (if you have modified it or not).
If you have an official ROM above 4.1.1, Your bootloader flash counter in download mode will change to "1" at every boot, if you have a custom kernel or recovery - even if you reset it with Triangle Away. See the return for warranty link later in this post to get around this.
oops
first i thought it was typo but after i check out dictionary i just learn a new and rare word ... teh ....:fingers-crossed:
qtwrk said:
oops
first i thought it was typo but after i check out dictionary i just learn a new and rare word ... teh ....:fingers-crossed:
Click to expand...
Click to collapse
Not new, not rare:
http://en.wikipedia.org/wiki/Teh