[HOW TO] Tweak your touchscreen [update: 11/04/12] - Samsung Galaxy SL i9003

NOTE: The first six posts are a reply to the old post that I removed long ago.
I shouldn't have removed it completely.
Click to expand...
Click to collapse
This is the current configuration of the touchscreen:
Code:
=========== [TSP] Configure SET for normal ============
=== set_power - GEN_POWERCONFIG_T7 ===
0. idleacqint= 64, 1. actvacqint=255, 2. actv2idleto= 50
=== set_acquisition - GEN_ACQUIRECONFIG_T8 ===
0. chrgtime= 10, 1. reserved= 0, 2. tchdrift= 5
3. driftst= 1, 4. tchautocal= 0, 5. sync= 0
6. atchcalst= 9, 7. atchcalsthr= 27
=== [COLOR="Green"][B]set_touchscreen[/B][/COLOR] - TOUCH_MULTITOUCHSCREEN_T9 ===
0. ctrl=143, 1. xorigin= 0, 2. yorigin= 0
3. xsize= 18, 4. ysize= 11, 5. akscfg= 1
6. blen= 16, 7. tchthr= 32, 8. tchdi= 2
9. orientate= 1, 10.mrgtimeout= 0, 11.movhysti= 3
12.movhystn= 1, [COLOR="Red"][B]13[/B][/COLOR][B].movfilter= [/B][COLOR="Blue"][B]46[/B][/COLOR], 14.numtouch= 5
15.mrghyst= 5, 16.mrgthr= 40, 17.tchamphyst= 10
18.xrange=799, 19.yrange=479, 20.xloclip= 0
21.xhiclip= 0, 22.yloclip= 0, 23.yhiclip= 0
24.xedgectrl= 0, 25.xedgedist= 0, 26.yedgectrl= 0
27.yedgedist= 0, 28.jumplimit= 18
=== set_keyarray - TOUCH_KEYARRAY_T15 ===
0. ctrl=131, 1. xorigin= 16, 2. yorigin= 11
3. xsize= 2, 4. ysize= 1, 5. akscfg= 1
6. blen= 0, 7. tchthr= 45, 8. tchdi= 4
=== set_grip - PROCI_GRIPFACESUPRESSION_T20 ===
0. ctrl= 19, 1. xlogrip= 0, 2. xhigrip= 0
3. ylogrip= 5 4. yhigrip= 5, 5. maxtchs= 0
6. reserved= 0, 7. szthr1= 30, 8. szthr2= 20
9. shpthr1= 4 10.shpthr2= 15, 11.supextto= 10
=== set_noise ===
0. ctrl = 135, 1. gcaful(2bts)=0
2. gcafll(2bts)= 0, 3. actvgcafvalid =3
4. noisethr= 27, 5.freqhopscale= 0,6. freq[0]= 29
7. freq[1]= 34, 8. freq[2]= 39, 9. freq[3]= 49
10.freq[4]= 58, 11.idlegcafvalid= 3
=== set_total ===
0 , linearization_config.ctrl = 0
1 , twotouch_gesture_config.ctrl = 0
2 , onetouch_gesture_config.ctrl = 0
3 , selftest_config.ctrl = 0
4. cte_config.ctrl= 0, 5. cte_config.cmd= 0
6. cte_config.mode= 2, 7. cte_config.idlegcafdepth= 16
8. cte_config.actvgcafdepth= 63, 9.cte_config.voltage= 60
================= end ======================
To change it you simply need to run few commands:
Code:
echo [COLOR="Red"][B]13[/B][/COLOR][COLOR="Blue"]0[B]46[/B][/COLOR] > /sys/touchscreen/[COLOR="Green"][B]set_touchscreen[/B][/COLOR]
XX is the number of the option. In this example 13=movfilter.
YYY is the value you want to set. In this case 46. You must use 3 digits.
set_touchscreen is the file where you store this information. It's not always set_touchscreen, it could also be set_noise, set_acquisition etc...
To apply the changes you have to run this:
Code:
cat /sys/touchscreen/set_write
To get the new configuration run
Code:
dmesg
This will output a lot of kernel messages, not only the touchscreen configuration.
If you want to get the default configuration: reboot, 'cat /sys/touchscreen/set_write' and then 'dmesg'.
That's it.
Here some values explained: http://pastebin.com/raw.php?i=WSqjYT2t
Here a script with the default values, you can use it as base: http://pastebin.com/CejX00v5
The changes are not permanent, they are resetted on every boot. If you do something wrong, you can always reboot.
Don't put anything untested in /etc/init.d/
====
Here a i9000 script adapted for our phone.
Code:
#!/system/bin/sh
#Touchscreen
#Configure touchscreen sensitivity
#Sensitive(Chainfire)
echo 7035 > /sys/touchscreen/set_touchscreen;
echo 8002 > /sys/touchscreen/set_touchscreen; #default setting
echo 11000 > /sys/touchscreen/set_touchscreen;
echo 13060 > /sys/touchscreen/set_touchscreen;
echo 14005 > /sys/touchscreen/set_touchscreen; #default setting
cat /sys/touchscreen/set_write;
Default values (you can also reboot the phone):
Code:
#!/system/bin/sh
#Touchscreen
#Configure touchscreen sensitivity
#Sensitive - default settings
echo 7032 > /sys/touchscreen/set_touchscreen;
echo 8002 > /sys/touchscreen/set_touchscreen;
echo 11003 > /sys/touchscreen/set_touchscreen;
echo 13046 > /sys/touchscreen/set_touchscreen;
echo 14005 > /sys/touchscreen/set_touchscreen;
cat /sys/touchscreen/set_write;
___________
Note
In different custom roms I saw this:
Code:
#!/system/bin/sh
#Touchscreen
#Configure touchscreen sensitivity
#Sensitive(Chainfire)
echo 7035 > /sys/class/touch/switch/set_touchscreen;
echo 8002 > /sys/class/touch/switch/set_touchscreen;
echo 11000 > /sys/class/touch/switch/set_touchscreen;
echo 13060 > /sys/class/touch/switch/set_touchscreen;
echo 14005 > /sys/class/touch/switch/set_touchscreen;
This script obviously is not for our phone, it doesn't work.

The touchscreen maximum scan speed of the AT42QT602240 it's 250Hz for 1 finger (one scan every 1/250 s --> 4ms per scan)
so it will always have delay while moving, maybe you can improve it to some extent but it's slow compared to rapid movements that can be made while drawing, but for normal use, it isn't noticeable.
More info about scanning speed results:
http://www.youtube.com/watch?v=vOvQCPLkPt4
i think MOVHYSTI it's there on purpose to prevent some unintentional rubbing.

You are right, thanks for the explanation.
I knew it was there for a reason, but I still prefer as it is now. As you said, it's ok for normal use, playing games it's harder now.
Edit: with the original movfilter value, games are not that bad (I only tried Angry Birds), not that I care that much

I also want to add that the controller chip 4ms isn't final, the response that the microsoft research team it's showing it's for the whole loop (finger detected > drawed point on screen) and for that a lot of other times are need to take in account, for example screen refresh rate of our device (and most) takes about 17ms (60hz), so there is a need to improve hardware on the forthcoming devices.

this problem has been solved in ddkp3 version of indian firmware ! cus when i try doin this it moves instantly ! or is it cus of vurrut kernel ? i dono but the touchscreen is working great for me

Negative
I am on MIUI.
I tried your test.
But my screen moved instantaneously.

Probably I didn't explain what I mean well enough. Let's try this:
Put your finger on the screen and try to move it changing the coordinates of a single digit, not three, not five, just one. It's better if you do this in a single direction, try to keep still the X or the Y.
I doubt you can do this. And do this right after you put the finger on the screen, not after the coordinates already changed, becase after that the hysteresis automatically changes.
I know the change is instant even without this patch, I'm not talking about centimeters, inches (or whatever you use) and it's not to be intended in terms of time. I'm talking about pixels. This change is nothing revolutionary, we can't improve our hardware. Moreover the value that make me feel the change was movfilter, but in some situations the screen was hard to use, so I put back the original value.
I'm suggesting to remove the hysteresis because I think that every app applies a sort of movement filter that is coupled with it. With the updated values I can easly keep the screen still with my finger on it (with the first ones there were some microscillations).
Does anyone know why the screen sensitivity changes while plugged in?
The TSP thresold is intentionally increased, I don't want to change this, it's just a curiosity, because I couldn't find any exhaustive explanation.

I added two scripts (read the OP).
@rom cooks:
This is especially for you. Read the note in the first post.

How did you get the first configuration file ??
how can I view the current configuration ??
what do this improvement does ?
is it multitouch?
what is movfilter ???

vivekkalady said:
How did you get the first configuration file ??
how can I view the current configuration ??
Click to expand...
Click to collapse
Oh, I forgot to add this info.
Code:
cat /sys/touchscreen/set_write
dmesg
The first command set the current configuration and then use printk() to show it. To see "printk()" messages, you have to use the second command (dmesg). This will print a lot of kernel messages, not only the touchscreen configuration.
vivekkalady said:
what do this improvement does ?
Click to expand...
Click to collapse
It's like changing brightness/colours of your screen. There's no real improvement, it's up to you. I showed you a way to configure your touchscreen.
is it multitouch?
Click to expand...
Click to collapse
I don't understand what you mean.
You can change the number of finger tracked by the screen if you want (default 5, numtouch).
vivekkalady said:
what is movfilter ???
Click to expand...
Click to collapse
A parameter I used in the example above.
If you want to know what's its effect, well, try to change it.
Basically it changes how the screen reacts to movements. If you set it to a very low value, scrolling becomes very hard, the screen is like immovable.

