Shared publicly  - 
 
Next Android version AOSP: the breakage continues

(disclaimer: I've had a long day and I'm rather tired, apologies if this post isn't very coherent)

This is a continuation of https://plus.google.com/113517319477420052449/posts/ZtXAhw164QD , which was already a continuation of https://plus.google.com/+Chainfire/posts/Lyhjzu1z9s1 .

AOSP commits happen every day, including ones to the SELinux git.

As anyone watching the SELinux AOSP commits lately suspected would soon happen, some days ago we saw a commit limiting /system write access to the recovery context (no problem at all). It was also to be expected this recovery context would then be limited to actual recovery, and today we saw the commit of that change as well (boom).

What this comes down to meaning is that write access to /system is no longer going to be available on "rooted stock" from the Android version these commits are included in.

There are some cases where this can be worked around, and there are also cases where I do not see a (practical, generic) workaround right now. I'm still looking, but even if there is one, I would expect it to be patched soon. I actually have a feasable work-around, but it may have some side-effects, and I would be really surprised if this work-around is not fixed really soon, as the Android/SELinux guys are actually aware of the issue.

From a security standpoint, this brings more security, and is thus better. Unlike most of the other AOSP changes I've posted about lately though, this change does not just require devs to update their apps, it will also actively inconvenience root-app users.

What it will probably mean in practice is that apps that need to modify /system, will have to do so via a custom recovery like TWRP. This means a major headache for root app devs, as users use various custom recoveries, rarely update to the latest version of whichever recovery they are using (causing scripts to fail), and scripts are not easily made 100% compatible with all the recoveries out there (and some recoveries are even intentionally crippled). It's usually the app dev who gets blamed for these things.

For root app users it mostly means rebooting more often - though keep in mind far from all root apps require modifying /system.

Sadly, there are a handful of root apps I know of that will be made completely impossible (barring a hack for these limitation) by these changes, but most apps will just be more cumbersome to use, if they need changing at all.

Writing to /system can be re-enabled by custom kernels, but using those may not be wanted, viable, or even possible (the same goes for custom recoveries, of course). One thing is for sure: this is certainly not the time to be buying devices whose bootloaders cannot be unlocked!

Some root app devs may require you to be running a custom kernel dropping this restriction, or use a specific custom recovery. This is of course their right as the developer. The added complexity however does practically guarantee that you're going to lose some options in apps you can use on any random device.

It is unknown if these commits will be present in the upcoming Android version, or (as some have speculated) they will not show up in 'retail' Android until the version after that. They may still be reverted, changed, abandoned or replaced as well. I'm just reporting on what is in AOSP now. Keep in mind we are really close to 4.4.3 release, so it may be that none of the things I've written about AOSP from the past few weeks will be present in 4.4.3, and will only be in whatever comes after that. It's even possible they will never end up in Google builds, though that would create a strange disconnect in security between Google and AOSP builds.

If you're wondering if they're about done now making root apps more difficult and complex - I don't know the answer to that. But I do know I can imagine quite a few more things they could do in this area, so eventually they probably will.
600
113
Zacharie Loire's profile photoOlivier Jobert's profile photofranck deveaux's profile photojunaid abbas's profile photo
178 comments
 
Rest in peace:
- Xposed framework (and all the modules)
- titanium backup
- greenify
- root explorer
...
 
Time to switch to Oppo, i think.
 
The single worst thing they can do is flip the switch on dm-verity and start hashing /system. This has yet to happen in AOSP, but the specification has been sitting idle on their website for quite some time.
 
+Andrew Svet How is switching to Oppo the answer? Do they use some magical version of Android that is different from any and all others?
 
These changes either are not in 4.4.3 (which i am running), or do not impact in this way. Users really do not need to worry about these kinds of changes, only developers. They can be removed or worked around in most cases.

+Andrew Svet oppo pulls from the same sources as any oem

+Павел Тихонов these changes won't prevent any of those apps from working
 
Android is adopting the same way like Windows? OK, the right time and a market gap for another really open mobile OS. Is Google going to shoot itself to leg? I really hope for a proper Android fork compatible with play store.
+Android
 
Why Google, why? Android has this amazing community and Googles seems intent on destroying it for $$$... You have the biggest mobile OS on the planet so why do this?
 
Can't wait to the point rooting is made so difficult that it is not practical anymore. Security of course.
Chainfire
+
2
3
4
3
 
+Justin Case *If* they are in there, they impact in this way. If /system is still writable as normal, it just isn't in there. Probably that means it will not be in 4.4.3 'retail' either. 

I also disagree regarding users not worrying about these things - unlike the other changes I posted about, this particular change does affect end-users, and not just the devs.
 
Recently, CM enabled an option to flash the latest CM built recovery when you update the ROM. Could this be related to these changes going forward?
 
+Justin Case OK, i hope you are right. But they do lock Android more and more and it's drivin' me crazy.
Like, WTF: you take Linux kernel, which is open source, you build an amazing OS based on it, then you give it to community to play with. And then, when you stolen enough of ideas, you just start to fuckin' build barriers for community to not surpass them. Fuckin' Google is full of shit.
 
+Chainfire I enjoy these posts, I don't enjoy the uninformed commentors.

The problem is saying "next version of Android". These commits are to the current version of Android, and to AOSP, not to Google's master. There is no guarantee they are going to be put into Google's master (likely will), and most OEMs do not pull from AOSP. They pull from CAF or private access to Google's own source.

To the commentors:
This doesn't stop root, doesn't stop root apps. If you are one of the people threatening to switch platforms, please do so now.
 
+Andrew Svet 

Google hasn't locked Android at all anymore, its actually became more open over the past few years. I'm not sure how anyone with any understanding of what is going on could even say its getting more locked.

Everyone of these changes is a good thing, and is helpful to Android users.
 
Next thing you know Android will be as closed as iOS is
 
If Google don't want to lock anything, why the put flag on nexus phone? 
 
Flag when unlock bootloader. Is this made by google? What's the point of having a "flag" on nexus device? 
Chainfire
+
2
0
1
0
 
+Justin Case You are right of course, AOSP does not necessarily relate to actual 'retail' firmwares. I do try to point this out in every post I make on the subject... Anyway, I have changed the title as suggested.

On the subject of Android becoming more open, it depends on the area... API wise for instance, more and more functionality is disappearing behind closed doors, making it difficult to manage some things on non-GApps devices... It's not all pretty.
 
+Andrew Svet , +Jason Newman, +Giacomo Pegorer. Can someone explain to me how this is a money driven change? Root us an exploit , a secret hole. Sure it is way more often used for benign purposes but if used mallacoisly your entire devices is compromised everything you type, everything you see full access.

Android is an operating system, it is meant to be secure. Proactive changes like this are what prevent trivial error like an oem leaking a permission from compromise millions of users.
Yes we have an amazing Android Community and I love being a part of it but us powerl users are the 1% Google is looking out for the 99%. I think that's a good thing, If for whatever reason you need root or more control they offer nexus devices sure it may not be your dream phone but if you need root it's an option. Because again the majority does not need root 
 
+Kostas Kap Assuming you mean the flag that is set when the bootloader is unlocked, this is so that hte bootloader knows it is unlocked and should behave in an unlocked fashion.
 
+Justin Case Oh, really?
How about rooting SGS2 which i ran from device itself couple of years ago? It took two minutes. Today i need a lot more time and effort to do it. How about kernel devs who gave up? How about SELinux you can't disable or at least edit it's permissions? WTF it set to restricted? Vendor lock? Ok, Google, i will never buy your shit again, just like i did with M$.
I'm a long time Linux user and i like my devices to behave the way I want them to behave. If Google want me to do it their way, then fuck Google. There's always Nokia 3310 to make a call if i need.
 
+Aaron Gascoigne yeah, you're right, I was just speaking for my personal needs, I don't use my smartphone for work, I don't installa cracked apps, I use the smartphone for chatting and something like that so, IMO security is less important for me. But I'm not expert so feel free to correct me man.
 
Thanks for the knowledge. Enjoy reading these post 
 
+Justin Case ok, it's a king of off topic but related somehow. Now in my phone I have unlock the bootloader and then I remove the flag. My device now don't know how to behave? Cm on, it's a nexus device, it's supposed to be unlocked and rooted with custom recovery and a ton of tweaks etc 
 
+Aaron Gascoigne That's exactly the point. The sheep would buy anything just because it has more megapixels and looks better than previous model.
 
+Andrew Svet You can disable SELinux, and you can change the policies. Absolutely none of your post makes logical sense at all.
 
I believe jcase as a security expert and writing tons of exploits for numerous devices etc, etc and being employed in this exact field of mobile security. Granted I might just want to believe him as well
 
Looks like I may be staying on 4.4.2 or reverting back to 4.3.1
 
arrgg...well, so much for this Verizon Galaxy S5...time to pick a new toy that is unlockable!
 
+Павел Тихонов I don't see how this change will kill Xposed modules (which already require a reboot to get enabled), Titanium Backup (its primary functions don't write to /system and it can be reworked to do things in recovery that it does need to write), Greenify?

