yashsingh1/xdaforums huggingface dataset:
[Android Software/Hacking General [Developers Only]] Crostantin:
really?? I am surprise !!!!

You mean that i haven't to charge one for month from 0% to 100% and etc.......

If it's true a lot stuff I red about Lithium batteries make sense.....maybe
[Android Software/Hacking General [Developers Only]] Wooaarr:
Most of the tweaks are useless, i totally agree!

Funny to see people "copy & paste" everything they see on the internet, just to "magically" make their phones faster...

Some interesting links regarding the topic:

First one...

Second one...

Take care
[Android Software/Hacking General [Developers Only]] Crostantin:
what about 3G fast dormancy??

the tweak should be:

ro.rill.fast.dormancy.rule=0

...your opinion??
[Android Software/Hacking General [Developers Only]] HTCDreamOn:
[MENTION=5016645]LaraCraft304[/MENTION] great guide, might want to mention the fact that those cyanogenmod specific changes can be found in performance settings anyway so although the build.prop lines would work, there is no need to use them.
[Android Software/Hacking General [Developers Only]] upndwn4par:
Your post looks eerily similar to Jeff Mixon's article.

http://www.jeffmixon.com/examining-build-prop-tweaks-for-android-ics-a-comprehensive-guide-part-1/

http://www.jeffmixon.com/examining-build-prop-tweaks-android-ics-comprehensive-guide-part-2/

And FYI, this is a Motorola build.prop tweak ("mot") that in fact works (or at least used to) on Motorola devices.

ro.mot.eri.losalert.delay
[Android Software/Hacking General [Developers Only]] thewaywardgeek013:
But not quite, as "pm.sleep_mode" was debunked at that blog post. Atleast here it is stated that it does something for Qualcomm/MSM Devices.

[MENTION=5016645]LaraCraft304[/MENTION] - Kudos to your work!
[Android Software/Hacking General [Developers Only]] Revontheus:
Does are only some "lines" some do really work like ones for ultra fast boot and deep sleep states

It depends on the device's chipset actually. It works on Qualcomms, Idk about exynos and nvidia
[Android Software/Hacking General [Developers Only]] Veliion:
How about the Killjoy mod pack?
[Android Software/Hacking General [Developers Only]] habitformer:
Haha..I've have that same debate for a while now with some friends. I agree 100% with you..But who am I a lowly Xda user with small thanks amount:)
[Android Software/Hacking General [Developers Only]] najodleglejszy:
yeah, I was surprised when I found out that lots of those tweaks were fake, I thought XDA folks knew better than that. I think the main reason people think they work is that to apply them you have to reboot your device, and EVERY device feels snappier after rebooting.
[Android Software/Hacking General [Developers Only]] cy56:
Please answer some of my questions related to build.prop and they are too many, can't be posted here. Located here: Please answer them!

http://xdaforums.com/showthread.php?p=76239
[Android Software/Hacking General [Developers Only]] Ryccardo:
Are you sure that the various APP_ADJ weren't implemented in Gingerbread? I remember seeing them in Samsung stock firmwares (although commented)...
[Android Software/Hacking General [Developers Only]] titooo7:
In my opinion this is one of the most useful informative threads I have seen in a while. :)

I hope now everybody will realise that they have to be careful when reading the list of features of so many blazing fast and buttery smooth roms.

A lot of users and rom chefs use those build.prop tweaks just because everybody use them and because they have read tons of times that it improves the battery life, performance, etcetera. But the truth is that none of them checked or proved if those lines make a difference, so it's good to see that someone made research to prove that some of the most famouse buildprop tweaks are placebo effect. :)

I personally always wanted to understand what those "tweaks" exactly do and check if there is some kind of documentation that proves that it works before applying those changes to my phone. I wouldn't be surprised if the list of placebo effect tweaks gets bigger!
[Android Software/Hacking General [Developers Only]] hillbeast:
Sad part is that despite the build.prop tweaks being disproved, or rather most of them, it won't stop people from trying. Its the same as the Entropy generator thing we saw a while back. All these tweaks are pointless as if there was something you could change in terms of performance or battery then Google or the OEMs would have done it already.

