We love getting your questions. It's always a good thing when we can help each other, and we learn stuff ourselves when looking for the answers. While we can't find time to answer all of them, sometimes a certain question comes up enough that it deserves a detailed answer.
"What does root mean?" is one of those questions. The concept may be simple for some of us, but for many folks who haven't spent time fiddling around with Android or any other permissions-based operating system, it's something to ask questions about. I'm going to try and answer them all as best I can.
Permissions
Before we define root, it's important to understand why it exists and how it works. It's because Android uses permissions (Linux-based permissions, to be exact) in the file structure. Every file, every folder and every partition has a set of permissions. These permissions decide who can read a file (look at or access the contents without changing them), write to a file (be able to change the contents of that file, or create a new file inside a folder or partition) and execute a file (run the file if it's a type that can run, like an app). This is done based on users and permissions — certain users have access, while users who don't have the right permissions are blocked from having access.
When you first set up your phone and turn it on for the first time, you are assigned a user ID. If another user logs in via Google, they are assigned a different user ID. When an app is installed on your phone, it's also assigned a user ID of its own. The system itself is a user and other processes that need to run on your phone may have their own user ID. Everything that can do anything to any files on your Android is a user.
A system of users and permissions is how Android keeps track of who can do what.
Let's say you install a messaging app. It gets assigned a user ID when you install it. It also gets a spot on your data partition of it's own, that only it has access to. You have permissions to execute the app, and when the app runs it has permission to access its own data folder and files. The app may also request permission to access things like your address book or SD card or photo library. If you say yes to these requests (or if you agree to the permissions on older versions of Android) the app's user ID is granted permission to the data files of those things, meaning it can look at the data folder and its contents and possibly change them or add new files. The app can't access any data files it doesn't have permission to "look" at. That means (in our example) it can't do things like look at the settings database, or access the data folder of another application. The term sandbox is often used for this — apps are sandboxed and can only play in the sandboxes they have permission to be in.
For files that are programs and can run (like apps), the same permission model applies. Your user ID has permission to run the apps you installed while you are signed in. The system user has permission to run them and other system-level users may have access to the apps or certain processes the apps use. Other apps can't start up apps they don't have permission to start. If you added a secondary user, they don't have access to your apps or files and vice-versa. There are files, folders and apps on your phone that your user ID doesn't have permission to see, alter or run. Usually those parts of Android require system-level permissions (the system user ID) to do anything with, and you aren't the system user or a user that has system-level permissions.
Switching permissions
While it's technically possibly to change the way your phone boots up and the files it uses to start the running system and assign your user ID elevated permissions, that's neither safe nor practical. But Android (and most Unix or Linux based systems) have what's called a root user, and support the SubstituteUser binary (think of a binary as a small app) to change user IDs. Those are used to administrate the system at the core level.
Because the people who made your phone don't want you to have easy access to the root user ID — and not all the reasons are selfish because it also protects you and your private data — the SubstituteUser binary isn't included in most builds of Android. Without SubstituteUser, we can't switch our user ID. Most system level things in Android have similar easy names, by the way. The core security (files in the bootloader and/or the kernel itself) are also built in a way to prevent you from switching user IDs as part of the SELinux (Security-Enhanced Linux — told you the names are easy) kernel module. Some phones (Samsung's Knox comes to mind) have further protections, and nearly all the companies who make Androids require that, in order to make changes, the bootloader would need to be unlocked so these files can be changed and allow you to switch user IDs. Some phones, like the BlackBerry Priv even go a step further and aren't going to boot if we change anything (even if we could).
To become root, you need a way to change your user ID.
Once we get past all that — either by unlocking the bootloader through authorized means or using some sort of exploit — we can place the SU binary (SubstituteUser) in a spot that it can run when it's called to run — that's called a PATH. If any app is in your user ID's PATH it will run without telling the system exactly where it is. You also need to make sure the SU binary is in a spot that your user ID has permission to execute (run) files. Any other app (Google Play has plenty of apps that need root permissions) will also need the same access. When you use a method to root your phone, all this is sorted out by the folks who built the root method.
Once all that is in place, we can run the SU binary (or another app can run the SU binary).
Getting root access
This is where root comes in. The SU binary uses flags when it's run to tell the system what user ID you want to switch to. For example, if I run the SU binary on my Ubuntu computer like this "su Jim -c nano" I will run the nano command as the user Jim (after supplying Jim's password). If you run the SU binary with no flags or arguments, it switches you to the root user. Normally you would need to supply a password, but since "root" is an unused user on Android it has no password. Running the command "su" will switch you to the user root, and assign you the user ID of 0, and put you in the root group. You are now the Super User.
As the Super User you can do anything to any file, folder or partition on your Android. By anything, we mean literally anything. You can remove bloatware apps and you can also remove essential system files that break your phone. You can also do things to the hardware like change the CPU frequency and ruin your phone forever.
Root is the super user, who can do anything. And we mean anything.
Apps can do the same thing. SU is placed where it's in the application PATH and any app can call it and run it. That app then has Super User permissions, and can do anything it likes to any file any place on your phone. This is why the people who made your phone really don't want you to have this level of access, and the companies who allow you to unlock the bootloader and change things still don't place the SU binary on your phone by default. Having root access with no way to control who or what can use it is dangerous to your phone's software and your personal data.
That's why you need to install an app that forces you to allow root access any time you or another app tries to invoke the Super User permissions. Most times when you use a root method for your phone one will be included, along with some other useful binaries like the BusyBox toolset. If you did things by hand, you'll need to install one yourself. SuperSU by Chainfire in Google Play is a good one to start with.
Odds and ends
Many phones and some root methods do things a little differently (Android 4.3 brought a lot of changes) and require scripts or a daemon (you'll see words like daemonsu or su.d mentioned) instead of just dropping the SU binary in place. These are used to call SubstituteUser so you can switch to the root user just like the raw binary method. The people who figured out how to root your phone have sorted all this out and it will work the same on the user-facing side.
It's also possible to "temp-root" some Androids. This means you can have Super User permissions and do a few things you need to do, but a reboot takes root access away. Likewise, you can have a "shell-root" where you can only access the root user through adb from your computer.
Finally, I want to stress that if you had these questions, you need to consider if you're ready to have a rooted Android. We weren't kidding when we said it's easy to ruin your phone with SuperUser access. There's no reason to be ashamed that you need to do a little reading or ask a few more questions before you do things that can break your phone or give some random rouge app access to all your data.
That's what we're here for.
