Related
I decided I wanted to use the kernel's led trigger support on my button backlight to watch sdcard activity since I don't really need it to light up for me to use the buttons anyway... of course, if one does:
#echo mmc1 > /sys/class/button-backlight/trigger
Then you'll see the intended effect.... that is, until android decides to turn the backlight on or off, at which point the trigger is turned off... so I grepped the cm-kernel source tree and found the struct that names them in the arch/arm/mach-msm/board-trout.c. I renamed this instance to "btn-backlight", and a simple
#echo mmc1 > /sys/class/leds/btn-backlight/trigger
Seems to do the trick... does anyone know if this might have any negative consequences? This is the first time I've ever modified C code in the linux tree at all, other than applying patchfiles and the like...
If there's enough interest in it, I could package it up as an AnyKernel zip update... should apply to board-sapphire.c just the same
I have no real knowledge on wether this would have a negative effect. I am purely commenting as it seems like a very good idea.
My main concern is how the kernel trigger support might interact with power managment... does the mmc trigger ONLY get called when there's activity, or will it stay idle as long as the sd card is idle as well?
It's been working well for me since I started it up on mine +BFS patches... here's the diff for my part if anyone wants to try it out: http://pastebin.com/cghjCqct
Just make sure you have whichever led trigger options you want to use set up in menuconfig, and set it up through /sys/class/leds/btn-backlight/trigger once your kernel is up and running...
Trigger will list what options you have in your kernel... I use mmc1 for sd card, not sure what mmc0 is there...
#cat trigger
And then, for example:
#echo mmc1>trigger
You can do this from a userinit.sh:
echo mmc1>/sys/class/leds/btn-backlight/trigger
Small hack, but I like it xD
Have you ever tried having your phone lay on a table for some time and when you come back to pick it up, it had almost burned through the table because of the battery heat do to an app running the CPU on a constant 100%?
Or have you tried waking up two hours to late for work, because you alarm did not go off do to the phones battery running dry during the night?
Bad applications or problems with some back-end processes is a problem for most people. To get some help with this problem, I have been running the Watchdog app for the last 3 years. It is a great application that will alert you whenever an app or a process is running wild in the background. However there is one issue with this app. It only alerts you when there is a problem. This does not help much if you are to far away from the phone, if your phone is in silent mode or if you are sleeping.
I wrote the developer of the app to see if there was any plans for making a tasker plug-in so that profiles can be made to handle this. I have yet to get an answer. In the mean time, I have made a complete watchdog profile for tasker that does what the watchdog app does, only this profile will auto terminate any wild processes if the screen is turned off. If the screen is on, it will to what the watchdog app does and alert you of the problem. It could be that you was playing a game or running a benchmark, so auto terminate while the screen is on, would not be a good idea.
The profile however, will drain more battery than the watchdog app does. Because of this I have set the check interval for 15 minutes instead of the 5 minutes I used on the app. This reduces the drain to about the same amount.
And to save even more power, I have included a Data control profile that will turn off data/wifi/sync when the screen is off, as long as you are not connected to a power source or if you are downloading, uploading or streaming. In this case the profile will wait until this state changes before turning off anything. And while off, tasker will alow sync (email and such) once every 15 minutes.
Both profiles is included in the attached download below.
Important!
The watchdog profile will need a proper busybox installed with proper symlinks for sed, grep and awk. It will also need a toolbox that supports top and ps with arguments.
You can run the update script from the Busybox Installer thread to make sure that your phone will work with this profile.
Changelog (2012-11-18)
Reduced the time from where the screen turns off, to the time Data/Sync is disabled
Data/Sync will now turn back on when the screen is unlocked rather than turned on. No need to waste power if you just want to check the time or notifications (Which can be done from lock screen in Android 4.x)
Fixed the 15 minutes data check when the screen is off. It only executed once after the screen was turned off
_______________________
Wow! Your watchdog implementation looks great! Will adopt it on my phone over the weekend.
Now I have only one battery-drain-controlling dream left - being able to find out the apps holding the wakelock for too long to kill them automatically. The reason for this is that sometimes I find battery drain to go from usual 1% per hour to 10% per hour just because some badly written app has not released the wakelock.
Alte.78 said:
Wow! Your watchdog implementation looks great! Will adopt it on my phone over the weekend.
Now I have only one battery-drain-controlling dream left - being able to find out the apps holding the wakelock for too long to kill them automatically. The reason for this is that sometimes I find battery drain to go from usual 1% per hour to 10% per hour just because some badly written app has not released the wakelock.
Click to expand...
Click to collapse
Are you talking about BetterBatteryStats? I know that it tells you exactly how long since a point in time (which can be manually customized) that certain programs/tasks hold wakelocks.
But not sure about any kind of specific stratification that displays only programs that hold the lock too long to kill them automatically (assuming that's what you are wanting?).
And OP, these sound great - I'm importing them as we speak :highfive:
dk_zero-cool said:
Important!
The watchdog profile will need a proper busybox installed with proper symlinks for sed, grep and awk. It will also need a toolbox that supports top and ps with arguments.
_______________________
Click to expand...
Click to collapse
I got all excited when reading about this until I read the Important section. After watchdog everything started getting confusing . I know I read somewhere about busybox but the other terms are all new to me...could someone explain it with a little more details on what I have to get/set up in order for this to work??
2am said:
I got all excited when reading about this until I read the Important section. After watchdog everything started getting confusing . I know I read somewhere about busybox but the other terms are all new to me...could someone explain it with a little more details on what I have to get/set up in order for this to work??
Click to expand...
Click to collapse
The profile is using some linux commands to get a list of all current processes and their CPU usage. These commands needs to be available in order for the profile to work.
If you are using a custom ROM, then you are most likely to have all what is needed. Especially if you are using a more current custom ROM.
In order to test this, download a terminal app or enter an ADB shell (Hope you know what this is) and see if the command line
Code:
top -n 1 | sed -e 1,7d | grep -e '[0-9]\+%' | awk '{print $3}'
returns anything. If it does (Except errors), then you will have all that is needed.
Alternatively you could check my Better Busybox Integration thread which will make sure that your phone is setup to work with this.
dk_zero-cool said:
The profile is using some linux commands to get a list of all current processes and their CPU usage. These commands needs to be available in order for the profile to work.
If you are using a custom ROM, then you are most likely to have all what is needed. Especially if you are using a more current custom ROM.
In order to test this, download a terminal app or enter an ADB shell (Hope you know what this is) and see if the command line
Code:
top -n 1 | sed -e 1,7d | grep -e '[0-9]\+%' | awk '{print $3}'
returns anything. If it does (Except errors), then you will have all that is needed.
Alternatively you could check my Better Busybox Integration thread which will make sure that your phone is setup to work with this.
Click to expand...
Click to collapse
well I entered that command and got
invalid argument "-n". and then a bunch of other lines after that...and I checked your other thread and there's even more code language ...ugh, I think this is one of those threads that I need to leave alone because it's too much for me to handle...sucks too cause your set up sounds really awesome...thanx for trying to help me though
2am said:
well I entered that command and got
invalid argument "-n". and then a bunch of other lines after that...and I checked your other thread and there's even more code language ...ugh, I think this is one of those threads that I need to leave alone because it's too much for me to handle...sucks too cause your set up sounds really awesome...thanx for trying to help me though
Click to expand...
Click to collapse
I will make a more simple command fix for you tomorrow that will make your phone work with this without having you enter any code.
dk_zero-cool said:
I will make a more simple command fix for you tomorrow that will make your phone work with this without having you enter any code.
Click to expand...
Click to collapse
ah thank you soo much!!!
2am said:
ah thank you soo much!!!
Click to expand...
Click to collapse
I have updated the Busybox Installer script to make sure that it will work on newer devices other than MTD, and I have added a custom toolbox binary that will contain the proper options for these profiles.
Just check the first post at the buttom in the Important section. Fallow the link, download the installer and run it in your recovery. After that you can import the profiles from this thread into your Tasker application.
Playing With Notification LED
Original source (for MotoG) <<< make sure you read the blog article before commenting ....
dedicated Blog article for MotoE
It's always cool to know at a glance that your device is charging without the need of lighting the screen, here is how:
Requirements :
Moto E (tested on XT1022)
Rooted
SU rights granted
adb if you want to monitor all this from a computer
Code:
#include <std_disclaimer.h>
/*
* Your warranty is now void.
*
* I am not responsible for bricked devices, dead SD cards, BURNT LEDs,
* thermonuclear war, or you getting fired because the alarm app failed.
* YOU are choosing to make these modifications, and if
* you point the finger at me for messing up your device, I will laugh at you.
*/
in /sys/class/leds/charging/trigger we have these triggers available :
Code:
[none] bkl-trigger usb-online mmc0 mmc1 battery-charging-or-full battery-charging battery-full battery-charging-blink-full-solid bms-online
easy to change them using :
Code:
echo battery-charging >/sys/class/leds/charging/trigger
needs to set any value !=0 for brightness (LED is either ON or OFF on MotoE):
Code:
echo 1 >/sys/class/leds/charging/trigger
Moto E (is quite different than Moto G MotoG has two LEDs too, they are simply impossible to see):
If you pay attention, you can se that Moto E has Two little white LEDs soldered under the LED hole, the first one (left) is ruled by /sys/class/leds/charging and the second one (less bright, ont the right) is ruled by the /sys/class/leds/white.
/sys/class/leds/white/trigger, and /sys/class/leds/white/brightness configure the right LED and these settings are overridden has soon as a notification comes.
/sys/class/leds/charging/trigger and /sys/class/charging/brightness configure the left LED (the brighter one) and these settings are not overridden by notifications AND both can work toghether:
You can see the left one kept ON while charging (using battery-charging trigger) and the right one Blinking with an incoming notification.
It is time for the community to help, and we will find out a way to correctly dim the LEDs if possible.
For now, the best way is to set left LED (/sys/class/leds/charging/) for charging using dedicated trigger and keeping the right one to none and get both working together this way.
______________________________
Set at boot:
WARNING : if you fail this, you may screw up your device ... (keep a backup somewhere)
Create a blank file and name it like 99charging_LED-blink
paste the following in that file :
Code:
#!/system/bin/sh
# enabling charging LED blinking while charging
echo "battery-charging-blink-full-solid" >/sys/class/leds/charging/trigger
echo "1" >/sys/class/leds/charging/brightness
mount /etc/init.d as RW
Paste 99charging_LED-blink there
set permissions as -RWXR-XR-X
Open terminal emulator, and type :
Code:
su
sh /etc/init.d/99charging_LED-blink
Plug it to charger, it should start blinking ... if not, make sure everything is correctly set
Reboot
Enjoy!
______________________________
For whose who asked, here is the proof of the 2 LEDs and their White-color :
http://forum.xda-developers.com/showpost.php?p=57039807&postcount=7
Feel free to test further and report your discoveries!
The above has been tested on stock rooted ROM, and reported to work on CM11-m12, both on XT1022.
Here is the LED related Thread for MotoG
XDA:DevDB Information
[LED][DEV] Moto E LED Custom Controls, Tool/Utility for the Moto E
Contributors
matmutant
Version Information
Status: Testing
Created 2014-11-24
Last Updated 2014-12-15
reserved
reserved
@matmutant Epic discovery sir.. :good:
tried this in trickster mod led control... but since the left one is so bright it overrides the indication of the right..i.e the change in the blinking intensity is not visible until observed closely...
AshuGite said:
tried this in trickster mod led control... but since the left one is so bright it overrides the indication of the right..i.e the change in the blinking intensity is not visible until observed closely...
Click to expand...
Click to collapse
In fact, you should use the following :
Code:
echo battery-charging-blink-full-solid >/sys/class/leds/charging/trigger
This way the brighter will blink during charge, so the notification LED will be visible too (that's not the same blink pattern so it gives an irregular blink feeling)
Of course, i have no idea why there are 2 LEDs, and if lighting the brighter one will burn it or not : i'm going to add a disclaimer to OP since this mod has potential consequences on Hardware.
Thank you for your report, may i ask you your device and ROM?
matmutant said:
In fact, you should use the following :
Code:
echo battery-charging-blink-full-solid >/sys/class/leds/charging/trigger
This way the brighter will blink during charge, so the notification LED will be visible too (that's not the same blink pattern so it gives an irregular blink feeling)
Of course, i have no idea why there are 2 LEDs, and if lighting the brighter one will burn it or not : i'm going to add a disclaimer to OP since this mod has potential consequences on Hardware.
Thank you for your report, may i ask you your device and ROM?
Click to expand...
Click to collapse
same results on cm11 m12 and stock 4.4.4 in XT1022
For whose who asked :
I was able to show that our MotoE has 2 LEDs (until now it was only a high suspicion) and that they are really White and not mis-configured RGB.
Here is the in-depth proof.
If only we could change their color.
Sent from my GT-I9070
Is this working?
Because i have planned to make app for this.
svprm said:
Is this working?
Because i have planned to make app for this.
Click to expand...
Click to collapse
Sure it works
Two steps are needed to set up each LEDs :
The Brighter One:
Code:
echo battery-charging-blink-full-solid >/sys/class/leds/charging/trigger
Code:
echo 1 >/sys/class/leds/charging/brightness
The 'notification' One (better keep it to trigger=none, so it will keep its role of notification LED), but if you wanna play with it:
Code:
echo battery-charging-blink-full-solid >/sys/class/leds/white/trigger
Code:
echo 1 >/sys/class/leds/white/brightness
Contrary to MotoG, i couldn't dim this LED by setting 0~255 for brightness
There might be a way to trigger flash LED when getting notification, but this is not for Moto E either
if you make an app for this we could share this thread as co-contributors and in-depth study these new possibilities
If we can change colour, it will be too good
Sent from my XT1022 using xda premium
nisu4717 said:
If we can change colour, it will be too good
Sent from my XT1022 using xda premium
Click to expand...
Click to collapse
didn't you read this? : http://forum.xda-developers.com/showpost.php?p=57039807&postcount=7
btw here is the latest discovery :
Using "bkl-trigger" as */charging/trigger allows you to get the LED on as long as the screen ("bkl" stands for backlight)
Code:
echo bkl-trigger >/sys/class/leds/charging/trigger
Just because having this feature working at boot is soooo cool xD
Set at boot:
WARNING : if you fail this, you may screw up your device ... (keep a backup somewhere)
Create a blank file and name it like 99charging_LED-blink
paste the following in that file :
Code:
#!/system/bin/sh
# enabling charging LED blinking while charging
echo battery-charging-blink-full-solid >/sys/class/leds/charging/trigger
echo 1 >/sys/class/leds/charging/brightness
mount /etc/init.d as RW
Paste 99charging_LED-blink there
set permissions as -RWXR-XR-X
Open terminal emulator, and type :
Code:
su
sh /etc/init.d/99charging_LED-blink
Plug it to charger, it should start blinking ... if not, make sure everything is correctly set
Reboot
Enjoy!
matmutant said:
Set at boot:
WARNING : if you fail this, you may screw up your device ... (keep a backup somewhere)
Create a blank file and name it like 99charging_LED-blink
paste the following in that file :
Code:
#!/system/bin/sh
# enabling charging LED blinking while charging
echo battery-charging-blink-full-solid >/sys/class/leds/charging/trigger
echo 1 >/sys/class/leds/charging/brightness
mount /etc/init.d as RW
Paste 99charging_LED-blink there
set permissions as -RWXR-XR-X
Open terminal emulator, and type :
Code:
su
sh /etc/init.d/99charging_LED-blink
Plug it to charger, it should start blinking ... if not, make sure everything is correctly set
Reboot
Enjoy!
Click to expand...
Click to collapse
i already created a script for myself but unable to figure out how to control blinking pulse...
AshuGite said:
i already created a script for myself but unable to figure out how to control blinking pulse...
Click to expand...
Click to collapse
The blinking pulse is Hardcoded, that means end-user cannot modify it, though some work in the light Hal should both give hability to dim the LED and control its pulse frequency (no idea if it will really be userspace configurable or not then)
@dhacker29 had done something related for MotoX a while ago :
http://review.cyanogenmod.org/#/c/57550/
However, that's not part of my skill range :cyclops:
matmutant said:
The blinking pulse is Hardcoded, that means end-user cannot modify it, though some work in the light Hal should both give hability to dim the LED and control its pulse frequency (no idea if it will really be userspace configurable or not then)
@dhacker29 had done something related for MotoX a while ago :
http://review.cyanogenmod.org/#/c/57550/
However, that's not part of my skill range :cyclops:
Click to expand...
Click to collapse
in cm11 we have the option to control the pulse frequency..
AshuGite said:
in cm11 we have the option to control the pulse frequency..
Click to expand...
Click to collapse
Exactly, buy only for the notification LED (the one we can dim, under the rule of /sys/class/leds/white), not for the charging LED (/sys/class/leds/charging)
Any video tutorial?
bsaikartheek said:
Any video tutorial?
Click to expand...
Click to collapse
As i told you on G+, feel free to make one and i'll share it here
Can someone tell me how to do it please m not able to do it
Sent from my XT1022 using XDA Free mobile app
Upon opening a terminal app, gaining root access, and typing
Code:
cd /
cd /sys/class/leds/charging
access to the charging LED is obtained. The following parameters are available (see attached screenshot).
Code:
echo 255 > max_brightness
sets the maximum brightness of the LED to the highest possible value. Then, changing x for 0–255 in
Code:
echo x > brightness
gives a solid light of the specified brightness.
Code:
echo 1 > blink
makes the LED blink, and specifying a duration x in ms for
Code:
echo x > ramp_step_ms
changes the speed at which it blinks.
TL;DR the phone has a great, bright LED that can be used for notifications. Would love to see more discussion about this.
As would I. It beats me why Motorola would include an LED and choose not to use it at all ever.
unfnknblvbl said:
As would I. It beats me why Motorola would include an LED and choose not to use it at all ever.
Click to expand...
Click to collapse
they do with all the phones.
munchy_cool said:
they do with all the phones.
Click to expand...
Click to collapse
Having had a Moto X 2014, I'm aware of this. The difference was that it kinda made sense for there to be no LED on that phone because of the fancy situation awareness it had. This phone, not so much.
@erfanoabdi has been reworking the light HAL for the Moto X4 to implement these discoveries, and it’s nothing short of impressive how he’s been doing all this for our device without having an X4 in his hands himself. Thank you so much, man!
Hi,
How can I get help for the other options?
Like trigger
The op has pigued my interest, however im not 100% sure what all that meant since im still a bit of a noob , but interested i am
Edit: time to change that signature..... if i can rrmember how tooo...
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.