[Samsung Galaxy S Blaze 4G] dispozable:
Apps, root permissions and SU​

The root (sometimes also known as root folder) is, as implied, the root of the file system, the root of all folders. It is the “folder of all folders”. Sometimes this can be hard to grasp, so here’s an example: if I have one single file on my entire hard drive called File.ext, then it is in the root of the hard drive. If it were in a folder called Folder, that folder would have to be in the root of the hard drive. Root is usually symbolized simply as /. So the file would be in /File.ext, or in /Folder/File.ext. In Windows, the root of the local disk would usually be C:/. The file in the root of the local disk in Windows would be in C:/File.ext.

System apps are installed in the folder /system/app/. They are usually not given root permissions. Data apps are stored in /data/app/, and do not have root permissions. Both /data/app apps and /system/app apps have a folder which they can use to read and write files in /data/data/. Without root permissions, this is the only place on the system they may read and write files to. They may also read and write files to storage (for pictures, music, and other large files that wouldn’t fit into /data/data/.

This concept is the basis for *nix OSs theoretically being more secure: if apps are sandboxed (are given limited place to work with), they can do less damage. Without being able to access anything other than it’s own folder, an app cannot do any harm: it cannot tamper with critical system files, it cannot read personal data from other apps, and it cannot make the phone unusable. Theoretically, the worst an app can do is either damage itself (such as with a bug), or read unencrypted files from an SD card (that’s why personal information on an SD card should always be encrypted!).

Having root permissions means you have permission to read and write anywhere in the file system - as far deep as the root itself (that’s why it’s called root permissions). Theoretically with root permissions, one can modify everything in the system and (if the intentions are evil) take complete control of the operating system. Root permissions is therefore normally a sensitive concept, and it is carefully guarded and not given to just any app. Bad apps with root permissions can cause great damage and potentially misuse these permissions. That’s why in stock Android, root permissions are reserved and the user is never allowed to mess with it.

“Getting root” (colloquially known in iOS as “jailbreaking”) is usually considered the ability of a user to manually allow specific apps to get root permissions. This is usually done in Android by the user with an app called Superuser (or just SU for short). With Superuser no permissions change, however if an app request root permissions the user may grant them to the app. The Superuser app has root permissions, and all it does, with the user’s consent, is modify permissions of other apps (such as changing their permissions from read-only to read-write). Getting root is usually done by attacking and exploiting a bug in the operating system (different with every device) and installing SU, or by flashing an operating system with SU pre-installed (also different with every device).

The reasons for getting root is to install apps that can do things normally not allowed by the operating system. Such examples may be internet tethering on devices from some networks, using the camera’s flash, etc. It also allows one to manually modify files of the system (usually with a file manager), such configuration files, scripts, or adding and removing system ringtones.

Many “Force Closes” in Android (when an app crashes) occur due to inappropriate permissions. If an app expects to have permissions to write to a certain folder and the OS denies it because it doesn’t have those permissions, it may crash and Force Close. To fix this, a function called Fix Permissions is used to reassign all apps the permissions they are supposed to have (including giving apps root permissions if they’ve already been given by the user).

Custom operating systems (custom ROMs) and Recovery​

Custom ROMs are modified operating systems that can be installed instead of the “stock” operating system installed on the phone when it leaves the manufacturing factory. Virtually all Android phones sold today are carrying already modified operating systems that are different from “vanilla Android” (the Android developed and released by Google). Since Android is open source, manufacturers (such as Samsung and HTC) can take the code, modify it to their taste and then install that on their phones before selling them. Google’s Nexus line is an example of vanilla Android - the “pure Google experience” - because there are no modifications on AOSP (Android Open Source Project).

Another type of modified operating system is CyanogenMod and MIUI, which are both based on AOSP and are developed and maintained by independent developers, usually with no interest in profit (though donations are always welcome). CyanogenMod is an example of a more vanilla approach (where the UI is relatively similar to AOSP) while MIUI takes a more modified UI experience (where the UI is known to draw inspiration from iOS). These modified operating systems usually offer extended functionality and are “pre-rooted” (meaning they have SU pre-installed in /system/app/).

These operating systems are usually distributed as zip files (one file containing everything needed to flash onto the intended partition). These zips are usually flashed via recovery, which itself is modified for being able to manually flash new images.

The recovery is usually meant for updating the operating system, such that when Samsung distributes a new update for their phones, the operating system images can be downloaded to the phone’s storage (SD card) and booted into recovery. When the phone is running the operating system, it can’t rewrite the whole /system partition because it is in use. Once in recovery, the phone can simply flash the whole image straight on to the /system partition. Therefore, the phone’s operating system is updated and the user’s data and apps and storage are left untouched.

Usually, the recovery has no interface or dialog, and the process is automated. This allows for an easy update process and customers do not have to get involved. A custom recovery will present an interface and allow many functions such as:

●	backing up the partitions as images

●	wiping partitions (including factory reset)

●	flashing images to any of the different partitions

●	other miscellaneous functions (such as wiping battery stats, fixing permissions, etc.)

Nandroid​

Since the recovery can read and write entire partitions as images, this gives recovery the ability to backup entire partitions as images. A nandroid is a backup composed of a few images for each of the /system, /data, /cache and /boot partitions. Once these are backed up, the phone can be entirely restored (including the exact state of the operating system, apps, settings, data and everything except for storage) no matter what happens to the system installed. If a critical bug occurs because something terribly irreversible happens, you can restore to a nandroid backup you made before this happened.

Simplified installation process for (custom) operating systems

The usual process for installing custom OSs:

●	root is obtained

●	a custom recovery image is flashed on to the recovery partition (with root permissions)

Once in recovery:

●	a nandroid backup is made for safe measure

●	data and cache are wiped (if the operating system installed is different than the one previously installed)

●	a custom operating system image is flashed to /system

ROM manager​

Koushik Dutta is a well known developer in the world of Android independent development. He is best known for developing ROM manager, the most comprehensive custom OS management app available, as well as the well known ClockworkMod (CWM) Recovery, one of the most widely used custom recoveries. He also happens to be the first person to root the first Android phone. Without praising enough, it is suffice to say that ROM manager and CWM recovery are some of the most important elements needed to know when getting started with custom OSs on Android.

Although gaining root is different with every device and every version of the operating system on the device (depending on the exploit found for that device), the rest of the process is similar across most devices. ROM manager requires root and can install CWM (if there is a version compatible with that particular device) and then do most of its functions straight from the app (such as telling it to wipe and then install a custom OS) as it reboots into recovery and does it automatically.

Bricked devices​

A “bricked” device is a device that, by either software or hardware, has become as valuable as (or less valuable than) a brick. This is a very broad definition, however the idea is simple: if the device won’t boot into Android, and it can’t be fixed - it’s bricked. Sometimes, the device won’t boot into Android, however that does not mean it can’t be fixed. From my personal experience, everything can be fixed. This is thanks to the fact that even if the operating system is broken, recovery can be used to reflash the operating system. Even if recovery is broken, HBoot or Download Mode can be used to reflash the entire memory.

The exceptions for this are:

●	the nand memory itself (the actual memory stick inside the device) is damaged

●	the IPL or SPL are broken and therefore neither HBoot or Download Mode are unavailable (Samsung devices can even be restored from such situations with a hardware JIG)

●	I’ve heard (not verified) that mismatching SPL and baseband can cause a brick, but haven’t ever had an issue with this.

I have personally reached situations very close to both of these cases on several devices, however I was always able to fix the device, and have never actually run into a brick. That being said,

always read the full instructions given

, and remember that you are taking the risk, not the person writing the instructions. If you’re in doubt, don’t do it. If you want to double-check, read forum threads and comments until you feel sure about going for it or not.

If that scared you, you should know that generally any person feeling confident with computer skills can manage to deal with this stuff, thanks to a great dev community revolving around Android working hard to make (usually free) solutions for everyone. If you know how to Google and someone has gone through it before (and someone has gone through it before), chances are you and your phone will be fine.

Why not use task killers​

Although this is not strictly related to Android modding, I felt it is important to stress how memory management works after explaining the different roles of each partition.

So first, a little bit about storage. Storage has two important properties (not including price): how much data can be stored on it (capacity/density), and how quick it is to write and read data to and from it (performance).

All data on a system that is meant to be stored, is usually stored on mass storage; high capacity, non-volatile storage. However, this type of storage is usually very slow and it wouldn’t make sense for the computer to run applications straight from mass storage, to keep reading and writing calculations it’s doing to the mass storage and to rely on such storage for second-to-second tasks. So when a user runs an application, operating system copies the binary and the data it is using to RAM, where it can quickly write and read what it’s doing. However, when something needs to be saved in the long term, it is copied back to mass storage. This is the difference between working with an open file, and actually saving the file after you changed it. When it is “open”, it is in RAM, where you can quickly read and write it. When it is “saved”, it is copied back to the hard disk (in the case of a desktop computer). Virtual memory is basically a part of the mass storage that is used as an extension of RAM. Although it is as slow as mass storage, it functionally extends the amount of RAM available (at a cost of performance).

​

However, when many applications are open, there may not be enough RAM to go around. Hence, you must manage your memory. Things you can do to manage your memory are:

●	close applications that haven’t been used in a long time - and thus clearing RAM space for more frequently used applications (at the cost of losing potentially important data)

●	copying the memory an application is using to virtual memory - and thus clearing the faster RAM space for more frequently used applications (at the cost of performance)

Every operating system has its own strategy and implementation of memory management. Linux is known for being particularly good at this, while Windows is known for being particularly not good at this. Linux manages to keep as many things in memory as possible for as long as possible, hence allowing applications to not close, open quickly and not lose data.

Applications in memory open faster because they don’t have to be loaded from the slow mass storage, they are already in memory. You can test this on your Android phone if you want: open an app and then press the back button until it closes, then open it again. Then open an app and press the home button until it is hidden, then open it again. You’ll see that after closing an app, opening it again takes much longer than loading it again without closing it. Makes sense, huh? Generally, used memory is good memory.

Used memory got a bad rap from Windows. For some reason, Windows works better the more free RAM there is. And it works terribly slow if there is no free RAM available. Why? Nobody knows. That is - I don’t know. Maybe it’s because Windows doesn’t know how to clear memory when more frequently used apps request it. Whatever.

Then came along task killers to clear your memory to speed your system. A task killer is a tool that pretty much closes applications in order to clear up free RAM. All you need to know is that on Linux used RAM is good RAM. Task killers on Linux will simply make loading applications take longer and won’t really help. A task killer is only good if you want to forcefully close an app for some reason (it’s misbehaving). This is possible within Android (Settings > Manage Apps > App > Force close, if you’re intertested). A task killer is mostly bad if there are apps that are supposed to run in the background in order to automatically update things, download stuff, etc. etc.

People believe that because of true, real multitasking in Android, apps are constantly open in the background hogging your data connection and battery life, doing crazy stuff and causing mayhem. But the engineers at Google are obviously smarter than that. Apps need to specifically request to run in the background, or run certain tasks in the background. That’s good! Because that lets you listen to music in the background while you browse the internet. It lets you download stuff in the background without having to stay on the download page like an idiot. It lets file managers finish copying large files without having to keep the file manager open. Assuming the application developer made sure to program the app properly. Sometimes you will end up with a developer who stupidly allowed an app to download stuff in the background non stop until you close the app. But let’s face it, the vast majority of your apps’ developers know how to program properly. Just leave the task killer alone.

Ending note

Although there can be drastic differences between devices from different manufacturers, the fact is that all Android distributions are *nix, and therefore share many traits, especially when dealing with such low-level processes. Understanding the underlying foundation under all Android devices is valuable knowledge for anyone interested in customizing the software on their device.

Composed: 2012-01-08 Google Docs link

Revised: 2012-04-24

Newbie NAPS is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License (a.k.a. Copyleft)

This is a community effort - no attribution necessary