Root Explorer, sure, if you need to write to /system, and it's going to suck doing quick build.prop edits, but this is still not the end of the world. And you know custom ROMs will easily disable this change. It's clearly aimed at shipping ROMs and their security.
 
+Kostas Kap If you remove the flag, it will behave as locked until you unlock it again. This is intended behavior. If you want it unlocked, leave it unlocked, if you want it locked, lock it! As you say, unlockable (nexus) devices are about choice, this is one of those choices.
 
The fact that we need a custom ROM for root access will mean the majority of users won't have it, less users will use root apps, less development, less innovation... That's too bad. 
 
+Andrew Svet , the gs2 was never meant to be rooted.
The time to unlock and root a nexus 5 is the same it was on the nexus one. Go and explain what selinux is to your mother, I'll wait. Selinux is over the head of most users so it is not exposed to them, look at how many people get in trouble with permissions which are explained on plain English. If vendor locks are a issue for you some oems over developer devices.

Aosp works roughly out the box on nexus devices, if selinux or anything else Google does to core Android you are more than welcome to check out the source and modify it to suit your needs. 
 
People should really, start developing for Ubuntu.....
 
Incoming android fragmentation KitKat forever.#rootequalsfreedom
Liz Loz
 
Windows phone then ....
 
+Andrew Svet , I wouldn't call them sheep. I would call them consumers, for most a better camera or bigger screen are the reason they upgrade in the first place. I tend to take the developer view on things as well, but you need to remember all The people who just want a phone not to know how it works.
When you go tv shopping you don't check which vendor has contributed back to open source you buy based on size/picture quality/ cost etc.