Edit: should mention that when I was doing custom ROMs, the only tweaks I used where ones to the VM which I spent many countless hours investigating whether it improved or not, and the home screen lock (back when it did something).
[Android Software/Hacking General [Developers Only]] titooo7:
+10000000
[Android Software/Hacking General [Developers Only]] mac20dnangel:
What About those that are in init.d folder? Do they work?
[Android Software/Hacking General [Developers Only]] _that:
Not necessarily. For example, you might want to sacrifice reliability for performance (disabling fsync in the kernel comes to my mind). Or balance performance and battery life differently.

And the placebo build.prop entries can be used to identify clueless "developers". :)
[Android Software/Hacking General [Developers Only]] hillbeast:
Yes but I'm referring to build.prop tweaks. There are of course plenty of tweaks that DO work. I know this because I used many of them back in the day. This is why my ROMs were regarded amongst the best on the Galaxy 3. I just thought them out before applying them.
[Android Software/Hacking General [Developers Only]] Lokifish Marz:
Not always. On a device now that many config files are a generic output with the generic entries intact. They even shipped it in root mode without su binary and super user and had to be told why this was a bad idea.

Granted, I'll admit that my stuff needs updating and cleaning, but the device in question is my first "want/need" device in over two years, the previous was running GB and I'm very time limited now.

[MENTION=5016645]LaraCraft304[/MENTION] You mention ro.media.enc* entries and the better solution being mediaprofiles xml. I would agree but in some cases you have to work with what you have or in the case of Mediatek devices, do not have.
[Android Software/Hacking General [Developers Only]] ShyPixie:
First, my thread is not based in blog posts or anything similar,it's not necessary...

