3 ms·

Rooting isn't exactly using the system as designed. In a normal Android system /system is read only unless mounted otherwise (which only really happens during u

Rooting isn't exactly using the system as designed. In a normal Android system /system is read only unless mounted otherwise (which only really happens during updates). They even (ab)use this to make seamless updates by creating a second /system partition, writing the update to that, then swapping over on next restart. If something goes wrong, they swap back to the first system partition. In this manner, the /system partition is NEVER written to outside of creation. Rooting is literally sidestepping this entire process to take full control over the system and mount /system as writable. Sure, you could probably make a /recovery, /system, and /data all different partitions, but now you are roughly doubling the amount of system data on the disk for not much of a reason.

mehrdadn 8y ago
> Rooting isn't exactly using the system as designed. Rooting is very much using the system as designed. Google supports it and provides tools to enable it. Some apps on the Play Store require it. Does that mean everyone should root? No. Does this have any bearing on the fact that the recovery image should not be modified when rooting? No. > They even (ab)use this to make seamless updates by creating a second /system partition, writing the update to that, then swapping over on next restart. If something goes wrong, they swap back to the first system partition. If Google could provide a better way to root then this wouldn't be an issue. That they provide a suboptimal method isn't a defense here. > In a normal Android system /system is read only unless mounted otherwise (which only really happens during updates). I like how you contradict yourself in the span of 2 comments. First you said "Removing that app from the system partition won't give you more usable space without repartitioning", now you say that space is usable for installing updates. You just refuted your own point. > In this manner, the /system partition is NEVER written to outside of creation. In other manners, it IS written to outside of creation, and this is clearly due to the way they designed the system, not because modifying /system should actually alter the recovery image. > Rooting is literally sidestepping this entire process to take full control over the system and mount /system as writable. Yes, that's what it is, because it's necessary for some apps to be able to do what they do. The fact that they don't provide a better mechanism isn't a defense for the consequences of providing a poor mechanism. > Sure, you could probably make a /recovery, /system, and /data all different partitions, but now you are roughly doubling the amount of data on the disk for not much of a reason. That it's "not much of a reason" is very much your quite-subjective opinion. And there are better solutions than what you proposed here. And PCs already do this. But at this point you're changing the subject -- a reduction in space usage would not make your claim that "that's literally what disabling it does" any more true. It's simply false.
- Klathmon 8y ago
  Google provides a very limited set of tools for it, really only meant for devs of devices. By your line of reasoning Google has apps that don't work when rooted, so therefore they shouldn't allow it at all. And i'm not contradicting or refuting myself, there are (oversimplified) 2 system partitions on Android when setup this way. It's a tradeoff they made and you can read more about the pros and cons at [0]. This is getting a bit aggressive for my tastes so this is probably my last reply, but the point i was trying to make is that most of android is designed around the fact that /system is read only and doesn't change (which is also a nice security buffer), and /data is where all user data sits, and to "factory reset" they wipe /data and nothing else. It's absolutely a trade off to have /system do double duty like that, but one that I think most people are more than happy with as the most common complaint about the system is that people can't delete "system" apps entirely. And creating a 3rd copy of those apps on /recovery so they could be deleted from /system and /user isn't really "solving" the problem, just moving it back a little, while using up a LOT more space on the user's device. [0] https://source.android.com/devices/tech/ota/ab/ab_faqs https://source.android.com/devices/tech/ota/ab/ab_faqs

mehrdadn 8y ago

> Rooting isn't exactly using the system as designed. Rooting is very much using the system as designed. Google supports it and provides tools to enable it. Some apps on the Play Store require it. Does that mean everyone should root? No. Does this have any bearing on the fact that the recovery image should not be modified when rooting? No. > They even (ab)use this to make seamless updates by creating a second /system partition, writing the update to that, then swapping over on next restart. If something goes wrong, they swap back to the first system partition. If Google could provide a better way to root then this wouldn't be an issue. That they provide a suboptimal method isn't a defense here. > In a normal Android system /system is read only unless mounted otherwise (which only really happens during updates). I like how you contradict yourself in the span of 2 comments. First you said "Removing that app from the system partition won't give you more usable space without repartitioning", now you say that space is usable for installing updates. You just refuted your own point. > In this manner, the /system partition is NEVER written to outside of creation. In other manners, it IS written to outside of creation, and this is clearly due to the way they designed the system, not because modifying /system should actually alter the recovery image. > Rooting is literally sidestepping this entire process to take full control over the system and mount /system as writable. Yes, that's what it is, because it's necessary for some apps to be able to do what they do. The fact that they don't provide a better mechanism isn't a defense for the consequences of providing a poor mechanism. > Sure, you could probably make a /recovery, /system, and /data all different partitions, but now you are roughly doubling the amount of data on the disk for not much of a reason. That it's "not much of a reason" is very much your quite-subjective opinion. And there are better solutions than what you proposed here. And PCs already do this. But at this point you're changing the subject -- a reduction in space usage would not make your claim that "that's literally what disabling it does" any more true. It's simply false.

Klathmon 8y ago
Google provides a very limited set of tools for it, really only meant for devs of devices. By your line of reasoning Google has apps that don't work when rooted, so therefore they shouldn't allow it at all. And i'm not contradicting or refuting myself, there are (oversimplified) 2 system partitions on Android when setup this way. It's a tradeoff they made and you can read more about the pros and cons at [0]. This is getting a bit aggressive for my tastes so this is probably my last reply, but the point i was trying to make is that most of android is designed around the fact that /system is read only and doesn't change (which is also a nice security buffer), and /data is where all user data sits, and to "factory reset" they wipe /data and nothing else. It's absolutely a trade off to have /system do double duty like that, but one that I think most people are more than happy with as the most common complaint about the system is that people can't delete "system" apps entirely. And creating a 3rd copy of those apps on /recovery so they could be deleted from /system and /user isn't really "solving" the problem, just moving it back a little, while using up a LOT more space on the user's device. [0] https://source.android.com/devices/tech/ota/ab/ab_faqs https://source.android.com/devices/tech/ota/ab/ab_faqs