They are numours devices that use the Linux kernel as a base and are not open source we are lucky goggle decided to share (arguably Android wouldn't be what it is today if it was closed source). 
 
I think a lot of users need to take a step back and consider the bigger picture.  +Justin Case or +Chainfire , please feel free to clarify if I'm also not getting it.

Consider the following analogy of your home. You have things going in and out but you have control of that for the most part.  You may even have an alarm system to deter people from trying to come in on their own.  But danged straight you ideally want to keep strict control of who comes in and out.

You have designed the house to be self-contained so that come what may you can survive.  But because all the control is in the house, someone on the inside can do a lot of damage.  Did I mention you also have a basement vault full of treasures beyond riches?

You can do a lot with that house but the issue always comes down to what is allowed to do things and where.  You probably wouldn't put the combination or code to the vault on a sticky note and then place it in the restroom where even guests could see it.  So I allow folks in some rooms of the house and others I just flat out say no unless you're escorted by me.  Or if you really want to you can say to heck with that and do whatever you want.

From a security perspective that's what Android faces by more openly allowing root for the sake of us who use it.  Remember what that gets access to do, and what it could do in the wrong hands. Root apps that don't really need it but were doing it as "the simplest route from A to B" will have to finally make it work the way it should in a secure environment.  Those apps that will need it to function will then either have to find a way that follows the new rules, limit themselves to instances that do not require the new rules (don't know if SELinux Permissive would allow in this instance, might have to be disabled, maybe someone can answer that.)

My bigger question to users who immediately rush to condemn this: do you fully realize yet what most people have on those devices?  For many it's a treasure trove of personal information and data that when used maliciously could wreak havoc on your life.  We should want that protected by default and for those of us who want, actively decide to go a different route.  It shouldn't be the other way around.. unless you already post all your account logins, numbers, transactions, messages, etc. in the public space for all to see and use.
 
+Nigel Hall You are right, sometimes I am a dick, in continuing that tradition, just know this cocky dick is right in this instance.
 
+Garwynn XDA but what Google is trying to do is making it harder to gain root access to those who want root access. It is as hard as it was before for apps that don't have root to steal data, so what it the point of all this? Please someone explain. 
 
Entertaining. It would seem to me that this would only impact stock-rooted users. Am I wrong?
 
+Jose Angel Galvez , it's a proactive measure as heart blead has shown critical security flaws can lay dormant for years. It's more of a in case we screw up we don't shoot ourselves in the foot kind of thing.

If you study root exploits over the years the way of gaining access is primarily a mistake on the original developer (devs are human to). So Google is trying to mitigate that risk. 
 
+Justin Case ya I know, but I already disagreed on dickishness thought :p

PS anologies are terrible. 1) this is not like that 2) seriously, this is not like that. Stop using anologies.
 