Second, show me in the where you get this ro.mot.eri.losalert.delay (See? http://goo.gl/8y5Vfr)

I not based my scarving in proprietary softwares (This work NEED a source code) or arbitrary tweaks without fundamentals. This is not in any code on AOSP or CyanogenMod Source....
[Android Software/Hacking General [Developers Only]] upndwn4par:
As I mentioned before, that comes from Motorola (sorry, I don't have the time or the inclination to dig through my old Atrix files).

Just because something doesn't exist in AOSP doesn't mean it is not valid. OEMs add stuff all the time. And obviously this will only work on their device.

Here's an example that contradicts another item you posted. This comes from the build.prop of the 4.3 update we recently received for the S4. Do you think Samsung uses fake build.prop tweaks?

#
# System prop for capping scroll velocity
#
ro.max.fling_velocity=4000

Also remember that this one did exist in AOSP source, but not since Gingerbread:

ro.HOME_APP_ADJ
[Android Software/Hacking General [Developers Only]] Crazygrouzin:
What about operation killjoy?
[Android Software/Hacking General [Developers Only]] god_md5:
what about ro.config.low_mem in 4.4.1?
[Android Software/Hacking General [Developers Only]] BxMxK:
When the TF700T was still fairly new (around version 4.0.3 timeframe if memory serves) I ran across Jeff Mixons column regarding this same topic. Since the TF700 had input lag I decided to look into this specific one and managed to verify in a repeatable manner that it did in fact affect the max input events on that device but only to a certain extent.

Although I would love to be, I'm no expert in android source code or compiling my own custom ROMs, however, just now a 10 second search still finds this:

https://android.googlesource.com/pl.../java/com/android/server/wm/InputManager.java

which pulls that prop which was enough evidence at the time for me to quickly conduct some controlled experiments to see whether or not this build.prop tweak was actually doing anything.

see:

http://xdaforums.com/showpost.php?p=30281591&postcount=140

That being said... I just now tried adjusting it again with that tablet running TF700 CROMi-Xenogenesis 5.0.3 - 10.6.1.27.1/US DEODEX (4.2.1) and it has absolutely no affect whatsoever. It no longer caps the input limit. I would suggest putting a caveat in your OP stating exactly what versions you looked into lest this thread become filled with "what about xxx device running 4.0.1?" etc.

Or maybe a table? Everybody loves tables. I'm in the military and can attest to the fact that a well maintained spreadsheet can definitely make defending the world a much simpler task :) Would be nice to have a go to list of every known build prop and what device/ROM they are actually included in (wow... and ROM Devs could actually provide that information quite easily... ahh... the irony of it all)

I'm all for trimming the fat of mis-information that runs rampant on the internet
[Android Software/Hacking General [Developers Only]] memaro_maro:
why not we just ask our developers??

this build.prop tweak already in everywhere.. thousand of apps for tweaking, xposed installer modules, repositories...

:( i dont want to say anything.. just hoping this tweak still valid for kitkat...

galaxy nexus i9250
[Android Software/Hacking General [Developers Only]] Renton91:
What about the xBlast Tools build.prop tweaks of Xposed Framework?

Do they work for real or are they just a lot of nonsense code?
[Android Software/Hacking General [Developers Only]] ShyPixie:
This not is part of AOSP or CyanogenMod, works only on some samsung and htc devices.....

I not find this in source....
[Android Software/Hacking General [Developers Only]] RedSkyRoad:
Will these mods work on CM11?
[Android Software/Hacking General [Developers Only]] ShyPixie:
1) Disable boot animation -> debug.sf.nobootanimation

This is ok for AOSP and CyanogenMod, can be found here:

platform_frameworks_base/cmds/bootanimation/bootanimation_main.cpp (45:49)

char value[PROPERTY_VALUE_MAX];
property_get("debug.sf.nobootanimation", value, "0");
int noBootAnimation = atoi(value);
ALOGI_IF(noBootAnimation, "boot animation disabled");

2) Hide adb notification -> persist.adb.notify

This is ok for AOSP and CyanogenMod, can be found here:

Cyanogen: android_frameworks_base/services/java/com/android/server/usb/UsbDeviceManager.java (747:753)

if (mAdbEnabled && mConnected) {
if ("0".equals(SystemProperties.get("persist.adb.notify"))
|| Settings.Secure.getInt(mContext.getContentResolver(),
Settings.Secure.ADB_NOTIFY, 1) == 0)
return;

AOSP: android_frameworks_base/services/java/com/android/server/usb/UsbDeviceManager.java (714:715)

if (mAdbEnabled && mConnected) {
if ("0".equals(SystemProperties.get("persist.adb.notify"))) return;

3) Audio & video hack -> ro.media.enc*, ro.media.dec*, ro.media.panorama*

This changes some properties to try get a better quality... the values exists in source, but not always work as expected.

As I said in the original thread, a more elegant alternative would be to edit /system/etc/media_profiles.xml

4) Google Dns Hack -> net.rmnet0.dns* & net.dns*

This is ok for Wifi and 2G/3G conection with google dns (8.8.8.8, 8.8.4.4)

5) Wifi scan interval -> wifi.supplicant_scan_interval

This is ok for AOSP and CyanogenMod, can be found here:

android_external_wpa_supplicant/wpa_supplicant.c (2459:2460)

if (property_get("wifi.supplicant_scan_interval", scan_prop, "5") != 0) {
wpa_s->scan_interval = (int)strtol(scan_prop, &endp, 0);

6) Max events per sec -> windowsmgr.max_events_per_sec

This not exists in source.

------

I see the others soon ...

Yes, work. Can also be accessed through development menu.
[Android Software/Hacking General [Developers Only]] ShyPixie:
As I said, this feature does not work, was removed a long time ago. Here is the commit:

https://android.googlesource.com/pl...^1..62d1058cc972a8fcb7739547abd3298f5d98a9b1/
[Android Software/Hacking General [Developers Only]] DARKCHYLDX101:
Here's one for you Lara. I found a line in the Nexus 5 Kitkat 4.4.2 buildprop script that sets dalvik as the default runtime. I then put in the name of the lib that sets Art as default runtime. Works.

persist.sys.dalvik.vm.lib=libart.so
[Android Software/Hacking General [Developers Only]] yusopa:
Try this in aosp rom like mokee and slimkat for mega it works. But not work in cm on samsung mega.

