Do build.prop tweaks actually work? - A guide - XPERIA X8 General

While searching deeper into build.prop tweaks, I came across this article. It was originally posted in Jeff Mixon's blog. At the moment the whole site is inaccessible, so it probably is a good idea to have it in full here (thanks to Google cache).
While its focused on ICS, some of the points made are aplicable to GingerBread too.
Examining build.prop tweaks for Android ICS: A comprehensive guide
(from: http://www.jeffmixon.com/examining-build-prop-tweaks-for-android-ics-a-comprehensive-guide-part-1/)
Android devices are great. They can easily be hacked and tweaked to seemingly no end. There’s a lot of great info out there detailing step-by-step instructions on how to perform various enhancements to your particular device. Unfortunately, there is also a fair amount of misinformation being disseminated via forums and blogs that can have a very negative effect on your device. Just because you can change something doesn’t necessarily mean you should. In this guide, I will walk through various common Android build.prop settings and evaluate whether or not you should actually change them on your Android ICS device, MythBusters style.
windowsmgr.max_events_per_sec – BUSTED
As the name implies, this property specifies how quickly the system is allowed to process certain events before throttling occurs. Specifically, this property is used by the InputDispatcher when processing screen touch and movement events. This value will really only come in to play with extremely rapid touch events, such as swiping or scrolling. The default value for this property is 90, and Google explains why:
Code:
// This number equates to the refresh rate * 1.5. The rate should be at least
// equal to the screen refresh rate. We increase the rate by 50% to compensate for
// the discontinuity between the actual rate that events come in at (they do
// not necessarily come in constantly and are not handled synchronously).
// Ideally, we would use Display.getRefreshRate(), but as this does not necessarily
// return a sensible result, we use '60' as our default assumed refresh rate.
result = 90;
Many build.prop tweaks set this value to 300, but it seems this is a bad idea. As Google points out, Android maxes out at 60fps. The default value is already allow for a possible max_events_per_sec of 90. Even if you allow for 300 max_events_per_sec, you’ll only ever see 60 of these events in any given second. Therefore, any value much higher than 90 is unlikely to have any noticeable impact on your experience in general. Additionally, setting this value too high can starve other UI events that need to get processed, viz. touch inputs. You’re not likely to feel like your device is running very smoothly when it is busy processing thousands of scroll events instead of responding immediately to you clicking to try and open a link or an app. There may be some specific scenarios where increasing this value does appear to improve system feedback, but changing this value for all UI events across the board will likely cause more problems than it will solve.
dalvik.vm.heapgrowthlimit and dalvik.vm.heapsize - BUSTED
Android devices are getting buffer every day and along with that, the amount of RAM devices have available has increased significantly. Devices with 1GB of RAM are now common; some are even equipped with 2GB already.
This is one property that has cropped up recently in various build.prop recommendations for ICS. Typical suggested values range from “48m” all the way up to “256m”, likely motivated by the common misconception that more is better. The real purpose of this property is much less obvious than one might initially guess. It is also another one you should probably avoid changing.
In ICS, the dalvik.vm.heapgrowthlimit property takes over as the effective dalvik.vm.heapsize property. Applications will be restricted to the value set by this property by default. Google has this to say about it:
Code:
// The largest size we permit the heap to grow. This value allows
// the user to limit the heap growth below the maximum size. This
// is a work around until we can dynamically set the maximum size.
// This value can range between the starting size and the maximum
// size but should never be set below the current footprint of the
// heap.
An indeed, we can see this enforced in several places in the Heap and HeapSource structures. Including:
Code:
if (overhead + HEAP_MIN_FREE >= hs->maximumSize) {
LOGE_HEAP("No room to create any more heaps "
"(%zd overhead, %zd max)",
overhead, hs->maximumSize);
return false;
}
heap.maximumSize = hs->growthLimit - overhead;
As we see here, the heap’s maximum size is determined by the growthLimit variable on the HeapSource structure. We can also see a check to ensure there is enough total heap space available to begin with before attempting to create the new heap. At first blush, it looks like like growthLimit (dalvik.vm.heapgrowthlimit) is redundant and synonymous with maxiumSize (dalvik.vm.heapsize). It seems that could set the dalvik.vm.heapgrowthlimit to 64M and the dalvik.vm.heapsize to 256M and only the growthLimit value would be used to govern a heap’s maximum size. That’s where this interesting method comes in:
Code:
/*
* Removes any growth limits. Allows the user to allocate up to the
* maximum heap size.
*/
void dvmClearGrowthLimit()
{
...
gHs->growthLimit = gHs->maximumSize;
size_t overhead = oldHeapOverhead(gHs, false);
gHs->heaps[0].maximumSize = gHs->maximumSize - overhead;
gHs->heaps[0].limit = gHs->heaps[0].base + gHs->heaps[0].maximumSize;
...
}
This method effectively removes any limitation set by dalvik.vm.heapgrowthlimit and sets the maximum heap size to the value defined by dalvik.vm.heapsize (or the hard-coded default of 16M). This method is wired up straight to the Dalvik runtime implementation as a native call and we can see it defined here:
Code:
static void Dalvik_dalvik_system_VMRuntime_clearGrowthLimit(const u4* args, JValue* pResult)
{
dvmClearGrowthLimit();
RETURN_VOID();
}
...
const DalvikNativeMethod dvm_dalvik_system_VMRuntime[] = {
...
{ "clearGrowthLimit", "()V",
Dalvik_dalvik_system_VMRuntime_clearGrowthLimit },
...
};
And if we keep chasing this rabbit “up” the rabbit hole, we can see it finally in action here in the ActivityThread Java class:
Code:
if ((data.appInfo.flags&ApplicationInfo.FLAG_LARGE_HEAP) != 0) {
dalvik.system.VMRuntime.getRuntime().clearGrowthLimit();
}
This flag is set by a relatively new attribute (API level 11) which you can add to the application element in an Android application’s manifest file.
So what does this all mean? The dalvik.vm.heapgrowthlimit property limits how large an Android application’s heap can get before garbage collection has to be attempted. The dalvik.vm.heapsize property defines an absolute maximum for the heap size for an application even when the largeHeap flag is set in the manifest. Google’s motivation behind doing this was clearly to limit the heap size to a reasonable amount for most applications, but also give some flexibility to app developers who know they’re going to need the largest heap size possible to run their application.
Should you change this setting? Probably not. The ICS default for a phone with (at least) 1024MB of RAM is 64m. You can check your specific phone’s value as the hardware vendor can override this themselves when they build the ROM. But don’t let the disparity between 1024 and 64 bother you; most mobile apps should not have any problems with 64MB of heap size unless the developers are naughty. When this limit is reached, a garbage collection routine will remove obsolete objects from memory reducing the heap size down considerably in most cases. It is extremely unlikely raising this value to reduce GC routines will have any perceptible effect. If anything, it could cause other apps or the general system to suffer from too many stale objects sulking around in memory. Garbage collection will inevitably occur either way, and when it does, the size of the heap will likely have a direct impact on the cost of the routine.
The point is, it is impossible for a user to optimize for every application using this system-wide setting. This responsibility falls on application developers to optimize their applications, not users. The largeHeap flag was created to allow developers to do just that. If you do feel compelled to experiment with this setting regardless, be mindful that an application could have up to two heaps at once. Thus, the heap growth limit value should always be, at most, a little less than half of the maximum allowable heap size.
debug.performance.tuning – BUSTED
This property doesn’t appear to exist in the ICS code base. Incidentally, I also don’t see it in Gingerbread (2.3.6). It’s possible this value is specific to only certain custom implementations of Android, such as Cyanogenmod, but as far as I can tell, this one does nothing.
video.accelerate.hw – BUSTED
Again, this one appears to do nothing in ICS.
persist.adb.notify – CONFIRMED
This one disable the USB debugging notification when you have your device connected to a computer. We can see this used here:
Code:
private void updateAdbNotification() {
if (mNotificationManager == null) return;
final int id = com.android.internal.R.string.adb_active_notification_title;
if (mAdbEnabled && mConnected) {
if ("0".equals(SystemProperties.get("persist.adb.notify"))) return;
This is a good one to disable (set to “0″) if you want to declutter your notification bar.
persist.sys.purgeable_assets – BUSTED
This one claims to free up memory, however it is nowhere to be found in the Android code base. This one is a patch made to Cyanogenmod 7 to do some Bitmap hackery. It may not even exist in CM9. Unless you are running CM7, or possibly CM9, this property has no effect.
persist.sys.use_dithering – BUSTED
Another Cyanogenmod-specific property. This will have no effect on stock ICS.
dalvik.vm.execution-mode – BUSTED
This property can set the execution mode of the Dalvik VM. The VM can run in three modes: fast, portable, and very likely JIT. It is possible to compile Android without JIT support, but the default is to include it. In general, JIT is the execution mode you are going to want on your device. This is why you will see most build.prop files setting this property to “init:jit”. However, this is unnecessary since the default execution mode is JIT:
Code:
#if defined(WITH_JIT)
gDvm.executionMode = kExecutionModeJit;
#else
...
As I mentioned before, WITH_JIT compiler flag is set by default in ICS, thus there is no need to define this setting in your build.prop. If WITH_JIT flag was set to false, setting the execution mode to JIT would have no effect anyway.
dalvik.vm.dexopt-flags – PLAUSIBLE
This property can set various options that affect how the Dalvik runtime performs optimization and verification. Suggested values range from turning bytecode verification off completely to enabling object registry mapping and precise garbage collection. Setting “v=n” will turn off bytecode verification, which while in all practicality is unlikely to cause any problems directly, it is a severe violation of the whole Java trust and security model.
On the other hand, setting “m=y” will turn on the register map for tracking objects to garbage collect. Incidentally, this also enables “precise” garbage collection, which, as you may have guessed is a slightly more accurate way to track objects for garbage collection. By accurate we mean less likely to falsely identify an object as still in use when in fact it is no longer being used. This would, in theory, be a more efficient mechanism to free up unused objects, and thus increase available memory (RAM).
Enabling precise GC seems like a good idea as long as your device has the muscle to spare, but I can not find enough information to know for sure what the total implication is to using precise GC versus conservative. I suspect it likely a trade-off of more cpu cycles per collection to obtain more free RAM. You will have to decide which one is more important to you based on your device capabilities and personal tolerance levels. This is assuming that the difference will even be perceptible in a real-world environment, which I suspect would be less than profound, if any at all.
ro.media.dec.jpeg.memcap – BUSTED
This property is one of many that promises to make your audio and visual experience better. Unfortunately, not only is it only related to JPEG decompression, it is completely unused in ICS (and Gingerbread for that matter) and has no effect on your device.
At first, it looks kind of promising:
Code:
// Key to lookup the size of memory buffer set in system property
static const char KEY_MEM_CAP[] = "ro.media.dec.jpeg.memcap";
Ok, cool. The property exists at least. However, that’s the only place this is referenced. The KEY_MEM_CAP is never used anywhere. If we look a little closer, we’ll come across this:
Code:
/* Check if the memory cap property is set.
If so, use the memory size for jpeg decode.
*/
static void overwrite_mem_buffer_size(j_decompress_ptr cinfo) {
#ifdef ANDROID_LARGE_MEMORY_DEVICE
cinfo->mem->max_memory_to_use = 30 * 1024 * 1024;
#else
cinfo->mem->max_memory_to_use = 5 * 1024 * 1024;
#endif
}
This looks like exactly where this property should be used, but isn’t. The value is clearly hardcoded here. In fact, if we look up the Skia project source tree on Google code, we can see that the latest version has this variable commented out now with the following comment:
Code:
/* For non-ndk builds we could look at the system's jpeg memory cap and use it
* if it is set. However, for now we will use the NDK compliant hardcoded values
*/
//#include <cutils/properties.h>
//static const char KEY_MEM_CAP[] = "ro.media.dec.jpeg.memcap";
ro.media.enc.hprof.vid.bps – CONFIRMED
This one is generally grouped together as a general “media” enhancement tweak. This particular property controls the “high” bit rate at which videos are encoded using the Android stock camera application. That means if you are using a third party camera app, this setting will have no effect. Let’s take a look at the snippet.
Code:
mVideoBitrate = getInt("ro.media.enc.hprof.vid.bps",
"ro.media.enc.lprof.vid.bps",
360000, 192000);
While the default values may seem very low, these are very unlikely to ever be necessary. When a device manufacturer deploys the production ROM, they will define many properties in a different property file (viz. “system.prop”), which will contain values specific to the hardware. Those values are going to be used instead of the hard coded ones we see here.
For example, if I launch a shell on a Galaxy S3 and run the following command:
Code:
getprop ro.media.enc.hprof.vid.bps
I will get a value back of “12000000″, even though I do not have this property defined in my build.prop. This is because it was defined in the default.prop file by Samsung knowing the capabilities of the device and the camera.
This setting can definitely be useful if these values are important to you, just be sure you’re not setting the value to the same (or worse yet lower!) than what is already defined on your device. While you’re at it, you may want to tweak some of the other values:
Code:
ro.media.enc.hprof.aud.bps
ro.media.enc.hprof.codec.vid
ro.media.enc.hprof.codec.aud
ro.media.enc.hprof.aud.hz
The names are pretty self-explanatory, but you can find out more info about each one with a little bit of Google’ing.
Summary
The build.prop file is a powerful tool for root users to modify the behavior of various aspects of the Android experience. However, there are no secret values here that are going to instantly make your phone run faster, better, smarter, or more efficiently. In fact, if you don’t know what you are doing, you can actually decrease the performance of your device. Over time I will investigate more build.prop properties to determine which ones can actually enhance your Android experience and which ones only create a placebo effect.

Nice But...
We all know the .prop is powerful but certainly it doesn't mean you can't modify strings to get your Rom/phone to run faster, in that case you're busted " Meaning as in by the person who had posted this" Not you xda guy xD.
If you are running ICS or GB try this out : Add it to the bottom of your build.prop string after the last string...
# dalvik props
dalvik.vm.heapstartsize=5m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=128m
windowsmgr.max_events_per_sec=240
debug.enabletr=true
ro.max.fling_velocity=12000
ro.min.fling_velocity=8000
ro.ril.disable.power.collapse=1
ro.telephony.call_ring.delay=0
persist.adb.notify=0
dalvik.vm.dexopt-flags m=y,o=v,u=y
#Render UI with GPU
debug.sf.hw=1
#debug.composition.type=gpu
debug.composition.type=c2d
debug.performance.tuning=1
debug.enabletr=true
debug.qctwa.preservebuf=1
dev.pm.dyn_samplingrate=1
video.accelerate.hw=1
ro.vold.umsdirtyratio=20
debug.overlayui.enable=1
debug.egl.hw=1
ro.fb.mode=1
hw3d.force=1
persist.sys.composition.type=c2d
persist.sys.ui.hw=1
ro.sf.compbypass.enable=0
# persist.sys.shutdown.mode=hibernate
ro.config.hw_quickpoweron=true
ro.lge.proximity.delay=25
mot.proximity.delay=25
ro.mot.buttonlight.timeout=0
If you are running GB : Remove the following strings from above...
#Render UI with GPU
debug.sf.hw=1
Now watch the magic

krishneelg3 said:
We all know the .prop is powerful but certainly it doesn't mean you can't modify strings to get your Rom/phone to run faster, in that case you're busted " Meaning as in by the person who had posted this" Not you xda guy xD.
If you are running ICS or GB try this out : Add it to the bottom of your build.prop string after the last string...
# dalvik props
dalvik.vm.heapstartsize=5m
dalvik.vm.heapgrowthlimit=48m
dalvik.vm.heapsize=128m
windowsmgr.max_events_per_sec=240
debug.enabletr=true
ro.max.fling_velocity=12000
ro.min.fling_velocity=8000
ro.ril.disable.power.collapse=1
ro.telephony.call_ring.delay=0
persist.adb.notify=0
dalvik.vm.dexopt-flags m=y,o=v,u=y
#Render UI with GPU
debug.sf.hw=1
#debug.composition.type=gpu
debug.composition.type=c2d
debug.performance.tuning=1
debug.enabletr=true
debug.qctwa.preservebuf=1
dev.pm.dyn_samplingrate=1
video.accelerate.hw=1
ro.vold.umsdirtyratio=20
debug.overlayui.enable=1
debug.egl.hw=1
ro.fb.mode=1
hw3d.force=1
persist.sys.composition.type=c2d
persist.sys.ui.hw=1
ro.sf.compbypass.enable=0
# persist.sys.shutdown.mode=hibernate
ro.config.hw_quickpoweron=true
ro.lge.proximity.delay=25
mot.proximity.delay=25
ro.mot.buttonlight.timeout=0
If you are running GB : Remove the following strings from above...
#Render UI with GPU
debug.sf.hw=1
Now watch the magic
Click to expand...
Click to collapse
Incresing hp to 128 your battery is going down like a hell
Sent from my E15i using xda premium

It work 200%
If u do it correctly
I increased my GPRS class from 10 to 12
And it work
Tested on mini cm10
if I helped press thanks :thumbup:

ElmirBuljubasic said:
Incresing hp to 128 your battery is going down like a hell
Sent from my E15i using xda premium
Click to expand...
Click to collapse
Elmir what's a good setting 120? 110?
Sent from my Ascend G300 using Tapatalk 2

ro.HOME_APP_ADJ=0 This line sends the settings app to cache and frees some RAM in addition to blocking the Xperia launcher to not restart when leaving a heavy application.
this line works on GB
sorry for my bad English

Nice copy and paste

Great :thumbup:
Sent from my E15i using xda app-developers app

Related

[CWM] Skeleton zips for system and user apps & build.prop optimization

http://forum.xda-developers.com/showthread.php?p=24233846
Just download the attached zip file according to your need, add apps.. flash.. enjoy.. Tested with cwm 5.0.2.7 touch..
********************************************************************************************************************************************************
Editing build.prop.
Even though some of the things are well known for us, some of them are new for me..So im jus posting it.
1.Force launcher into memory
Property
ro.HOME_APP_ADJ = 1
Function
This will force the Default launcher into memory. But your device should be having enough free memory, otherwise you will meet lags and performance will be reduced severely. Use a light weight launcher for this.
Values
0 : Turns off the feature. Frees up memory.
1: Keeps the default launcher in memory .Will have highest priority and Android auto kills it only when it’s really necessary.
2.Improving Camera Image quality
Property
ro.media.enc.jpeg.quality=100
Function
This will force the camera application to use 100% quality setting when saving camera images as JPEG
Values
1-100 : with 1 as the worst quality and 100 as the best quality.
3.Increase resolution of panorama image
Property
ro.media.panorama.defres=3264x1840
ro.media.panorama.frameres=1280x720
Function
This will force the panorama mode in the camera app to save the image at a higher resolution. This may not be supported by all phones. And since it is an Android 4.0 feature , you will need that android version as well.
Values
defres: Provide the full panorama image resolution.Consisting of all images.
frameres: Provide the resolution of each frame of panorama.
4.Improve performance in video playback and streaming
Property
media.stagefright.enable-player=true
media.stagefright.enable-meta=true
media.stagefright.enable-scan=true
media.stagefright.enable-http=true
media.stagefright.enable-rtsp=true
media.stagefright.enable-record=true
Function
Android uses the media framework named “Stagefright” from Froyo ( Android 2.2 ) onwards. While Stagefright is more open and simple, it is sometimes buggy compared to the previously used OpenCore framework. However, Google has greatly improved its stability. These values might affect the stability of playback in some devices, if it is ruining your experience , then revert to the original values.
5.Improve touch responsiveness through Hardware Rendering
Property
debug.sf.hw=1
persist.sys.ui.hw=1
debug.performance.tuning=1
video.accelerate.hw=1
debug.egl.profiler=1
debug.egl.hw=1
debug.composition.type=gpu
Function
This will force the system to use GPU for rendering each 2D frame in applications. Since android uses frame by frame rendering of the screen normally, this will offload the rendering to GPU by a huge amount and will make the user experience smoother.
Values
debug.composition.type values : GPU / CPU . GPU will make use of the graphic chip on your device for rendering each frame.
6.Disable Error Profiler
Property
profiler.force_disable_err_rpt=1
profiler.force_disable_ulog=1
Function
These commands enable or disable the error profiler in the android. For most android users, there is no use in having error profiling . however , some applications might make use of this for generating error reports.
Values
0 :Enable the feature. Better to delete the property if you don’t want to disable it.
1: Disables the feature.
7.Modify WiFi network scanning time.
Property
wifi.supplicant_scan_interval=180
Function
This command will be already present in all build.prop files. This controls the number of seconds the device waits before scanning for WiFi networks.
Values
Default value is 180 . It is in seconds . You can increase the value if you want to save more battery and doesn’t use WiFi extensively. Or else , you can decrease it , if you are dropping your WiFi signal often.
8.Disable logcat – Android Logger
Property
logcat.live=disable
Function
This command controls the Android Logcat file generation. This file is mainly used for debugging. Expensive disk reads/writes can be reduced by disabling Android logcat.
Values
disable / enable
9.Improve Voice Call clarity
Property
ro.ril.enable.amr.wideband=1
Function
This command controls the AMR audio codec’s property.AMR codec is used for voice calls.
Values
1 or 0 .
10.Disable Extended JNI Checks
Property
ro.kernel.android.checkjni=0
ro.kernel.checkjni=0
Function
“JNI does very little error checking. Errors usually result in a crash. Android also offers a mode called CheckJNI, where the JavaVM and JNIEnv function table pointers are switched to tables of functions that do an extended series of checks before calling the standard implementation.” . That’s the definition from Android developers documentation. While disabling this may cause some data loss when the application crashes, most applications ,which are popular, have been thoroughly checked and hence will be using precious CPU time for extended checks . Save that time by disabling this.
Values
0 / 1 : disable / enable .
11.Disable Android Device Check In.
Property
ro.config.nocheckin=1
Function
Every Android device checks in at the Google Servers when an internet connection is found, this helps Google in tracking the number of installations and the statistics of different android versions. This can be disabled to save for saving traffic and some CPU time, due to the frequent polling for checking internet connection.
Values
1/0 for disabling and enabling , respectively.
12.Increase Voice Call Audio Adjustment Steps.
Property
ro.config.vc_call_steps=20
Function
By Default, android offers seven audio levels for calls. This can be altered through this command , if you want to fine adjust the volume of your voice calls. This won’t increase the volume if it’s already low. But you can manage it by more precisely.
Values
Number of steps as integers. 7-20 is recommended. 7 is the default.
Editing Build.Prop
For editing build.prop, your device should be rooted. That’s the first requirement.
It is at /system/
If you have Root Explorer / ES File Explorer installed on your device you can edit from the device itself. More easier method is to get he application named build.prop Editor . It can be used to change the values and add new fields.
works only in cm10 based roms.
Souron29 said:
works only in cm10 based roms.
Click to expand...
Click to collapse
Of course
doesn't CM10 Rom for O1 include this? U posted it separately so thought might be working with CM9 or CM7
Souron29 said:
works only in cm10 based roms.
Click to expand...
Click to collapse
Then what is the point?
Sent from my LG-P500
This tread should be named as:[APP][CM10] messaging app with quick reply, popup notifications
Sent from my LG-P500 using xda premium
It has been taken from the latest nightly.. I dono whether our cm10 build by rashed have this..:laugh:
carrthee89 said:
It has been taken from the latest nightly.. I dono whether our cm10 build by rashed have this..:laugh:
Click to expand...
Click to collapse
I think we have this
Sent from my LG-P500 using Tapatalk 2
Bump.Now the thread is usefull
Sent from my LG-P500 using xda premium
Updated with build.prop optimizations

[GUIDE] Tweak Your Phone Yourself

I've been playing around with a lot of settings, and these particularly made my phone smoother, faster, lag free and much more resposnsive despite the large amount of apps on my phone.
I tried to keep too much technical details out while covering the basic function of each attribute being altered
Tested on : Stock 4.2.2, 4.2.2 based AOSP ROMs, 4.4.x based AOSP ROMs
What do you need :
1. Root Access
2. Busy Box
3. App - Performance Control by @h0rn3t - Original thread (check the download tab for apk) - http://forum.xda-developers.com/showthread.php?t=2444376
4. Root Explorer like ES Explorer - https://play.google.com/store/apps/details?id=com.estrongs.android.pop
5. A little patience
WARNING​I have and am currently using these tweaks on my phone without any issues. So if your phone goes BOOM, tries to take over the world or tries to eat your brain, it's not my fault.​
Performance Control Tweaks​
First of all, take screenshots of your default settings that you are going to alter. So if this doesn't work for you and you want to revert to original settings, you can do that on your own
1. Install the Performance Control application from above (or app with similar features)
NOTE: If you are on any custom ROM like PAC-MAN, the system might have it's own version of performance control (check Settings>Performance Control option). Follow these instructions to install the current one.
Download the latest apk from the above thread, rename it "PerformanceControl.apk"
Mount System. Copy the apk to /system/app and overwrite with the current application. Give it -rw-r--r-- permissions. Then Reboot. Done!
2. In Performance Control :
The first screen is CPU Settings, as shown I'm using interactive Governor with cfq I/O scheduler, after selecting them check the "Set on Boot" option.
NOTE: If you are on a custom kernel and you have SmartassV2 governor with CFQ or SIO I/O scheduler available, use that instead.
Interactive governor dynamically scales CPU clockspeed in response to the workload placed on the CPU by the user. Interactive is significantly more responsive than OnDemand, because it's faster at scaling to maximum frequency and therefore better for performance.
SmartassV2 is a rewrite of interactive governor with major tweaks that boost both battery and scaling of frequencies when performance is needed.
cfq I/O scheduler is basically for fair queing of processes, so it's better for multi-tasking in my opinion.
SIO I/O scheduler is a mix between noop and deadline but works with no reordering or sorting (downside) but still performs well.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
​
The second screen is Memory Settings, please "Aggressive" or "Very Aggressive", screenshot there for reference if you want to set it manually, and check the "Set on Boot" option.
This handles how much memory is to be allocated and freed to and from the applications.
Since 4.4 ROMs we have also been provided with the KSM feature in our kernel.
To enable this, simply click "Enable KSM" then Select "Settings".
Here you alter the pages to be scanned and the sleep time, i.e., how often should they be scanned.
I've found the following values to work well for me without compromising performance,
Pages to scan : 256
Sleep : 1500 ms
Once you have set the values, press "Apply Values", go back and check "Set on Boot"
KSM is a kernel thread that runs in the background and compares pages in memory that have been marked MADV_MERGEABLE by user-space. If two pages are found to be the same, the KSM thread merges them back as a single copy-on-write page of memory. KSM will save memory over time on a running system at the cost of CPU Power which can have an affect on battery life on long running devices.​
For 4.4 ROMs running custom kernel, zRAM.
NOTE: I am explaining this since it's a feature provided to us, but I do not recommend using it unless you keep running low on RAM.
To enable this, simply click on zRAM, configure the value in MBs (18%-25%), 200MB - 256 MB should be optimal. Then Click on Start.
In zRAM unnecessary/un-used storage resources/processes are compressed and then moved to a reserved area in the fixed RAM. This reserved area is referred to as zRAM and acts like a virtual swap area. This virtual space is what you configure in settings.
Advantage of using this feature is that it allows more RAM to stay free for use as well as keep apps and their data in standby mode so they are readily available when needed. This is very beneficial for low RAM devices is why it has been added to the official Kitkat.
However, the down-side of using this feature is that the compression (and de-compression) of data when it is stored away (or brought up for use) uses more CPU power and time. Which would mean, using this feature actively would probably reduce a little battery backup of your phone.​​
The third screen is Advanced Settings, simply click on the SD read ahead option, and select 4096 (or 2048, lower value if you prefer) and check the "Set on Boot" option.
This is the read ahead speed for your internal and external memories. It helps your phone read any and all data faster while you are using it.
Now we have VM Settings, please select each value and set it according to specific value (screenshots available for reference) and "Apply Values" to save the alterations after you are done editing, then check the "Set on Boot" option.
PLEASE NOTE : we are only editing these values :
vm.dirty_background_ratio : 70
vm.dirty_expire_centisecs : 500/1000
vm.dirty_ratio : 90
vm.dirty_writeback_centisecs : 1000/2000
vm.drop_caches : 3
vm.min_free_kbytes : 4096
vm.overcommit_ratio : 100
vm.swappiness : 20
vm.vfs_cache_pressure : 10
Each of settings is a direct tweak on how system and kernel handle the data.
Dirty Ratio and Dirty Background Ratio control how often the kernel writes data to disk (Increasing these might decrease a little lag but might also affect negatively on performance, so skip these if you want to).
Dirty expire and writeback centisecs are used to define when dirty data is old enough to be eligible for writeout by the kernel flusher threads (higher values are supposed to decrease lag and increase battery by flushing data less often, again, might lower the AnTuTu score a little bit, so stick to the lower values if you want).
Drop caches : Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free. This will drop data sectors at each boot and let the kernel start caching as soon as the boot is complete.
1 => To free pagecache
2 => To free dentries and inodes
3 => To free pagecache, dentries and inodes
Minfree kbytes, like the name suggests, it's the minimum Kbs the system VM keeps free for each zone of memory
Overcommit Ratio allows the processes to allocate (but not use) more memory than is actually available
Swappiness is the tendency of a kernel to use physical memory instead of actual RAM, so you might want to keep this value around 20-30.
VFS Cache pressure is the file system cache pressure, so for faster operation we want the kernel to prefer RAM for this, so keep this value at 10-20
​
Scroll to the last Screen, Tools. Here we have a lot of useful options that can be used for personal use, but we are mainly concerned with Optimize DBs option. Simply click Optimize Databases, it will ask you to confirm and take a minute or two to complete the command.
You can re-use this command every two weeks or so, since it's like de-fragmenting your phone's DB.
Use of this is, when a large amount of data is deleted from the database file (while being used by system or app) it leaves behind empty space, or free, unused database pages. This means the database file might be larger than necessary. Running VACUUM to rebuild the database reclaims this space and reduces the size of the database file. In other cases, database file becomes fragmented - where data for a single table or index is scattered around the database file. Running VACUUM ensures that each table and index is largely stored contiguously within the database file​​
Build.prop Tweaks​
First of all, take a backup of your original build.prop before altering anything. So if this doesn't work for you and you want to revert to original settings, you can do that on your own
How to do it?
1. Install a Root Explorer. I'll be using ES Explorer.
2. Give it root permission to access the Root Explorer mode.
3. Click the Root Explorer to get the following menu, and choose "MOUNT R/W" to mount /system partition in read/write mode.
4. Navigate to /system folder to find build.prop
Now you have two options, either Open and Edit it right there or copy build.prop to your PC and edit it using any utility like Notepad++.
If you use your PC to edit the file, you will have to copy and overwrite the original file with rw--r--r-- permissions (can be found by selecting build.prop in ES and selecting it's properties).
NOTE: /system will go back to Read only mode after each reboot, if you get any error unable to edit/copy build.prop you probably haven't mounted the /system partition as R/W.​
NOTES : Please Read
1. All the tweaks that I am about to list have been available on XDA and several other sites. I am just listing the ones I found useful and have tested myself.
2: I'm using CM's default build.prop as reference. As each ROM's build.prop is different, please check if the developer has already added the tweak before adding it again. If the value or tweak is already present, you may edit it's value if you need to.
3: Add the new tweaks/lines at the end of the build.prop, so that you can easily find or remove them if needed.
4: You don't have to use all the tweaks, just the ones you feel you need.​
The fun stuff
Lines that are not present in stock CM11 and can be added directly, are listed under TO-ADD.
Lines that are present but the values need to be edited are listed under TO-CHANGE
Lines that start with #DONTCOPY are for your information purposes only, and ofcourse don't need to copy them.
'#' - Hash Tags are used as comments in build.prop for sorting purposes, so even if you copy the # line, it will not give you any errors.
TO-CHANGE
#For Dalvik App performance
dalvik.vm.heapstartsize=8m
dalvik.vm.heapgrowthlimit=64m
dalvik.vm.heapsize=256m
​
TO-ADD
# Camera and Video Tweaks
ro.media.enc.jpeg.quality=100
ro.media.dec.jpeg.memcap=8000000
ro.media.enc.hprof.vid.bps=8000000
ro.media.capture.fast.fps=4
ro.media.capture.slow.fps=120
ro.camcorder.videoModes=true
ro.media.panorama.defres=3264x1840
ro.media.panorama.frameres=1280x720
# Camera and Video Flash Tweaks
ro.media.capture.flashMinV=3300000
ro.media.capture.torchIntensity=40
ro.media.capture.flashIntensity=70
# Disable Sending Usage Data
ro.config.nocheckin=1
# Enable sensor sleep
ro.ril.sensor.sleep.control=1
# EGL debug for system performance
debug.egl.hw=1
debug.egl.profiler=1
# Frees More RAM
persist.sys.purgeable_assets=1
# Incoming and Outgoing Call Tweaks
ro.telephony.call_ring.delay=0
ring.delay=0
# Increase Responsiveness
windowsmgr.max_events_per_sec=140
video.accelerate.hw=1
# Increase Performance
debug.performance.tuning=1
# Media Tweaks
media.stagefright.enable-player=true
media.stagefright.enable-meta=true
media.stagefright.enable-scan=true
media.stagefright.enable-http=true
media.stagefright.enable-rtsp=true
media.stagefright.enable-record=true
# Net Speed Tweaks
net.tcp.buffersize.default=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.hspa=4096,87380,256960,4096,16384,256960
#DONTCOPY there's no space between any number here, but XDA is displaying it anyway. please remove it while copying into build.prop
# Pointer duration optimize for better scrolling
ro.min_pointer_dur=8
# Power saving
ro.ril.power.collapse=1
pm.sleep_mode=1
#DONTCOPY pm.sleep_mode=1 -> collapse - will totally power off the cpu
#DONTCOPY pm.sleep_mode=2 -> sleep - cpu is still on, but put into low power mode
# Proximity Sensor responsiveness during Calls
ro.lge.proximity.delay=25
mot.proximity.delay=25
# Signal Reception Tweaks
persist.cust.tel.eons=1
ro.config.hw_fast_dormancy=1
# Scrolling Tweak
ro.max.fling_velocity=12000
ro.min.fling_velocity=8000
# HW debug and Persist SystemUI HW
debug.sf.hw=1
persist.sys.ui.hw=1
# WiFi to Scan Less Frequently
wifi.supplicant_scan_interval=180​
Let me know if it worked for you
If any member has any other sysctl, VM or build.prop tweak that I might have missed or a setting value that works better for them, please let me know. I would be happy to test and post here
Edit (Change-log in OP)
-----Edited March 10, 2014-----
Reason :
- Modified the Power Collapse tweak
- Reduced max_events_per_sec
- Added build.prop tweaks
Enable sensor sleep
EGL debug for system performance
Improve Voice Quality during Calls
Pointer duration for better scrolling
Signal Reception Tweaks
SystemUI HW
-----Edited : Feb 21, 2014-----
Reason :
- Highlighted VM explanations
- Fixed "wifi.supplicant_scan_interval" in build,prop
- Added explanation and values for zRAM for 4.4.2 kernel
-----Edited : Jan 26, 2014-----
Reason : Added VM property drop_caches (Performance Control)
-----Edited : Jan 26, 2014-----
Reason : Added Scrolling tweak for Build.prop
-----Edited : Jan 21, 2014-----
Reason : Added Warning. (LOL )
-----Edited : Jan 21, 2014-----
Reason :
-Renamed the thread to [GUIDE] Tweak Your Phone Yourself
-Reordered the OP to make room for build.prop tweaks
-Put the explanations in a separate box for Performance Control
-Added info about SmartassV2 and SIO for custom kernel
-Added KSM settings info and config
-Added Dirty expire and writeback centisecs config and info for VMSettings
-Added instructions to alter build.prop file
-Added build.prop tweaks
-----Edited : Jan 1, 2014-----
Reason : Added "Tested on : Stock 4.2.2, 4.2.2 based AOSP ROMs, 4.4.x based AOSP ROMs" to the OP
-----Edited : Nov 9, 2013-----
Reason : Added install instructions for custom ROMs like PACMAN which have their own old PerformanceControl
-----Edited : Nov 06, 2013-----
Reason : Performance Control version used : 2.1.8.
-UI and implementation changes in PerformanceControl and added Optimize DBs in the OP
Great, will try out, been using sd booster.
Sent from my GT-I9082 using xda app-developers app
wiryawang said:
Great, will try out, been using sd booster.
Sent from my GT-I9082 using xda app-developers app
Click to expand...
Click to collapse
Let me know how it works out for you
nice ....
can this be used on stock rom?
felcont12 said:
can this be used on stock rom?
Click to expand...
Click to collapse
Yes, should work the same
This tweak works great, very smooth result.
Testing
Will Test these tweaks for 24 Hours...see how they perform against the other packs I've installed in my device.
Will post results. Will then run Benchmark and Stability test.
Cheers,
Paul
Really Worked For Me.
Thanks A Lot!
---------- Post added at 11:46 PM ---------- Previous post was at 11:45 PM ----------
Really Worked For Me.
Thanks A Lot!
TeSt and replay
Not able to download performance control app
Sent from my GT-I9100 using XDA Premium 4 mobile app
ashutiwari3003 said:
Not able to download performance control app
Sent from my GT-I9100 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
It will not work in the XDA mobile app
Try to open the link in any android browser
Sent from my GT-I9082 using xda premium
Seems to be a little quicker. Any issues will report back. Funny thing is my rom already had a version of performance control in it so I wondered why it wouldn't install version 2, it's because I had an older version installed but it worked once I uninstalled the old version
Sent from my SCH-I535 using xda premium
i try this and this is fast and smooth
@ashutiwari3003 this is a direct link for App - Performance Control hit thanks if i help you
http://get.xda-developers.com/dl/6/0/0/PerformanceControl-2.1.4.apk?key=afM0PWLUPDaF6n6Uv5d6GA&ts=1382029384
medozse7s said:
i try this and this is fast and smooth
@ashutiwari3003 this is a direct link for App - Performance Control hit thanks if i help you
http://get.xda-developers.com/dl/6/....apk?key=afM0PWLUPDaF6n6Uv5d6GA&ts=1382029384
Click to expand...
Click to collapse
Link is dead FYI
Sent from my SCH-I535 using xda premium
medozse7s said:
ok the apk in attached
Click to expand...
Click to collapse
Thanks but I've already downloaded it from OP
Sent from my SCH-I535 using xda premium
Thanks, I've been looking for a clear explanation a lot of these terms, specifically the VM settings. As far as kernel-tweaking apps go, I've been using Trickster Mod (on the advice of several devs), but everyone should use what works for them. It covers the SD read-ahead buffer, but not the min-free settings, so I might look around for my own combination of apps.
I'm especially glad to hear anyone's experience with the SD read-ahead buffer. The only thing I had been able to determine was: that my S3 works best in multiples of 1024. But then, there were times that I had lag, & I wasn't sure if it was because of my large buffer, or some other things that I had messed with. It really threw me when I noticed a couple of custom kernels that come with a small default buffer.
Can't wait to try this, but I might not get to it tonight. Sick Children.
Sent from my Nexus 7 using Tapatalk 4
--------------OP Edited--------------
Updated SD read ahead speed to 3072
medozse7s said:
ok the apk in attached
Click to expand...
Click to collapse
Please do not give direct links or apk for the applications used. The reason I used a thread link is to support the dev who made this great app. Anyone who needs it can go the thread and get it, it is working fine I just checked it. Thank you
pbr2 said:
Thanks, I've been looking for a clear explanation a lot of these terms, specifically the VM settings. As far as kernel-tweaking apps go, I've been using Trickster Mod (on the advice of several devs), but everyone should use what works for them. It covers the SD read-ahead buffer, but not the min-free settings, so I might look around for my own combination of apps.
I'm especially glad to hear anyone's experience with the SD read-ahead buffer. The only thing I had been able to determine was: that my S3 works best in multiples of 1024. But then, there were times that I had lag, & I wasn't sure if it was because of my large buffer, or some other things that I had messed with. It really threw me when I noticed a couple of custom kernels that come with a small default buffer.
Can't wait to try this, but I might not get to it tonight. Sick Children.
Sent from my Nexus 7 using Tapatalk 4
Click to expand...
Click to collapse
Hi, VM Settings are basically part of sysctl.config that decide how the linux os and kernel handle the data that is stored on RAM, both physical and virtual and how often to write it. Trickster Mod yes is a great app that gives you a great interface to handle a lot of features, and in there recent version they included sysctl.config as well
Version 2.6.770 (20131005)
- Add Sysctl editor (donate)
Click to expand...
Click to collapse
But the main issue would be to find the specific settings I'm referring to. If you open the editor you will the config file goes on forever. But yes the Trickster Mod can be used to edit them.
Regarding the SD card buffer, the reason I didn't simply use the 4th screen in my post to edit SD read ahead speed is because like most apps, Performance Control and possibly Trickster Mod as well, is that they only edit either sdCard or extSdCard, usually not both. Try installing SD Booster which I mentioned above, when you open the app it displays current read ahead speed of both of your storage, and probably only one of them would be the one you have set through Trickster. You can edit and monitor both through this app and even set different read ahead for each.
Lastly, yes 1024 multiples are used to be set as read ahead as it covers one entire kB/MB of data. The most common altered value is 2048, and honestly I've been experimenting and the difference after 2048 (3072/4096) isn't that much except that 3072 seems to have a little boost
Hope your children feel better today
(Benchmark of my 16GB class 10 card using Rom ToolBox Pro)
I can't download it
Sent from my GT-I9082 using XDA Premium 4 mobile app

[GUIDE]Build.prop explained [Updated 11/30]

Hello fellow xda members. Today i present you my little tutorial about the build.prop file. I have taken the reference build.prop from k2wl's aokp rom.
Please make a nandroid backup in case something goes wrong.
I´m not responsible for any damages to your phone.
CREDITS
-Chris_84
-k2wl (for refrence build.prop)
-xda-developers
Click to expand...
Click to collapse
What is the build.prop ?
TheManii: Build.prop is what holds the majority of the runtime flags that are used when android boots, think of it as being
similar to config.sys on dos or environment variables in various OS's. It only holds variables, it cant run any scripts on it's own. Whatever is placed inside depends on android itself to pay attention to the flag and actually use it.
In easier words it is a file in your android system that maintains certain parameters on your phone in order for your phone to run.
These properties are device specific and can change depending upon the various specifications of the device and also includes some system properties.
Click to expand...
Click to collapse
Where is build.prop located?
You will find the build.prop file in root/system/build.prop. You can open it with a root explorer/es explorer which has a built in text editor.
Click to expand...
Click to collapse
How to edit build.prop?
1.With a root explorer or ES file exploreror.
copy /system/build.prop to the root of the internal sdcard (/mnt/sdcard).
2.Edit it using a text editor (ES and root explorer have an inbuilt text editor) or on computer using notepad++.
3.Be careful as some of the parameters already exist. Just change their values.
4. Overwrite /system/build.prop with the edited file.
5. Make sure that the permissions are still rw-r--r--:
6. Reboot into recovery
wipe cache and dalvik cache.
Make sure to edit existing line if present
Click to expand...
Click to collapse
LETS BEGIN
This mentions that the build prop is built by build info shell script during the compilation of the ROM.
# begin build properties
# autogenerated by buildinfo.sh
Version name of 4.2.2(jellybean)
ro.build.id=JDQ39
Current rom version on phone
ro.build.display.id=aokp_i9082-userdebug 4.2.2 JDQ39 eng.k2wl.20130827.005402
Your current modem version
ro.build.version.incremental= eng.k2wl.20130827.005402
Current sdk version of framework plus codename
ro.build.version.sdk=17
ro.build.version.codename=REL
Current android version on phone
ro.build.version.release=4.2.2
This is the time and date of when the Kernel was built.
ro.build.date=Aug 27 00:54:58 IST 2013
Other Kernal Details
ro.build.date.utc=1377545098
ro.build.type=userdebug
ro.build.user=android-build
ro.build.host=k2wl-HP-EliteBook-8440p
Test keys means that the ROM is not an official version of the ROM. Release keys are for official releases.
ro.build.tags=release-keys
Model Number
ro.product.model=GT-I9082
Phone Manufacturer
ro.product.brand=samsung
This name is the codename of the
device.
For example-
HTC Explorer - pico,
Nexus 7 - grouper
Nexus 4 - mako
Galaxy Ace - cooper
Grand - baffin
ro.product.name=baffin
System Images
It is the first instruction set (CPU + ABI
convention type) of the code. Ours is an arm type arch cpu and abi version 7a )
ro.product.cpu.abi=armeabi-v7a
ro.product.cpu.abi2=armeabi
Default Country settings.
Language of software
Region of software
ro.product.locale.language=en
ro.product.locale.region=GB
If you not able to connect to your wifi, you can try to set here the same number of channels as your router currently got. For example: Your router is set to 12 channels you can paste the same number in here.
ro.wifi.channels=
Here you can set the standard media sounds for each notification. But the file should be present in system/media/...
ro.config.ringtone=S_Over_the_horizon.ogg
ro.config.notification_sound=S_Whistle.ogg
ro.config.alarm_alert=A_toy_watch.ogg
Your phone is still usable, even if sim card is not inserted.
keyguard.no_require_sim=true
Default format of date
ro.com.android.dateformat=mm-dd-yyyy
Your bluetooth name
net.bt.name=Samsung Galaxy Grand Duos
Disable Boot Animation
debug.sf.nobootanimation=1
Your battery capacity (in MHz)
ro.semc.batt.capacity=1200
The setup wizard when you flash a custom rom and it asks your language, gmail id etc
ro.setupwizard.mode=DISABLED (or ENABLED or OPTIONAL)
Here you can set the default density (in pixel per inch)(default is 240)
ro.sf.lcd_density=240
Minimum brightness of your screen
ro.lcd_min_brightness=40
Your default brightness
ro.lcd_brightness=160
Basically you control the class-loading and dalvik-vm there. Here you can set different values.
v=a means verify all,
v=f means verify full,
o=v means optimize verify,
v=n will turn off bytecode verification
u=n means do not optimize for unprocessor
m=y means register maps yes
dalvik.vm.dexopt-flags=m=y
Enables multi touch
ro.product.multi_touch_enabled=true
Max number of multi touches
ro.product.max_num_touch=2
Disable sending usage data
ro.config.nocheckin=1
Here you can set the delay of time your phone starts to ring when you recieve a call.
ro.telephony.call_ring.delay=0 (0 means disabled)
Disable waking up of phone by volume buttons ro.config.hwfeature_wakeupkey=0
Off the proximity quickly after call
mot.proximity.delay=25
ro.lge.proximity.delay=25
This property is supposed to keep the launcher in memory under the assumption that it would somehow make it faster
ro.HOME_APP_ADJ=1
Allows your phone to use an ext-4 file system
ro.ext4fs=1
Disables debug icon on status bar
persist.adb.notify=0
Key lights stay on while screen is on
ro.mot.buttonlight.timeout=0
Disable notification sound when SD is inserted
persist.service.mount.playsnd=0
Disables location of device. Also delete /system/app/networklocation.apk and /system/framework/com.android.location.provider
.jar
ro.com.google.locationfeatures=0
ro.com.google.networklocation=0
To enable the timeout of hard key lights to stay on when screen is on and lights off when screen is off
ro.mot.buttonlight.timeout=0
To enable the menu button too unlock the phone
Not sure if it works
ro.config.hw_menu_unlockscreen=true
Proximity sensor debounce time
mot.proximity.delay=450
mot.proximity.distance=60
Default data roaming is enabled
ro.com.android.dataroaming=true
Judging from its name I assume people think it disables some kind of logging mechanism. But 'no'.The “ulog” referred to in this property is an HTC-specific service that HTC calls the User Behavior Logging Service. This service is centered around tracking user behavior related to the HTC Sense launcher. The HTC ULog tracks some basic things like the number of ANRs and/or crashes, but it also potentially tacks things like your wallpaper selection, your installed apps and your locatio (HTC specific)
profiler.force_disable_ulog=1
Unlike the latter, this one actually does turn off sending device crash log data to HTC. This will make your device run faster/smoother/better (HTC specific)
profiler.force_disable_err_rpt=1
# Increase Quality Of MediaStreaming
media.stagefright.enable-meta=true
media.stagefright.enable-scan=true
media.stagefright.enable-http=true
media.stagefright.enable-record=false
# Net Speed Tweaks
net.tcp.buffersize.default=4096,87380,256960,4096,
16384,256960
net.tcp.buffersize.wifi=4096,87380,256960,4096,163
84,256960
net.tcp.buffersize.umts=4096,87380,256960,4096,163
84,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,163
84,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,163
84,256960
# Google DNS Tweak
net.wlan0.dns1=8.8.8.8
net.wlan0.dns2=8.8.4.4
net.pdp0.dns1=8.8.8.8
net.pdp0.dns2=8.8.4.4
net.ppp0.dns1=8.8.8.8
net.ppp0.dns2=8.8.4.4
net.eth0.dns1=8.8.8.8
net.eth0.dns2=8.8.4.4
net.gprs.dns1=8.8.8.8
net.gprs.dns2=8.8.4.4
# Touch Responsiveness
Scrolling Responsiveness
Faster Scrolling
debug.performance.tuning=1
video.accelerate.hw=1
windowsmgr.max_events_per_sec=500
ro.max.fling_velocity=12000
ro.min.fling_velocity=8000
# Media Tweaks
Increase photo and video quality
ro.media.dec.jpeg.memcap=8000000
ro.media.enc.hprof.vid.bps=8000000
ro.media.enc.jpeg.quality=100
Makes streaming videos stream faster
media.stagefright.enable-player=true
media.stagefright.enable-meta=true
media.stagefright.enable-scan=true
media.stagefright.enable-http=true
Better Flashlight intensity & camera-flash quality
ro.media.capture.flash=led
ro.media.capture.flashMinV=3300000
ro.media.capture.torchIntensity=65
ro.media.capture.flashIntensity=70
# Signal Tweaks
Defines weither to use [0=UMTS] [1=HSDPA only] [2=HSDPA & HSUPA] [5=No significant information has been found but it makes the switch between WiFi and HSxPA nearly instantaneous (note works like "2" but better)]
Here you can improve your Data speed if your provider supports it. Set this to 0 if you want lower speeds, and up to 2 for faster speeds.
ro.ril.hsxpa=2
Defines what class speeds to use with EDGE.
Class 10 will significantly save battery, unless you use EDGE/GPRS instead of 3G)
12 is the default value for most modern phones.
Setting this value to 12 can improve the data speed significant on lower connections.
ro.ril.gprsclass=10
0=off
1=Default
no change when turned off. In some phones stability is increased when turned off.
ro.ril.hep=1
Enable "dual transfer mode" on EDGE networks. Requires different GPRS class settings. Only set this to 1 if your network allows simultaneous transfer of Circuit switched (CS) voice and Packet switched (PS) data over the same radio channel (ARFCN). Turning this off on some carriers, including Optus (AU) and AT&T increases upload speeds.
ro.ril.enable.dtm=1
Enable increased ciphering on
HSDPA/HSUPA, for increased security, but decrease in performance.
ro.ril.enable.a53=1
Adds the 3G prefix e.g. Optus 3G, etc. Purely cosmetic
ro.ril.enable.3g.prefix=1
Other signal tweaks
ro.ril.hsdpa.category=10
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=14449
ro.ril.hsupa.category=5
# Dalvik VM tweaks
This controls the smallest amount of memory given to a single application.
dalvik.vm.heapstartsize=5m
This value represents the maximum allowed amount of memory that the Dalvik Virtual Machine can allocate to the applications. A higher value means faster apps but more RAM consumption.
dalvik.vm.heapgrowthlimit=48m
The dalvik.vm.heapsize property defines an absolute maximum for the heap size for an application
dalvik.vm.heapsize=128m
This point stands for "Debug SurfaceFlinger Hardware" or GPU hardware acceleration
debug.sf.hw=1
Explained Earlier(change to this to load apps faster and free more ram)
dalvik.vm.dexopt-flags=m=v,o=y or m=y
This property can set the execution mode of the Dalvik VM. The VM can run in three modes: fast, portable, and JIT. It is possible to compile Android without JIT support, but the default is to include it. In general, JIT is the execution mode you are going to want on your device. This is why you will see most build.prop files setting this property to “int:jit”.
In ICS or lower , there is no need to define this setting in your build.prop
dalvik.vm.execution-mode=int:jit or int:fast
Others
dalvik.vm.heaptargetutilization=0.75
dalvik.vm.heapmaxfree=2m
dalvik.vm.lockprof.threshold=500
# Improve battery
improve battery under no signal
ro.mot.eri.losalert.delay=1000
Bluetooth OPP low speed to save power
debug.bt.lowspeed=true
Wifi to scan less frequently
wifi.supplicant_scan_interval=240
System can free more Ram when needed
persist.sys.purgeable_assets=1
This property purports to significantly increase your battery life by putting signaling your device to use a better power mode when your phone is idle. Recommended values range from 0, 1, 4 with the most common be 1
pm.sleep_mode=1
To save battery turn off wifi, internet, bluetooth, gps, lower the brightness at night, kill all apps running in background, clear ram, underclock if kernal supports and also switch off the animations settings>display>no animation.
Reserved
Sent from my GT-I9082 using XDA Premium 4 mobile app
that is awesome work
informative posts. :good:
medozse7s said:
that is awesome work
Click to expand...
Click to collapse
Dwama said:
informative posts. :good:
Click to expand...
Click to collapse
Thank you very much! It's a honor to get such a good feedback from ual!
Sent from my GT-I9082 using XDA Premium 4 mobile app
Digitizer problem
Hello,
any idea if there is a property which would control the digitizer orientation? My digitizer got mixed up after flashing a new ROM version and the manufacturer`s stock is not the same stock as used to be inside the tablet.
ATM my digitizer is mirrored top-down in landscape and there might be a build.prop to compensate. Does such setting exist?
Joe
awesome NOOB guide for the build.prop! had a doubt, can i edit the build.prop and change the wallpaper?
when the rom is loaded i want the default wallpaper to be like the stock rom! is it possible?
if so then which are the lines i need to edit! pls inform!
WBR
ReyTech.
Awesome Awesome Guide....Very informative Post...Keep up the good work...
Sent from my GT-I9082 using XDA Premium 4 mobile app
Awesome work... Hats off..... Thank you...
Sent from my GT-I9082 using XDA Premium 4 mobile app
joeprusa said:
Hello,
any idea if there is a property which would control the digitizer orientation? My digitizer got mixed up after flashing a new ROM version and the manufacturer`s stock is not the same stock as used to be inside the tablet.
ATM my digitizer is mirrored top-down in landscape and there might be a build.prop to compensate. Does such setting exist?
Joe
Click to expand...
Click to collapse
Two methods to do that.
1. By editing your build.prop
ro.sf.hwrotation=xx in /system/build.prop should do the job.
xx = 00 (portrait mode - default)
xx = 90 (landscape mode)
xx = 180 (full tilted)
2. What you need to do is edit yourAndroidManifest.xml*file and specify the orientation for your activity, as well as handle orientation changes yourself:
Then your activity will always run in a landscape mode regardless of the device orientation.
However note that this will affect all applications running on the device.
ReyTech said:
awesome NOOB guide for the build.prop! had a doubt, can i edit the build.prop and change the wallpaper?
when the rom is loaded i want the default wallpa per to be like the stock rom! is it possible?
if so then which are the lines i need to edit! pls inform!
WBR
ReyTech.
Click to expand...
Click to collapse
Decompile framework-res.apk then go to
res/drawable-sw600dp-nodpi/default_wallpaper.jpg
Replace the image that you want with resolution of 1440x1080.
Recompile and push the framework-res.apk to system/framework/here.
Hope it helps.
Amazing!!!!!!!!!!!!!!!!!!
Wowwwwwwwwwww..... Great Work Mate...........
Thumbs Up :good:
Thanks man ......helped a lot to understand the inside of android.....
Sent from my GT-I9082 using Tapatalk
GREAT explanation !! Is all of the information still relevant to KitKat ? I just want to be sure.
Can anyone tell me what line is this for?
" persist.sys.recovery_update=false "
thankss alott
Any way to enable the notification led from the build
Sounds Great, Thanks for sharing.
Great topic
losing signal
hi any one has/have an idea for fixing my problem to my kata i3s mt6582 kitkat 4.4.2 when in my house i have a signal i can use data connection surfing etc,
but when it come to my work or when i go to my work my signal are losing and its totally drop the signal,
any idea on how to fix lossing of signal
:crying::crying::crying::crying::crying::crying::crying::crying:
persist.sys.recovery_update=false
subhad43 said:
Can anyone tell me what line is this for?
" persist.sys.recovery_update=false "
Click to expand...
Click to collapse
This basically means that when the system will update/auto update over the air, or OTA, or Delta updates, or for that sake even when you manually flash the new update, the system will not replace your custom recovery.
You can view this under the Developer Option, where the option "Update Recovery" or "Update Cyanogen Recovery" is turned off by default.
This is to help with custom recovery , as inbuilt recovery is limited and does not have all the customisations.

[TUTE][TIPS] Android RAM Management

Android RAM Management
What's this thread about?
This is a brief account of some useful aspects of android memory management and what could be done to make it better or to suit our needs. This is arranged in two parts; A) RAM Management Lesson. B) RAM Management Tips. Whoever is familiar with the Android RAM management concepts can skip to the second part (2nd post). [highlight]Please read and understand carefully before applying anything to the phone. I'm not responsible for any unwanted effects thereby. Credits belong to respective authors of any MOD/APP discussed here.[/highlight]
A) RAM Management Lesson
Android uses a different way of handling processes. Instead of killing every process after its activity ended, processes are kept until the system needs more memory. The idea is to give speed improvements if you start that activity again. But how/when does Android kill a process if it needs more memory and and which process to kill first?
This is managed by the LMK (Low Memory Killer) driver of Android. You may already know that every app/process in Android is assigned an oom_adj value, which indicates the likelihood of it being killed when an out of memory (OOM) situation occurs. More higher it's value, the higher likelihood of it getting killed. Valid range is -17 to +15. (if in the -17 range means it won't get killed). According to that, there are six groups (OOM groups), into which apps/processes are categorised:
1. Foreground app
2. Visible app
3. Secondary server
4. Hidden app
5. Content provider
6. Empty app
Basically these could be described as..
FOREGROUND_APP:
// This is the process running the current foreground app. We'd really
// rather not kill it!
VISIBLE_APP:
// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear.
SECONDARY_SERVER:
// This is a process holding a secondary server -- killing it will not
// have much of an impact as far as the user is concerned.
HIDDEN_APP:
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption.
CONTENT_PROVIDER:
// This is a process with a content provider that does not have any clients
// attached to it. If it did have any clients, its adjustment would be the
// one for the highest-priority of those processes.
EMPTY_APP:
// This is a process without anything currently running in it. Definitely
// the first to go!
Click to expand...
Click to collapse
These groups are defined by oom_adj value limits, and apps would fall into one of those groups according to the oom_adj value assigned to that particular app. "Foreground apps" usually have an oom_adj value of 0 or less (so they are the least killable; i.e High priority). "Empty apps" have a higher oom_adj (they are killed early; i.e Low priority). Also, oom_adj value changes according to the state of the user app; it's 0 when the app is active in the foreground and assigned a higher value when the app goes to the background.
Why their "killability" differ? Apps belonging to these different groups (that have different oom_adj's), start to get killed at different levels of free RAM. These triggering RAM limits are defined by the LMK minfree values. Above 6 categories correspond with 6 RAM limits which are set in the LMK minfree. Eg: Stock Android 4.3 in our SP comes with the minfree values of 58,68,78,88,98,118. (these are in MB; see below how to check it). Practically what it means is, Empty apps will get killed when ram goes below 118mb, Content providers when it goes below 98mb, Hidden apps when it goes below 88mb and so on.. lastly starts killing Foreground apps when ram goes below 58mb. You may notice that this last value (58mb) is not desirable when using memory intensive apps like heavy games. The app might shutdown while we interact with it. It won't be a surprise if RealRacing3 would shutdown in the middle of a race with these minfree settings!
[Highlight]Notes:[/highlight]
1. In our SP (and newer kernels), oom_[highlight]score[/highlight]_adj is used instead of old oom_adj. (oom_score_adj valid range is -1000 to 1000). But oom_adj is also maintained for compatibility I think.
2. It is said that there are many OOM process categories that are assigned different oom_adj priorities by the ActivityManagerService, but eventually all of those would be considered under above six slots/groups (according to oom_limits), for the purpose of killing by the LMK minfree triggers. Therefore, those six are the importatnt ones for normal users like us.
[highlight]Now, to the practically important part...[/highlight]
# We can check the minfree values (also change them) and see the OOM groupings of apps/processes with this Memory Manager app easily.
a) LMK Minfrees:................... ......................................b) OOM groupings:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
....
If we click on an app in the list and select 'more info', we can see it's oom_adj value. In my case, System UI has -12 (foreground), Home Launcher has 1 (visible group) etc..
# We can check these manually in a terminal too..
a) LMK Minfrees:
Give the following command (without quotes) in a terminal emulator or adb shell: "cat /sys/module/lowmemorykiller/parameters/minfree"
Code:
$ cat /sys/module/lowmemorykiller/parameters/minfree
[b]15000,17532,20065,22598,25131,30263[/b]
** These are in pages; 1 page=4K. Therefore, converting these in to MB results in.. 58,68,78,88,98,118. (e.g: 15000 x 4 /1024 = 58,5938)
b) OOM_adj value of an app:
*This is not much useful. But nice to know where to get these values from.
E.g. take home launcher. Find out it's PID (process ID) like this.. (command with output posted)
Code:
$ ps |grep [b]home[/b]
u0_a26 1653 721 471408 78076 ffffffff 00000000 S com.sonyericsson.home
It's pid is 1653. To see it's oom_adj value..
Code:
$ cat /proc/[b]1653[/b]/oom_adj
1
It's 1 (foreground). You might get 6 (hidden). So, your home is easily killed than my home . See below why..
At the same time we can see the new oom_score_adj..
Code:
$ cat /proc/[b]1653[/b]/oom_score_adj
58
* To convert old oom_adj value to newer oom_score_adj..
oom_score_adj = (oom_adj x 1000)/17 (truncate the decimals). So, (1x1000)/17=58.823
*There's another value (0-1000) of oom_score (cat /proc/1653/oom_score), which is THE actual indicator of how likely a process will get killed. It changes according to the tunable oom_score_adj and other factors..? something like that.. forget it!
[highlight]## The above mechanism could also be described according to what is mentioned in kernel source files[/highlight], as below. Can skip if it's boring ..
It's from 'drivers/misc/lowmemorykiller.c' of kernel sources (4.3; .266)
* The lowmemorykiller driver lets user-space specify a set of memory thresholds
* where processes with a range of oom_score_adj values will get killed. Specify
* the minimum oom_score_adj values in
* /sys/module/lowmemorykiller/parameters/adj and the number of free pages in
* /sys/module/lowmemorykiller/parameters/minfree. Both files take a comma
* separated list of numbers in ascending order.
*
* [highlight]For example, write "0,8" to /sys/module/lowmemorykiller/parameters/adj and
* "1024,4096" to /sys/module/lowmemorykiller/parameters/minfree to kill
* processes with a oom_score_adj value of 8 or higher when the free memory
* drops below 4096 pages and kill processes with a oom_score_adj value of 0 or
* higher when the free memory drops below 1024 pages.[/highlight]
*
* The driver considers memory used for caches to be free, but if a large
* percentage of the cached memory is locked this can be very inaccurate
* and processes may not get killed until the normal oom killer is triggered.
Click to expand...
Click to collapse
If we take our phone values, "cat /sys/module/lowmemorykiller/parameters/adj" command returns: "0,58,117,235,529,1000". These are in (new) oom_score_adj values. If we convert them to (old) oom_adj values, these become "0,1,2,4,9,15". (eg:117x17/1000=1.989=2; The last value becomes 17, but oom_adj range ends with 15, so we take 15). Now, with our minfrees of 58,68,78,88,98,118, what it means practically is to kill processes with a oom_adj value of 0 or higher when the free memory drops below 58mb and kill processes with a oom_adj value of 1 or higher when the free memory drops below 68mb and so on... Therefore, it's clear that the adj values "0,1,2,4,9,15" (or score_adj values "0,58,117,235,529,1000") define the limits of each of 6 OOM slot described above.
Another point to note is what mentioned above in the kernel source file "..driver considers memory used for caches to be free..", which is described below.
[highlight]What is "Free RAM"?[/highlight]
What's reported in many apps as "free ram" is actually not free/empty. Linux/Android always tries to utilise the whole ram in some way, so the ram is not wasted. Ram which is not used by active apps, is used for caching apps and for some buffers. These caches and buffers can release memory for apps when needed. We can see the ram usage in detail with this command.. "cat /proc/meminfo" [giving "watch cat /proc/meminfo" would refresh the output every 2 seconds].
Code:
$ cat /proc/meminfo
MemTotal: 859764 kB
[B]MemFree: 26380 kB
Buffers: 2008 kB
Cached: 136600 kB[/b]
SwapCached: 0 kB
Active: 557312 kB
Inactive: 70520 kB
...blah.. ..blah...
....
Reported "free ram" was ~150mb when this was taken. Out of that, most (135mb) is already cached. ["Free RAM"=MemFree+Cached]. Actual free is very little. So, increasing "free ram" makes the phone much snappier because most of that "free" part of the RAM is used for caching things.
-->> RAM Management Tips
B) Tips for better RAM management.
Following is an account of which i benefitted from, sharing for others who may not be aware of these. Your milage may vary... Desired "RAM Management" differs depending on whether expecting more multitasking or a snappy phone with lot of free RAM. Nowadays, phones with better specs generally won't show any lag even if tuned for multi-tasking , although "free RAM" stays little lower. I prefer towards more multi-tasking
1. Change the minfree values to suit your needs. [highlight](Need Root access)[/highlight].
LMK Minfree values can be changed on the fly. Use lower values if you want more multitasking. Higher values if need more "free ram" for gaming etc.. . I use 8,12,45,65,95,165 for more multitasking and for foreground apps to stay until ram becomes much lower. Asphalt8 never crashed with this! If we use values like 15,25,95,145,195,245 "free ram" would be more but background apps (e.g. Hidden apps) would shutdown earlier. However, make sure NOT to increase the first 2 slots too high, so that the Foreground and Visible apps would stay even if RAM goes lower.
How to set/change them:
a) You can set those values with the above Memory Manager app and press Apply. (and tick 'apply at boot' for those values to be applied at every boot).
** There are many preset values you can experiment with.
b) Or can do the manual way.. Give the following command in a terminal/ADB shell:
Code:
echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree
(That's after "su" command to get root prompt). ** Need to 'echo' them in pages; not in MBs. See first post how to convert them.
Note: This won't survive reboot. You can run this command as a script with init.d every boot. (For init.d support, check this). The script would look like this:
Code:
#!/system/bin/sh
echo "2048,3072,11520,16640,24320,42240" > /sys/module/lowmemorykiller/parameters/minfree ;
c) Can use Minfree Manager app. To set the minfrees, press Apply after entering the values. If we press 'Apply at Boot', it saves a script under init.d. No hassle.
** There are many apps that can do these kind of changes. Eg: Auto Memory Manager, Ram Manager(Free/Pro)-with other options. The above described ones are very easy to use.
2. Use 'App Settings' xposed module to make any app "stay" in memory (make it "Resident"). [highlight](Need Root access)[/highlight]
It would definitely help multitasking by keeping the needed apps in the background without getting killed, even if RAM becomes low. It possibly works by reduces the app's oom_adj value. That's why you can see Opera Mini in the 'Foreground app' list in my screenshot above (1st post). It's oom_adj value is 0. You can do this for your home launcher and any app you wan't to stay un-killed in the background.
Caution: Making apps to stay in memory would make them stay without being killed, even when e.g. a heavy game is starving for RAM. Therefore, indiscriminate use of this option is not advised. I think it's better to..
(i) Apply only to the apps which have an 'Exit' button/menu, so we can shut it down when needed.
(ii) If no exit button, Add to the 'Greenify' list to be hibernated when the app is not needed. But it asks for confirmation before hibernating these kind of apps with 'High Priority' oom_adj status.
How-to:
1. Get Xposed installer from here. Install it. Install the Xposed framework through it. Refer to the respective thread for more details.
2. Then download the 'App Settings' module through Xposed installer..
3. Open 'App Settings'.. App list will load.
4. Select the app you wan't to tweak.. It will lead to a page as seen in the screenshot above.
5. Select 'Resident' and save (upper right corner button). Can change any other setting if needed.
3. Use zeppelinrox's jar patcher tools to patch services.jar. [highlight](Need Root access)[/highlight].
It changes Home Launcher priority and many other LMK related tweaks. This is why you see my home launcher is under visible apps (oom_adj 1). No launcher redraws even after asphalt8! See the particular thread for details. In summary, patching services.jar results in (quoted from the thread):
- This will SuperCharge Your Home Launcher and ADJ/OOM Priorities! You pick launcher strength!
- This lets you run up to 70 hidden apps instead of the default 15 (RAM permitting) without breaking the lowmemorykiller!
- This tries to bypass the 30 minute service inactivity limit by increasing it to 24 hours.
Click to expand...
Click to collapse
** From ICS up, Android doesn't read ADJ values from build.prop or local.prop - they are hardcoded into services.jar! That is the reason for needing to patch services.jar to change OOM priorities. More details in the respective threads.
How-to (quoted):
Get Jar patcher tools from the thread. I used 'Ultimatic_Jar_Patcher_Tools_RC7_TEST6_ALL_DEX_ALL_OSes_NO_FLASH.zip'. Extract it in the PC. Make sure ADB drivers installed.
How to run -=Ultimatic Jar Patcher Tools=-
1. Connect your Android to your PC with Android Debugging ENABLED and Mass Storage DISABLED so your device has access to your sdcard.
2. Windows: Run either the zip's *.bat or the attached *.exe
If running the exe, you can put a different ultimate jar power tools script version in the same folder and it will use that one otherwise it uses the embedded version!
If you have cygwin installed, you can even use the zip's *.sh file at the cygwin prompt.
Linux/Mac OSX: run the zip's *.sh file
Just be sure to read everything and answer Yes or No as is your preference.
Example: The script allows you to choose the level of your Launcher's Super Strength! (BulletProof, Die-Hard, or Hard To Kill)
Click to expand...
Click to collapse
** Always keep a cwm backup before attempting this; might not get it correct in the first attempt..
4. With the above jar patching, can use zeppelinrox's supercharger script. [highlight](Need Root access)[/highlight].
It can be used to change the minfrees and it re-groups the OOM categories. It also has tons of other cool tweaks. If we check "cat /sys/module/lowmemorykiller/parameters/adj" after applying the SuperCharger scripts to our phone, it returns.. "0,176,352,588,705,1000". Converting to oom_adj values (see 1st post) it becomes "0,3,6,10,12,15". Comparing with stock values (0,1,2,4,9,15), we can see that the above described six OOM slots are re-arranged, sort-of categorising more processes towards higher priority. Can test those settings by echoing those values (this won't survive reboot):
Code:
echo "0,176,352,588,705,1000" > /sys/module/lowmemorykiller/parameters/adj
** Not advisable to meddle with this if no clear idea about what is being done. Use the SuperCharger script instead. Checkout the respective thread for more info.
[For me, this OOM regrouping made some task killings more difficult and it didn't relese RAM readily when needed for heavy games..(may not be same for others ). So I'm not using it at the moment. I'm setting up minfrees as described previously.]
How-to (briefly):
1) Get the latest SuperCharger script from the thread.
2) Make sure requirements are met. Eg: Rooted, Busybox installed.
3) Run the script through 'Script Manager-Smanager' app (with root access granted).
4) Read the output of the screen and reply to the prompts accordingly.
** Keep a cwm backup before attempting this, just in case..
5. Override the "Hidden app limit" of Android. [highlight](Need Root access)[/highlight].
In addition to the LMK driver mechanism described above, this is another parameter that leads to killing of Hidden and Empty apps. Apps are killed when the number of those apps go beyond the specified limits. (Traditionally it was 15, so no more than 15 hidden apps would stay in the background even if there's plenty of RAM). There's a build.prop setting which can control this in our SP. (Btw, services.jar patching mentioned above makes that limit to 70). With the build.prop setting mentioned, we could make it to even 150 ! (This way, we can maximize multitasking and app killing is fully handed over to LMK minfrees, which we can control).
How-to:
Code:
ro.sys.fw.bg_apps_limit=70
Add this line to end of build.prop file (in /system) and leave another blank line below that, and save the file. Then reboot.
Tip: Build Prop Editor is an easy way to edit the build.prop.
** Always keep cwm backups before doing these kind of things.
How to test:
a) Install CatLog app (need root) [This is for reading Logcat]
b) Run it and enter "longer" (without quotes) in the filter bar. Might get a filtered output like this:
It means that the 24th Empty app had got killed, because of exceeding the hidden app limit. This is after services.jar patching making the Hidden app limit to 70. Before it was #17 if I remember correctly.
c) Check the same output after applying the build.prop setting. Should get a little increase. (When I made Hidden app limit to 100, output was #34th empty app gets killed. So, I wen't upto 150 until that kind of output disappeared ).
## Credits to @zeppelinrox for finding that build.prop setting. You can read what happened here in his thread.
How it works:
By @zeppelinrox
In Android 4.2 the max hidden apps are divided into 2 parts (In AMS smali the value is stored in "mProcessLimit")
Part of it goes towards hidden apps.
Part of it goes towards empty apps.
So what happens is it gets the max apps limit (v2)
It gets multiplied by 2 so "v2" is doubled in value.
Now... that is divided by 3 and that value is assigned to empty apps (v13)
Finally, empty apps (v13) is subtracted from v2 to give you hidden apps (v17)
So by default, there are MORE empty apps than hidden apps!
2/3 are empty
1/3 are hidden
So your original config was probably...
max hidden apps = 25
empty apps = 17 (25x2/3)
hidden apps = 8 (25-17)
So normally (without jar patching), if the limit is 70 it would break down like this...
max hidden apps = 70
empty apps = 46 (70x2/3)
hidden apps = 24 (70-46)
** Services.jar patching reverses this ratio (to give more allowance to Hidden apps than Empty apps. Then it results in:
max hidden apps = 70
empty apps = [highlight]23[/highlight] (70x3/9)
hidden apps = 47 (70-23)
Click to expand...
Click to collapse
That's why my 24th Empty app was getting killed with app limit of 70. You might get a totally different value if this build.prop setting is applied without services.jar patching. Appreciate your feedback
[highlight]** Please Note: I'm no dev. I wrote this according to what i understood by reading around in the net. I'd be more than glad if anyone points out any shortcomings/improvements. Thanks.[/highlight]
Credits/Sources
@zeppelinrox for his supercharger thread with overwhelming info, for finding out the build.prop setting in our SP, for explaining things and many more!
@androcheck for his thread
Took more info from here, here, here, and here.
[Highlight]An interesting observation...[/highlight]
Many of us refer to 'Settings>Apps>Running' to see how much free RAM is available at a particular moment. Generally we believed that it shows the correct value. But, some observations makes that value doubtful. E.g: This value doesn't tally with /proc/meminfo values. Furthermore, 'Free RAM' indicated by other apps at times are totally different.
(1).CoolTool - 121 MB
(2).meminfo (watch cat /proc/meminfo) - Looks compatible with cooltool value.
(3). Android says - 23MB!!??
**(all 3 values were updating realtime..)
Sometimes it goes the other way:
(gave time to settle down of course)
Any thoughts?? Does anyone experience like this or only me?
Just in case..
mrhnet said:
@androcheck for his thread...
Click to expand...
Click to collapse
Hi @mrhnet: I got pinged by your mention of my username. Thank you for this valuable thread! It's so important for xda having people around which actually explain and give knowledge to others! This is how a community should work! Great work! :good:
P.S.: Also thanks for giving me credit. That's not to be taken for granted. When I search the web for the unfortunate typo in my posting "on Android the current forefround application" I find a lot of resources which simply copied my words and often did not give any credit. So I appreciate this very much!
@androcheck
Thanks for the encouragement..
nice tutorial with full descriptions...great..:good:
This is wonderfull! I will add this to the tutorial Index this weekend
mrjraider said:
This is wonderfull! I will add this to the tutorial Index this weekend
Click to expand...
Click to collapse
Thanks. That's nice of you
thx u very much for the detailed explanation, gonna try ur recommended values later
great bro can be a sticky thread
mrhnet said:
Just in case..
Click to expand...
Click to collapse
Nice thread dude.
Now I'm glad that I had patience with your patching issues lol
However I don't think I have the patience to go into every tiny detail which is why I link to @androcheck 's thread in my original Supercharger OP (which is now post #3)
And you may find useful the new tool that I'm finally on the verge of releasing...
androcheck said:
Hi @mrhnet: I got pinged by your mention of my username. Thank you for this valuable thread! It's so important for xda having people around which actually explain and give knowledge to others! This is how a community should work! Great work! :good:
P.S.: Also thanks for giving me credit. That's not to be taken for granted. When I search the web for the unfortunate typo in my posting "on Android the current forefround application" I find a lot of resources which simply copied my words and often did not give any credit. So I appreciate this very much!
Click to expand...
Click to collapse
Yeah don't you hate that... personally I'm to lazy to copy other people's efforts and rather link to them while doing something new.
No sense in retreading a good tire
zeppelinrox said:
Yeah don't you hate that... personally I'm to lazy to copy other people's efforts and rather link to them while doing something new.
No sense in retreading a good tire
Click to expand...
Click to collapse
Thanks.
I didn't take any offense, if not I would have written it, someone else would have. In the end the knowledge has spread.
@zeppelinrox
I'm so glad about your comments on this thread. Thanks
Awaiting for your new works.. as always..
mrhnet said:
@zeppelinrox
I'm so glad about your comments on this thread. Thanks
Awaiting for your new works.. as always..
Click to expand...
Click to collapse
Soon.
It's done but gotta write up an OP
Edit: Done http://goo.gl/9H58pS
This is a great thread, you've explained everything very well. :good:
In my experience, RAM management works best if I set very low LMK values, like this. Anything higher means processes will get closed sooner.
Multitasking is good with this, not very good, though, because this is a Sony ROM, but still way better than higher values.
But be warned, using these values on stock 4.3 made it unstable for me, but it works on stock 4.1 without any problems.
Also, I've read on some sites that Sony will release Kitkat for the SP in June, and Kitkat has ZRAM enabled and also some other memory management-helping changes are made by Google. So I really hope it will be released for our device.
Edit (05.23): Well, it seems after a few days of testing, that these low values don't do anything good. The phone slows down a lot. So, this post might be considered pointless. Anyway, it was a good experiment.
I found one thing: in /proc/meminfo it shows more than 200 MB at Cached, but the launcher still redraws when i press Home in Chrome, and sometimes when going back from minfree manager (while chrome is running). So why doesn't the system utilize the Cached memory instead? I see that you, mrhnet, have 78 MB cached on one of the screenshots... Is this some sort of ram management bug in the stock 4.1 or what?
Lajbymester said:
I found one thing: in /proc/meminfo it shows more than 200 MB at Cached, but the launcher still redraws when i press Home in Chrome, and sometimes when going back from minfree manager (while chrome is running). So why doesn't the system utilize the Cached memory instead? I see that you, mrhnet, have 78 MB cached on one of the screenshots... Is this some sort of ram management bug in the stock 4.1 or what?
Click to expand...
Click to collapse
200mb cached means it's included in "free RAM". But it changes according to RAM demand/usage by apps. (Give "watch cat /proc/meminfo" command [without quotes] in a terminal to see; "watch" command runs what comes after that every 2 seconds). Maybe, by the time you switch from Chrome to terminal, Cached amount might have changed. (I think Chrome is a memory hog btw; haven't used it much).
If you really want to see what was in meminfo while chrome is on, I suggest to "record" meminfo values to a file real-time. Can do like this:
*Open terminal emulator
*go to /sdcard
Code:
cd sdcard
*append output of meminfo to a file every 2 seconds
Code:
watch cat /proc/meminfo >> memlog.txt
*leave terminal emulator in background and do whatever in chrome. Meminfo values should be recording in the background; terminal is not easily shutdown because it has a notification (apps having a notification saying that it's running has a high priority I think).
*then come back to terminal emulator and do a "ctrl+c" to break the recording (see terminal settings to know what's assigned as ctrl button)
*now you have a memlog.txt file in sdcard with meminfo output every 2 seconds (might look overwhelming ). If 2 seconds is too frequent, can adjust "watch" command accordingly (eg: watch -n 10 cat /proc/meminfo). Just give "watch" command to see it's usage.
You can go through that file leisurely to see how Cached etc have changed with time. Can filter with "grep" to avoid other gibberish.
Eg:
Code:
grep -w Cached: memlog.txt
This command outputs only the "Cached:" line in the file. [Remember: everything is case sensitive in Linux]. You can even write that output to another file for ease (can do for other values also):
Code:
grep -w Cached: memlog.txt >> Cached.txt
grep -w MemFree: memlog.txt >> MemFree.txt
grep -w Buffers: memlog.txt >> Buffers.txt
Then can go through these files leisurely to see min/max values. I think you can do lot of things with "grep". A Linux geek might even arrange these data to make a graph! @zeppelinrox is the man for this I think
Thanks for the very detailed reply
Actually I was doing the "cat /proc/meminfo" command on the computer using adb on the computer, so switching apps wouldn't interfere. ("watch cat /proc/meminfo" doesn't work for some reason, it doesn't output anything but the actual date). And while looking at Chrome with 2 heavy desktop websites, it was showing ~220 MB at Cached. It doesn't ever go below 180 MB...
Ok.
Dunno exactly what's wrong there.. Just remembered a part from kernel sources I've mentioned in OP:
The driver considers memory used for caches to be free, but if a large
* percentage of the cached memory is locked this can be very inaccurate...
Click to expand...
Click to collapse
Maybe part of Cached is "locked"?? Can do a reboot and see whether the situation persists (if not done already).

[9.0 r1] Is 'dalvik.vm.heapsize = 36m' a mistake?

Hi Essential Phone owners,
Can someone confirm that the Essential Phone has set dalvik.vm.heapsize to 36m instead of... 512m?
The build.prop in the vendor partition of the phone has this line:
dalvik.vm.heapsize=512m
// line 29
But the build.prop in the system partition has:
dalvik.vm.heapsize=36m
// line 68
Any devs know which one gets applied last? I think at the current state it would be heapsize=36m which is unusual.
For anyone that can edit build.prop on their own phone you can try this,
1. Remove dalvik.vm.heapsize=36m in system's build.prop
Or
2. Add dalvik.vm.heapsize=512m at the bottom of the system's build.prop
:angel:
this is extraordinarily interesting due to the fact that ive seen reports on reddit claiming this makes scrolling smoother. i deleted the heapsize=32 line and noticed maybe a slight difference. nothing night and day but a small improvement. granted i am running stock with elementalX kernel but its still worth noting that in my case it seems to yield a slight improvement
JBlaze05 said:
this is extraordinarily interesting due to the fact that ive seen reports on reddit claiming this makes scrolling smoother. i deleted the heapsize=32 line and noticed maybe a slight difference. nothing night and day but a small improvement. granted i am running stock with elementalX kernel but its still worth noting that in my case it seems to yield a slight improvement
Click to expand...
Click to collapse
Where did you find reports on reddit?
Anyways thanks for your input!
TFutoMaki said:
Where did you find reports on reddit?
Anyways thanks for your input!
Click to expand...
Click to collapse
this would be the thread
This means nothing...
su
getprop|grep heapsize
It's all placebo
Heap size and scrolling? Wtf. No, just no. I have a thread on here that actual helps with the scrolling. Add the following to your build prop in /system to improve scrolling lag and stutters.that other stuff would do nothing.
#Property to enable touch optimizations
persist.vendor.qti.inputopts.enable=true
persist.vendor.qti.inputopts.movetouchslop=0.6.
The 0.6 can be changed to your liking. 6 works well. Don't go past 8 or **** gets weird.
Thanks you all, I got with me the Essential phone now so yeah seems like it is system build.prop, and then vendor build.prop applies over it. Interesting stuff that I should remember
Dalvik heapsize
36mb heap size is use before for low memory devices that have only 512mb of physical memory or ram, Running in gingerbread os etc. that uses only small amount of physical memory and not much features added on the Android operating system, The answer to your question is 36mb heap size is not gonna work in newer Android devices and it can cause bootloop, because the newer Android Operating System requires higher usage of physical memory for full functionality.
"vendor_build.prop and system_build.prop Is the same list in functionality they only have different location, the system combining them in to one build.prop, to check your full system combined build.prop install terminal emulator and enter- "getprop"
vendor.prop is should be for Rom versions and the system.prop is for manufacturer default Android features and device features configuration.
marvinxxx said:
36mb heap size is use before for low memory devices that have only 512mb of physical memory or ram, Running in gingerbread os etc. that uses only small amount of physical memory and not much features added on the Android operating system, The answer to your question is 36mb heap size is not gonna work in newer Android devices and it can cause bootloop, because the newer Android Operating System requires higher usage of physical memory for full functionality.
"vendor_build.prop and system_build.prop Is the same list in functionality they only have different location, the system combining them in to one build.prop, to check your full system combined build.prop install terminal emulator and enter- "getprop"
vendor.prop is should be for Rom versions and the system.prop is for manufacturer default Android features and device features configuration.
Click to expand...
Click to collapse
You answered a 2 year old post...

Categories

Resources