+Jose Angel Galvez The issue is not for apps that don't have root but what does.  If you work for a company and have classified materials you are only supposed to have access to the materials you need and that is it.  That's not how root works right now in Android - once you're in you have free reign, and that's concerning from a security standpoint.

I don't think anyone's talking about it going away and never coming back.  It's just going to be harder to get and you will have to choose to do it, which if a manufacturer decides they want to lock it down and not allow it - then that's their choice.  You have an equal choice to find one that doesn't and I'm sure there will always be versions available that will allow that (like Samsung developer edition phones).  Not always the cheapest or easiest, but doable.
 
+michael hopper Right. For the majority of users that use Android straight out of the box... they probably won't notice it.  And that's what this is about, protecting the many while balancing it with what the few want.
 
Android has greatly matured thanks to many ideas borrowed from the Dev community and for that I am thankful. But I have given in to the stock experience on a mature OS with low hanging modifications and customizations to make it my own.

I have found great freedom from simply deciding to no longer root my phones. No longer load custom ROMS.

I spent way too many years crack flashing ROMs and somehow justifying to myself that I was better off for it. I think for a long time I was, but a maturing OS that has absorbed so many ideas from the Dev community has left me quite content with a stock experience.


 
FYI: I actually have a feasable work-around, but it may have some side-effects, and I would be really surprised if this work-around is not fixed really soon, as the Android/SELinux guys are actually aware of the issue.
 
In different views, I feel a little bit safe imagining an Android more secure. But in the end I really hope that devs can discover gaps to keep developing great root apps.
#hope 🙏 
 
It would be great if someone could point me to a link with information why I'm able to gain rw access to /system on omni but not while on cyanogen. And how to overcome this...
 
Thanks +Chainfire +Justin Case for take time to clarify this. Please don't feed the trolls. You guys are a lot of levels up than trolls. And noobs like me. Thanks again.
 
How hard would it be to flip SELinux into permissive mode to make required changes, then back again? Sort of like unlocking the bootloader to install a new one, then re-locking for a bit more security?
John A.
+
3
4
3
 
As long as root access allows me to block ads and do stuff like the Xposed framework modules I'll still be happy. I think a lot of commenters have no idea of what they're talking about or what is really going on. I think many root users have some kind of elite status thinking going on. I do not know for sure if these new policies will affect ad blocking and custom frameworks but I really hope they don't. That will seriously make me consider changing os'es sooner than later. I doubt root explorer and titanium backup will be affected. Perhaps some of the more advanced feature of titanium, but all I need is backup of the apk's in case I download an update that breaks something. I also hope greenify isn't broken, but heck, even though I use greenify I really haven't kept up or tested to see if it keeps some things tame that used to be wild. Android has gotten a lot better in that respect even when an app developer has written a poor app. I am all for more security. Android really has the backbone to be more secure than ios. Google and company really need to implement some more stuff that is easily user friendly or easily implemented with you can turn it on or off switch if you want. I just hope Google doesn't backdoor the 1% community that has helped android so much and just break it to the point where it's no fun or locked down to a dummy level like iOS is. Samsung for one needs to be kicked in the balls for not letting us encrypt our phones because we trip Knox rooting. That's just basic. Let's just hope Google balance everything for the small minority and keeping it simple for the minority and majority.
 
Hey +Chainfire that's why we have you and rely on you. You are the one that always seems to work it out in the end, keep up the great work and thanks for always keeping us in the know!
 
But lack of titanium backup? Google should maybe create thier own proper backup solutions then with full system images and stuff
 
What is device administrator?
 
People really need to read what jcase is saying here. This is only a problem if a) your bootloader is locked and/or b) you are running a stock kernel. This likely won't affect anyone in any meaningful way right now.
 