From PEKAN with DROID
[Android Software/Hacking General [Developers Only]] DARKCHYLDX101:
It could be because the build prop sets dalvik as default which would conflict with the one that sets art as default?
[Android Software/Hacking General [Developers Only]] yusopa:
Thanks. Will check your opinion

From PEKAN with DROID
[Android Software/Hacking General [Developers Only]] reywal:
There really is such thing as SPOILER. lol!
[Android Software/Hacking General [Developers Only]] DARKCHYLDX101:
Might also want to check if all the files and libs that make art work are there too.
[Android Software/Hacking General [Developers Only]] zelendel:
If you check the portal there is a story about some of the latest commits to aosp that change this build prop line to set art as default in up coming android versions

Bat cave One
[Android Software/Hacking General [Developers Only]] yusopa:
True. I take note about that couple days ago. Thank bro

From PEKAN with DROID
[Android Software/Hacking General [Developers Only]] Renton91:
I found these other tweaks.

What can you tell me about them? Are they working or just other fakes?

Thanks :)

persist.sys.ui.hw=1

debug.egl.profiler=1

debug.egl.hw=1

debug.composition.type=c2d

debug.enabletr=true

debug.overlayui.enable=1

dev.pm.dyn_samplingrate=1

hw3d.force=1

hw2d.force=1

ro.config.disable.hw_accel=false

ro.fb.mode=1

ro.sf.compbypass.enable=0

ro.vold.umsdirtyratio=20

persist.sys.composition.type=c2d

dalvik.vm.execution-mode=int:jit

ro.config.hw_quickpoweron=true

net.tcp.buffersize.default=6144,87380,1048576,6144,87380,524288

net.tcp.buffersize.wifi=524288,1048576,2097152,524288,1048576,2097152

net.tcp.buffersize.umts=6144,87380,1048576,6144,87380,524288

net.tcp.buffersize.gprs=6144,87380,1048576,6144,87380,524288

net.tcp.buffersize.edge=6144,87380,524288,6144,16384,262144

net.tcp.buffersize.hspa=6144,87380,524288,6144,16384,262144

net.tcp.buffersize.hsdpa=6144,87380,1048576,6144,87380,1048576

media.stagefright.enable-player=true

media.stagefright.enable-meta=true

media.stagefright.enable-scan=true

media.stagefright.enable-http=true

media.stagefright.enable-record=true

persist.sys.NV_FPSLIMIT=60

persist.sys.NV_POWERMODE=1

persist.sys.NV_PROFVER=15

persist.sys.NV_STEREOCTRL=0

persist.sys.NV_STEREOSEPCHG=0

persist.sys.NV_STEREOSEP=20

debug.gr.numframebuffers=3

ro.min_pointer_dur=1
[Android Software/Hacking General [Developers Only]] isaak:
I have a samsung i9070 4.1.2, is there a concrete way to check android source related to my device only?

AOSP is a bit generic if there are different tweaks for different devices.
[Android Software/Hacking General [Developers Only]] yossi2010:
windowsmgr.max_events_per_sec used to do something m in GB.

When reduced under screen refresh rate it would cause touch events to be slower

Aka the touch would skip. When set to 10 it would scroll jumply 10 times a second when the finger is on screen.

Any value higher then 60 seemed to do nothing.

TESTED ON CM7.2!

Right now I have no idea why this line is Even in the build prop in cm11

As I tried to lower it and it does simply nothing.

It was in the code once.
[Android Software/Hacking General [Developers Only]] sudosurootdev:
I know this was started a long time back, but I'd like to comment on the topic. You have a valid point (in some cases). I always check the AOSP, CM, and Vanir sources (Vanir is what I build) for property_get in sources or all other forms for source code searching for build props. But, you must remember, vendor files, like shared object libs, may contain source code which look for props as well, such as ro.mot.eri.losalert.delay in Motorola vendor files. Also, a big one is that you must take into account that different devices use different kernel sources which may have property_get / property_set values. And many Google Apps may read and use them! I know ro.config.nocheckin does work. Use it and you have to re-enable it in Google Search settings. Some values are sent/received by radio transmission to/from Cell Carriers. Really, a lot that you listed in the first post, do for sure work. So, don't everyone remove them just cause you read it doesn't work. As long as it isn't something that does work, but will mess up your phone, it doesn't hurt for it to be in there. I add my own props in my code often for things I want done, then I just put it in build.prop to use.

