Develop Bugs

[TWEAK] Automatic Brightness levels!

Issue: http://code.google.com/p/cyanogenmod/issues/detail?id=2298
After toying around with the automatic brightness I'm now here to share my settings ...
I use the following settings:
Light sensor filter enabled.
Window length 10 seconds.
Reset threshold 400 lux.
Sample interval to 0.5s.
Light levels use custom checked.
Screen dim level, not sure what it is for but I have it on 1 instead of 20. ((edit: I found what it is for, it's the step size the filter takes? Or not? :s))
Edit other levels...
Number of levels: 18
0 1
10 1
117 17
225 33
272 49
320 65
480 80
640 96
960 112
1280 128
1940 144
2600 160
4200 175
5800 192
6900 207
8000 223
9120 239
10240 255
Allow light decrease checked.
Decrease hysteresis to 10%.
I hope people like my light settings, if you don't please tell me why

Reasons why some settings should be altered:
Reset threshold, should be able to set to 100 and 200 lux. At the moment if you walk into light it takes the filter some time to go up, so 100 or 200 lux would trigger a reset faster. Also the sensor starts at 225 lux so why 400 as a minimum in the first place?
Window length, as for the above, if you walk into light a smaller window length would help put brightness up much quicker in combination with a smaller reset threshold.
If the above two settings could be added in CMParts/ODParts that be great as the filter would be much more responsive to short period light changes. For example if you go from outside to inside or visa versa.
And maybe it would even be a better idea to remove the whole custom light levels and add a linear function to it to go with the filter (configurable) and just have 254 steps (1-255) over 10-10240?
Adding 254 steps yourself is ... A PAIN ><

English please
guys i know there is a problem with the light sensor in desire and i have the same case with mine it this is all about it please let me know how to fix it please.

shazan said:
guys i know there is a problem with the light sensor in desire and i have the same case with mine it this is all about it please let me know how to fix it please.
Click to expand...
Click to collapse
What ROM are you using? CyanogenMod and forks of it (OpenDesire, DeFrost etc) have a custom preferences menu where you can check out the light sensor values. That is when you leave the filter off and goto edit other levels. Hold your phone in line with a TL light and it should jump to 1280.
Do you see the top most number change when light changes?

Call me crazy, but I am ><
I put the whole table into the automatic backlight custom levels: http://www.linux-box.nl/~sjoer/1to255/1to255.php
And it works really well with light changes, it should work even better if reset threshold can be lower (200 or maybe 100) as it will respond to bright light <> no light much better.

how did you did that?
without typing lol

This is insane..... so much trouble for such a simple task. Automatic Brightness. On winMO i used g-lite wich was satisfacatory. A have the desire for a month now. I searched from a similar soft and i didn't find. But i'm not gooing to try this much trouble for something that should be easy. Thank you.

Im sorry but....HOW do I apply this ?

Can this be applied to other roms?
I am using Pinky desire and would love to do this.
Phil

philje123 said:
Can this be applied to other roms?
I am using Pinky desire and would love to do this.
Phil
Click to expand...
Click to collapse
yes and for stock roms please

The screen minimum value is 10-255, so how can I set "1" to the first 2 levels?
I set 10, and I like the settings overall.

sfjuocekr said:
I hope people like my light settings, if you don't please tell me why
Click to expand...
Click to collapse
First off, "10 1" is redundant as you already cover that from 0 to 9. So 17 levels should be enough. Second, on the last line "10240 225" you probably meant "10240 255". Testing your settings with these modifications now. I find you have a lot of levels, probably can do with less to reduce flickering, but as I said, testing these first.

Can we use these settings in a Sense rom and if yes how?What file do we have to edit?

so useless guys.
setup max brightness and enjoy the brilliant screen.
it takes less battery than this tool to constantly check your ambient brightness.

Can someone please make a post about how to use this (and especially on Sense Roms)? So far it only shows us "which sensor-level should be what brightness" but it doesn't provide any information on how to apply it.
I assume CM either has an app for this installed (if so, please tell us WHICH so we can use it too) or a shell-script in background (if so, tell us WHICH) adjusting the settings.

Could anyone post a how-to use these settings?
Edit: Nvm, it's under: Cyanogen Settings.
Btw under "Edit other levels" you should only change the boxes that's under "Lower"? You shouldn't touch "Screen" and "Button"?

Trying this out, and will see how it goes. Only have 5 levels on my current setup, so this should be a lot smoother

snudel said:
so useless guys.
setup max brightness and enjoy the brilliant screen.
it takes less battery than this tool to constantly check your ambient brightness.
Click to expand...
Click to collapse
Is that true?

any more improvements?
and how can i backup this setting?
i wont to input it again when i flash a new rom :-(

sfjuocekr said:
Issue: http://code.google.com/p/cyanogenmod/issues/detail?id=2298
After toying around with the automatic brightness I'm now here to share my settings ...
I hope people like my light settings, if you don't please tell me why
Click to expand...
Click to collapse
Since the source code of Sense kernels is available now, would it be possible to write the tool for Sense ROMs too? You sure would do a lot of people a big favor

activity manager cpu 100%

Hi
i have a weird thing , dont know if its rom related but defenetly noticed it after rooting my device and installing cosutm roms. well i only used ARHD since 2.0.09 and i love it.
but , what happens is that suddenly and out of nothing (after like hours/days and the rom running smooth and ultra fast) , system cpu usage jumps to 100% and never bugs off only through a restart, and this seems to happen with all the different versions of ARHD i had, even though i install most of them with full wipes. but this i don't understand and it annoyes me cos it uses this cpu amount and drains battery and it happens suddenly and randomly , dunno what triggers it, and no matter how i tried to track it to see the error but couldn't find a thing.
i just hope u can help me by taking a look at this log i saved from android systeminfo app registering some errors (3 min log and it drained 14% battery ) , it shows something about "activity manager", im not a developer and i know nothing about those codes, but would be awesome if someone helps me out with any tip please.
thank you.

I am not a DEV but i don't think your log file includes any clue of what is causing your problem. Do you have sense account on? or any types of account that let you track your phone?

Activate usb debugging
Seems to be the bug with the .init process.
Sent from my Desire HD using Tapatalk

thank you for the replies , i already have usb debugging on. dunno what is causing this, its totally random and its driving me nuts.

can you see a process that uses 100% cpu in android system info? If yes, try to kill it and look at your cpu usage.
CPUNotify is a great tool. It shows cpu usage in the notification bar
Sent from my Desire HD using Tapatalk

the process showing 100% cpu usage (not always but randomly, no idea what triggers it ) is system , and u can't force close or end that task

Hmm strange... i can't even find a process called activity manager on my phone...
Well i don't know but maybe it's related to the DroidDream malware. Some apps in the market were infected with this virus. And i've read that the virus gains root access and can download other apps in the background.
Here's a link: http://forum.xda-developers.com/showthread.php?t=977154
I really don't know if it's related to this but it just came to my mind
Sent from my Desire HD using Tapatalk

thx for the help mate , but i dont think its related to droidream cos ive been having this issue since a while (long time before droidream was up )
im still monitoring to find out what is causing this issue.

i have the same issue since going to a rooted ROM (HD rev 2.0.12). tried every build up to 3.0 and i have the same issue. it seems to be randomly triggered (i've seen it trigger after playing "robo defense", playing music, making a call etc).
i have no sense account and dont have malware and have usb debugging on
I fix/hack it this way..open adb shell
type
chmod 700 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
ie disallow anything (even system_server) from reading this file.
in fact i automate this command to run every 15 mins using an app called phone prioritizer. as soon as you type the chmod..your logcat will stop spinning and all will be well (iove not seen any side effects yet).
ps. you have to run this every time you open setcpu, as it will reset the permission on this file to 777/666 depending on the version of setcpu you have.
Activate usb debugging
Seems to be the bug with the .init process.
Click to expand...
Click to collapse
nope that totally different. that problem shows itself in "top -m 5" as init taking all the cpu ..this will show as system_server.
the "bug" manifests itself in this kernel file:
goto url github.com/android/platform_frameworks_base/blob/master/services/java/com/android/server/ProcessStats.java#L157
it spins on getCpuSpeedTimes() where it reads time_in_state..why it does this i dont know..it looks like mBuffer is corrupt as nosuchelementException would indicate that the buffer didnt have 2 words per line of the file yet the real file looks fine if you cat it (readFile seems not to initialise this on reading it to null first (but i'm not a java expert..maybe ".read" does this) so perhaps it has junk in it on certain conditions..any java guys out there can explain why they made this a glbal variable? it seems like it should be a local one)
by chmodding the file i cause an IOException to throw in readFile (which is then ignored and the return is gracefully set as null..this then skips the infinate loop).
you can see this issue in a few bugs like android issue 9733..oxygen rom issue 507 etc.

wow , cheers mate for the help , sounds a bit complicated for me but at least we know what it is now and how to get over it.
but how come mike1986 doesnt know about this bug and its fix ? he could incorporate this into his next build so it saves us that command run every 15 mins. or it cant be incorporated ?
someone should tell him to be honest
but cheers for explanation mate, thank you

Is Apache14 informed about this? Maybe he can solve it in next Kernelversion.

walda said:
Is Apache14 informed about this? Maybe he can solve it in next Kernelversion.
Click to expand...
Click to collapse
i have no idea about that , if he does then im sure he will fix it

As I read in mikes 3.0 thread, he is informed. Fine...
sent from my DHD via Tapatalk

further to this.
in ProcessStats.java (im not sure if this is a kernel file or if it sits just outside the kernel).
mBuffer looks to me to be the main problem.
1. in apaches rom, which is overclocked he defines 23 CPU speeds..ProcessStats.java only allows 20
Code:
private long[] getCpuSpeedTimes(long[] out) {
long[] tempTimes = out;
long[] tempSpeeds = mCpuSpeeds;
final int MAX_SPEEDS = 20;
if (out == null) {
tempTimes = new long[MAX_SPEEDS]; // Hopefully no more than that
tempSpeeds = new long[MAX_SPEEDS];
this is a minor issue..as this overflow is trapped in the loop anyway:
Code:
if (speed == MAX_SPEEDS) break; // No more
however, the definition of mBuffer is too small:
Code:
private byte[] mBuffer = new byte[256];
my file at the moment is 300 bytes. the readFile reads only once instead of looping until end of file:
Code:
int len = is.read(mBuffer);
is.close();
so only the first 256 bytes are ever read.
My assumption is that IF the files first 256 bytes ends up cutting off the last read line (and that line lies in the first MAX_SPEEDS lines of the file) before the speed time element..this causes a NoSuchElementException to throw..as the last line will be like
921600 255
960000 750
998400 8042
10368
ie the line
1036800 3089
was cut off too soon and this code
Code:
long val = Long.parseLong(token);
tempSpeeds[speed] = val;
token = st.nextToken(); <-- here
val = Long.parseLong(token);.
in getCpuSpeedTimes() fails as it cant see the timing?
would then fail on the second nextToken().
the big question is who owns that code in our custom ROM? is it the same as the original android code so we are at the mercy of Google to fix it or is this something Mike / Apache will be able to patch up ..assuming i'm making sense
the only workaround is as i said before: to chmod this file to 700 and ensure it stays there (avoid using setcpu as it changes the permissions).
You can probably also reduce this by limiting the CPU frequency range your phone uses (ie keep the filesize smaller)..if you have profiles that span 200mhz to 1.2ghz then you will probably hit this sooner
i did a test.
1. rebooted my phone..ensured time_in_state had permissions -r--r--r--
2. manipulated CPU frequency using cpu tuner to make all frequencies have at least 5 bytes per line.
once the first 20 lines were > 256 bytes and the 256nd byte sat between <cpu speed> and <time spent at that speed> i get the loop.
eg just before the issue arose i saw:
Code:
# cat time_in_state
cat time_in_state
245000 200030
422400 12676
460800 11929
499200 10333
537600 37021
576000 10685
614400 13672
652800 10646
691200 14864
729600 13956
768000 12662
806400 15025
844800 22094
883200 26741
921600 10389
960000 9937
998400 17606
1036800 6864
1075200 1560
1113600 1296
1152000 2158
1190400 2540
1228800 2463
i had my cpu pinned to 960 mhz.
the 256 at this point lies here:
Code:
1075200 1560
1113600 1
ie line 20 is cut off after 1..this is still "valid" in terms of the data in mBuffer..but once 960 rolled into five digits
Code:
# cat time_in_state
cat time_in_state
245000 200030
422400 12676
460800 11929
499200 10333
537600 37021
576000 10685
614400 13672
652800 10646
691200 14864
729600 13956
768000 12662
806400 15025
844800 22094
883200 26741
921600 10389
960000 10288
998400 17606
1036800 6864
1075200 1560
1113600 1296
1152000 2158
1190400 2540
1228800 2463
the 256 byte now meant the last line shifts to:
Code:
1036800 6864
1075200
the 2nd word is now totally missing!
as soon as this happened..my logcat started issuing
Code:
Unexpected exception collecting process stats
java.util.NoSuchElementException
at java.util.StringTokenizer.nextToken(StringTokenizer.java:272)
at com.android.server.ProcessStats.getCpuSpeedTimes(ProcessStats.java:596)
at com.android.server.ProcessStats.getLastCpuSpeedTimes(ProcessStats.java:568)
at com.android.server.am.ActivityManagerService.updateCpuStatsNow(ActivityManagerService.java:1657)
at com.android.server.am.ActivityManagerService$4.run(ActivityManagerService.java:1583)
errors.
something later on then causes this behavior to go into a full tight loop (as once the issue starts..it just issues this every few seconds..so most uses wont notice it).

didnt mike fixed it with his latest release (ARHD 3.1) ?

Goodm7sn said:
didnt mike fixed it with his latest release (ARHD 3.1) ?
Click to expand...
Click to collapse
mike changed the file permission to 700 to get around it. the bug is still there in the code though. also im not sure if hes scheduling it to make it stay at 700..if not then users with setcpu installed may still get the problem (as setcpu changes the file permission back to 777/666 when you open the gui).

DazzaL said:
i have the same issue since going to a rooted ROM (HD rev 2.0.12). tried every build up to 3.0 and i have the same issue. it seems to be randomly triggered (i've seen it trigger after playing "robo defense", playing music, making a call etc).
i have no sense account and dont have malware and have usb debugging on
I fix/hack it this way..open adb shell
type
chmod 700 /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state
ie disallow anything (even system_server) from reading this file.
in fact i automate this command to run every 15 mins using an app called phone prioritizer. as soon as you type the chmod..your logcat will stop spinning and all will be well (iove not seen any side effects yet).
ps. you have to run this every time you open setcpu, as it will reset the permission on this file to 777/666 depending on the version of setcpu you have.
nope that totally different. that problem shows itself in "top -m 5" as init taking all the cpu ..this will show as system_server.
the "bug" manifests itself in this kernel file:
goto url github.com/android/platform_frameworks_base/blob/master/services/java/com/android/server/ProcessStats.java#L157
it spins on getCpuSpeedTimes() where it reads time_in_state..why it does this i dont know..it looks like mBuffer is corrupt as nosuchelementException would indicate that the buffer didnt have 2 words per line of the file yet the real file looks fine if you cat it (readFile seems not to initialise this on reading it to null first (but i'm not a java expert..maybe ".read" does this) so perhaps it has junk in it on certain conditions..any java guys out there can explain why they made this a glbal variable? it seems like it should be a local one)
by chmodding the file i cause an IOException to throw in readFile (which is then ignored and the return is gracefully set as null..this then skips the infinate loop).
you can see this issue in a few bugs like android issue 9733..oxygen rom issue 507 etc.
Click to expand...
Click to collapse
Thanks mate, your solution is really effective on my DHD with revolution 3.0.
I am going to reflash with revolution 3.1, hopefully 3.1 will cure the cpu 100% usage

im on android revolution HD and i can confirm this , 100% system cpu of death is still here, didnt get fixed , had to change setcpu frequency and it stopped
meh phone cant last 12 hrs without a restart, frustrating.

DazzaL said:
mike changed the file permission to 700 to get around it. the bug is still there in the code though. also im not sure if hes scheduling it to make it stay at 700..if not then users with setcpu installed may still get the problem (as setcpu changes the file permission back to 777/666 when you open the gui).
Click to expand...
Click to collapse
if setcpu changed the range once the gui is opened , what do u recommend us to use for overclocking ? something safer
thx for helping

I read that it happens with CPU tuner and even without anything also!
The only solution I see is to fix the frequency file.
sent from my DHD via Tapatalk

[Tips] Screen Color Calibration for the Galaxy Nexus

After using the Galaxy Nexus for two weeks, I found the screen color of the new amoled+ is much better than the Nexus S, but still inaccuracy. I'm a part-time photographer who keen on the right Gamma, color accuracy and color temperature.
So I just finished some test with such things:
Galaxy Nexus
franco Kernel 18.5 nightly(with the ColorControl from Ezekeel)
Voodoo Screen Test app
x-rite i1 Display 2 color meter
HCFR software
The test result was not so good...
Average Gammar value is about 1.9, far from the ISO stand 2.2. So the color is just too bright (I'm not saying screen brightness).
The shadow part (0-40% gray level) of 3 color curve were almost out of trim. In another words, incaauracy color balance.
As the color unbalance. The color temperature is starting from lower than 5500K to 6500K, which the ISO stand is 6500K at any color level.
I also tested the ColorControl in franco Kernel. After the adjustments, Gammar value is still bad, but I save the (most part of) color balance & color temperature in the end.
The adjustments step by step:
Make sure you have a rom/mod with /init.d autorun function.
Bye, stock rom...
Make sure you have a kernel with ColorControl function.
Such like Ezekeel, franco...Else? I don't know.
Set the screen brightness to 50%.
It's the mesurement "baseline". But why 50%?
Because, at this point the screen has a brightness about 120 Lux--also a ISO stand. So, it's very close to our desktop LCD.
Make a new file as /etc/init.d/900colorcontrol-b50
Which could be done by Root Explorer or adb.
Inside the file, type such line:
Code:
echo "-10 0 -10" > /sys/class/misc/colorcontrol/v1_offset
echo "1820000000 1900000000 2000000000" > /sys/class/misc/colorcontrol/multiplier
I choose "182 190 200" here, because the default value was about 200. Rising will increase the risk of LED Burn-in.
And, don't forget the 7 zero!!!
Just reboot & enjoy the almost right color temperature.
It's (6500±300)K at any color level in my device. Not perfect, but much better indeed.
Done, that's all I can do for you.

Thanks so much for the mod.
I'm willing to test your new calibration for the GNex color but how can I revert back to stock in case of problem ?
So I guess we can only use this modification at 50% of brightness ? If we change to auto, how could it be ?

Sorry for being a noob here, but this is compatible with any rom/kernel right? I'm currently running on AOKP Build 25 and Popcorn kernel 7.1
Thanks,
Mosh

Hi, and thank you for offering your expertise. I'm not confident in doing the above.... Can you offer a little bit more step by step?
I've played around with root explorer which I imagine is what is necessary to change these values.you lost me at the 2nd step.....
Also, is 50% necessary?
Thanks kindly,
_______________________________
frAncO Kernel ;-P

mazubo said:
Hi, and thank you for offering your expertise. I'm not confident in doing the above.... Can you offer a little bit more step by step?
I've played around with root explorer which I imagine is what is necessary to change these values.you lost me at the 2nd step.....
Also, is 50% necessary?
Thanks kindly,
_______________________________
frAncO Kernel ;-P
Click to expand...
Click to collapse
mohitrocks said:
Sorry for being a noob here, but this is compatible with any rom/kernel right? I'm currently running on AOKP Build 25 and Popcorn kernel 7.1
Thanks,
Mosh
Click to expand...
Click to collapse
heo_con184 said:
Thanks so much for the mod.
I'm willing to test your new calibration for the GNex color but how can I revert back to stock in case of problem ?
So I guess we can only use this modification at 50% of brightness ? If we change to auto, how could it be ?
Click to expand...
Click to collapse
Step by step detail added. Thx for reading~

Thanks for the guide!
Sent from my Galaxy Nexus using XDA App

You can change all of these settings from Franco's kernel updater program directly without modifying any files.
The OP's settings appear a little warm at first but I'm liking them so far...
Sent from my Galaxy Nexus using xda premium

Can you please add this file 900colorcontrol-b50

sooooo do i make a folder in system like this?
system/etc/init.d/900colorcontrol-b50 and then add that text above or??

Instead of making that script, can we just input those numbers into the Color Control?
-10, 0, -10 for Gamma (RGB);
182, 190, 200 for Multiplier (RGB)
Right?

Thank!
your feeling about color is exactly. Gray is dirty, it's not sync at all pixels.
I hope someone changes this by kernel - easy for me control everything
After flash franco kernel it's better more but not perfect.
If this problem is not improved, i'll buy other phone that uses Superamoled PLUS replace this one . HIZzzz

These settings look green to me
Sent from my Galaxy Nexus using Tapatalk

Indeed... especially settings menu looks very greenish!
But maybe I get used to it...
Edit: Maybe a typo? '-10 0 10' looks not that bad at all ;-)
jornbjorn said:
These settings look green to me
Sent from my Galaxy Nexus using Tapatalk
Click to expand...
Click to collapse

phunghoang24 said:
Thank!
your feeling about color is exactly. Gray is dirty, it's not sync at all pixels.
I hope someone changes this by kernel - easy for me control everything
After flash franco kernel it's better more but not perfect.
If this problem is not improved, i'll buy other phone that uses Superamoled PLUS replace this one . HIZzzz
Click to expand...
Click to collapse
And that would do absolutely nothing
SAMOLED Plus displays are identical to the SAMOLED HD displays when it comes to colors and such.

It would be better and more easy if someone was able to do an app like this one that works for the Nexus One :
http://forum.xda-developers.com/showthread.php?t=745248
I really miss this app since I've bought my Galaxy Nexus

Thanks for the info. I had mine looking very similar but with a combination of lower brightness and higher multiplier values. Nice to have it set now without the additional risk of burn in. Thanks a ton.

screen looks greenish compared to franco's recommended value, using his instead but thanks for the write up.

kashix said:
screen looks greenish compared to franco's recommended value, using his instead but thanks for the write up.
Click to expand...
Click to collapse
must be a typo in his gamma settings -10,0,10 is ALOT better (=

Great find colors are much more accurate now

These settings are way off on my device, its too green.

[Q] Screen showing up late on new call

I have this strange problem on cm7.2 that on a receiving a new call my willy's screen shows up pretty late to answer that call, after 4 to 5 rings. its only happening in ring style lockscreen. If I change it to sliding tab then it works ok. I have set the lowest value of CPU at 352 MHz. Anyone else with this problem?

sixline said:
I have this strange problem on cm7.2 that on a receiving a new call my willy's screen shows up pretty late to answer that call, after 4 to 5 rings. its only happening in ring style lockscreen. If I change it to sliding tab then it works ok. I have set the lowest value of CPU at 352 MHz. Anyone else with this problem?
Click to expand...
Click to collapse
usually this is nothing else than good old lag - just make sure that there aren't too many background processes running. I'm using Autostarts to control which apps are allowed to start in certain conditions plus Autokiller Memory Optimizer to set the minfree values (when the system will free up memory) plus - probably most helpful - setCPU. While the CM7 OC settings are already doing a good job to set min and max frequency and governor you can't set the value for screen off state explicitely...

eventcom said:
usually this is nothing else than good old lag - just make sure that there aren't too many background processes running. I'm using Autostarts to control which apps are allowed to start in certain conditions plus Autokiller Memory Optimizer to set the minfree values (when the system will free up memory) plus - probably most helpful - setCPU. While the CM7 OC settings are already doing a good job to set min and max frequency and governor you can't set the value for screen off state explicitely...
Click to expand...
Click to collapse
Thanks for reply. I've installed setcpu, Can u please explain how to explicitly set the value for screen state off in it? I cannot find this setting..

Ok I found that in profiles..I have set the minimum off screen value to 352 MHz..What do you think its OK?

sixline said:
Ok I found that in profiles..I have set the minimum off screen value to 352 MHz..What do you think its OK?
Click to expand...
Click to collapse
oh, for me 264MHz works (I had problems with 176 which I used before) - but like I said: many factors are involved here. It usually takes some trial and error to find your perfect settings.
You might also want to have a look at this thread: Autokiller memory optimizer. - xda-developers

eventcom said:
oh, for me 264MHz works (I had problems with 176 which I used before) - but like I said: many factors are involved here. It usually takes some trial and error to find your perfect settings.
You might also want to have a look at this thread: Autokiller memory optimizer. - xda-developers
Click to expand...
Click to collapse
OK. Thanks a lot

Also I've found this improves my calls....
ro.telephony.call_ring.delay=0
add this line into your buildprop (edit) save the settings and then delete the buildprop backup it creates.
I think this is the same tweak scratch pointed me to and also made a flashable zip etc but I can't find it so I'm not sure if its the same as. This is a tweak I found in a buildprop tweak thread somewhere but I use it and notice a difference.hope it helps.
P.s reboot after you save the edited buildprop.
Jokerdroid

slymobi said:
Also I've found this improves my calls....
ro.telephoney.call_ring.delay=0
add this line into your buildprop (edit) save the settings and then delete the buildprop backup it creates.
I think this is the same tweak scratch pointed me to and also made a flashable zip etc but I can't find it so I'm not sure if its the same as. This is a tweak I found in a buildprop tweak thread somewhere but I use it and notice a difference.hope it helps.
P.s reboot after you save the edited buildprop.
Jokerdroid
Click to expand...
Click to collapse
I'm collecting that information now. Perhaps i can go back to 176Mhz
Swyped from my HTC Wildfire (Buzz)

slymobi said:
Also I've found this improves my calls....
ro.telephoney.call_ring.delay=0
add this line into your buildprop (edit) save the settings and then delete the buildprop backup it creates.
I think this is the same tweak scratch pointed me to and also made a flashable zip etc but I can't find it so I'm not sure if its the same as. This is a tweak I found in a buildprop tweak thread somewhere but I use it and notice a difference.hope it helps.
P.s reboot after you save the edited buildprop.
Jokerdroid
Click to expand...
Click to collapse
Well thanks I'll try it

I applied all these things and now its a lot better. Thanks a lot guys

slymobi said:
Also I've found this improves my calls....
ro.telephoney.call_ring.delay=0
add this line into your buildprop (edit) save the settings and then delete the buildprop backup it creates.
I think this is the same tweak scratch pointed me to and also made a flashable zip etc but I can't find it so I'm not sure if its the same as. This is a tweak I found in a buildprop tweak thread somewhere but I use it and notice a difference.hope it helps.
P.s reboot after you save the edited buildprop.
Jokerdroid
Click to expand...
Click to collapse
are you sure about it?
I'd guess it should be
ro.telephony.call_ring.delay=0
(Without that Irish "e")
?
Swyped from my HTC Wildfire (Buzz)

eventcom said:
are you sure about it?
I'd guess it should be
ro.telephony.call_ring.delay=0
(Without that Irish "e")
?
Swyped from my HTC Wildfire (Buzz)
Click to expand...
Click to collapse
I've not got it with the "irish e" lol ?? So yes drop the e
Jokerdroid

slymobi said:
I've not got it with the "irish e" lol ??
Click to expand...
Click to collapse
just wanted to make a spectacular answer
But...
While originally thinking of Irish whiskey I came across that one here (and that was like WTF!?): phoney - Wiktionary

CPU Temp throttling fix on Lollipop

Did anyone know how to fix or what I need to mod in order to increase the max temp before the CPU start throttling? Im running stock rooted with TWRP on 5.0.1
Send from my LG-D851 Xposed with a bunch of good ****

Well I did edit the following files in system/etc/thermal-engine-8974.conf & thermal-engine-default.conf and change the value 65 to 75 (I understand that this is the cap temp to start throttling the CPU. Change value, fix permissions and reboot. Great performance after that, 0 lag, It does get a little warmer on load however, idle is normal temp. Recommended! (make sure you back up the files just in case ?
Send from my LG-D851 Xposed with a bunch of good ****

You can just go here and turn it off 3845#*851#

Still_living714 said:
You can just go here and turn it off 3845#*851#
Click to expand...
Click to collapse
Those settings are already off, at least on mine, but thanks for the advice. [emoji106]
Send from my LG-D851 Xposed with a bunch of good ****