+Garwynn XDA Remember that Android is Linux-based.  If I type in "su root" in a terminal in just about any Linux distro and enter the root password, I'm in as the root user then and (should) be able to do anything I damn well please with the system at that point.  Including stuff that could potentially render it inoperable, if I don't know what I'm doing.  Understandably, that's not desirable from a security/enterprise perspective, but that's what having root access means.  Same thing with Android, that's why it's called "rooting."  Because you're essentially letting yourself issue commands (either through a GUI or terminal) as the root user.

Also, the "Developer Edition" phones actually come because carriers (Verizon and AT&T) go even farther than Samsung does to block root and bootloader unlocking.
 
+Braden Farmer but still we shud have a official non root backup method in android...like most other advanced OS
 
I always buy Nexus, and I always unlock and root.

I run rooted stock, but I'll ROM in a flash (pun intended) if I can't remount /system when I feel like it.
 
In a way yes, it is possible.  I'm not an expert with Linux, but I'm pretty sure similar policies could be possible with Linux.
 
+Gregory Wicklund - But consumer desktops don't usually ship with Linux... and nobody who knows how to install Linux would install a distro that was so crippled as to prevent the root account from managing the system.
 
+Garwynn XDA SElinux is a role based framework, and not a user based framework, per se. And I most certainly have locked my root user down, back when I was learning it, in the early days. 
 
Honestly though, +Chainfire's been like the angel of death, wrt keeping us updated on the root front. I keep feeling more and more depressed with every single update. 
 
Gotta love the knee-jerk reactions here, which often make exactly the same assumptions I would have made (and still tend to make) had I not learned from experience to wait until authorities on the subject weighed in ( +Justin Case for example).
 
+Jeff McIntire Dude, in the beginning, I was saying "so what". Now I'm going to really start paying more attention to the contexts being pushed to the AOSP mainline trunk. 
 
Of course I assumed right away that the first thing many custom ROM developers would do is bypass this security feature, though it could come at a cost to users of such ROMs as security breaches continue growing in number and in nastiness. 
 
As far as ads are concerned, the added security should help block adware and spyware, which lead to ads popping up many times more than what they serve up at Mountain View.
 
The real revenue stream Google is looking for is not more ads, but more interest from enterprise customers as Blackberry slips further into irrelevance and competition from the likes of Apple and Microsoft intensifies in this lucrative market.
 
I'm not concerned about custom ROM's. I'm concerned about exploiting stock devices, with bootloaders that can't necessarily be unlocked all that easily, +Jeff McIntire. 
 
There's a reason I only run cm, tbh. 
 
+Matt Eskes in that case, this news should actually be encouraging to you (by the way, bootloader unlocks affect the /boot partition as opposed to the /system partition iirc). The changes Google is making resemble Samsung's efforts to court enterprise customers with Knox. These are good developments from my point of view.
 
Oh, security by any name is a good thing(tm). However, in this case, it's king of a double edged sword, because you do have the guys who like things like xposed framework on stock ROM's, etc... Those are other guys who have to worry about this. 
 
Tbh, I don't use root all that much, even though I run custom. 
 
+Matt Eskes im confident this restriction will cause no issue. I know I can produce a work around for it in a few minutes for most devices on stock roms. Being the craptastic programmer I am, I am sure a more capable can do it in even shorter time.
 
You make a good case for leaving Android behind
 
Meh I dont really care. There is a loophole for everything(same goes for Knox, just gonna have to dig harder) so I think next version of Android we would be still having root and would be laughing that we thought that there will be no root.
 
R.I.P all the good apps that we could use b4...
 
Open source doesn't mean open to security related stuff also. As the OEMs try various security assurance ways like the latest KNOX, we cannot be surprised if Google is trying to make AOSP more secure as questions always arise on how secure our "Smartphone" is. +Chainfire , When you are here, i don't think people won't know how to find ways to get into system without compromising on security. :D
 
+Artem Russakovskii Xposed and its modules are being installed to the /system partition on the fly

Titanium backup needs root permission to function at all (and Helium also, BTW) and it needs access to /system so that you could freeze, disable, delete and backup system applications

Greenify also needs root access and an ability to write to /system if you want to greenify some system apps you don't use or need (mainly this applies to OEM bloat)

Root explorer is obvious, yeah. It's main feature is to browse around every possible partition, folder and file if the OS. Same applies to any other file manager that can get root permissions (File Explorer, ES Explorer, X-Plore, ...)
 
The main concern is about gaining share in enterprise usage. Android is not doing good in this case. Also this will prevent those dumb users away from rooting their phone. 
 