1 quick example of an incorrect on you listed as false is dalvik.vm.verify-bytecode Here is PROOF:

property_get("dalvik.vm.verify-bytecode", propBuf, "");

if (strcmp(propBuf, "true") == 0) {

verifyJava = true;

} else if (strcmp(propBuf, "false") == 0) {

verifyJava = false;

} else {

/* bad value or not defined; use default */

}

if (verifyJava) {

kVerifyArg = "-Xverify:all";

kDexOptArg = "-Xdexopt:verified";

timeoutMult = 11;

} else {

kVerifyArg = "-Xverify:none";

//kDexOptArg = "-Xdexopt:all";

kDexOptArg = "-Xdexopt:verified";

timeoutMult = 7;

}

:good:
[Android Software/Hacking General [Developers Only]] _that:
True.

Unlikely, that would make the kernel dependent of a usermode program. On which device does the kernel have access to the Android properties?

True. In most cases, the names of used properties show up in the decompiled smali code, or by simply searching for strings in classes.dex.

I don't agree. If you change anything in software, you should always know what the intended effect is and verify that it has the intended effect.

From which file in which Android version is that code?
[Android Software/Hacking General [Developers Only]] sudosurootdev:
I agree that you should know what it does. What I meant was if a prop is supposed to speed up Internet or lower RAM usage (something simple/safe) but it isn't actually in source code, it does nothing... No harm. Some people are scared of the build.prop file. I used to be that way as well but I learned a ton by experimenting. Now I'm building from source daily, helping maintain G2 device repos and other source repos for VanirAOSP and the owner of kernel for those same devices. I just always kept a backup and a .tot file in case of errors.

https://android.googlesource.com/pl...ik/src/main/native/dalvik_system_TouchDex.cpp

Yes it is from Gingerbread, which is probably true for many... Came from some version. That should be specified... Not stating that it is false. It maybe in later versions also. Just haven't checked. I just ran a quick search on that as I knew I'd seen it in source somewhere.
[Android Software/Hacking General [Developers Only]] caspboy:
My ROM doesn't have a media_profiles.xml? But what it does have is a build.prop full of media.enc tweaks:

## Media
ro.media.enc.hprof.file.format=mp4
ro.media.enc.hprof.codec.vid=m4v
ro.media.enc.hprof.codec.aud=amrnb
ro.media.enc.hprof.vid.width=640
ro.media.enc.hprof.vid.height=480
ro.media.enc.hprof.vid.fps=24
ro.media.enc.hprof.aud.bps=12200
ro.media.enc.hprof.aud.hz=8000
ro.media.enc.hprof.aud.ch=1
ro.media.enc.hprof.duration=60
ro.media.enc.lprof.file.format=3gp
ro.media.enc.lprof.codec.vid=m4v
ro.media.enc.lprof.codec.aud=amrnb
ro.media.enc.lprof.vid.width=176
ro.media.enc.lprof.vid.height=144
ro.media.enc.lprof.vid.fps=15
ro.media.enc.lprof.vid.bps=256000
ro.media.enc.lprof.aud.bps=12200
ro.media.enc.lprof.aud.hz=8000
ro.media.enc.lprof.aud.ch=1
ro.media.enc.lprof.duration=30
ro.media.enc.file.format=3gp,mp4
ro.media.enc.vid.codec=m4v,h263
ro.media.enc.aud.codec=amrnb
ro.media.enc.vid.h264.width=
ro.media.enc.vid.h264.height=
ro.media.enc.vid.h264.bps=
ro.media.enc.vid.h264.fps=
ro.media.enc.vid.h263.width=176,640
ro.media.enc.vid.h263.height=144,480
ro.media.enc.vid.h263.bps=64000,1000000
ro.media.enc.vid.h263.fps=1,24
ro.media.enc.vid.m4v.width=176,640
ro.media.enc.vid.m4v.height=144,480
ro.media.enc.vid.m4v.bps=64000,2000000
ro.media.enc.vid.m4v.fps=1,24
ro.media.enc.aud.amrnb.bps=5525,12200
ro.media.enc.aud.amrnb.hz=8000,8000
ro.media.enc.aud.amrnb.ch=1,1
ro.media.enc.aud.aac.bps=
ro.media.enc.aud.aac.hz=
ro.media.enc.aud.aac.ch=
ro.media.dec.aud.wma.enabled=0
ro.media.dec.vid.wmv.enabled=0
ro.media.cam.preview.fps=0
ro.media.enc.jpeg.quality=90,80,70

