• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

For those having issues editing their build.prop in Marshmallow,or other system files

Search This thread

simms22

Recognized Contributor - R.I.P
Jun 4, 2009
34,055
25,931
BROOKLYN!
www.androidcommunity.com
As ive been reading about this very much lately, after people have flashed Marshmallow and rooted, many are having issues editing their build.prop files. And many arent having any issues at all. Well, the fix is rather easy. You are going to have to change your SElinux to be permissive. Many that arent having the issue is because they are either using a custom kernel that has set SElinux to be permissive, or are using an app to change it. I use an app, dir viper4, because it needs to gave SElinux at permissive. There arent any apps that do it in the play store, because google removed them. But.. theres a site called xda that somebody is posting their SElinux changer app in ;) http://forum.xda-developers.com/showthread.php?t=2524485
 

NLBeev

Senior Member
Jul 4, 2007
3,338
1,865
Scheveningen
About Google removing apps . . . . . . .security?
Just assuming . . . Google dev's have managers that puts them under pressure. . . Why. . .
1. Deals with telecom providers; demanding special factory images. Project Fi.
2. Ignoring many user requests; forcing encryption and forcing to use apps with text on white background.
3. Dark material removed since M-preview 3.
4. Use of RRO layers needs root access.
5. Deals with banks for Android Pay; not working when rooted.
6. Bloat. Built-in apps that should be in the play store.
7. Privacy. Services that can't be blocked.
8. Boot message device corrupt when it isn't.
 

doitright

Senior Member
Oct 31, 2014
1,512
861
First thing that comes to mind, is that you shouldn't EVER BE editing /system/build.prop. Its purpose is that it is generated by the build, hence "build".prop. If you need custom properties added to the system, use /data/local.prop.

Second thing is that most of the problems with system partition edits are NOT due to selinux problems. Most are because the factory sysimage bloats it absolutely FULL of crap. Delete some junk like google photos (which is a bloated pig).

Third, there is *absolutely no* reason to disable selinux. Just switch your context to one that matches the files you are trying to interact with. The su command has a parameter "--context" that lets you do this. Look it up.
 

ANDR01DN00B

Senior Member
Apr 30, 2013
1,629
785
Your downstairs basement
Just assuming . . . Google dev's have managers that puts them under pressure. . . Why. . .
1. Deals with telecom providers; demanding special factory images. Project Fi.
2. Ignoring many user requests; forcing encryption and forcing to use apps with text on white background.
3. Dark material removed since M-preview 3.
4. Use of RRO layers needs root access.
5. Deals with banks for Android Pay; not working when rooted.
6. Bloat. Built-in apps that should be in the play store.
7. Privacy. Services that can't be blocked.
8. Boot message device corrupt when it isn't.
There are many logical reasons, however.

1)ProjectFi actually NEEDS special factory images
2)Security
3)It was unstable and needs more work (they are improving it for future releases)
4)I'm actually not sure about this one... I agree with you
5)Security
6)They've remove most apps like PinyinIME and HindiIME from the system with 6.0
7)Security
8)Security
 

blueyes

Senior Member
124e31fc07b8d02073584cee3416bc80.jpg


Dang old security. Pha. Lol. Don't need permissive w viper. [emoji12]

Official Team Bliss Flo, Deb, v410 Maintainer

Sent from my Nexus 6 using Tapatalk
 

mrizvi66

Member
Mar 31, 2008
46
6
Princeton
if i make any changes to build.prop at reboot my phone just sits at the Google screen. Even after setting SElinux to be permissive.

Any other solutions???

I'm running MRA58k rooted with supersu v2.50
 

simms22

Recognized Contributor - R.I.P
Jun 4, 2009
34,055
25,931
BROOKLYN!
www.androidcommunity.com
yes, I made a backup. so i'm up and running.

all i tried to add was:

net.tethering.noprovisioning=true

i added it at the very bottom. i've done it before on lollipop and it worked before i'm not sure why it's not working now tho.

if you make any spelling errors or gramatical errors, or miss any spaces, your phone wont ever boot up.
 

MunkinDrunky

Senior Member
Feb 25, 2012
349
54
First thing that comes to mind, is that you shouldn't EVER BE editing /system/build.prop. Its purpose is that it is generated by the build, hence "build".prop. If you need custom properties added to the system, use /data/local.prop.

Second thing is that most of the problems with system partition edits are NOT due to selinux problems. Most are because the factory sysimage bloats it absolutely FULL of crap. Delete some junk like google photos (which is a bloated pig).

Third, there is *absolutely no* reason to disable selinux. Just switch your context to one that matches the files you are trying to interact with. The su command has a parameter "--context" that lets you do this. Look it up.


Great advice on local.prop. Did not know this before. Read up on it and sounds more useful especially when applying edits you dont want to re-enter after each flash.