I have problems scrolling trough homescreens. Sometimes I have to move my finger across the screen 3 times to scroll. And sometimes I want to scroll and accidentaly open an app. I hate it, I tried every rom and the only one that partially solve this was Cranium. I think this happend because the procesor have other priorities (conect wifi, download data package, send sms, etc) over the touchscreen.

juanmaper said:
I have problems scrolling trough homescreens. Sometimes I have to move my finger across the screen 3 times to scroll. And sometimes I want to scroll and accidentaly open an app. I hate it, I tried every rom and the only one that partially solve this was Cranium. I think this happend because the procesor have other priorities (conect wifi, download data package, send sms, etc) over the touchscreen.
Click to expand...
Click to collapse
ur touchscreen is probably DIRTY or has sum oily liquids on it ! clean it with a soft wet cloth several times and it'll go away ! i had that isue before

shriomman said:
ur touchscreen is probably DIRTY or has sum oily liquids on it ! clean it with a soft wet cloth several times and it'll go away ! i had that isue before
Click to expand...
Click to collapse
No dude, its a soft problem. Thanks anyway.

juanmaper said:
I have problems scrolling trough homescreens. Sometimes I have to move my finger across the screen 3 times to scroll. And sometimes I want to scroll and accidentaly open an app. I hate it, I tried every rom and the only one that partially solve this was Cranium. I think this happend because the procesor have other priorities (conect wifi, download data package, send sms, etc) over the touchscreen.
Click to expand...
Click to collapse
So this happens while you are doing other things, right?
If it's not because of some dirty on the screen, the only suggestions I could give you are:
try to change CPU governor
try to change I/O scheduler
try to convert your partitions in ext4 (Cranium used it if I'm not wrong)
See if this can help: http://forum.xda-developers.com/showthread.php?t=1137554

loSconosciuto said:
So this happens while you are doing other things, right?
If it's not because of some dirty on the screen, the only suggestions I could give you are:
try to change CPU governor
try to change I/O scheduler
try to convert your partitions in ext4 (Cranium used it if I'm not wrong)
See if this can help: http://forum.xda-developers.com/showthread.php?t=1137554
Click to expand...
Click to collapse
Im using lulzactive, and is a little more smoother, but time to time it happend that cannot scroll well.
loSconosciuto said:
Does anyone know why the screen sensitivity changes while plugged in?
The TSP thresold is intentionally increased, I don't want to change this, it's just a curiosity, because I couldn't find any exhaustive explanation.
Click to expand...
Click to collapse
+1. When plugged in the phone is really smooth.

I am also having the same problem... Especially in Swype keyboard... I think its a sensitivity problem...btw... Does a screen protector decreases or interfere with the sensitivity of the screen...?

landono5 said:
Does a screen protector decreases or interfere with the sensitivity of the screen...?
Click to expand...
Click to collapse
I don't know, I've never used one, but it's not unlikely.
You can increase the sensitivity with:
Code:
echo 7025 > /sys/touchscreen/set_touchscreen
cat /sys/touchscreen/set_write
Try different values.
If you go below ~10 your finger is detect even if you don't touch the screen. I suggest you not to use too low values here. (default=32)
landono5 said:
I am also having the same problem... Especially in Swype keyboard... I think its a sensitivity problem...btw...
Click to expand...
Click to collapse
I had problems with swype too. I had lags especially when the "suggestions bar" appeard/disappeared. Try this:
Swype settings->Word suggestion->tick everything
In this way it's less probable that the "suggestion bar" disappears.
Now, after a clean wipe and some tweaks, this problem seems almost gone and the setting I suggested does nothing in my case, but you can try.

landono5 said:
I am also having the same problem... Especially in Swype keyboard... I think its a sensitivity problem...btw... Does a screen protector decreases or interfere with the sensitivity of the screen...?
Click to expand...
Click to collapse
I have a screen protector and it doesnt interfere with the sensitivity. I think it depends on the protector. I have a cheap one, and its ok.
loSconosciuto said:
I don't know, I've never used one, but it's not unlikely.
You can increase the sensitivity with:
Code:
echo 7025 > /sys/touchscreen/set_touchscreen
cat /sys/touchscreen/set_write
Try different values.
If you go below ~10 your finger is detect even if you don't touch the screen. I suggest you not to use too low values here. (default=32)
I had problems with swype too. I had lags especially when the "suggestions bar" appeard/disappeared. Try this:
Swype settings->Word suggestion->tick everything
In this way it's less probable that the "suggestion bar" disappears.
Now, after a clean wipe and some tweaks, this problem seems almost gone and the setting I suggested does nothing in my case, but you can try.
Click to expand...
Click to collapse
Low values consume more battery, right?

juanmaper said:
Low values consume more battery, right?
Click to expand...
Click to collapse
I don't know, I use a value similar to the stock one. I put low values once for testing purpose only.
I suggested not to go below 10 because the touchscreen becomes almost unusable, it does things by itselfs.

loSconosciuto said:
I don't know, I use a value similar to the stock one. I put low values once for testing purpose only.
I suggested not to go below 10 because the touchscreen becomes almost unusable, it does things by itselfs.
Click to expand...
Click to collapse
I think the problem is not the sensitivity, its the number of times that the screen refresh the position of the finger. Because when I touch the screen just a bit, it work. But when trying to scroll, sometimes it dont.

Related

[HOW-TO] Fix left speaker balance

Unfortunately I was one of the many people who have received a TF where the right speaker was significantly louder than the left. The reason for this is unknown by me as I've not disassembled my TF, and there are conflicting answers as to whether or not it is a software or hardware issue. However, with the help of fellow XDA member verkion for the initial fix and pointing me in the right direction, I've tinkered around enough that I feel comfortable sharing with the rest of the community. Let's get started.
Requirements:
-Root
-Left speaker actually working
-Root Explorer or similar file manager (recommended method)
--ADB if you don't use Root Explorer
--Text editing program (Notepad++ is recommended and free) if you decide to use ADB
Let's start with the recommended method, Root Explorer.
Step 1: Open Root Explorer and navigate to /system/data.
Step 2: Tap on the "Mount R/W" button.
Step 3: Tap and hold on the file "srs_processing.cfg" and once the menu comes up, select the "Open in Text Editor" option.
Step 4: Scroll down to:
//BLOCK: ( srs_spk_int : ) TruEQ - Internal Speaker Tuning
Here's where things can get kind of annoying, because you will have to change values, save & exit, then reboot and test your results. Anyway, there are 4 values you will want to focus on, and those are:
srs_spk_int:trueq_lband0 = 900.000000,-9.000000,0.700000 // TruEQ Left Band 0 Tuning (CF Gain Q) -
srs_spk_int:trueq_lband1 = 11000.000000,6.000000,0.500000 // TruEQ Left Band 1 Tuning -
srs_spk_int:trueq_lband2 = 400.000000,3.000000,0.7000000 // TruEQ Left Band 2 Tuning -
srs_spk_int:trueq_lband3 = 2500.000000,-9.000000,0.700000 // TruEQ Left Band 3 Tuning -
The values in bold are the only ones I've messed with so far with very good results. The beginning values have a maximum of around 16000, and 17000 results in your left speaker not working, something above 16000 but below 17000 may work but I haven't tried it. The two middle ones, I don't know the maximum because It wasn't necessary to up them that much. For example, mine look like this:
srs_spk_int:trueq_lband0 = 1400.000000,-9.000000,0.700000 // TruEQ Left Band 0 Tuning (CF Gain Q) -
srs_spk_int:trueq_lband1 = 16000.000000,10.000000,0.500000 // TruEQ Left Band 1 Tuning -
srs_spk_int:trueq_lband2 = 900.000000,7.000000,0.7000000 // TruEQ Left Band 2 Tuning -
srs_spk_int:trueq_lband3 = 7500.000000,-9.000000,0.700000 // TruEQ Left Band 3 Tuning -
For me, this works out wonderfully! However, results may vary.
Step 5:
Once you've changed those values, save & exit, then restart your TF and examine results. Repeat steps if necessary.
Method 2: ADB. NOTE: Make sure USB debugging is enabled.
Step 1: Connect TF to computer.
Step 2: In a command prompt/terminal navigate to where your Android SDK is and type adb devices to make sure your TF is recognized, if so, type adb remount. If it succeeds, proceed to step 3, otherwise you may need to either enable USB debugging, or install drivers.
Step 3: Type "adb pull /system/data/srs_processing.cfg" It will save the file in the same directory as adb.
NOTE: Do not close command prompt/terminal.
Step 4: Open "srs_processing.cfg" in Notepad++ or whatever qualified text editor you use. NOTE: Due to the nature of how Windows reads files, Notepad might not save the file correctly and definitely will not open it looking pretty. Wordpad might be the same. Basically, the file needs to be saved in UNIX format.
Step 5: Scroll up to Step 4 of the Root Explorer method and proceed.
Step 6: Save the file with Notepad++ or whatever qualified text editor you use.
Step 7: Back in command prompt/terminal, with the file saved over the original type "adb push srs_processing.cfg /system/data/"
Step 8: Reboot your TF as you normally would, or with adb method "adb reboot"
Examine results and repeat steps if necessary.
Attached below are the default srs_processing.cfg and my edited one.
Feel free to post back your own values, because they may be more refined than mine or may work for someone else better as well. ENJOY!
Update: Thanks to seshmaru, a typo was discovered. ASUS added an extra zero to the bold part in line: srs_spk_int:trueq_lband2 = 400.000000,3.000000,0.7000000 // TruEQ Left Band 2 Tuning - I've updated the default file as well as my edited one to remove this extra 0. While this did boost volume in the left speaker for me, it still was not on par with the right one.
Update 2: verkion suggests "turn off the Hard Limiting in the Internal Speaker Boosted section by setting:
hlimit_skip to 0 instead of 1. This gave me a little more "headroom" before distortion became unbearable. A hard limiter is a CLIPPING filter...it just "snips the sound" when it goes over a preset value instead of trying to "scale down the volume.""
NOTE: If your right speaker is more quiet of course look for the srs_spk_int:trueq_rband lines instead.
EDIT:
While looking at your fix I noticed something, this is what I pulled from my config:
Code:
srs_spk_int:trueq_lband0 = 900.000000,-9.000000,0.700000 // TruEQ Left Band 0 Tuning (CF Gain Q) -
srs_spk_int:trueq_lband1 = 11000.000000,6.000000,0.500000 // TruEQ Left Band 1 Tuning -
[B]srs_spk_int:trueq_lband2 = 400.000000,3.000000,0.7000000 // TruEQ Left Band 2 Tuning -[/B]
srs_spk_int:trueq_lband3 = 2500.000000,-9.000000,0.700000 // TruEQ Left Band 3 Tuning -
srs_spk_int:trueq_rband0 = 900.000000,-9.000000,0.700000 // TruEQ Right Band 0 Tuning (CF Gain Q) -
srs_spk_int:trueq_rband1 = 11000.000000,6.000000,0.500000 // TruEQ Right Band 1 Tuning -
[B]srs_spk_int:trueq_rband2 = 400.000000,3.000000,0.700000 // TruEQ Right Band 2 Tuning -[/B]
srs_spk_int:trueq_rband3 = 2500.000000,-9.000000,0.700000 // TruEQ Right Band 3 Tuning -
if you pay attention you will find that the 2 highlighted lines are a different length, even though they should be equal, woops Asus?
I modified this line
srs_spk_int:trueq_lband2 = 400.000000,3.000000,0.7000000 // TruEQ Left Band 2 Tuning -
to read
srs_spk_int:trueq_lband2 = 400.000000,3.000000,0.700000 // TruEQ Left Band 2 Tuning -
This fixed my unbalance problem.
Thanks - this was driving me nuts.....
looks like Asus left out a 0, did you try adding one?
No I removed a 0 based on the fact that all others have five 0's or there are a total of six digits
Sent from my Transformer TF101 using Tapatalk
Ah, yes that makes sense, it balanced your speakers correctly?
Thanks for posting this up Freeza. Honestly, I was too lazy to do this before. Did you notice the Left Speaker tends to distort far "earlier" (lower volume threshold) than the right one?
danielsjam...are you sure changing/removing a zero fixed or changed the balance? It shouldn't make any difference considering its a trailing zero. I'll test this in a few just to be certain.
Thanks!
verkion
seshmaru said:
NOTE: If your right speaker is more quiet of course look for the srs_spk_int:trueq_rband lines instead.
EDIT:
While looking at your fix I noticed something, this is what I pulled from my config:
Code:
srs_spk_int:trueq_lband0 = 900.000000,-9.000000,0.700000 // TruEQ Left Band 0 Tuning (CF Gain Q) -
srs_spk_int:trueq_lband1 = 11000.000000,6.000000,0.500000 // TruEQ Left Band 1 Tuning -
[B]srs_spk_int:trueq_lband2 = 400.000000,3.000000,0.7000000 // TruEQ Left Band 2 Tuning -[/B]
srs_spk_int:trueq_lband3 = 2500.000000,-9.000000,0.700000 // TruEQ Left Band 3 Tuning -
srs_spk_int:trueq_rband0 = 900.000000,-9.000000,0.700000 // TruEQ Right Band 0 Tuning (CF Gain Q) -
srs_spk_int:trueq_rband1 = 11000.000000,6.000000,0.500000 // TruEQ Right Band 1 Tuning -
[B]srs_spk_int:trueq_rband2 = 400.000000,3.000000,0.700000 // TruEQ Right Band 2 Tuning -[/B]
srs_spk_int:trueq_rband3 = 2500.000000,-9.000000,0.700000 // TruEQ Right Band 3 Tuning -
if you pay attention you will find that the 2 highlighted lines are a different length, even though they should be equal, woops Asus?
Click to expand...
Click to collapse
oh wow. I hadn't noticed. GREAT find.
verkion said:
Thanks for posting this up Freeza. Honestly, I was too lazy to do this before. Did you notice the Left Speaker tends to distort far "earlier" (lower volume threshold) than the right one?
danielsjam...are you sure changing/removing a zero fixed or changed the balance? It shouldn't make any difference considering its a trailing zero. I'll test this in a few just to be certain.
Thanks!
verkion
Click to expand...
Click to collapse
Yeah, I do notice it a tad, but I can definitely live with it! I was hoping you wouldn't mind.
Yes fixed my left speaker. Before this I could barely hear my left. If not wrong they are using ALSA sound drivers. You may find more info at the ALSA web site.
Sent from my Transformer TF101 using Tapatalk
I pushed the OP's attached file (srs_processingDEFAULT.zip) then my left speaker became more louder. I pushed back my pulled stock original file from my TF but then my right speaker is now louder.
Stock pulled file attached.
Updated the OP to reflect seshmaru's findings.
BTW, anyone know what srs_processing_JN101.cfg is for? It's almost identical to the original cfg and it showed up for 3.1. if you change stuff in there, sound seems to be unaffected?
Thanks!
verkion
Since sharing is caring, here's my srs_processing.cfg
You'll notice in the TrueEQ settings, my center frequencies are completely different (or quite different at any rate), because I was trying to get a nice flat response. It's better but not very good b/c the speakers suck at the end of the day.
I ALSO turned down the gain in the following section:
Code:
HLimit - Internal Speaker Boosted
hlimit_boost = 2.000
This it to prevent the distortion in the left speaker but has the negative effect of making everything quieter.
Incidentally, the reason why I am trying to get a flat response is because you'll notice that there are 10 GEQ settings for "Internal" and 10 GEQ settings for "External". They are all set to 0 at the moment but you COULD tweak them to your liking. Each of the presets appears to be a 10-band equalizer, probably fairly standard frequency spacing, controlled in dB gains. i.e. you actually have a built in Equalizer that isn't really being utilized properly.
You can have a bunch of different profiles and then switch between them by specifying which preset you want to use:
Code:
geq_int_preset = 0 where 0 is the preset number
This line is found at the top of the srs_processing.cfg file.
Lots more to play with in that config file. I wish there was some way to "reinitialize" the sound engine without having to reboot. Then, a program w/a gui could be written that allows this stuff to be adjusted by the user as long as they had root access.
Thanks!
verkion
verkion said:
BTW, anyone know what srs_processing_JN101.cfg is for? It's almost identical to the original cfg and it showed up for 3.1. if you change stuff in there, sound seems to be unaffected?
Thanks!
verkion
Click to expand...
Click to collapse
It's probably for the Eee Pad Slider.
i tryed your fix and it works really nice! but i'm "scared" about the stress that the left speaker have to sustain. i notice that there is a very strong vibration of the left side of the back cover so i think that the left speaker isn't equal to the right but it's smaller.
i don't want a damaged left speaker so i renounce to the balancing
I think the problem with speaker balance is due to the fact that the right side as more opening (microsd, hdmi) for the sound waves to get to our ears...if you look at the left side those tiny holes on a metal casing don't let enough sound waves thought that's why when you listen to some music at a higher level you feel the back plastic casing vibrating... Like a subwoofer made of plastic
Sent from my Desire HD using XDA Premium App
andrew2511 said:
i tryed your fix and it works really nice! but i'm "scared" about the stress that the left speaker have to sustain. i notice that there is a very strong vibration of the left side of the back cover so i think that the left speaker isn't equal to the right but it's smaller.
i don't want a damaged left speaker so i renounce to the balancing
Click to expand...
Click to collapse
Interesting. I haven't applied this fix yet and noticed my right speaker (the louder one) is already having the vibrating effect.
So wouldn't it be normal that the left speaker, the quieter one, would also make the case vibrate around it if you turn up the volume to balance with the other speaker?
hi all
after trying this my speakers is now balanced
its works!!!
ASUS is using a 'static' version of that processing system - it only reloads at boot. Sorry guys. There's an interactive version with various UI and import/export features too - but generally it's only active during development/QA - at retail it is often locked-out.
Nice find on that typo - now I have to go debugging
Shawn_230 said:
Interesting. I haven't applied this fix yet and noticed my right speaker (the louder one) is already having the vibrating effect.
So wouldn't it be normal that the left speaker, the quieter one, would also make the case vibrate around it if you turn up the volume to balance with the other speaker?
Click to expand...
Click to collapse
the right vibrates too but applying the fix the left back cover will vibrate more and more than the right one. so balancing the speakers, the left having the same volume of right seems to be stressed much more
tested on iron maiden

[GUIDE] Maximum Battery - Maximizing your battery life with CM7 ROM by NeoLojik

UPDATE [11th September 2011]
Modified the SetCPU profiles:
Removed AC-charging Overclock (subject to temperature warnings mentioned in replies)​Reduced some MAX values (has added 5 hours of real-world battery use and makes no noticable difference in performance)​Added an optional < 101% profile to default the maximum clock speed to 729MHz (does not reduce performance, adds 2 hours effective runtime)​Specified the Priority values (which I had forgotten to mention originally)​
Introduction - The Desire S Battery Problem
As a fellow Desire S owner, you no doubt agree that it is a lovely phone: sleek, thin, relatively light, feature-filled... almost everything anyone could ever want from a phone!
However...
As a fellow Desire S owner, you no doubt agree that the battery life (on the Stock Sense ROM, regardless of how strict your PWM settings) is rather pathetic.
I have two HTC Desire S phones (one for myself, one for my wife), and both of them have almost exactly the same runtime (give or take a few minutes) when run in identical test conditions... no more than 18 hours (almost all of which with the display turned off) between charges, and less than 8 hours average with light-to-moderate screen-time when in use.
Bottom line: it's rather pathetic, and unacceptable.
Thankfully, we have options now... and this guide provides you with the option I have chosen for my Desire S phones.
Introduction - The Sacrifice
HTC Sense is (to many) considered a very "pretty" GUI, with nice animated transitions, a rounded feel etc, however it comes at a price: it's a battery hog!
I have played with many Sense 2 and Sense 3 ROMs on the Desire S, all of which share the common result of dimished battery runtime...
Bottom line: The simplest way to get more battery life is to sacrifice Sense entirely!
Just to point out: HTC Sense is the only sacrifice this guide makes in the persuit of optimal battery life! Unlike other guides, this one doesn't compromise any other features, or ANY performance (in fact, I've found performance with the setup described here to be even better than the stock ROM... noticably so!)
DISCLAIMER
I cannot (and will not) be held responsible for any losses or damages resulting from your use of this guide or the materials it contains. If you brick your phone, you've done something wrong and the fault is your own.
You should follow this guide with a fully charged battery, and if possible perform all steps involving a PC from a Laptop, with your phone connected via USB to minimize the risks associated with sudden power loss on your mains supply.
Stage 1: S-OFF
Aside from a lucky few whose Desire S came with S-OFF as a factory default, most of us have S-ON handsets.
With S-ON, you cannot flash a custom ROM onto your Desire S... but fear not, as there is now a FREE (and insanely simple) way to unlock our handsets, giving us the precious S-OFF we require.
You will require the Android SDK to be installed on your system, as well as the USB drivers for the HTC Desire S (these are installed as part of HTC Sync, though you should close HTC Sync from the system tray before proceeding as the S-OFF process will refuse to run with HTC Sync running at the same time)
Head on over to http://revolutionary.io/ to download their tool. This guide presumes you are using Windows, though it should be easy enough - if you're a Linux user - to adapt this information for your Linux platform.
Once you press the link to download Revolutionary, you will notice that a form appears asking for certain information. You'll see a screenshot of this below, but before we get to that there's something you must do...
Open a Command Prompt window from the Platform-Tools directory of the Android SDK.
From that Command Prompt window, type adb devices. Presuming you have the HTC Desire S drivers installed correctly, and your handset connected to your PC via USB, you should something like this:
{
"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"
}
LEAVE THIS COMMAND PROMPT WINDOW OPEN, WE'LL NEED IT AGAIN SHORTLY
The third line of text begins with your handset's serial number.... you will need to enter this into the form on the Revolutionary website in order to generate your Beta key:
Once the Revolutionary zip file has downloaded, extract its contents into a folder on your PC (doesn't matter where, so long as you have access to that location).
Run revolutionary.exe following the instructions provided (it's a very quick and simple process... the automated portion of which shouldn't take more than 2 or 3 minutes to complete)
When it prompts you to install the Recovery mod, do it! You will need it for the next stage of this guide!
Your HTC Desire S now has S-OFF, is equipped with a version of ClockWork Recovery, and is ready to recieve the custom ROM! (All is good with the world).
Stage 2: The Custom ROM
IMPORTANT - THIS WILL FACTORY RESET YOUR PHONE (UNAVOIDABLE) SO DON'T FORGET TO BACK UP WHATEVER YOU NEED BEFORE YOU PROCEED WITH THIS GUIDE! YOU HAVE BEEN WARNED!
NOTE You will either need a spare MicroSD card, or to back up your existing MicroSD card and make it accessible to have files written to it from your PC (I use a card reader, but you can always use the USB Mass Storage feature of the phone itself to access the SD card in your phone from your PC)
The custom ROM of choice is NeoLojik's CyanogenMod 7, lovingly and paintakingly prepared especially for our HTC Desire S handsets, with quite probably the most prompt and spectactular support from NeoLojik himself.
I have chosen NeoLojik's CM7 ROM because it has proven (after exhastively testing other ROMs for the Desire S) to provide me with the very best battery performance, as well as all of the settings you will tweak as part of this guide.
Download (from the ROM's thread linked above):
The latest version of his ROM
The recommended Tiamat Kernel
The recommended version of the Google Apps package
To save time later, download The Android Market 3.1.3 APK
(You can download the APK from your phone directly after you've completed this portion of the guide, if you prefer)
Place the three ZIP files, as well as the Android Market APK, on the root folder of your MicroSD card (by "root" I mean the initial path of the SD card, which is whatever drive letter it mounts as on your Windows PC - e.g. "H:\")
Now, with your phone still connected to your PC via USB (and the SD card put back into your phone, if required), return to the Command Prompt window we used earlier and type adb reboot recovery
Now direct your attention to your phone
Once the Recovery Menu has loaded (should take about 30 seconds) we will follow some simple instructions below... but first, a few points on how to use Recovery:
Use the Volume Up and Down buttons on your handset to highlight one of the displayed options
Use the Power button to trigger the highlighted option.
wipe data/factory reset
wipe cache partition
apply update from sdcard
choose zip from sdcard
update-cm7.1.0-RC1-DesireS-Nexx-signed.zip (or whatever the ROM's filename is at your time of downloading... it will change as the ROM evolves)
apply update from sdcard
choose zip from sdcard
Tiamat_Saga-v1.1.2.zip (or whatever the filename is for the recommended Tiamat kernel at your time of downloading)
apply update from sdcard
choose zip from sdcard
gapps-gb-20110613.zip (again, filename might be slightly different for you)
Remembering with each selection to navigate to the "YES" option in the confirmation menu (this exists to prevent you from accidentally flashing the wrong file onto your phone)
Now, from your PC (or from the Recovery menu... doesn't matter which), you want to reboot your phone! To do this from the PC, you will just type adb reboot into the Command Line window we used previously.
Your phone will now boot with the new ROM (CyanogenMod), and has been factory reset (so you'll have to run through the first-run configuration wizard).
NOTE: Don't be scared if (after the boot animation disappears) the screen remains black for a minute or so! The first boot of the new ROM (especially with the Tiamat Kernel) does take a bit longer than every subsequent boot there-after. Just give the phone a few minutes, and press the Power button. You SHOULD see the Lock screen once the device is ready!
Run through the first-run wizard following instructions provided (fairly strait forward), though keep in mind that (at the time of writing) the wizard does not prompt for a WiFi connection until AFTER it attempts to log in to your Google account! Fear not, though, as when it fails to connect to your Google account (presuming you don't have Mobile Data available to you), it'll then prompt for a WiFi network and repeat the Google account login afterwards.
Once you have completed the first run config, open the "File Manager" app included as part of the ROM.
Navigate to /sdcard and run the com.android.vending-3.1.3.apk file. You'll be prompted to allow unknown sources, you want to tick that box and click on the APK again.
Once you've installed this, you will be running the latest (and greatest) version of Android Market, which (amongst other things) enables you to use a different Google account for your Apps (very useful if you want to install your paid applications on your wife's phone, as I have)
Welcome to CyanogenMod!....
Stage 3: Battery-saving Mega Settings [Menu-by-Menu]
The Settings I'm providing you here are the results of countless hours of experimentation (as well as logic and common sense). They have proven to provide the best degree of battery runtime with absolutely no performance or feature sacrifice!
If a menu or entry within a menu isn't mentioned, it's because it has no bearing on power saving!
Wireless & networks
Wi-Fi settings
Network notification = OFF
Press the Menu button, then Advanced
Wi-Fi sleep policy = NEVER​
Call settings
Vibrate on answer = OFF
Vibrate every 45 seconds = OFF
Vibrate on hangup = OFF (NOTE: I leave this ON as my one concession as it's the only way you will know if a call drops out on you unexpectedly!)
Vibrate call waiting = OFF
Always use proximity = OFF
Enable sensor rotation = OFF
Voicemail notifications = ON (it doesn't save power, but seriously... you want it on!)​
CyanogenMod settings
Display
Automatic backlight
Light sensor filter > Enabled = OFF (If enabled, unnecessarily drains more battery life! The feature itself is pointless as there is no difference to the UX with it Enabled or Disabled!)​Light levels
Use custom = ON
Screen dim level = 14
Allow light decrease = ON
Edit other levels...
This is what I consider to be the most optimal set of levels:
Lower | Screen | Buttons
0 | 21 | 2
160 | 31 | 2
255 | 35 | 2
320 | 40 | 0
640 | 50 | 0
1280 | 75 | 0
2600 | 90 | 0
5800 | 130 | 0
8000 | 200 | 0
10000 | 255 | 0
Press Save & apply (scroll to the top to find the button)
NOTE: You may want to play around with some of the values in this table, as screen brightness is not a "one size fits all" affair, and what I can see clearly might not be so clear for you (or vice-versa). Basically, use those levels as a starting point, and tweak them from there until you find the best settings for you in various lighting conditions.
I will say this, you don't want to set the Buttons value above 0 if you can see the buttons even faintly at a given light level. The backlighting for the buttons is a surprising battery drain (it's calculated as part of the Screen's power consumption in the Battery Usage menu). Bottom line: if you don't need any lighting on the hardware buttons in order to use them even in pitch blackness, then set the value of Buttons for each set in the table to 0 and squeeze more life out of your battery!​
Performance (press OK when the warning is displayed)
CPU settings
Available governors = SMARTASS ("SMARTASS" has been designed specifically [and brilliantly] to scale the CPU frequency with such a perfect balance of performance-on-demand versus power saving... it's the perfect choice!)
Min CPU frequency = 192
Max CPU frequency = 1036 (We'll be using SetCPU [full version, bought from the Market] to set up some magical CPU profiles later in this guide, saving us LOTS more battery life!)
Set on boot = ON​
Sound
Haptic feedback = OFF (Remember: The phone's vibrator consumes more power than playing a beep or other short tone through the speaker at even the highest volume!)​
Accounts and sync
Auto-sync = OFF (Auto-sync being disabled saves both battery power, as well as bandwidth on your Mobile Data tarif [2G and/or 3G dependant on carrier]. Really, you should just "sync on demand" as and when you want/need to!)​
This concludes the Settings portion of the guide!
Stage 4: SetCPU (for ROOT users) configuration
SetCPU for ROOT Users is available for on the Android Market for just £1.25 (or $1.99 USD). Not only does this program enable you to overclock/underclock your phone's CPU, but more importantly it enables you to provide Profiles, to scale the CPU based on the operational status of your phone.
This is well worth the infintismal pricetag, as the potential power savings (at no performance cost) is more than significant!
Open SetCPU, go to the Profiles tab:
Enable = ON
Notifications = ON (Really this is up to you! I like to have notifications for when the profile is changing to ensure that the CPU is scaling properly, and to ensure that my profiles are the best they can be for performance/battery balance)
Add Profile
Profile = Charging AC
Max = 1036800 (Potentially, you could set it up to 2GHz, but I have stability (and heat) concerns, and I can't possibly see any circumstance where 2GHz would be remotely useful! If you do elect to overclock (particularly whilst charging), you will need to add a profile (with 100% priority) to drop the Max value if the temperature exceeds 45 C)
Min = 192000
Scaling = smartass
Press Save​
Add Profile
Profile = Charging USB
Max = 1036800 (Basically 1GHz [original] CPU clock. We don't want to bleed into the minimal input of power provided by USB, so this is the best setting to use)
Min = 192000
Scaling = smartass
Press Save​
Add Profile
Profile = Battery <
Battery < = 75%
Max = 652800
Min = 192000
Scaling = smartass
Press Save​
Add Profile
Profile = Battery <
Battery < = 50%
Max = 576000
Min = 192000
Scaling = smartass
Press Save​
B]Add Profile[/B]
Profile = Battery <
Battery < = 30%
Max = 422400
Min = 192000
Scaling = smartass
Priority = 80
Press Save​
Add Profile
Profile = Screen Off
Max = 345600
Min = 192000
Scaling = smartass
Priority = 60
Press Save​
Add Profile
Profile = Time
Time = 01:00 - 08:00 (NOTE: Substitute the given range with whatever your daily sleeping hours are!)
Max = 345600
Min = 192000
Scaling = smartass
Priority = 70
Press Save​
The following profile is optional... and (if used) would specify your default clock speed
Add Profile
Profile = Battery <
Battery < = 101%
Max = 729600
Min = 192000
Scaling = smartass
Press Save​
Feel free to experiment with other profiles as well! Perhaps you may want to procedurally reduce your CPU speed based on Battery % in a more gentle way... this is certainly possible, and would squeeze even more life out of your battery.
You should also feel free to use lower MAX values for each setting (I would strongly advise against higher values) if you feel that the lower clock speed makes little-to-no noticable difference in performance as you use your phone.
Personally, I notice no difference between 729600 and 1038600!​
Stage 4: Recalibrating your Battery
Install the Battery Calibration app (FREE on the Android Market).
If your phone isn't charged, charge it up so that it is showing 100% (with the Green LED lit).
Run Battery Calibration and press the Battery Calibration button. Immediately unplug the power/USB cable from your phone, and allow it to run (as normal) until fully discharged.
Once the phone has switched itself off, plug it into the AC cable (using the mains charger).... and LEAVE YOUR PHONE SWITCHED OFF until the LED indicator is lit green!
You may want to repeat the discharge/recharge cycle one or two more times (as many people claim that this provides a better calibration)... though really that just entails running your phone on the battery until it is fully discharged, then allowing it (whilst switched off) to fully recharge on the mains adapter (AC)... which is not what most people would normally do as a routine.
Potential Stage 5: Tasker
Tasker (£3.99 on the Android Market) enables you to create profiles which automatically change various settings based on one or more given criteria. This even includes the ability to switch on and off features of your phone such as WiFi, Bluetooth, GPS, GSM, Mobile Data and Airplane Mode.
By creating suitable Tasker profiles, you can squeeze even more battery life out of your phone!
If it's of benefit to people (let me know in the comments) I can expand this guide to include step-by-step instructions on creating the various profiles I would recommend in order to squeeze more battery runtime out of your phone without sacrifising features/functionality.
General Battery Storage/Maintenance Advice (Applies to all Lithium-Ion Batteries, including those used in Laptops)
To prolong the operational lifespan of your battery, you should not really allow your battery to run for very long below 50% charge, as "topping up" a half-charged battery generates less wear and tear on the battery, prolonging its overall lifespan.
NEVER leave your phone fully discharged for more than an hour, or the LiIon cells will begin to degrade, meaning your battery will never be able to physically hold as much charge. Indeed, the longer you leave a discharged battery, the less overall capacity your battery will retain.
NEVER store your battery (even if the phone is running at the time) in cold conditions! As a general rule of thumb, if it's "a little chilly" for you, it's unhealthy for the battery!
Both of the above tips form respectively the Number 1 and 2 causes of battery death! Don't let your battery become another statistic!
If - like me - you have one or more "spare batteries", you will likely be tempted to store them when they are fully charged (100%). This sounds like a good thing to do, but actually it can have (to a slightly lesser degree) the same damaging effect on the battery as leaving it fully discharged for any prolonged period of time!
The absolute best level of charge at which you should store a battery is at 50%, or as close there-to as possible!
Dependant on how often you find yourself recharging your battery, you should recalibrate it between every 3 to 6 months (the more often you discharge/recharge, the less often you should recalibrate).
Also, you should ALWAYS recalibrate after having flashed a new (or updated) ROM and/or Kernel!
My results using the exact configuration [excluding Tasker] detailed in this guide...
As I stated above, with the way I use my Desire S, I was lucky to get 8 hours of what I would call "light-to-moderate" use whilst running on the battery!
With the configuration detailed in this guide, I have now had a successful "100% to discharged" usage of 46 hours (under the exact same usage conditions as when I was using the stock ROM factory-installed on the phone (and updated OTA ~ a week ago).
This is a VERY significant improvement, though I must stress that results will vary heavily based on how much (or what) software you're running on the phone, how often you're interacting with it, how long you spend in calls etc.
Basically, every phone is different, and every operator (me, you, everyone) is different.
Please also keep in mind that your phone won't "settle in" to the new settings in terms of battery runtime until you've done 2 or 3 discharge/recharge cycles (as explained in the Battery Calibration portion of this guide)
Conclusion
There are plenty of third-party ROMs out there, and (obviously) I can't physically test them all! I have tested what I believe anyone would consider to be a perfectly suitable number (more than a dozen now), and have found the exact combination detailed in this guide to provide the very best battery runtime for me.
I understand that some of you will likely have your own ROM preference (for various reasons), but I hope that at least some sections of this guide will be useful to you.
If you just want to get the very best battery performance out of your Desire S, and either don't particularly care what ROM you use, or (like me) happen to love Cyanogen anyway... this guide will fit you like a glove!
Need any more advice?
No problem... post your comments and questions as a reply to this guide, and I'll answer anything I can, as promptly as possible (please consider that I have a company to run, and a life beyond the Internet... so replies might not always be "instant")
I hope you like this guide, and more importantly... I hope you enjoy your new-found battery runtime!
Unfortunately, I'm a Sense fan. ...so will take persuding to move away from the interface, as been using it for many years, but, I still appreciate a piece full of insight and advice written for the communities benefit. Well done and thanks for sharing.
I'll reference this in the development INDEX next to CM7 ROMS
ben_pyett said:
Unfortunately, I'm a Sense fan. ...so will take persuding to move away from the interface, as been using it for many years, but, I still appreciate a piece full of insight and advice written for the communities benefit. Well done and thanks for sharing.
I'll reference this in the development INDEX next to CM7 ROMS
Click to expand...
Click to collapse
Yeah, I can understand why so many people strictly adhere to Sense ROMs... for me the "slight prettiness" of Sense doesn't justify the hammering of the battery... especially as I actually preffer the L&F of Cyanogen anyway
If I have gotten 18 hours with almost always screen off I returned the phone. With nomal usage my phone last more than one day. Keeping the screen almost always off last almost 2 days with wifi and sync turned on (to be honest, never reached that again). ROM is whether LBC or rooted stock whith stock HTC kernel. So I can find any problem there. Nevertheless, this is a smartphone, and I always have a charger with me
I will try CM and what the battery life is like.
Profile = Charging AC
Max = 157440 (Potentially, you could set it up to 2GHz, but I have stability concerns, and I can't possibly see any circumstance where 2GHz would be remotely useful!)
Min = 192000
Scaling = smartass
Press Save
Fried CPU kgo. Overclock + Charging = Excessive heat being generated.
zeekiz said:
Profile = Charging AC
Max = 157440 (Potentially, you could set it up to 2GHz, but I have stability concerns, and I can't possibly see any circumstance where 2GHz would be remotely useful!)
Min = 192000
Scaling = smartass
Press Save
Fried CPU kgo. Overclock + Charging = Excessive heat being generated.
Click to expand...
Click to collapse
I have tested this setting with my own phone, and the heat increase was LESS than 1 Celcius (infintismal)... sure, if you wanted, you could use a lower value.
Its your call, your thread, I just feel that it isn't a good idea. At least even consider placing a warning adjacent to it.
LaKraven said:
I have tested this setting with my own phone, and the heat increase was LESS than 1 Celcius (infintismal)... sure, if you wanted, you could use a lower value.
Click to expand...
Click to collapse
You could add a setcpu profile for limitting the temperature. I dont overclock, but when im using my phone while charging, it gets hot, so I limit the temperature at 41.1 C , so 768mhz - 245mhz , on demand.
lbc ROM, stock kernel
zeekiz said:
Its your call, your thread, I just feel that it isn't a good idea. At least even consider placing a warning adjacent to it.
Click to expand...
Click to collapse
I've updated the guide (see the update notes at the very top of the post). The on-AC overclock setting has been removed, and I have placed a warning about overclocking next to it.
Updated the post to address a typo in one of the SetCPU profiles (I missed a 0 from the end of 345600).
I will have done this process by tomorrow, I'm sure - even bought Tasker. - Hoping I wont damage something in the process since I've never dealt with an HTC phone before. :/ Since my mom bought it to me as a present, she just peeks in from time to time to check wth am I doing with it - gotta keep a satisfied grin on my face all the time while I'm figuring how to fix this problem lolz
Really you just need to follow instructions (read everything through at least twice before you begin), be patient... and double-check everything you're abuot to do before you do it.
You can't do any more than that!
I've flashed both of these phones so many times now, and the only mistake I ever made was forgetting to clear the cache (Which results in an infinite boot loop or "soft brick", easily recovered by constantly typing "adb reboot recovery" in your Command Prompt, which will eventually make the phone re-enter recovery mode (exiting the infinite boot loop), at which point you can wipe, clear cache, reflash, and relax!
LaKraven said:
Really you just need to follow instructions (read everything through at least twice before you begin), be patient... and double-check everything you're abuot to do before you do it.
You can't do any more than that!
I've flashed both of these phones so many times now, and the only mistake I ever made was forgetting to clear the cache (Which results in an infinite boot loop or "soft brick", easily recovered by constantly typing "adb reboot recovery" in your Command Prompt, which will eventually make the phone re-enter recovery mode (exiting the infinite boot loop), at which point you can wipe, clear cache, reflash, and relax!
Click to expand...
Click to collapse
Funny, so true, in fact, did just that myself about two minutes ago while testing another ROM, meant trip to PC, plug in, power on, and then sorted adb reboot recovery
Swyped from HTC Desire S using XDA Premium
ben_pyett said:
Funny, so true, in fact, did just that myself about two minutes ago while testing another ROM, meant trip to PC, plug in, power on, and then sorted adb reboot recovery
Swyped from HTC Desire S using XDA Premium
Click to expand...
Click to collapse
Good to know I'm not the only one! It's such an easy step to overlock... just a good job it's also the least fatal mistake to make!
and then this
.. Ther is no Path in User, but there is in System...Geez, so tired..What do....:/ I'm all set to flash, just this thing I think...
You need to reinstall Java JDK.
This has happened to me before!
LaKraven said:
You need to reinstall Java JDK.
This has happened to me before!
Click to expand...
Click to collapse
Thx man I did that, I also don't have any command prompts in here :
C:\Program Files (x86)\Android\android-sdk\platform-tools
Bombastc said:
Thx man I did that, I also don't have any command prompts in here :
C:\Program Files (x86)\Android\android-sdk\platform-tools
Click to expand...
Click to collapse
Open Windows Explorer, navigate to C:\Program Files (x86)\Android\android-sdk\platform-tools
Hold down SHIFT and RIGHT-CLICK in on that folder
Click "Open command line window here"
You're then ready to start using ADB commands
LaKraven said:
UPDATE [11th September 2011]
Potential Stage 5: Tasker
By creating suitable Tasker profiles, you can squeeze even more battery life out of your phone!
If it's of benefit to people (let me know in the comments) I can expand this guide to include step-by-step instructions on creating the various profiles I would recommend in order to squeeze more battery runtime out of your phone without sacrifising features/functionality.
Click to expand...
Click to collapse
I would really like that. Yesterday followed your guide and learning new things as i went about the CyanogenMod. I'm curious now how far my battery will bring me :-D.
At the moment i'm using the trial version of phoneweaver and automateit, which are nice programs, but if tasker is more efficient although having a steeper learning curve, i will switch in an instant.
shizuku said:
I would really like that. Yesterday followed your guide and learning new things as i went about the CyanogenMod. I'm curious now how far my battery will bring me :-D.
At the moment i'm using the trial version of phoneweaver and automateit, which are nice programs, but if tasker is more efficient although having a steeper learning curve, i will switch in an instant.
Click to expand...
Click to collapse
As a tasker convert myself, I can also say that you'll read a great review of some of its functionality and a slightly biased review of the product by wnp_79 as part of his [GUIDE] Update 28/06/11: HTC Desire S Guide (V1.03) For Newcomers to Android which is in a sticky at the top of the forum.

[Q] Scrolling Cache and other TouchScreen Questions

I've been doing some digging about the touchscreen , it's mechanism and how or in what ways it can be tweaked.
First of all i broke my first digitizer , ordered another one and replaced it completely. This gave me an opportunity to experiment on the old broken one (Although cracked , it was still intact)
The digitizer creates an electrostatic barrier which is sustained by the battery. When disturbed by a capacitive material (Skin) electrons flood through the capacitive material leaving the digitizer.
The controller measures the disturbance in the electrostatic barrier and it's location.
As the current leaves the digitizer , it increases its response time , especially in multi-touch situations.
Inspired by the Overvolting , i wired 3 1.5 volt batteries in parallel and wired the output to a 0.5 volt regulator. (If you connect the negative side you can't use the touchscreen)
I taped the wires to the touchscreen , connected it and opened up the phone.
The touchscreen's response time decreased a little bit , i don't actually know if it's actually placebo.
I unwired the regulator and tried the 1.5 volt in parallel alone.
Guess what , i noticed at least %40 improvement on the touchscreen... (Not placebo , i'm sure.)
So according to the information above i have 2 questions ;
1. Is there any way to tweak the operating system to give the digitizer additional , more powerful current ?
2. Is there any way to optimize the touchscreen more efficiently , softwarewise ? (Read about the scrolling cache and few other things , if you could explain how i can disable it and measure the differences , that'd be great.)
Thanks in advance.
These are good information s to know ,, thank you very much .
About tweaking there are some tweaks avaiable for every device (init.d scripts and build.prop tweaks) I do not know what do they actually do but it's inprove it .
About the voltage I do not know (but maybe it will damage the screen if it still on for a long time maybe) .
But be careful do not play with these things much maybe you will lose your screen .
Use these commands (tweak) :-
echo 7035 > /sys/class/touch/switch/set_touchscreen;
echo 8002 > /sys/class/touch/switch/set_touchscreen;
echo 11000 > /sys/class/touch/switch/set_touchscreen;
echo 13060 > /sys/class/touch/switch/set_touchscreen;
echo 14005 > /sys/class/touch/switch/set_touchscreen;
Run them with terminal emulator or save them as *.SH file or you can make them as an init.d script to make it run every reboot .
Sent From My LG-P920 (ICS Ported)
Try Use THANKS Button If I Helped

[FIX] For MANY scripts broken due to missing wait_for_fb_sleep/wake files.

I originally found the fix in the SuperCharger Thread when I found that my Flush-O-Matic script wasn't working properly on my Sony Z1.
See original posting here.
zeppelinrox said:
Hey I realized yesterday that Flush O Matic doens't work properly on newer kernels.
Well it works, but it doesn't wait for the screen to go off before flushing.
A little googlie told me that the newer kernels no longer have the /sys/power/wait_for_fb_sleep file.
Normally, FOM will try and read it's contents (but it's unreadable) and it just hangs until the device goes to sleep.
When it goes to sleep, that file can be read and the script gets "unhung" and flushes.
And when the file is missing, well FOM will just spit out errors (check the log) and dump cache without uh... waiting for the fan to be turned on...
BUTT (yeah, thats a big butt!) I fingered out another way for newer kernels... heh.
Check it via PC... with the screen on do this
Code:
adb shell
su
while [ "`cat /sys/class/graphics/fb0/dynamic_fps`" ]; do sleep 1; done; echo " OK Flush Time!"
Who's your daddy!? LOL
While the screen is on it should hang there until you turn off the screen.
When the screen goes off, it will pronounce what "time" it is...
I'll probably do sleep 10 instead of sleep 1 tho to minimize battery suckage.
Click to expand...
Click to collapse
This fix would be applicable to various scripts on xda that will get outdated due to the missing wait_for_fb_sleep/wake files on some device/kernel combinations.
Currently effected hardware, that I'm aware so far: some Sony, Moto and Nexus devices using kernel version 3.3 or above.
These scripts change things or do things depending on whether the screen turns off or turns on.
Examples are cpu governor scripts or other screen state scaling scripts.
As mentioned above, it had effected my FOM script which dumps caches at a user defined interval.
However, when the time is up, it will actually wait until the screen is off if the screen happens to be on at the time.
So if you have a misbehaving script due to the missing /sys/power/wait_for_fb_sleep/wake files, you should have 2 other files that you can use.
1. /sys/class/graphics/fb0/dynamic_fps
2. /sys/class/graphics/fb0/show_blank_event
File contents with screen off:
Code:
[email protected]:/ $ cat /sys/class/graphics/fb0/dynamic_fps
[email protected]:/ $ cat /sys/class/graphics/fb0/show_blank_event
panel_power_on = 0
[email protected]:/ $
File contents with screen on:
Code:
[email protected]:/ $ cat /sys/class/graphics/fb0/dynamic_fps
60
[email protected]:/ $ cat /sys/class/graphics/fb0/show_blank_event
panel_power_on = 1
[email protected]:/ $
So when the screen is off, dynamic_fps is empty but has a value (60 in my case) when the screen is on.
I preferred to take advantage of that file.
However some may like to use the contents of show_blank_event and check whether panel_power_on = 0 (off) or panel_power_on = 1 (on).
Of course, a script will have to check and decide whether to use the wait_for_fb_sleep file or use the new way.
So a fixed script will look something like:
Code:
if [ -f "/sys/power/wait_for_fb_sleep" ]; then
echo "Android is now `cat /sys/power/wait_for_fb_sleep`!"
else while [ "`cat /sys/class/graphics/fb0/dynamic_fps`" ]; do sleep 10; done
echo "Android is now sleeping!"
fi
So if that code is ran when the screen is on, when the screen is off, the output would be Android is now sleeping! and it won't matter if you have the wait_for_fb_sleep file
Alternately, to do something when the screen turns on...
Code:
if [ -f "/sys/power/wait_for_fb_wake" ]; then
echo "Android is now `cat /sys/power/wait_for_fb_wake`!"
else while [ ! "`cat /sys/class/graphics/fb0/dynamic_fps`" ]; do sleep 10; done
echo "Android is now awake!"
fi
Of course, when the screen comes on, the output will be Android is now awake!
I used sleep 10 so that it doesn't do any needless work.
Of course sleep 1 would give an instant reaction but isn't very battery or cpu friendly.
You can decide for yourself how long is a good sleep interval between checks.
Anyhow, hope that helped
Nice! Will try on my VU
sent from my LG-P895 using Tapatalk bajakan
Thank you
I wanted this to implement a small idea of mine ,also scanned through the 11k+ lines from supercharger script but couldn't find screen off thingy
Yeah,finding a small line in FastEngineFlush.sh also was hard
But this post helped!
The reason why your are called a XDA Scripting Genius! :good:
Really useful!
Madaditya said:
I wanted this to implement a small idea of mine ,also scanned through the 11k+ lines from supercharger script but couldn't find screen off thingy
Yeah,finding a small line in FastEngineFlush.sh also was hard
But this post helped!
The reason why your are called a XDA Scripting Genius! :good:
Really useful!
Click to expand...
Click to collapse
Whats your idea?
And yeah, even the flush script is rather complex lol
zeppelinrox said:
Whats your idea?
And yeah, even the flush script is rather complex lol
Click to expand...
Click to collapse
LOL yeah.
Wanted to make a background script that turns your data connection off on screen off + one minute and enables data on screen on.
Something close to Stamina mode in Sony Devices.
Reason,i face considerable battery drain on Custom roms,and a xperia user always misses Stamina mode
Madaditya said:
LOL yeah.
Wanted to make a background script that turns your data connection off on screen off + one minute and enables data on screen on.
Something close to Stamina mode in Sony Devices.
Reason,i face considerable battery drain on Custom roms,and a xperia user always misses Stamina mode
Click to expand...
Click to collapse
Nice idea!
Whats the command to disable data?
zeppelinrox said:
Nice idea!
Whats the command to disable data?
Click to expand...
Click to collapse
svc data enable/disble
for wifi:
svc wifi enable/disable
Madaditya said:
svc data enable/disble
for wifi:
svc wifi enable/disable
Click to expand...
Click to collapse
Oh nice.
You learned me something lol
I couldn't find /sys/class/graphics/fb0/show_blank_event or /sys/class/graphics/fb0/dynamic_fps or /sys/power/wait_for_fb_wake/sleep. Instead i am using this /sys/class/leds/lcd-backlight/brightness. 0 will mean screen is off, any other value for screen on. Thanks You could add this in OP

Improve idle drain by tweaking Android Doze parameters

Hey xda-Community!
I recently wanted to reduce my idle drain and searched for ways to edit Android Doze settings, because I remembered seeing a tutorial that said you can change deviceidle-constants, that dictate how Doze works (how fast it kicks in, how long it kicks in, light/deep doze).
I tried all those old tutorials, but I quickly realized the old ways to change the parameters are deprecated, so I asked people on android.stackexchange.com and someone actually gave me the answer (thanks Andrew) (https://android.stackexchange.com/questions/247680/is-device-idle-constants-deprecated-in-android-12).
This works from Android 12 on and is achieved using a shell.
Commands:
Note: When using an adb shell, you have to put "adb shell" before those commands. I'll just put the bare commands here, you add what you have to add.
Checking the settings:
You can check your current Doze settings (and statistics) with "dumpsys deviceidle".
Changing a setting;
Every parameter has to be set individually. It's not that bad tho, as you only have to do this once.
Syntax is: "device_config put device_idle [KEY] [VALUE]".
One example: "device_config put device_idle light_after_inactive_to 30000"
You can check "dumpsys deviceidle" to see what keys there even are. To help you out, here's an explanation of what each key actually sets. You can also get a visual sense of how the light mode and the deep mode work (not my work, thanks to easz from github).
Spoiler: My recommended settings
First; reset parameters with: "device_config reset trusted_defaults device_idle"
light_after_inactive_to 30000
light_pre_idle_to 120000
light_idle_to 300000
light_idle_factor 2
light_max_idle_to 900000
light_idle_maintenance_min_budget 30000
light_idle_maintenance_max_budget 180000
inactive_to 900000
sensing_to 0
locating_to 0
motion_inactive_to 0
idle_after_inactive_to 900000
idle_pending_to 60000
max_idle_pending_to 120000
idle_pending_factor 2
idle_to 900000
max_idle_to 21600000
idle_factor 2
wait_for_unlock true
I also wrote a windows batch script (works via adb, you have to rename the .txt file to .bat) and a bash file that changes the parameters to my recommendations. See attachments.
will these settings persists even after a reboot? or upgrading rom?
maxs8007 said:
will these settings persists even after a reboot? or upgrading rom?
Click to expand...
Click to collapse
yes, these will stick after a reboot. Not sure about upgrading, but I would guess that it'll stay, because we don't actually modify anything on the system partition
@Doomkopf for me those settings won't stick.
For testing purpose I just applied those yesterday morning:
adb shell device_config put device_idle motion_inactive_to 300000
adb shell device_config put device_idle light_after_inactive_to 180000
This morning they are back to stock values. Any ideas? :S
Utini said:
@Doomkopf for me those settings won't stick.
For testing purpose I just applied those yesterday morning:
adb shell device_config put device_idle motion_inactive_to 300000
adb shell device_config put device_idle light_after_inactive_to 180000
This morning they are back to stock values. Any ideas? :S
Click to expand...
Click to collapse
I set mine like 6 weeks ago, it's still set. I miss many information, what phone do you use, what ROM, how you check if it's still set etc
Doomkopf said:
I set mine like 6 weeks ago, it's still set. I miss many information, what phone do you use, what ROM, how you check if it's still set etc
Click to expand...
Click to collapse
Hi, oh well here are some more infos:
Pixel 6 Pro
Latest Android 13 Stock ROM
Kirisakura Kernel
I check via "adb shell dumpsys deviceidle".
I set it all your settings on friday and today (monday) there are back to stock values.
Previously I tried settings my own settings on wednesday morning and had stock values on the next day already as well :S
Utini said:
Hi, oh well here are some more infos:
Pixel 6 Pro
Latest Android 13 Stock ROM
Kirisakura Kernel
I check via "adb shell dumpsys deviceidle".
I set it all your settings on friday and today (monday) there are back to stock values.
Previously I tried settings my own settings on wednesday morning and had stock values on the next day already as well :S
Click to expand...
Click to collapse
That doesn't sound good I'd check right after setting it, so you can see if it was changed at all (which I assume). If it indeed gets set and unset again, you could check this github repo (https://github.com/easz/doze-tweak) at "Caveat".
Those values got reset in the past already, but as it didn't happen to me, I thought Google stopped doing that. Maybe that old workaround still works Otherwise, you'll have to flash a custom rom I guess xD
EDIT: I also recommend looking at values easy to distinguish. For example, "sensing_to" and "locating_to" were nonzero before, now they are zero (for me), so these values are easy to compare for me. The values you need to look at are at the most upper part of the output, but I guess you already knew that
Doomkopf said:
That doesn't sound good
Click to expand...
Click to collapse
Did you ever mess with any other settings using device_config before? Like the number phantom processes, empty or cached processes, ActivityManager tweaks or anything else? Because I assume you did (and using Android 10 or higher) and disabled the settings sync back to the defauls.
Did you ever use the below command?
device_config set_sync_disabled_for_tests persistent
What does the below commands says?
device_config is_sync_disabled_for_tests
Perhaps it says true? If yes that's why your settings aren't changing.
crok.bic said:
Did you ever mess with any other settings using device_config before? Like the number phantom processes, empty or cached processes, ActivityManager tweaks or anything else? Because I assume you did (and using Android 10 or higher) and disabled the settings sync back to the defauls.
Did you ever use the below command?
device_config set_sync_disabled_for_tests persistent
What does the below commands says?
device_config is_sync_disabled_for_tests
Perhaps it says true? If yes that's why your settings aren't changing.
Click to expand...
Click to collapse
You quoted the wrong man
@Utini How'd it work out? If my last response doesn't help, maybe this one helps u
Doomkopf said:
You quoted the wrong man
@Utini How'd it work out? If my last response doesn't help, maybe this one helps u
Click to expand...
Click to collapse
No, logically I quoted the correct man Just wanted to indirectly tell others about the above trick / setting
Doomkopf said:
Hey xda-Community!
I recently wanted to reduce my idle drain and searched for ways to edit Android Doze settings, because I remembered seeing a tutorial that said you can change deviceidle-constants, that dictate how Doze works (how fast it kicks in, how long it kicks in, light/deep doze).
I tried all those old tutorials, but I quickly realized the old ways to change the parameters are deprecated, so I asked people on android.stackexchange.com and someone actually gave me the answer (thanks Andrew) (https://android.stackexchange.com/questions/247680/is-device-idle-constants-deprecated-in-android-12).
This works from Android 12 on and is achieved using a shell.
Commands:
Note: When using an adb shell, you have to put "adb shell" before those commands. I'll just put the bare commands here, you add what you have to add.
Checking the settings:
You can check your current Doze settings (and statistics) with "dumpsys deviceidle".
Changing a setting;
Every parameter has to be set individually. It's not that bad tho, as you only have to do this once.
Syntax is: "device_config put device_idle [KEY] [VALUE]".
One example: "device_config put device_idle light_after_inactive_to 30000"
You can check "dumpsys deviceidle" to see what keys there even are. To help you out, here's an explanation of what each key actually sets. You can also get a visual sense of how the light mode and the deep mode work (not my work, thanks to easz from github).
Spoiler: My recommended settings
First; reset parameters with: "device_config reset trusted_defaults device_idle"
light_after_inactive_to 30000
light_pre_idle_to 120000
light_idle_to 300000
light_idle_factor 2
light_max_idle_to 900000
light_idle_maintenance_min_budget 30000
light_idle_maintenance_max_budget 180000
inactive_to 900000
sensing_to 0
locating_to 0
motion_inactive_to 0
idle_after_inactive_to 900000
idle_pending_to 60000
max_idle_pending_to 120000
idle_pending_factor 2
idle_to 900000
max_idle_to 21600000
idle_factor 2
wait_for_unlock true
I also wrote a windows batch script (works via adb, you have to rename the .txt file to .bat) and a bash file that changes the parameters to my recommendations. See attachments.
Click to expand...
Click to collapse
Hi, currently I am using Naptime by Franco with ADB permissions. I'm not sure, but it should work by using the following options (maybe not only these, but I don't know well if there are other places where Doze options are stored):
inactive_to=2592000000,
motion_inactive_to=2592000000,
light_after_inactive_to=0,
light_pre_idle_to=30000,
light_max_idle_to=86400000,
light_idle_to=43200000,
light_idle_maintenance_max_budget=30000,
light_idle_maintenance_min_budget=10000,
min_time_to_alarm=60000,
min_light_maintenance_time=10000,
wait_for_unlock=0,
quick_doze_delay_to=86400000
It's working very well (I get 2% drain in 8 hours of sleep), but I wanted to try and improve it further, because the App tells you when and how much Doze is enforced and when maintenances are performed.
In my case, from my understanding, I don't need maintanances so often, or maybe I don't need it at all, because all the apps of which I need notifications are in non-optimized battery mode.
For reference, during night it performs 4-6 maintenances circa.
Coming to the point, I wanted to ask you I can use you settings even if they have further options like:
sensing_to 0
locating_to 0
and if I can make your settings even more extreme on some values.
For further reference, I have disabled through adb the "motion_engine", any system gesture and I have the Location always disabled (through UI shortcut, not ADB or advanced options).
NovaProspekt70 said:
Hi, currently I am using Naptime by Franco with ADB permissions. I'm not sure, but it should work by using the following options (maybe not only these, but I don't know well if there are other places where Doze options are stored):
inactive_to=2592000000,
motion_inactive_to=2592000000,
light_after_inactive_to=0,
light_pre_idle_to=30000,
light_max_idle_to=86400000,
light_idle_to=43200000,
light_idle_maintenance_max_budget=30000,
light_idle_maintenance_min_budget=10000,
min_time_to_alarm=60000,
min_light_maintenance_time=10000,
wait_for_unlock=0,
quick_doze_delay_to=86400000
It's working very well (I get 2% drain in 8 hours of sleep), but I wanted to try and improve it further, because the App tells you when and how much Doze is enforced and when maintenances are performed.
In my case, from my understanding, I don't need maintanances so often, or maybe I don't need it at all, because all the apps of which I need notifications are in non-optimized battery mode.
For reference, during night it performs 4-6 maintenances circa.
Coming to the point, I wanted to ask you I can use you settings even if they have further options like:
sensing_to 0
locating_to 0
and if I can make your settings even more extreme on some values.
For further reference, I have disabled through adb the "motion_engine", any system gesture and I have the Location always disabled (through UI shortcut, not ADB or advanced options).
Click to expand...
Click to collapse
Hey; please don't quote the whole post, it doesn't really tell me anything
I don't really understand: What do you want to know from me/what is your question? ^^
Yes, you can make some values more extreme, but you said you already did (less maintenance, more idle)
Doomkopf said:
Hey; please don't quote the whole post, it doesn't really tell me anything
I don't really understand: What do you want to know from me/what is your question? ^^
Yes, you can make some values more extreme, but you said you already did (less maintenance, more idle)
Click to expand...
Click to collapse
Hey, I'm really sorry, I'm new on XDA.
I wanted to know why you have some options valued that I don't, like for example:
light_idle_factor 2
sensing_to 0
locating_to 0
and if using them might improve even more my doze.
Also, even if I have Naptime installed, which already improved things by a lot, I wanted to know if some of my values could be improved further to avoid useless maintenances (like I said I have between 4 and 6 maintenances during night, but I barely need 1).
NovaProspekt70 said:
Hey, I'm really sorry, I'm new on XDA.
I wanted to know why you have some options valued that I don't, like for example:
light_idle_factor 2
sensing_to 0
locating_to 0
and if using them might improve even more my doze.
Also, even if I have Naptime installed, which already improved things by a lot, I wanted to know if some of my values could be improved further to avoid useless maintenances (like I said I have between 4 and 6 maintenances during night, but I barely need 1).
Click to expand...
Click to collapse
Doomkopf said:
You can check "dumpsys deviceidle" to see what keys there even are. To help you out, here's an explanation of what each key actually sets. You can also get a visual sense of how the light mode and the deep mode work (not my work, thanks to easz from github).
Click to expand...
Click to collapse
I linked a xda post that explains every value in detail (first link in second quote/my post);
locating_to and sensing_to: By the pictures (also in second quote/my post), you can see how deep doze works; before going into IDLE mode of deep doze, it goes through a sensing phase (motion detection starts) and locating phasing. Default behavior of doze is to not go sleep when you move the device. This skips this phase (time for detecting motion with sensor is 0). Same with locating; when android notices that you move the device (train, car, ...) via gps (or wifi triangulation, etc) it doesn't go to sleep. This also skips that phase
light_idle_factor 2: This multiplies light_idle_to with 2 everytime if goes thorugh a idle/maintenance cycle until it reaches light_max_idle_to. So this basically doubles your light idle time every cycle until it reaches a max duration (which you can set, I also did in my recommended settings)
In that overview you could also think about how to tweak your values so you get less maintenances during night, as you wanted. Basically you have to make both (deep and light) idle_to's longer. I recommend to increase light idle_to first (more light idle, less maintenance), before going too deep on deep sleep - sometimes your phone needs to do backups at night, etc. Dont be afraid to set a "too large" maintenance window, your phone won't suddenly start to draw much power for nothing. You just have a few seconds/minutes less deep sleep (which is ok, little percentage). Give it something like 2 minutes per night, if you're afraid a backup will take longer, you can even go for 3-4 minutes per night.
Doomkopf said:
I linked a xda post that explains every value in detail (first link in second quote/my post);
locating_to and sensing_to: By the pictures (also in second quote/my post), you can see how deep doze works; before going into IDLE mode of deep doze, it goes through a sensing phase (motion detection starts) and locating phasing. Default behavior of doze is to not go sleep when you move the device. This skips this phase (time for detecting motion with sensor is 0). Same with locating; when android notices that you move the device (train, car, ...) via gps (or wifi triangulation, etc) it doesn't go to sleep. This also skips that phase
light_idle_factor 2: This multiplies light_idle_to with 2 everytime if goes thorugh a idle/maintenance cycle until it reaches light_max_idle_to. So this basically doubles your light idle time every cycle until it reaches a max duration (which you can set, I also did in my recommended settings)
In that overview you could also think about how to tweak your values so you get less maintenances during night, as you wanted. Basically you have to make both (deep and light) idle_to's longer. I recommend to increase light idle_to first (more light idle, less maintenance), before going too deep on deep sleep - sometimes your phone needs to do backups at night, etc. Dont be afraid to set a "too large" maintenance window, your phone won't suddenly start to draw much power for nothing. You just have a few seconds/minutes less deep sleep (which is ok, little percentage). Give it something like 2 minutes per night, if you're afraid a backup will take longer, you can even go for 3-4 minutes per night.
Click to expand...
Click to collapse
Thank you very much, very helpuful!!
Based on your information, I think I understand better how Naptime works. It increases the parameters of Light Doze making them similar to those of Deep Doze, and also increases the duration.
Wouldnt it be easier to just create a routine or mode ?
Like when I am around my work place I have set it to turn wifi off so it dont keep scanning for wifi and stuff.
I personally feel with Samsung most things can be controlled within their phone and developer settings and not to mention their add on apps like Good Guardian and Good lock.
tfn said:
Wouldnt it be easier to just create a routine or mode ?
Like when I am around my work place I have set it to turn wifi off so it dont keep scanning for wifi and stuff.
I personally feel with Samsung most things can be controlled within their phone and developer settings and not to mention their add on apps like Good Guardian and Good lock.
Click to expand...
Click to collapse
I do use Samsung Routines to Enable Offline Mode and Battery Saving at night, which along with Naptime gives me 2% used battery in 8 hours over night, but during the day I can't find a good usage for it.
tfn said:
Wouldnt it be easier to just create a routine or mode ?
Like when I am around my work place I have set it to turn wifi off so it dont keep scanning for wifi and stuff.
I personally feel with Samsung most things can be controlled within their phone and developer settings and not to mention their add on apps like Good Guardian and Good lock.
Click to expand...
Click to collapse
I don't know what it would be easier as; this method?
This basically just configures doze to better fit your needs. It already had values in it before and it was activated before. You can (and should) do all this and still create a routine or mode additionally.
Doze is android's main internal battery saving feature, so tweaking it goes a long way.

Categories

Resources