+Павел Тихонов You're confusing root functions such as reading and executing with writing. Only write to /system while booted may be going away. Reading and executing as root still remains as before.

And writing will still be possible, just with a reboot, which most of the apps would be able to work around. 
 
I need to buy a oppo. What do the developers think out there. I'm have reboot issues this week with my rooted t-mobile note 3. I can unstall wanan. But my heart breaks over titanium backup.
 
+Chainfire is this the reason why i cant change com/port settings when im trying to reflash stock G2 software... if so is there a way around it. My computer says i need permission/write privileges to access these settings 
 
The more I look at Google it is THE instrument of implementation of totally controlled society. Those creeps will not stop at anything...
 
For the record: Xposed only needs to write to /system for the (un)installation of the framework. And it has offered installation via recovery since version 2.5, released two months ago.

Installing/enabling modules does NOT require write access to /system. A reboot is only required because modules need to be loaded during startup to work properly.

That said, I do expect issues with SELinux. It totally makes sense because things like root apps and Xposed allow you to go beyond the limits defined by the system, which is exactly what SELinux is designed to prevent. Any way to circumvent these restrictions means that there is a hole in the policy that will eventually be fixed. Actually, there already are some conflicts, but ironically they are not showing up on most ROMs because the security context gets lost when the installer replaces app_process.

The main issue will be that the framework and modules (running in various different processes) need to access configuration files, which at the same time need to be writable by the installer/the module's UI. Usually, these files are stored in /data/data/<pgk>, which seems to be restricted by the AOSP policies. Using other locations need more effort and might end up being restricted as well.

I'm wondering whether the installer (or any other app) would be allowed to chcon its configuration files to some context that allows wider access. If that works, how are the chances that the context gets reset frequently (e.g. on the next reboot)? Would it be possible to for apps to add their own rules to the policy to allow more access on their own files?

Any advise (except for "simply disable SELinux") is very welcome!
 
I can't see this actually happening. Or it will become: Google, The other fruit....
 
+Tom Gralith  Dont blame google, they are victims of their own success, the establishment is forcing them to cooperate and makes it illegal for google to even mention it. The people of the USA voted for this, and they can vote it out.
 
+Wan Dera oh well, the old game of victimhood 'we were just doing what we were told' - + people may not have the choice to vote google out. Times are changing indeed, and very fast.
Translate
 
Might as well change the name from Google to Apple. 
 
Es hört sich nicht gut aus ohne das was einmal war und heute auf morgen nicht mehr da sein scheisse ..es muss eine möglichkeit sein vielleicht nicht jetzt oder morgen aber irgend wann kommt das gute wieder .Root muss haven ...
Translate
 
At least android is still more open source than iOS well slightly:)
 
+Logan Seitz iOS isn't open source AT ALL, and android is 100% open source, developers can see the sources used for the builds, and that's how we knew about the stuff chainfire posted. More limited for the average user yes, but still open source
 
+Dan Larruso only making it difficult for those that refuse to read and actually understand what is going on. They are historically making it more open. We have a greater % of unlockable devices now, than 3 years ago.
 
+Chainfire is there a way you can create a fix for us LG G2 (vs980) Verizon with a GPS fix? Nothing seems to work
 
Yes, such changes make it harder to manipulate Android. That's the whole point of SELinux. Quite often, security measures make your life harder. Still, you set a password on your PC (if it might be accessible for others) and lock your door (unless you live several miles from civilization). If you occasionally install apps on your smartphone, then it makes sense to secure it from the risk of unwanted manipulations. Obviously, we would still like to use the "good" manipulations, but there is no technical difference between good and bad manipulations. If you leave a back-door open for the good stuff, then an attacker could use it as well. You wouldn't leave a key next to the door, or a button to skip the password prompt, even though that would make it more convenient for you.

And that's why unlockable devices do make a big difference. If you feel the need to make an exception from "security by default", you can flash a different ROM/kernel and just do it. This procedure is outside of the system to be protected. Just like you could give a friend an extra key, or use a fingerprint scanner to give you access to your computer.
I don't think there is a safe way to allow adding such exceptions inside the system.
 
+anyone......does someone know where 4.4.3 came from? I saw a post of someone using it. How? Very interesting! Anyone????
 
I am new in Andriod world I have rooted my Galaxy Grand Duos now is there any possibility of upgrading to Kitkat
 
Must be+Jeremy Meiss. Must have got bummed when he found out he couldn't make it to the Justin bieber concert 
 
