Fine tuning an Android system

Fine tuning an Android system

crok - crok.bic @XDA - crokbic @Telegram

Fine tuning a the Activity Manager a little bit

So, Android's activity manager (AM) is managing the processes, taking care of the cached and empty apps' RAM, too.

If the AM is using it's defaults it won't let too much apps sit in memory while cached / in state "empty".. it uses a kind of token system, 32 (or even less, 24 in some ROM sources) cached apps are allowed, check the AOSP source here:

https://android.googlesource.com/platform/frameworks/base/+/master/services/core/java/com/android/server/am/ActivityManagerConstants.java#81

..and this is almost hardcoded to the built ROM.. the only way to change the value is (a bit unusual I think): you must add a value in the settings.db - but after that it is automatically pushed to AM (it's not managed via build.prop or system.prop values..) Check the trimming trigger levels as well..

https://android.googlesource.com/platform/frameworks/base/+/refs/tags/android-9.0.0_r55/core/java/android/provider/Settings.java?autodive=0////#10490

..so if cached apps number is 32, then empty is half so it's 16, trim trigger of empty is 24 and trim cache is 5.. 5 only. Whenever you push the home button and the app has no service running (and that's the usual stuff.. no games have services.. most of the apps have no services..) So if you check the linked portion of the AM source you can see that if you add some value to the settings.db you can increase these numbers. I use max_cache 192 and it works really good.


So.. Android 9 and below..

To test it you can easily add it with Settings Database Editor from by4a for example:

https://play.google.com/store/apps/details?id=by4a.setedit22

Add a new key to the global table:

Key name: activity_manager_constants
value: max_cached_processes=192

An even easier way is to use ADB (or root + terminal) + pm:

adb shell settings put global activity_manager_constants max_cached_processes=192

..or on a rooted device:
su
settings put global activity_manager_constants max_cached_processes=192

To check the AM values issue this command:

Via ADB:

adb shell dumpsys activity settings

Using root on the phone:

su -c dumpsys activity settings

Look at the end of the output, look for CUR_MAX_CACHED_PROCESSES and the rest before and after the change, then start multitasking and check how it performs for you.

The best thing is: it does work without rooting your phone (if you are afraid of rooting..).


Android 10+ the above won't work..
New type of configuration has been implemented, something like:

adb shell
cmd device_config set_sync_disabled_for_tests persistent
cmd device_config put activity_manager max_phantom_processes 2147483647
cmd device_config put activity_manager max_cached_processes 160
cmd device_config put activity_manager max_empty_time_millis 43200000
cmd settings put global settings_enable_monitor_phantom_procs false

# If you are running MIUI then I advise you to disable PeriodicCleaner
# because it's the single most useless and annoying service ever
# (killing apps and services even though all the MIUI tips & tricks
# set for them, even processes running with OOM_ADJ 400 and 250!!!...)
cmd periodic enable false

Best of all: you don't necessarily need root!


I explained everything (with the sources I used..) on my Magisk module's GitHub page:

https://github.com/crok/crokrammgmtfix


JIT optimization for all applications:

adb shell cmd package compile -m speed -f -a

Or from a terminal with root on the phone itself:

su -c package compile -m speed -f -a

..or:

su
package compile -m speed -f -a





I know about 4 other build.prop values that also helps multitasking

I think this one only works up to Nougat:
ro.sys.fw.bg_apps_limit=128

From Oreo this is the correct one:
ro.vendor.qti.sys.fw.bg_apps_limit=128

And these three - from Oreo onwards:
ro.vendor.qti.sys.fw.bservice_enable=true
ro.vendor.qti.sys.fw.bservice_age=10000
ro.vendor.qti.sys.fw.bservice_limit=64

Google it up, please, for more info ;)



Running the dexopt background job forcefully.

Really handy after dirty flashing, after updating apps, etc.. the system would do it by itself when conditions are met (like deep doze idle, charger connected..) but sometimes it doesn't work because apps (or doze settings..) doesn't even let the phone idle correctly.. if someone starts to experience overall "slowness" of starting time of the apps (not like memory thrashing.. swapping to zRAM back-and-forth..) then most likely simply running the dexopt background job forcefully does the job and the phone will be snappy again:

With root from a terminal:

su -c cmd package bg-dexopt-job
- or -
su
cmd package bg-dexopt-job

- or -
from a PC with adb:
adb shell "cmd package bg-dexopt-job"

- or -
adb shell cmd package bg-dexopt-job

It runs for a lot of time usually.. seriously.. mostly depends on how much and how "big" are your apps (system and 3rd party apps installed from Play or elsewhere) and unfortunately it has no progress bar or indicator or anything, when it finished you will just got back the prompt and that's all. I usually have 35..40ish apps installed and no heavy games and for me it used to run for about 12..15 minutes. But it works like a charm! Best thing: forcing the job does not need root, you can try it on your unrooted phone right now, with adb (:

Anyway, the DexOpt can be tweaked further. There are levels of optimization for the apps' code, there are profiles for a lot of situations, like during installation, during boot.. Here are the profiles and their descriptions:

https://www.digi.com/resources/documentation/digidocs/90001546/task/android/t_faq_optimize_android_runtime.htm

And these are the props for these profiles and situations:

dalvik.vm.bg-dex2oat-threads=4
dalvik.vm.dex2oat-threads=6
pm.dexopt.bg-dexopt=everything
pm.dexopt.core-app=everything
pm.dexopt.forced-dexopt=everything
pm.dexopt.install=everything
pm.dexopt.nsys-library=everything
pm.dexopt.shared-apk=everything


Report Page