[suggestion] suggestions for adjustments to limit the background (to save battery)

[WeirdMidas]

Hello, I came here just to give you some suggestions to help you with your module (mainly because I got some of your tweaks, such as HWUI and Surfaceflinger, so I felt obliged to help you).

The help I want to give is: background limitation

through these cmds:

# Always limit the background as much as possible
cmd settings put global app_standby_parole_interval 0
cmd settings put global auto_retrieval 0
cmd settings put global restricted_background_apps 1
cmd settings put global restrict_background_data 1
cmd settings put global app_standby_enabled 1 
cmd settings put global background_activity_management_enabled 1
cmd settings put global force_background_check 1
cmd settings put global app_auto_restriction_enabled true
cmd settings put global auto_restrict_background_apps_enabled 1
cmd settings put global forced_app_standby_for_small_battery_enabled 1
cmd settings put global background_task_service_interval_ms 10000

Each of these adjustments limits the background in a different way. I tested them in my module, and none of them affected notifications, downloads, etc. in a "noticeable" way, but I didn't test all the things that depend on the background, but notifications and downloads are fine for me.

Extra suggestion:

# Let kernel know our image version/variant/crm_version
if [ -f /sys/devices/soc0/select_image ]; then
    image_version="10:"
    image_version+=`getprop ro.build.id`
    image_version+=":"
    image_version+=`getprop ro.build.version.incremental`
    image_variant=`getprop ro.product.name`
    image_variant+="-"
    image_variant+=`getprop ro.build.type`
    oem_version=`getprop ro.build.version.codename`
    echo "10" > /sys/devices/soc0/select_image
    echo "$image_version" > /sys/devices/soc0/image_version
    echo "$image_variant" > /sys/devices/soc0/image_variant
    echo "$oem_version" > /sys/devices/soc0/image_crm_version
fi

The one above is to improve the kernel's compatibility with the system by "showing the kernel all the correct information", this helps with consistency on cell phones with custom kernels, custom ROMs, etc.

[TatshSiow]

I prefer to do the tuning systemlessly, so that will be better for users to revert the default settings after removing the module
But the extra suggestion is good, I will try to put this into the next build!

[WeirdMidas]

Oh, okay, forgive me for the background limitation.

As compensation, I have a somewhat "risky" setting (in this case, it needs testing to see if it works on all devices) that I managed to find by looking at kernel patches on schedutil.

The setting is to set the up/down rate to 10ms/40ms.

Like this:

# Schedutil config based in this patch: https://patchwork.kernel.org/project/linux-pm/patch/c6248ec9475117a1d6c9ff9aafa8894f6574a82f.1479359903.git.viresh.kumar@linaro.org/
echo "10000" > /sys/devices/system/cpu/cpu4/cpufreq/schedutil/up_rate_limit_us
echo "10000" > /sys/devices/system/cpu/cpu0/cpufreq/schedutil/up_rate_limit_us 
echo "40000" > /sys/devices/system/cpu/cpu0/cpufreq/schedutil/down_rate_limit_us
echo "40000" > /sys/devices/system/cpu/cpu4/cpufreq/schedutil/down_rate_limit_us

The reason for this? It is to eliminate the latency of frequency transitions and allow the CPU to maintain more stability.

In the patch I saw this setting, it is said to improve the performance of scheduler tasks by up to +10%. I tested this setting on my device, and from 156fps in Minecraft, I got 157fps (a very small improvement, maybe it is a margin of error) in three different tests in the same game.

I did not notice slow app openings, some even opened faster even with a very high up rate. Others at the same speed, others slower, etc.

Energy consumption is ok, I didn't notice any difference.