Well considering you will find most of your answers (and admittedly those that aren't your answers, you know, just like any other Internet community) on XDA, I would say that statement is correct. 
 
+Brandon Nguyen and XDA didn't have his answers on how to get tickets at the last minute. Neither did Rootz, and all the other Android communities out there. But, you know, let's just throw XDA under the bus. :-D 
 
If android breaks then let's try Tizen if Sammy goes to that path
 
+Dan Larruso From a software stand point, android is GETTING EASIER to work with, more open, and better documented. I'm not really sure what experience you are drawing on, but I'm speaking from the professional experience of working on Android, specifically security, full time. Not copying pasting roms for kids to play with.

Also, using "retard" as an insult, just makes you look ignorant.
 
Who can tell us where (aside from XDA and its flaming tween trolls and kang-tastic copycats) you can get a development community for the Galaxy Grand Duos? If you know of such a site other than XDA you probably need to get out more 😋

tl;dr - XDA is the only site I'm aware of that can help someone take full advantage of a rooted Galaxy Grand Duos 😉
 
+Jason Baker that was me, no not very interesting actually. Just another minor bump.
 
Saying XDA is full of assholes is like saying New York State sucks because you ran into some dickheads on 7th Ave in Manhattan.
 
I can't help but laugh at the irony of complaining about the attitudes of certain XDA users while manifesting the exact same attitudes in this G+ thread 😆
 
"What it will probably mean in practice is that apps that need to modify /system, will have to do so via a custom recovery like TWRP. This means a major headache for root app devs, as users use various custom recoveries, rarely update to the latest version of whichever recovery they are using (causing scripts to fail), and scripts are not easily made 100% compatible with all the recoveries out there (and some recoveries are even intentionally crippled). It's usually the app dev who gets blamed for these things."

From the standpoint of a root app developer, the two most important items are:

1) Ensuring that whenever possible, daemonsu starts up from a context that isn't subject to the new SELinux restrictions.  This probably requires a custom initrd (boot image), which is not great, but the alternative (TWRP) also requires an unlocked bootloader.

2) If #1 isn't possible on a given device, "su" should have a standard way to report its capabilities back to the app, so the app knows it is dealing with a root shell that is crippled in some way.  "su" should assume that old apps that aren't aware of the SELinux restrictions will fail; in this case it should deny root access so that they abort in a predictable manner.  Maybe new SELinux-tolerant apps should invoke "su --restricted" to indicate that they can operate correctly without write access to /system, or execute access to /data, etc.

To help with #1, maybe somebody could write a clever recovery script that unpacks your boot.img to modify the init.rc and *_contexts files, then saves a backup and writes out a new image.  Feature request: it would be great if this also unconditionally enabled /system/etc/init.d support.
 
Bundle of thanks for reply and suggestion :)
 
+Dan Larruso wow! Nothing else to do but curse people out for they're opinions? If you've had a bad experience then fine... But don't be a fuckin douche bag. Tell you what...when you get your helmet, let me know and I'll get ya some cool stickers....you fuck! Keep you're dumb ass comments to yourself. There's no place for people like you here. Grow the fuck up dude. For real....bahaha...little girl
 
+Justin Case thanks bro. I was wondering. I'd still love to check 4.4.3 out! I just like trying new things. Thanks for the input brother
 
Well... we are almost back to the stone age of closed-source bricks (however this time there is a lot of malware installed and battery lasts 1 day).
 
I think humankind has finally figured out that time (actually, attention) really is money.  That's what we're productive with, and that's the direction in which our thoughts continue.  That said, adblocking, if you agreed to accepting the ads, really is theft.  (Yeah, I do it anyway.  If I like the app, I turn it off and click on one or more, which is most of the apps I keep.)

