Related
Nook Rooting 101
Author’s Note: This may be long, but it provides useful info to those considering Rooting their Nook. It does NOT tell you how to root your Nook. (A sequel is intended to provide that information. But let’s start with this one.)
To the experts: feel free to post with your corrections and condemnations. The hope is that it will be improved and eventually turned into a Sticky for those new to the forum and the process.
“I got a new Nook for my birthday. What’s all this stuff about rooting?”
The Barnes & Noble Nook eReaders share some of the same electronic architecture as many smart phones and tablets. These devices work using the Android Operating system. The factory installed OS (Operating System) of the Nook limits many of the possible advanced features since it was designed primarily to be a reader. Some tech-savvy programmers have learned how to root the Nook devices to more closely emulate advanced features found on many of the Android devices.
Quick detour: Those wanting to root their Nooks are going to run into a lot of terminology. Here is a link to a glossary of many of these terms.
http://www.acertabletforum.com/foru...-dummies-guide-android-terminology-lingo.html
The number of terms addressed within this post will be a much smaller number. But these are terms that you really should understand before attempting to make changes in your Nook.
What is Rooting?
The term “root” comes from the Unix/Linux world and is used to describe a user who has “Superuser” rights or permissions to all the files and programs in the software OS. Regular users can use the software, but cannot make changes. Superuser privileges allow changes to the software code on the device.
“Rooting” means obtaining “superuser” rights to your Nook’s software. You gain the ability to load custom ROMs, install custom themes, increase performance, increase battery life, and the ability to install software that would otherwise cost extra. Rooting is essentially “hacking” your Nook.
ROMs
A stock ROM is the version of the device’s operating system that comes loaded on it when you buy it. The Nook Readers have a stock ROM.
A custom ROM is a fully standalone version of the OS, including the kernel (which makes everything run), apps, services, etc - everything you need to operate the device, except it's customized by someone in some way..
So what does the "customized" part mean? Since Android is open source, developers are free to take stock ROMs, modify them, remove garbage, optimize them, add things, and pretty much do whatever their imagination and skills allow. (And just so you know, they can also write bad programming too.)
Kernals
Another word you’ll frequently see on this site is kernel. Your Nook’s kernel controls much of the communication between the various electronic parts of the unit. An analogy is that the kernel is like programming stored in the Read Only Memory found on desktop and laptop computers. Think of the BIOS (Binary Input Output System). Some portions of the settings in this memory can be changed, such as when you install a hard disk drive. BIOS also allow other settings to be adjusted to suit the preferences of various users. But other portions of the BIOS should not be changed or your computer’s electronics cannot communicate with one another.
That is a pretty close approximation to how the kernel on your Nook is setup. Some portions of the programming were set at the factory and should not be changed. But other portions of the programming can be changed. And updates to the programming for kernels are made available.
Many of the custom ROMS you can load on your Nook will make at least some changes within the kernel of your unit. Just as there are various versions of the custom ROMs. There are versions of the programming for kernels as well. Let’s stop there for now. The subject can quickly get pretty deep. That should be enough for now.
Two Approaches
Some people who want to use one of these custom ROM systems on their Nook just install the MOD on a SD chip. (SD stands for Secure Digital.) All current Nook readers accept a Micro SD chip. A custom ROM can be loaded onto your Nook from this SD chip. Some people choose to Root their Nook with the Android Operating System operating from the SD chip. Then by powering down the Nook, they can remove the SD card. They can then restart their Nook and the regular Barnes & Noble system will operate.
At least some of the custom ROMs allow users to select whether to run the operating system (ROM) installed on the SD card, or run the native Nook operating system. You don’t need to go through the process of inserting or removing the SD card to change the OS. A series of keys are pressed as the Nook is starting to select the ROM you want it to run. This is called dual booting.
The other method of rooting consists of loading the custom ROM into the emmc. (This stands for Embedded Multi- Media Card.) This is the flash memory of your Nook that contains the original Barnes & Noble operating system. Loading the ROM into the emmc means the original B & N operating system is no longer available to run. Many advanced users report the ROMs operate a bit faster and that there are fewer problems when the Nook is run in this manner. But do remember that this means the original operating system on your Nook will no longer run. There are instructions located on this site that include steps to re-install the original system. So, this may not be as drastic a step as it might seem at first glance. There are also programs which will allow you to save all the data settings – including the OS settings currently loaded on your Nook so they can be restored later. That will not be covered in this post.
Those totally new and unfamiliar with Rooting may find it a little safer to use the SD chip method. As they gain more experience and know better what they are doing they may decide to venture out and try the emmc method for the potential advantages this method offers.
The Downside Of Custom ROMs
Of course, there are dangers of using custom ROMs which you should be aware of.
You May Void Your Warranty
As long as we’re talking about risks, this one needs to be mentioned. It's possible that custom rooting might void your warranty. The manufacturer might be able to tell that the Nook has had a custom ROM installed and not honor the warranty, in case you need to use it. Barnes & Noble hasn’t acted hostile to rooting yet, but that could change.
Something Could Go Wrong
First of all, something may go wrong with the flashing process (that's the process of installing a custom ROM) and leave your Nook in a bricked state. A Bricked Nook means it won’t operate. The chances of this are relatively low – especially if you use the SD chip method. And most of the time you can restore your Nook back to normal. Please take note of the phrase “most of the time”. You should understand that a bricked Nook is a possibility that can happen.
Try to go for a custom ROM that has been tested by time and has lots of positive feedback from users on this site. You are more likely to be successful with such a ROM.
Other Potential Problems
Custom ROMs could have bugs. Bugs are mistakes in the programming. Some are minor and won’t cause big problems. But others can be more serious.
There are appropriate locations on this site where you can post problems due to bugs. Those who post in the ROM forum will likely get an answer back and the bug will probably be acknowledged. Experienced users may even suggest methods to fix the problem.
So What‘s the Bottom Line?
Many of the people at this site have determined that the potential benefits of running these custom ROMs outweigh the risks. There are lots of experienced people here who will offer their advice if you decide to try this. But it is ultimately your responsibility to consider the risks and benefits in deciding what to do.
Quick detour: Let’s be realistic. Your Nook is never going to be an I-Phone. It was designed to be an eReader. (So was the Kindle.) Rooting can add features and capabilities to your Nook that Barnes & Noble probably won’t ever include in their stock ROMs. But rooting won’t really turn your Nook into a smart phone.
“But there are so many choices!”
Yes there are. Let’s try to understand why this is a good thing. Apple and Microsoft own the rights and hold patents on their operating systems. They jealously guard their secrets and strictly enforce their patents. And they make money selling their operating systems.
Unix is also a patented operating system. Linux is an open source operating system based on Unix. It isn’t really owned by anyone. The concept allows many users to tinker with it to improve it. The Android operating system is loosely based on Linux and is also open-source. Developers take stock ROMs and modify them to create their own unique versions. Developers of custom ROMs are able ptimize the software, unlock built-in features, and create an even better version of the Android software. The Android developers who make these custom ROMs release the software to the general public free of charge. We are fortunate to have these developers constantly working and freely sharing these custom ROMs available to everyone.
Stable versus Cool
Since ROMs are constantly being developed by many people, there are multiple flavors of ROMs available to us. Anyone who has ever done any programming knows that sometimes your new code fixes one problem but creates others. Programmers generally call these bugs.
A major portion of the ROMs may work OK, but there may be bugs in portions of the code. Groups of developers collaborate and post their versions of a MOD to be checked out and tested by other users to discover and fix all the bugs.
Then there are some general flavors of the Android system that have become established and are recognized by many. Let’s consider a few of those since you will see these mentioned frequently on this site.
Since April 2009, each Android version has been developed using a codename based on a dessert item. Released in alphabetical order, the names were Cupcake, Donut, Éclair, Froyo, Gingerbread, Honeycomb and Ice Cream Sandwich.
The Android versions distributed within the lifetime of the Nook include:
o Android 2.1 (codename Eclair)
o Android 2.2 (codename Froyo)
o Android 2.3 (codename Gingerbread)
o Android 3.0 (codename Honeycomb)
Quick detour: One further issue confusing to nubes is that at least some people will refer to a MOD by its Android number, example: 2.3. Others will use a number related to its codename, example CM7.0. Remember these people are really into this stuff. These numbers and differences really stick in their heads. Rule of thumb, if the number is below 4, it’s probably the Android number.
Let’s look at these individually. We’ll use the codenames in this list.
Eclair
Eclair is what your Barnes & Noble Nook Color runs as delivered. And even they are replacing it with Froyo.
Froyo
Many consider Froyo an improvement over Éclair. It has been in use for some time and is considered a stable platform for the Nook. Barnes & Noble is currently (as of 2/5/2012) loading this system using a method called push to update Nooks to run a stripped down version of Froyo. It is important to understand that the B & N version does not have all the features of some of the custom Froyo ROMs.
Gingerbread
The Gingerbread version that many people use has become known as CyanogenMod 7. That’s right – sometimes the system is called Gingerbread and sometimes it is called CyanogenMod 7, though many just refer to it as CM7. It was developed from the official Android Gingerbread source code, but was modified for many smart phones. There are many versions of this that will run on Nooks of various kinds. As of this writing, many consider this a good choice for a Nook operating system. It blends many recent features with at least some degree of stability. The CM 7 releases includes Bluetooth support for the Nook, meaning that you can use Bluetooth keyboards and headsets! It should be noted that Bluetooth support is still evolving.
Honeycomb
This Android system first showed up on the Motorola Xoom tablet. It offers some new features, but has not been released by the official development community. Because such development is constantly underway, some may post test versions for downloading. Be careful! This ROM is still very much in the developmental process. As an example, a few developers have been trying to take features of Honeycomb and include them in updated versions of Gingerbread. One of these versions has been given its own name: phiremod nook.
Generally, Éclair and Froyo, are considered to be stable and mostly bug free. Some versions of Gingerbread are close to being bug free, while other Gingerbread versions are still being sliced, diced, tweaked and tested. Honeycomb is still being tested. If this post stays on this site for a few months, there may be newer and more stable versions of Gingerbread. Or a stable version of Honeycomb for the Nook may become available. And some are experimenting with newer Android systems, like one called IceCreamSandwich. (Remember that this is being written in February of 2012.)
FYI: there are even new flavors of these general ROMS. There is also CM7.1 and CM7.2. And there is a version out there called CM9. So the development community is hard at work tinkering and tweaking.
Finally, as you start to explore and consider MODs for your Nook, you will often see some of these letters in the names of custom MODs.
Stable versions are those where all known issues have been addressed and resolved. This version is for everyday use.
-test / -RC versions are similar to the experimental versions, but are in the final stages of testing before being declared as "stable". There may be a few bugs left, but this version is usually stable enough for everyday use.
Experimental / -alpha versions are those where new features are being added, modified, and tweaked, and there are known bugs that are being worked on. This version is for beta / alpha testers.
Nightly builds are daily compiled builds from source. This version therefore has the latest features & tweaks, but it is also the mostly likely to have bugs and issues. These versions are probably poor choices for nubes.
So which do you want to use? Éclair came on your Nook. And currently, Barnes and Noble is pushing their stock version of Froyo out over the Internet automatically to your Nook. Gingerbread – going by the name of CyanogenMod7.0 – may be a good choice for starting out, as of the date of this writing. Yes, you can upgrade this to later versions as you become familiar with what is out there and how to root your Nook.
End of the lesson.
Hope this information was helpful. Happy Rooting!
Great info, and sure to be helpful to many. Here are a some suggestions:
A description of CM versions might be helpful, linking CM versions to Android versions.
CM 7.1 is the latest stable. You might mention nightlies, and the 7.2 RC0 Mirage release.
No mention of ICS? With all the buzz lately, I'd definitely include it in the list of Android versions, and mention it with CM9.
I think there are three choices:
Root stock B&N firmware.
Dual-boot with CM (or similar) on SD (external).
Over-write eMMC (internal) with CM (or similar).
I see a lot of confusion between these, and a lot of misconception that you have to root stock before loading either of the other options.
Was the NOOK color originally shipped with Eclair? I thought they were Froyo from day one. I know a lot of us were disappointed when B&N 1.4.1 shipped as Froyo.
Thanks for the feedback. Remember, this is Nook 101, not 201. I didn't want to provide so much info that it left folks feeling overwhelmed. I suggested they begin with CM7.0. I mentioned CM7.1 and CM7.2. This sucker is already long. I had to narrow the focus to keep from turning it into a novel.
ICS is Ice Cream Sandwich, isn't it? I mentioned that CM9 is under development, but I'm pretty sure nubes should not start with that. Besides, my understanding is that it is still very much in the RC testing phase. Isn't that right?
I said there were two approaches. But I said some MODs allow for dual booting. Again, I didn't want to overwhelm.
I read in two different places (not on XDA) that Eclair was the original OS for the Nook. I think they began to push Froyo in the Fall of 2011.
You will also note that I did not cover the various models of the Nook at all. And I didn't mention the change in the hardware of Nook Color that has happened in the past two or three months. I didn't feel qualified to explain those. I'm still a relative nube myself.
BO
First, thanks for all the hard work with the words. I saw your initial posts and can only figure you are a writer, to be so willing to set everything you have done down in an orderly manner.
I'd like to add a fourth choice to bobstro's list of possibles (and I am not so adept at all this Nooker stuff myself that I believe it is too much for beginners):
Triple boot using Racks' great info and files here in the developer's wing. That way a learner can get a very stable CM7 GB (Kang build) a working - and for an "in process" ROM - quite stable CM9 (ICS) both on one SD card, and still have an untouched B&N stock on their NC.
Believe me; it's not too hard to set up; it has the best of all worlds. And it increases the fun factor by a million!
You know what root is but I don't get a clear picture of why it is called root.
In the unix/linux world if you are a superuser you have root access. Rooting a device is gaining root access to the device. With root access there are no restrictions to what you can do to the device. Including brick it.
BTW: Bricking a device is just that. Turning a beautiful orchestration of electronic components into a paperweight or, brick.
I think I included that the term rooting comes from the unix/linux world and the business about the superuser. See, that's the problem with something so long. It's easy to miss stuff. But I wanted to be clear about some of the essential stuff. It's a balancing act. Anyway, thanks for the input.
Yes. I saw why it was called bricking. I can add that.
BO
Thanks for the suggestion. I'll look into Rack's method and see whether I can include it. Again - this post is intended to be 101, not 201 info.
I wrote some computer manuals for teachers at least for a few years. It's been awhile since I did that. I try to be clear. The problem is that sometimes I try to keep it so simple that I often go overboard - result - very long. Verbose is the word. I could never have worked for Reader's Digest.
I see that nearly 150 people have at least looked at the file (maybe at least scrolled through it), but I haven't seen all that much feedback so far.
Some are making suggestions for improvement. My concern really is have I been accurate about what I actually did include?
BO
BO
You start using the term MOD without having defined it partway down.
I found this bit potentially confusing:
FYI: there are even new flavors of these general ROMS. There is also CM7.1 and CM7.2. And there is a version out there called CM9.
What is CM if this is 101?
Thanks. I'll try to adjust the issue you raised about using MOD before it has been defined. I believe I did explain CM was CyanaMod, but I'll double check it.
BO
It's a sequence thing. You use CM before CyanogenMod, and don't link them together. You might try something like CyanogenMod (CM) to link them.
Maybe a mention of OTA updates?
Gotcha. I'll see what I can do.
Thanks!
BO
This is just purely a great, great post, especially for newbies.
Keep it up, bachon.
Back to bachon, here's a few things
1. "“Rooting” means obtaining “superuser” rights to your Nook’s software. You gain the ability to load custom ROMs, ....."
Rooting has nothing to do with loading custom ROM. In order to be able to install/loading custom ROM, the bootloader must be unsigned/unchecked. Short way of saying, you can root but it doesn't mean after root, you can install custom ROM. It's a function of the bootloader.
2. Personally, I think and I do believe some devs. think that the term "rooting" is only applied to the stock ROM/OS. When you installing/running a custom ROM, the term "rooting" is irrelevant and should not be used (since we already able to access the root directory of that OS/ROM)
3. Not a biggie, but pls rename "Kernals" to "Kernels"
The other way of saying the kernels: are the firmware drivers that handle all the communications between the hardware and the operating system.
4. If you have the "Two Approaches" sections, you should also have "Three Approaches"
5. In the "Downsides of Custom ROMs" you mentioned it will void the warranty. This is only true if you install a custom ROM in eMMC. If you're running one off uSD, you know by removing the uSD, it's back to stock. No warranty voided.
6. Since you listed "o Android 3.0 (codename Honeycomb)", you should add "Android 4.0.x (codename Ice Cream Sandwich), just to complete
7. I do think we should have a short paragraph about what CyanogenMod team and their codenames. I don't want to go way back but CM7, the "7" denotes for Gingerbread builds and on-going "9" is for Ice Cream Sandwich. Why do they skip "8"? 'Cuz "8" was reserved for Honeycomb.
I can't pass out the cigars yet, huh?
votinh said:
This is just purely a great, great post, especially for newbies.
Keep it up, bachon.
Thanks for the kind words, votinh.
Mod, you should sticky this thread.
Back to bachon, here's a few things
1. "“Rooting” means obtaining “superuser” rights to your Nook’s software. You gain the ability to load custom ROMs, ....."
Rooting has nothing to do with loading custom ROM. In order to be able to install/loading custom ROM, the bootloader must be unsigned/unchecked. Short way of saying, you can root but it doesn't mean after root, you can install custom ROM. It's a function of the bootloader.
2. Personally, I think and I do believe some devs. think that the term "rooting" is only applied to the stock ROM/OS. When you installing/running a custom ROM, the term "rooting" is irrelevant and should not be used (since we already able to access the root directory of that OS/ROM)
I'm afraid my understanding for what you are saying is insufficient to write this clearly. Can you say more about this to clarify things? I thought it was obtaining superuser rights that gave users the ability to load ROMs and other software on their Nooks. I'm going to need more information to correct this.
3. Not a biggie, but pls rename "Kernals" to "Kernels"
The other way of saying the kernels: are the firmware drivers that handle all the communications between the hardware and the operating system.
Oops! Good proof reading. Thanks. Is it OK to just add your addition to the final post, or is the rest of what I have said wrong?
4. If you have the "Two Approaches" sections, you should also have "Three Approaches"
OK. Here's my current understanding. 1. Running a custom MOD from the SD Card. 2. Installing a custom ROM in eMMC. 3. Having a dual boot capability.
Someone mentioned having two different ROMs loaded on an SD card. Does this allow the original Nook OS to run with no SD card inserted?
Any clarification needed there? I'm looking to make this VERY clear for newbies.
5. In the "Downsides of Custom ROMs" you mentioned it will void the warranty. This is only true if you install a custom ROM in eMMC. If you're running one off uSD, you know by removing the uSD, it's back to stock. No warranty voided.
Hmmm. Is there no way running or updating a ROM can brick a Nook? It seems to me that someone trying to upgrade from one custom ROM to another could follow the wrong steps and trash the contents of the emmc. Am I wrong?
6. Since you listed "o Android 3.0 (codename Honeycomb)", you should add "Android 4.0.x (codename Ice Cream Sandwich), just to be complete
7. I do think we should have a short paragraph about what CyanogenMod team and their codenames. I don't want to go way back but CM7, the "7" denotes for Gingerbread builds and on-going "9" is for Ice Cream Sandwich. Why do they skip "8"? 'Cuz "8" was reserved for Honeycomb.
Click to expand...
Click to collapse
I wondered what happened to CM8. Thanks for that. I'm so new here that I'm not sure I can really explain the CyanogenMod team and their codenames. Care to give me some tips? It would really help.
While I'm asking: why and when was the codename for Gingerbread changed to CyanogenMod?
I don't mind including Ice Cream Sandwich/CM9, but I don't know that much about it. Input from the seasoned veterans would help.
Frankly, most of the suggestions I've received seem to want to add more information. I wanted things to be clear without overwhelming. Truth is, I cannot write clearly about things I don't quite understand.
If folks will share and explain the info to me then I'm more than willing to try to put it in a form that neophytes can understand.
Finally, MOD and ROM seem to be used interchangeably by many in the Nook forums. Anybody willing to provide their 2 cents worth on the difference?
Thanks
BO
I'm afraid my understanding for what you are saying is insufficient to write this clearly. Can you say more about this to clarify things? I thought it was obtaining superuser rights that gave users the ability to load ROMs and other software on their Nooks. I'm going to need more information to correct this.
Click to expand...
Click to collapse
Obtaining superuser rights is NOT enough to load custom ROMs on the device. Take a look at the Nook Tablet as an example.
Obtaining superuser rights is enough to install other applications. It is still not 100% true. Take side-loading feature as an example, some devices, even rooted, still cannot sideloading.
OK. Here's my current understanding. 1. Running a custom MOD from the SD Card. 2. Installing a custom ROM in eMMC. 3. Having a dual boot capability.
Click to expand...
Click to collapse
What you said is MOST common mistake and should be changed.
Boot from eMMC along with running off uSD is NOT dual-booted, at least not TRUE dual-booted. People here love to call it as "dual-boot" so I go with that, but it isn't, really.
True dual-boot is one ROM in eMMC and another ROM also in eMMC. Same applied for uSD.
This is a true dual-boot:
http://forum.xda-developers.com/showthread.php?t=1448186
Someone mentioned having two different ROMs loaded on an SD card. Does this allow the original Nook OS to run with no SD card inserted?
Click to expand...
Click to collapse
The link I just provided up there is exactly what it for.
And yes, it is INDEPENDENT to eMMC. You can leave stock OS intact.
Hmmm. Is there no way running or updating a ROM can brick a Nook? It seems to me that someone trying to upgrade from one custom ROM to another could follow the wrong steps and trash the contents of the emmc. Am I wrong?
Click to expand...
Click to collapse
Dealing with eMMC, yes, if you screw it up, then you got what you have. If you only dealing with uSD and leave eMMC untouch, everything on eMMC should still be there, cleanly.
Note: the NC is virtually unbrickable unless the hardware parts broken.
While I'm asking: why and when was the codename for Gingerbread changed to CyanogenMod?
Click to expand...
Click to collapse
Gingerbread is Android mobile OS codename by Google.
CyanogenMod is a developer team. Their codename gets their teamname and as I said "7" is Gingerbread version of their work.
Note: CM7 widely known for custom ROMs, not only for NC but for many other devices
Link: http://www.cyanogenmod.com/
See their device list.
Finally, MOD and ROM seem to be used interchangeably by many in the Nook forums. Anybody willing to provide their 2 cents worth on the difference?
Click to expand...
Click to collapse
I rarely see MOD as refer to ROM but I would guess, MOD is shortcut for Modification/Modified.
ROM usually refers to OS.
Votinh (or anyone else),
When you write computer code, you have to break the instructions down into step-by-step commands. Computers have no common sense to guess what you’re telling them to do. You can’t just say, “Print”. You have to be a whole lot more specific.
I’m trying to get you to do that here. Because you (and many others on this site) understand this stuff so well, you’re using broader statements like “It’s a function of the bootloader.” I’m asking you these questions to break it back down into the step-by-step stuff. If you can get me to understand it, I think I can write it down so many other nubes will understand it and MAY stop bugging everybody by asking over and over. Please be patient and bear with me.
OK. Let’s take these one at a time. Rooting first:
You said:
“Rooting has nothing to do with loading custom ROM. In order to be able to install/loading custom ROM, the bootloader must be unsigned/unchecked.”
“Short way of saying, you can root but it doesn't mean after root, you can install custom ROM. It's a function of the bootloader.”
First, I’ve been under the impression that rooting is an absolutely essential first step in order to be able to do things like loading a custom ROM. It isn’t all that is required, but it is the FIRST requirement. Isn’t that correct?
Think of a Nook straight out of the box. If I stick a formatted SD chip in my Nook with no OS, the Nook loads the stock OS. If I stick a SD chip imaged using “generic-sd-v1.3.zip” and with the zipped archive, “Encore_CM72-MIRage-01262012.zip” loaded on the SD chip, then the Nook will expand the “MIRage*.zip” and run the CM7.2 custom ROM. Isn’t that right?
Which of these zipped archives (if any) actually contains the instructions that roots the Nook?
Which of these zipped archives (if any) actually contains the instructions that unchecks the bootloader?
Which of these zipped archives (if any) contains the instructions that alters the bootloader?
Which of these zipped archives (if any) actually loads the custom MOD?
Is it accurate to say that rooting the device is only the first step necessary before the bootloader can be unchecked?
If so, is it also accurate to say that the installation process for any custom ROMs must then uncheck and alter the bootloader before any custom ROM can be installed or loaded?
My way of thinking of it is as follows: rooting only unlocks the first lock on the device. Then the installation process for the custom ROM must unlock other locks before a custom ROM can be loaded or installed.
BO
bachon said:
[...] First, I’ve been under the impression that rooting is an absolutely essential first step in order to be able to do things like loading a custom ROM. It isn’t all that is required, but it is the FIRST requirement. Isn’t that correct?
Click to expand...
Click to collapse
No, that is not correct. Rooting is providing root access on a (in a sensible case) unrooted device. This is typically your stock firmware. You can root a NC which shipped with unrooted (locked) B&N 1.2, 1.3 or 1.4.1 firmware, for example. You can also root a NT which ships with 1.4.x firmware as well.
Loading alternate firmware is where the locked bootloader comes in. On the NC, with no locked bootloader, independent of rooting, you can install alternate firmware, either to SD card (leaving the internal eMMC firmware, rooted or not, unchanged), or over-write the internal eMMC firmware with something new. I'd expect that something new to be rooted in the case of alternate firmware, but I suppose it doesn't have to be. On the NT, this is all complicated (if B&N had their way, impossible) because of the locked bootloader, but progress is being made working around this. See the NT forums for details.
If you're going to load alternate firmware on a NC, rooting is not a requirement. In fact, a lot of people like dual-booting (sorry, the term is descriptive enough without getting into semantics, and I've yet to hear a better term) something like CyanogenMod off of SD while preserving their unrooted stock B&N firmware for "warranty purposes", since they are completely independent of each other. Boot off of SD and you get CM. Pull the SD out and boot and you get B&N.
To make it short, bachon,
bootloader is essentially a piece of low-level code that resides on the non-volatile on boards that handling how the system starts up and how it behaves during powering up. The other way to say: it is the very first thing to run soon the power provided.
If it is "signed/locked" then you have a hard time to manipulate it such loading custom ROM, even preventing alter the stock recovery, and in some case, not even allow us to touch the system kernel.
Think of a Nook straight out of the box. If I stick a formatted SD chip in my Nook with no OS, the Nook loads the stock OS. If I stick a SD chip imaged using “generic-sd-v1.3.zip” and with the zipped archive, “Encore_CM72-MIRage-01262012.zip” loaded on the SD chip, then the Nook will expand the “MIRage*.zip” and run the CM7.2 custom ROM. Isn’t that right?
Which of these zipped archives (if any) actually contains the instructions that roots the Nook?
Which of these zipped archives (if any) actually contains the instructions that unchecks the bootloader?
Which of these zipped archives (if any) contains the instructions that alters the bootloader?
Which of these zipped archives (if any) actually loads the custom MOD?
Click to expand...
Click to collapse
The "generic...." is just a container.
The "encore-...." is the actual custom ROM.
If so, is it also accurate to say that the installation process for any custom ROMs must then uncheck and alter the bootloader before any custom ROM can be installed or loaded?
Click to expand...
Click to collapse
Absolutely true.
---------- Post added at 10:21 AM ---------- Previous post was at 10:20 AM ----------
Oh, and bobstro have provided a very good example of it, down to the very specific case.
Bobstro,
So a lot of people who say "I rooted my Nook" aren't correct. They may have loaded another OS, like CyanogenMod 7.2, but that doesn't mean that they've necessarily rooted their Nook. Is that correct?
These folks would be more accurate to say "I hacked my Nook."
Is that closer to being accurate?
How and why did so many people start calling it rooting? I know about the root user in Unix. Do some of the OS installations go the extra step of actually rooting the Nook?
BO
I think you spelled Bacon wrong.
bachon said:
Bobstro,
So a lot of people who say "I rooted my Nook" aren't correct. They may have loaded another OS, like CyanogenMod 7.2, but that doesn't mean that they've necessarily rooted their Nook. Is that correct?
These folks would be more accurate to say "I hacked my Nook."
Is that closer to being accurate?
How and why did so many people start calling it rooting? I know about the root user in Unix. Do some of the OS installations go the extra step of actually rooting the Nook?
BO
Click to expand...
Click to collapse
I don't mean to jump on bobstro's toe, I hope he allows me to answer the question.
1. Again, I repeat, the term "root" should only be applied when you're dealing with STOCK ROM.
2. If you are running CM7 or any custom ROM such MIUI, .... you DON'T NEED to root since it ALREADY allows you accessing the root directory. Therefore "rooting" process is no need.
3. If you are running any custom ROM, ideally, you should not say "I'm rooting my device".
Why people using that? They say so and no one correct them so the term spreads.
I see it mentioned a few times but what on the phone prevents say 4.4.2 from being installed after the upgrade to 4.4.3?
Because the partion table and bootloader are different and can't be downgraded at all.
Or, you can downgrade... But brick your device after, even later.
Anyone who knows anything about the moto x will tell you just don't. ?
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
knitler said:
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
Click to expand...
Click to collapse
Security!
Look at the whole Windows/AntiVirus industry.
All because Microsoft wanted unsecure compatibility with the old OS.
Saving software dev time making things work.
knitler said:
I find that odd. I wonder what the purpose is for doing that.
There is no way to just re-write those sections? Even on a Dev Edition?
Click to expand...
Click to collapse
No, the Dev edition is no different. All the same "rules" apply.
The Dev edition is the same as any other.... It just keeps is warranty if you unlock it.
aviwdoowks said:
Security!
Look at the whole Windows/AntiVirus industry.
All because Microsoft wanted unsecure compatibility with the old OS.
Saving software dev time making things work.
Click to expand...
Click to collapse
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
KJ said:
Or, you can downgrade... But brick your device after, even later.
Anyone who knows anything about the moto x will tell you just don't. ?
Click to expand...
Click to collapse
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
AGISCI said:
Because the partion table and bootloader are different and can't be downgraded at all.
Click to expand...
Click to collapse
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
scryan said:
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
Click to expand...
Click to collapse
It is security. Specifically the SECURED BOOTLOADER. Don't confuse secured with locked. Yes, you can unlock your bootloader, but it is still secured.
Read up on "TrustZone" and see why it is important, and why the OEMs would not want you to be able to downgrade. You can "buy" or "not buy" whatever you want....
I really don't get the linux reference. We are talking about a bootloader, not linux in general. That's beyond the fact that any smart linux user would almost never have any reason at all to downgrade. Think about the heartbleed vuln that was discovered recently. Why on god's green earth would you want to downgrade openssl back to a version that is vulnerable??
The early (4.2.2 & 4.4) bootloader (motoboot.img) was vulnerable to an exploit that allowed us to disable write protection. The updated bootloader (4.4.2+) is patched. You *CAN NOT* downgrade back to the vulnerable version.
^Does that not have *everything* to do with security??
scryan said:
I'm kind of not buying this for a second?
How about linux, which is often pointed to for its security... And you can upgrade, down grade, switch out every component for newer/older/different, switch kernels, upgrade kernels, downgrade kernels... hell change out kernels with out even rebooting.
Really not buying it has anything with security.
I think we understand that, I mean if the OP didn't he wouldn't have the question of "why not?". Its not I think it might be a good idea... We are just trying to understand the situation because it seems unique, and so we were hoping someone who knows a lot about
This is the most I have heard so far, and I have heard it once or twice... But can't the recovery image include information on the partition table?
I realize the way it is, but was curious on some more technical information explaining it...
Click to expand...
Click to collapse
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
AGISCI said:
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
Click to expand...
Click to collapse
Can't just fake the version number?
No, it's not possible.
samwathegreat said:
I really don't get the linux reference. We are talking about a bootloader, not linux in general. That's beyond the fact that any smart linux user would almost never have any reason at all to downgrade. Think about the heartbleed vuln that was discovered recently. Why on god's green earth would you want to downgrade openssl back to a version that is vulnerable??
Click to expand...
Click to collapse
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
samwathegreat said:
You can "buy" or "not buy" whatever you want....
Click to expand...
Click to collapse
I know, and that is why I want to understand what it is I would be buying.
AGISCI said:
Because even though the patition file and bootloader are included in the archive, they fail to flash because they have a lower version than what is installed.
Click to expand...
Click to collapse
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
scryan said:
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
I know, and that is why I want to understand what it is I would be buying.
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
Click to expand...
Click to collapse
The custom recoveries don't flash gpt.bin nor motoboot.img so using a custom recovery it's impossible to correctly flash a Moto X. You MUST use stock recovery with a Moto X. The problem isn't that it causes a brick by flashing an old version. The problem is that a brick happens the next time you do an OTA update. When the OTA update occurs there is a mismatched partion table and bootloader, so it ends up causing a brick.
The developer edition and the standard moto x are 100% identical. They only difference is that you don't void the warranty when you unlock the bootloader on the dev edition, however with the non dev edition your warranty is voided. So the same problem with the partition table and the bootloader ALSO apply to the developer edition as well.
AGISCI said:
The custom recoveries don't flash gpt.bin nor motoboot.img so using a custom recovery it's impossible to correctly flash a Moto X. You MUST use stock recovery with a Moto X. The problem isn't that it causes a brick by flashing an old version. The problem is that a brick happens the next time you do an OTA update. When the OTA update occurs there is a mismatched partion table and bootloader, so it ends up causing a brick.
The developer edition and the standard moto x are 100% identical. They only difference is that you don't void the warranty when you unlock the bootloader on the dev edition, however with the non dev edition your warranty is voided. So the same problem with the partition table and the bootloader ALSO apply to the developer edition as well.
Click to expand...
Click to collapse
Well said :good:
Still the answer is security.
So upgrade as Moto intended & do not downgrade!
---------- Post added at 07:37 PM ---------- Previous post was at 07:30 PM ----------
scryan said:
Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
Click to expand...
Click to collapse
Our recovery devs never restore such partitions or boot loader elements.
scryan said:
The linux reference was in direct reply to the quote above it that was making the argument that the PC anti-virus industry as well as the proliferation of malware and viruses is an example of the insecurity that is a result of a computers administrator having the technical ability to downgrade his OS software.
I mention linux because he was using PC OS's as an example, and Linux allows you not only to downgrade... but rewrite the bootloader. Or use a different bootloader. You bootloader can boot securely with UEFI, or you can just use BIOS. All this insecurity, but virtually no viruses, and very few security issues.
Why would you want to downgrade openssl? I wouldn't. I probably wouldn't flash back to an earlier version of android either... I keep my system pretty damn up to date. The point is more that his assertion that MS and Windows proves that being able to downgrade creates inherent security issues doesn't really hold up when you look at other systems that provide even more freedom.
I know, and that is why I want to understand what it is I would be buying.
I guess this is the part that we are not understanding. Perhaps because I don't understand enough and have not looked through decompressed recovery images enough... but basically the issue is that Motorola is bricking the device, rather then letting it be downgraded to an potentially insecure image. I am guessing then this is a soft brick?
Does recovery not have the ability to re-write the partition table though? Is there no partition table information in this recovery image? I get that the stock recovery would not allow it, but wouldn't a developer edition user be able to flash a custom recovery that wouldn't have issues flashing the partition table. Don't TWRP or CWM, ect do this?
I guess then that is where the trust zone comes in...
Click to expand...
Click to collapse
Smh I normally don't chime into these threads but I had to, you can't downgrade the bootloader because of security/compatibility plan and simple. It's the same concept as why you can't downgrade most PC's bios, if there is a flaw found in the system as a whole, then they don't want you to downgrade to that version. A lot of the times when people brick their device trying to downgrade is because it will flash, but because an efuse was blown when it was upgraded the downgraded version will not boot. Yes the recovery can technically rewrite those partitions but again because the efuse was blown it will not boot. Also yes being able to downgrade on any system Windows, Linux, Unix, IOS, Xbox, PS, etc are causes to security issues. If you can downgrade a system to a vulnerable version, it is then by definition less secure, no matter how you try to spin it. Take the futex vulnerability which affected most linux kernels from the past 5 years, so why would any desktop linux user ever want to downgrade to a vulnerable kernel? They wouldn't but if the end user isn't knowledgeable of the vulnerability they wouldn't know that downgrading makes them vulnerable. So since phones are used by so many people who are not knowledgeable of vulnerabilities, why would you want to give them the opportunity to downgrade themselves to a vulnerable OS?
Appreciate the info given... I don't want to downgrade, I am not trying to downgrade, I understand why its a bad idea, ect...
My view point was more questioning the insistence that it being technically possible to downgrade creates a security flaw on a machine that is kept up to date by a responsible individual. Unless we are trying to speak more abstractly about that fact that given someone the opportunity to make a mistake makes it more likely for one to occur, I don't think that security threat exists until you actually use that ability to downgrade to something with a flaw.
I guess then it comes down to personal viewpoint of do I want my phone to brick it self to protect me from myself and like sam said, you choose to go elsewhere... But then that is somewhat what I am trying to figure out. Even though its not something I would probably ever have to deal with, I don't like the idea... But "bricking" can be such a vague term with manufacturer specific recovery tools and "different levels of bricking".
Just trying to understand how what and when actually happens. I probably need to read some more of the recovery threads, and I have been looking through old threads here while considering VZ dev moto X and waiting for the x + 1 announcement, but I figured I would jump on the thread while it was here.
I understand keeping it simple because its generally a bad idea all around, and its just best not to confuse things... but its been hard to find deeper discussion or information then the general warnings. A bit of a better picture from this thread though.
aviwdoowks said:
Still the answer is security.
So upgrade as Moto intended & do not downgrade!
---------- Post added at 07:37 PM ---------- Previous post was at 07:30 PM ----------
Our recovery devs never restore such partitions or boot loader elements.
Click to expand...
Click to collapse
By "Our recovery devs" do you mean the ones doing the moto specific stuff? Do you know if this Is typical of the custom recoveries for other devices?
@scryan
I know far less then other posters, but yes android recoveries are all very similar in that regard.
scryan said:
Appreciate the info given... I don't want to downgrade, I am not trying to downgrade, I understand why its a bad idea, ect...
My view point was more questioning the insistence that it being technically possible to downgrade creates a security flaw on a machine that is kept up to date by a responsible individual. Unless we are trying to speak more abstractly about that fact that given someone the opportunity to make a mistake makes it more likely for one to occur, I don't think that security threat exists until you actually use that ability to downgrade to something with a flaw.
I guess then it comes down to personal viewpoint of do I want my phone to brick it self to protect me from myself and like sam said, you choose to go elsewhere... But then that is somewhat what I am trying to figure out. Even though its not something I would probably ever have to deal with, I don't like the idea... But "bricking" can be such a vague term with manufacturer specific recovery tools and "different levels of bricking".
Just trying to understand how what and when actually happens. I probably need to read some more of the recovery threads, and I have been looking through old threads here while considering VZ dev moto X and waiting for the x + 1 announcement, but I figured I would jump on the thread while it was here.
I understand keeping it simple because its generally a bad idea all around, and its just best not to confuse things... but its been hard to find deeper discussion or information then the general warnings. A bit of a better picture from this thread though.
Click to expand...
Click to collapse
The thing is you keep looking at it from a PC point of view, where you basically have full control over the software and hardware. Phones have much tighter restrictions on them from carriers, fcc, etc they're not personal computers. So the reason they make it where you can't downgrade the bootloader is because that's what controls the restriction on downgrading any other partition on the device.
So with the Moto X's 4.4.4 update they probably blew an efuse, so users with a locked device can't downgrade. This is done because with locked devices they can only flash signed kernels, so by blowing the efuse they can't downgrade to the vulnerable 4.4.2 and below kernel even though it is signed correctly. This is because lets say a malicious app was able to get on a device that had the ability to downgrade say back to 4.2.2. That app could flash the older vulnerable signed kernel to the recovery partition, to disable write protection gain more control over the phone etc, without the users knowledge. Now that is a stretch and probably will never happen but that doesn't mean the threat isn't there, and hackers are very creative at deploying malicious attacks. So by updating the bootloader and blowing an efuse the older vulnerable kernels can't be flashed. Now this is all negated if you're unlocked of course, but if you don't want to ever worry about this issue don't update your bootloader. This is not recommended but I've mentioned it several times on this forum I haven't updated my X's bootloader since I bought it, it's still running the factory 4.2.2 bootloader, running 4.4.4 with no problem.
The other thing you're missing is we're technically not supposed to have the ability to restore our phones, except for the developer edition of course. The fastboot restore files are leaked not released to the public, they are designed for use when phones are returned to be refurbished. So they don't want the phones that are being refurbished to be flashed back to an older version, they want it to be refurbished and the latest software version flashed to it.
iKrYpToNiTe said:
The other thing you're missing is we're technically not supposed to have the ability to restore our phones, except for the developer edition of course. The fastboot restore files are leaked not released to the public, they are designed for use when phones are returned to be refurbished. So they don't want the phones that are being refurbished to be flashed back to an older version, they want it to be refurbished and the latest software version flashed to it.
Click to expand...
Click to collapse
A bit selfish, and perhaps lazy of me but I am only really here talking about the developer version, I just haven't bothered to write the full "verizon developer edition " every time (most of this is research for next phone, which will be developer handset)... To me, obviously a locked phone is going to have weird restrictions and hacked together paths to getting things done, your not supposed to have admin rights...(yeah, maybe I do look at it too much as a computer. Mostly because I am annoyed the differences seem intentionally imposed). But when I pay outright for a device so that I can own it and have full administrative control... anyways, thats a different more philosophical discussion. The point is I have been talking about an unlocked device using third party software where possible.
Either way, appreciate the reply. I have a better understanding of the issue... Though coming from an S4 it still seems weird that MDK*/developer phones don't seem to have the same issues/warnings. It would seem however that the difference may be that MDK/dev owners only use kernels/roms prepared for their devices and do not update the bootloader. I suppose if more people in the Moto X community were worried about maintaining the ability to downgrade an unlocked device it would be technically possible to upgrade in a way that could be easily reversed, similar to the S4.
(*MDK was the first VZ S4 firmware, and the only one that has a released exploit to allow for a full custom recover. Later locked firmwares must rely on safestrap)
Hi,
While going through the threads, I was not able to exactly understand what is the difference between ROOTing a phone and installing a Custom ROM in it. (I'm new to this ROOTing world - only had a chance to watch a friend root Samsung Galaxy S3 long long time back ... Apart from that I do not have much knowledge). I'm planning to root my Sony Xperia Z2 and was wondering if ROOTing is enough or should I proceed further to install a custom ROM.
Rooting your device just gives you privileged access that permits you to modify the operating system.
A custom ROM is an entire Android operating system that has been customized or otherwise modified. Depending on the ROM, it could be stripped down or have all sorts of additional system apps and features. Custom ROMs generally include root access, though not always.
If you're going to start somewhere, you should probably just root your existing stock ROM. Though unless you have a specific need (e.g. per-app firewall, ad blocking, backup/restore) or just like to tinker with ****, I wouldn't bother.
DRM Keys are important.
srcm.ch said:
Hi,
While going through the threads, I was not able to exactly understand what is the difference between ROOTing a phone and installing a Custom ROM in it. (I'm new to this ROOTing world - only had a chance to watch a friend root Samsung Galaxy S3 long long time back ... Apart from that I do not have much knowledge). I'm planning to root my Sony Xperia Z2 and was wondering if ROOTing is enough or should I proceed further to install a custom ROM.
Click to expand...
Click to collapse
Before rooting or start tinkering your stock rom, make sure to backup your DRM Keys. They are very important for Xperia devices and are essential for proper functionality of Camera and Music applications (Stock ones).
srcm.ch said:
Hi,
While going through the threads, I was not able to exactly understand what is the difference between ROOTing a phone and installing a Custom ROM in it. (I'm new to this ROOTing world - only had a chance to watch a friend root Samsung Galaxy S3 long long time back ... Apart from that I do not have much knowledge). I'm planning to root my Sony Xperia Z2 and was wondering if ROOTing is enough or should I proceed further to install a custom ROM.
Click to expand...
Click to collapse
I would recommend before rooting your phone you determine for yourself the purpose for which you are rooting, some people do for customisation via xposed and gravitybox, some do it for control e.g. removing stock apps, whatever the purpose, because rooting can cause your phone to stop working, it's a venture that's best taken with a purpose, my personal preference is to root a stock android environment rather than running ROMs
question
So im trying to make a "custom" rom but i want it to have root by default lke Cyaogen. Do i change something in build.prop or something else?
Is it possible to unlock?
At this moment, no.
You will know as it'll be reported here very early. There are some third party companies that do it. Some are cheaper than others.
For the moment, there is nothing..
Sucks I know
I asked this before on another similar thread and didn't get a response. Is it possible to dump the bootloader from either an unlocked or locked phone to analyse it for potential vulnerabilities either in how it handles the unlock code, or more generally that would allow a user to soft-mod unlock the phone? I know for the 5th, 7th, and 9th gen Fire 7 tablets exploits were found in the LK part of the bootloader which eventually allowed for a customised version of TWRP to be flashed onto the devices, and later LineageOS. If we could dump the current Huawei bootloader surely we could try to find if there are any similar exploits?
I am found metod but it needs mrt dongle((
Tbh custom roms aren't really important anymore. Google is already ruining android everytime a new update comes around, like the overlay feature that was introduced in oreo but then removed for no reason.
Besides EMUI is already optimised for the chip so, again, no reason for custom roms and/or rooting (unless you want to remove bloatware but that can be solved via ADB)
The Restless Soul said:
Tbh custom roms aren't really important anymore. Google is already ruining android everytime a new update comes around, like the overlay feature that was introduced in oreo but then removed for no reason.
Besides EMUI is already optimised for the chip so, again, no reason for custom roms and/or rooting (unless you want to remove bloatware but that can be solved via ADB)
Click to expand...
Click to collapse
I am need it for root and lineage os
Hey, i wanted to ask you guys if it's really worth it to install a custom rom ? I have a chinese ROM and it's just full of bloatwares and unwanted services that tend to be annoying. That being said, if MIUI has a way better user experience than a custom ROM and flashing a ROM is just gonna make it worse (I've seen some problems concerning the fingerprint sensor or the battery drain) i don't think i'm willing to make that step. That's why i want to ask you guys if you're satisfied with a custom ROM, and is it really worth it knowing that I bricked my old phone while rooting it so I'm kinda reluctant.
IDK if it is too late but I recently flashed a custom ROM and as I type this, my phone is being reverted back to MIUI,
I used the custom ROM for a few days and here are some pros and cons.
Pros:
1. Much faster
2. Better battery life
3. Some extra customizations
Cons:
1. Banks apps! Some bank apps won't work even with all the work arounds.
2. Camera cannot be opened right from the lock screen (atleast without workarounds).
3. MIUI has the option to restrict internet access to individual apps, out of the box. Custom ROMs will probably need root and extra apps to get this functionality.
Long story short, I was making work arounds and doing tricks just to get things that were included in MIUI from the beginning.
But! if you want to experience the latest and pure android, custom ROMs are the way to go. Also, most normal users do not need or use the root tools or apps.
And, you can debloat your phone without root access, just by using ADB.