When you root a Bionic you remove some restrictive software walls that prevent activities like ... one app written by me modifying an app written by you that is running on the same Bionic.
In an un-root-ed Bionic it is not going to happen. In a root-ed Bionic it may happen. Not will but may.
There is nothing destructive about root-ing. There is potentially something very destructive after root-ing.
What I have seen repeatedly is people who have root-ed their Bionic and then did something they either didn't remember or were not aware of and shot themselves in the foot.
It was not the act of root-ing that caused the problem ... it was the potential that suddenly became available.
The closest analogy I can come to is if your Bionic was a System/360 it would be like running every app in Supervisor State/Protect Key 0.
So ... any time a person has a problem on a root-ed Bionic it could or could not be the same as a problem on an un-root-ed Bionic even when they seemed to have identical symptoms. With the root-ed Bionic you never know.
(It is unfortunate that the defacto best Backup/Restore app for Android devices requires you to be root-ed.)
It is certainly true that rooting can be a double edged sword... Which is why it isn't for everyone that doesn't understand the risks it opens.
The for mentioned backup/restore utility... ie Titanium Backup... couldn't do what it does without it having root access. So it's less unfortunate as much of a requirement in order to backup/restore in system areas not available if unrooted.
Users should have access to the systems they own in order that they are able to perform required administrative duties to maintain or even alter their system to better fit their needs. Of course, with that type of access, the user must also take responsibility for their actions and not blame the equipment if the changes they make causes errors or performance loss.
There should be an easy way to root and un-root. Titanium Backup Pro could then root/run as it does today/un-root leaving all the protections in place except when it is running. While it is running no other apps should be allowed to run.
This easy ability to root/un-root should be assigned to an administrator account and the administrator could determine if he/she wanted to do it or not.
For those who have chosen to root ... they could just turn it on ... turn it off when a system update came along ... and turn it on again.
As it stands today ... un-root-ed provides a different environment from root-ed and that is the subject of this thread.
Using a util such as VooDoo Rootkeeper would provide the option to root/unroot as you are talking about.... but care still needs to be taken since the user could still perform potentially risky procedures.
I actually lost root when testing to ensure it worked... it seems the old SU backup I had wasn't able to be reapplied so I had to re-root using the linux exploit for JB, then delete the old SU backup in VooDoo... and resave the new SU root. After that, it worked as it should have.
Android should have a built-in capability to root/un-root that is available to administrative accounts. It is a limitation in the design that was never included.
Having users go to a third-party app to perform the function and stand on their heads to have a third-party find an exploit after each system update is absurd. It should be built into the system.
The purpose of this thread was to document that the root-ed Bionic is a vastly different environment then the un-root-ed Bionic and that needs to always be kept in mind.
It is easy to come to the conclusion that when the same error message shows up on two Bionics in those different environments that it means the same thing. This might be true. Conversely it might not be true. Because of what the root-ed Bionic is ... you will never know.
If that is not what you were mentioning... it is still all that you had said was missing... Your previous statement had no mention that you also wanted it as a default option included with the Bionic and not just with the available third party options as it is now. Had you said it that way to start with, I would have certainly agreed with you and not had mentioned the other options available.
A Rooted Bionic IS the same as an Unrooted one with only ONE exception... the permissions given to the user that allow them to perform additional duties... That one difference is far from being "vastly different". To say that it is vastly different is wrong or at the least misleading when it only differs in one attribute... the permissions.
An analogy for a Windows computer... The difference is between the user being given standard user rights vs administrator right... That doesn't make Windows different for a standard user than the admin user... it only makes what the two user types different in what actions they can perform.
You did however correctly state that the action of rooting itself was not the potential danger... but the possible actions that could allow is what could cause trouble...
A Rooted Bionic IS the same as an Unrooted one with only ONE exception... the permissions given to the user that allow them to perform additional duties... That one difference is far from being "vastly different". To say that it is vastly different is wrong or at the least misleading when it only differs in one attribute... the permissions.
There is only one difference ... that one difference opens the door to all manner of differences ... like reading and writing data that is not even identified to the un-root-ed user as existing.
The fact that the safeguard is removed provides an environment where human error can have far reaching impacts. What we have seen is some of those errors being made and their impact finally being felt days, weeks, or months later. In many cases this really makes problem determination a challenge.
In today's "root only through a hack" Android the user needs to prepare to recover from the kinds of problems they can accidental cause.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