Now that our phones are the gateway (via text/phone number  or Google Authenticator/IMEI, for now) to our cloud data, and also being used for corporate purposes and by government officials....  Well, lets just say men in suits aren't always as smart as they look.  This isn't just security for the masses (unless you change perspective and count everyone's Target transactions).

The part of this that really pisses me off is that, like styli, new hardware will be released, and I'll have to choose between it, with its stock closed-source code, and making one gadget do what this other one does with just a couple of tweaks. It ends up eating the reason I liked Android so much in the first place, it brought real tools to less-developed countries (and less-monied folk like me).  And there's the problem, less-developed countries are out-of-control.  Really.  They are ungoverned, and hungry.

So, if it's harder for us mostly-innocents to crack, it's harder for a Central African thief to crack, or worse.  I don't think Google is trying to piss developers off, but I imagine they have a better view of the bigger repercussions of leaving things as open as they've been.
 
I did a Google seach and came across this thread.
I hope it's the appropriate place to get some help.

I used Mobile Odin on my N5100 to update to N5100XXDND8 - and now - no wifi (seems to be a "bootloader" issue of some sort from what I've read),

I tried emailing (market1@chainfire.eu) 3 times - no answer.
Is there an N5100XXDND8 fix (bootloader or otherwise) available (I'm DYIN" w/o WiFi)!
 
+Kevin Cernekee I think it's a little early to simply "break every app that doesn't advertise it is compatible". There are a lot of root apps out there that will not break, even with these changes (though I admit I haven't tested actual 4.4.3 release yet to see what is and isn't in there - probably none of it, until next release).

Context-wise, su always runs as u:r:init:s0. Custom boot images will not be viable in a number of situations. Not a minor reason is users crying about it breaking OTA capabilities.

As for that script, it's one of the first things that was added to my to-do list after all this. However, this is all not a solution for every firmware. Neither is disabling SELinux completely or dropping it to permissive mode (as some have suggested).

At least it seems we have some months left 'til next Android release before these all become major issues, so there's still ample time to discuss and test.
 
Android 4.4.3 is finally here. Has anyone tried to root their new devices?
 
My smg900m have an upgrade and now I lost the root :( 
 
1.99r4 does not work with the moto x 4.4.3 update on the developer edition. I flash the zip and the supersu app doesn't show up. But then I install from play store and su works?
 
The "truth" behind this is that Google is dealing with our information and behavior. And there are root apps that breaks their point of view.
-titanium backup: allows to transfer a special offer (such as appoftheday) to your new device.
-xprivacy: removes permissions that apps do not require but have got it to sell it.
-custom recovery: the best way to keep safe your data (backup)
and a long so on

Today* Google inhibit the root capacity and the recovery, tomorrow we need a free or feed Google Drive's plan to save our app data and they will read it wirhout punishment nor people knowledge.

Im exaggerate this, but what about the new permissions notice and the hidden internet permission? (for google analytics obviously)
 
Selinux is a stupidly security enforcement with the actual storage system. Specialy extSdCard, that Google do not want. A storage change that improves chrooting, a proxy that allows custom rules (even selinux rules) to each app and file stored in device, and which we could manage. This should be the first step.
 
Si puedes leer esto..te agradeseria si me ayudas a rootear mi samsung galaxy tab 3 probe de las mil maneras y no pasa nada...
Translate
 
Going over to the lg g3 it's been a ball going to miss your work bud!
 
I'm happy for owner (be they individual or corporation) to enable locked systems as they see fit, but by same token owners who do not want their system locked should be able to disable it.

The argument that phones and tablets must be locked systems that owners can't disable for security rings hollow when laptops with 3g capabilities are used within corporate environment. They are secured by software / hardware controlled by the corporate owner, as phones and tablets could also be.

I suspect it has more to do with third party access payments to distribute bloatware and advertising on these systems, and manufacturers are protecting this revenue stream by preventing users blocking/removing it.

That is a valid commercial decision if it is used to subside the cost of the device, but you should also be able to buy the 'unlocked' version for an appropriate premium on which you can do what you like (just like your personal computer).
 
+Chainfire , hey, was referred to you by my bro. I got a micromax canvas turbo A250 model and lookin to root it, boost it. Not sure if half the stuff works, was told you alone, to be checked with before thinking for rooting.

Need help to know how to get the rooting, rom setup done. Guide me..
 
From Captain of the Federal Reserve please pay if using Pos system at stores and or Atm systems the 2 U.S. and or 3 U.N. payments around the world$ !2,001 12 and under $31,999. 13 and older pays for medical insurance and the $50. every other week plus inflation 1776,$250,000. unsecured revolving line of credit 0% intrest $10,000. death ins. no payments past due, banks get 1% from Tarriff revenue to provide and 1% credit on payments from Tarriff revenue all payments go to the General Treasury,$245./ month cash $245. / month food stamps $500,000.unsecured revolving line of credit $10,000. death ins.0% intrest no payments ever considered past due,PAY now due at 10 days of age TL. 
Add a comment...