Anyone got any ideas, btw my ROM is AOSP 2.2.2. Could i use a media_profiles.xml from another device and edit for mine?
[Android Software/Hacking General [Developers Only]] ShyPixie:
Do not worry about it, works well. Create a media_profiles in this case would be just a aesthetic change.
[Android Software/Hacking General [Developers Only]] ShyPixie:
Added some background info about XLOUD and ClearAudio on main thread
[Android Software/Hacking General [Developers Only]] Hamidreza2010:
Can i remove this invalid code from my custom rom?

my custom rom is 4.3 jb for sony xperia sp
[Android Software/Hacking General [Developers Only]] ShyPixie:
What?! Invalid code?! :eek:
[Android Software/Hacking General [Developers Only]] Sid_Sun:
For your 3G boosting

Brother I think 3G can be boosted if you disable data throttling from your services.jar file :)
[Android Software/Hacking General [Developers Only]] MT27i:
Well, How to do it? any guide btw?
[Android Software/Hacking General [Developers Only]] Sid_Sun:
Here is the link http://xdaforums.com/showthread.php?t=863923
[Android Software/Hacking General [Developers Only]] evildog1:
you haven't listed all build.prop tweaks. Can you please update your thread?
[Android Software/Hacking General [Developers Only]] _that:
Which new tweaks do you want to have debunked?
[Android Software/Hacking General [Developers Only]] _that:
Many of these are already mentioned in the first post. Please specify the ones that are not yet documented in this thread and about which you couldn't find any information by a quick Google and forum search.
[Android Software/Hacking General [Developers Only]] LazerL0rd:
Any debug.* tweaks can be set through Developer Settings.
[Android Software/Hacking General [Developers Only]] sharkie405:
Is "wifi.supplicant_scan_interval" still a valid tweak in Oreo? Does anyone know?
[Android Software/Hacking General [Developers Only]] alispeedsport:
Hi [MENTION=5016645]ShyPixie[/MENTION]

Thank you for great guide.

however is any good and correct build.prop tweak code for google stoke android 6 to up, on mt 6735 cipsets?

Thanks.
[Android Software/Hacking General [Developers Only]] Mscreams:
Which tweaks I should pick got Samsung touchwiz NN rom, for good ram, battery and speed management plz
[T-Mobile Samsung Galaxy S 4] omnifarious:
Its not possible to flash these files thru cwm, yet... Thanks to all those who tried to help.

Click here for MDL Modem Odin Flashable thanks to [MENTION=2651267]mrvirginia[/MENTION].

These are untested so I don't know if they work. If you're brave enough and don't mind odin flashing back to stock in case something goes wrong, here they are. * I am not responsible for anything that may occur other than the desired effect. *

The partitions are correct. modem.bin goes to the "mdm" partition ("/dev/block/mmcblk0p2") and NON-HLOS.bin > "apnhlos" ("/dev/block/mmcblk0p1"). According to GS4.pit (I believe) these are where the files go.

MK2_MODEM_signed.zip = modem.bin

MD5: FBFCF18A1A9F5C64F7EED6EF328D5680

MK2_WIFI_FIX_signed.zip = NON-HLOS.bin

MD5: 9D967E0B22AB14CCF58E7E18713B7C8C

Flash thru custom recovery. Let us know how it goes.

Thanks to user [MENTION=1823302]j_r0dd[/MENTION] for sharing with the community. ->> http://xdaforums.com/showpost.php?p=47865459&postcount=62