(Take all this with caution) Good to note for others that local.prop is read after build.prop in boot up (hope i got that right), so you can use the same lines in build.prop in local.prop with changes in the values. Those values in local.prop will override those in build.prop! *except if the same line in build.prop begins with ro. "read only". **apparently the addition of qemu. in place of ro. in local.prop will override the build.prop line setting that had ro. at the beginning. Now does anyone know what qemu is exactly? Emulator? For hardware?
 
  • Like
Reactions: duttyend

doitright

Senior Member
Oct 31, 2014
1,512
861
Great advice on local.prop. Did not know this before. Read up on it and sounds more useful especially when applying edits you dont want to re-enter after each flash.

(Take all this with caution) Good to note for others that local.prop is read after build.prop in boot up (hope i got that right), so you can use the same lines in build.prop in local.prop with changes in the values. Those values in local.prop will override those in build.prop! *except if the same line in build.prop begins with ro. "read only". **apparently the addition of qemu. in place of ro. in local.prop will override the build.prop line setting that had ro. at the beginning. Now does anyone know what qemu is exactly? Emulator? For hardware?

qemu is the virtual machine infrastructure used for the android emulator. It is far more generic than for just the android emulator, but android does use it. The prefixes used imply a priority, and qemu (because of its association with the emulator for testing) is considered as for testing and development purposes, so it can, as you say, override.
 

Pecata

Senior Member
Dec 31, 2009
1,119
236
Salt Lake City
First thing that comes to mind, is that you shouldn't EVER BE editing /system/build.prop. Its purpose is that it is generated by the build, hence "build".prop. If you need custom properties added to the system, use /data/local.prop.

Second thing is that most of the problems with system partition edits are NOT due to selinux problems. Most are because the factory sysimage bloats it absolutely FULL of crap. Delete some junk like google photos (which is a bloated pig).

Third, there is *absolutely no* reason to disable selinux. Just switch your context to one that matches the files you are trying to interact with. The su command has a parameter "--context" that lets you do this. Look it up.

I am sorry if this is a stupid question but when you say data/local.prop-do you mean root/data/ or just data/ in internal memory?
and if I create local.prop and add the line qemu.hw.mainkeys=1 in local.prop would that be able to hide the navigation bar even if the I don't touch build.prop?
 
Last edited:

Top Liked Posts

  • There are no posts matching your filters.
  • 8
    As ive been reading about this very much lately, after people have flashed Marshmallow and rooted, many are having issues editing their build.prop files. And many arent having any issues at all. Well, the fix is rather easy. You are going to have to change your SElinux to be permissive. Many that arent having the issue is because they are either using a custom kernel that has set SElinux to be permissive, or are using an app to change it. I use an app, dir viper4, because it needs to gave SElinux at permissive. There arent any apps that do it in the play store, because google removed them. But.. theres a site called xda that somebody is posting their SElinux changer app in ;) http://forum.xda-developers.com/showthread.php?t=2524485
    5
    First thing that comes to mind, is that you shouldn't EVER BE editing /system/build.prop. Its purpose is that it is generated by the build, hence "build".prop. If you need custom properties added to the system, use /data/local.prop.

    Second thing is that most of the problems with system partition edits are NOT due to selinux problems. Most are because the factory sysimage bloats it absolutely FULL of crap. Delete some junk like google photos (which is a bloated pig).

    Third, there is *absolutely no* reason to disable selinux. Just switch your context to one that matches the files you are trying to interact with. The su command has a parameter "--context" that lets you do this. Look it up.
    3
    Great advice on local.prop. Did not know this before. Read up on it and sounds more useful especially when applying edits you dont want to re-enter after each flash.

    (Take all this with caution) Good to note for others that local.prop is read after build.prop in boot up (hope i got that right), so you can use the same lines in build.prop in local.prop with changes in the values. Those values in local.prop will override those in build.prop! *except if the same line in build.prop begins with ro. "read only". **apparently the addition of qemu. in place of ro. in local.prop will override the build.prop line setting that had ro. at the beginning. Now does anyone know what qemu is exactly? Emulator? For hardware?

    qemu is the virtual machine infrastructure used for the android emulator. It is far more generic than for just the android emulator, but android does use it. The prefixes used imply a priority, and qemu (because of its association with the emulator for testing) is considered as for testing and development purposes, so it can, as you say, override.
    2
    I am sorry if this is a stupid question but when you say data/local.prop-do you mean root/data/ or just data/ in internal memory?
    and if I create local.prop and add the line qemu.hw.mainkeys=1 in local.prop would that be able to hide the navigation bar even if the I don't touch build.prop?

    It does go in /data/ and you can simply make a new file, name it local.prop. Any lines you put in local.prop that are not in build.prop will be used just like in build prop. Any lines you put in local.prop that are in build.prop will take priority (so you dont have to change any lines in build.prop) unless the line in build.prop is ro. (read only). To circumvent this you will do as you suggest by adding qemu. if that line in build.prop starts with ro.
    1
    setenforce 0 don't work no mo on dat m?

    Sent from my Nexus 6 using Tapatalk