• 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

MunkinDrunky

Senior Member
Feb 25, 2012
349
54
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.
 
  • Like
Reactions: duttyend and Pecata

MunkinDrunky

Senior Member
Feb 25, 2012
349
54
Now that I am on stock rooted M, mra58r rooted via chainfire method (his kernel+beta SU)(not the systemless one), it seems that lines local.prop are not taking effect. For example: persist.debug.wfd.enable=1 which after testing in build.prop works just fine.

1) tried local.prop with the added line, fixed permissions (I made them the same as all .prop files I saw have), rebooted, but the effects never showed(no miracast).
2)deleted local.prop, added the same line in build.prop, reboot and voilà effect takes and my miracast screen mirroring works per usual.
3)delete the line in build.prop, reboot, create local prop again, fix permissions reboot, and mirroring all gone :(

Is there new something new about M that is different enough from lollipop so that local.prop in /data/ doesn't work anymore?

Edit: note this isn't quite the same question as OP. My edits to build.prop work great but local.prop doesnt. Plus as described I should be selinux enforcing still.
 
Last edited:
  • Like
Reactions: birdie

birdie

Senior Member
Nov 25, 2012
306
110
Vatican
Now that I am on stock rooted M, mra58r rooted via chainfire method (his kernel+beta SU)(not the systemless one), it seems that lines local.prop are not taking effect. For example: persist.debug.wfd.enable=1 which after testing in build.prop works just fine.

1) tried local.prop with the added line, fixed permissions (I made them the same as all .prop files I saw have), rebooted, but the effects never showed(no miracast).
2)deleted local.prop, added the same line in build.prop, reboot and voilà effect takes and my miracast screen mirroring works per usual.
3)delete the line in build.prop, reboot, create local prop again, fix permissions reboot, and mirroring all gone :(

Is there new something new about M that is different enough from lollipop so that local.prop in /data/ doesn't work anymore?

Edit: note this isn't quite the same question as OP. My edits to build.prop work great but local.prop doesnt. Plus as described I should be selinux enforcing still.
I can confirm that this option (persist.debug.wfd.enable=1) has no effect when being added via /data/local.prop. I'm now trying to find anything in Marshmallow documentation which pertains to this file.
 
Last edited:

rspear

Senior Member
Mar 3, 2012
82
5
I'm on marshmallow. Tried local.prop and the app to set permissive and nothing works like it did in lollipop.
I just want the stupid navbar buttons gone.
 
  • Like
Reactions: simms22

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