Develop Bugs

How to configure Android's *internal* taskkiller

Hi!
Note:
Sorry this posting got very long. But it will tell you how to configure Android's internal taskkiller which may help getting your hero really speedy again.. Without using any taskkiller.
Here the long story:
I just was curious if already someone tried to play around with Android's internal low-memory task killer.
We all know that Android uses a different way of handling processes. Instead of killing every process after its Activity ended, processes are kept until the system needs more memory. These processes usually should not harm the overall performance and should give speed improvements if you start an Activity again. That's the idea.
But when does Android kill a process? And which process? As far as I understood android keeps a LRU (last recently used) list and starts killing the oldest unneeded process. This way it is much smarter than any of the taskkillers we see in the Market.
Just for curiosity I started to investigate how this mechanism works. Please correct me if you think that I got something wrong:
What I found out:
ActivityManagerService.java tracks the "importance" of processes (is foreground, is running a service, ..) and reflects this importance by setting the "oom_adj" value of the process.
(For info: "oom_adj" is a value of every process under Linux which gives the kernel a hint, which process it can kill in an oom [out of memory] situation. You can see this value on every Linux 2.6 system in the proc directory: /proc/[PID]/oom_adj ). The higher this value is set, the more likely this process gets selected by the kernel's oom killer.)
It seems that on Android the current forefround application gets an oom_adj value of 0 and as soon it's not visible anymore it gets some higher value. I assume the concrete value is dependent by the processes' place in the LRU list.
The out-of-memory killer in the standard Linux kernel only runs in one situation: when the available memory is critical low. However in the Android Linux kernel there is implemented a more fine-grained handling of low memory situations.
I found the kernel source file "lowmemorykiller.c" (located in the kernel source tree under "drivers/misc/"; or look here for GIT source tree: http://tinyurl.com/lowmemkiller).
This module seems to be more configurable than the kernel's standard out-of-memory killer as you can define more than one memory limit, when it should get active and you can tell it which oom_adj values it may kill.
In other words:
You can say "if free memory goes below XXXX then kill some process with oom_adj greater then YYY; if free memory goes even more below than ZZZ then start to kill some processes with oom_adj greater than XYXY. and so on.."
So it's possible to define multiple memory criterias and matching processes which can be killed in these situations. Android seems to group running processes into 6 different categories (comments taken out of "ActivityManagerServer.java"):
Code:
FOREGROUND_APP:
// This is the process running the current foreground app. We'd really
// rather not kill it! Value set in system/rootdir/init.rc on startup.
VISIBLE_APP:
// This is a process only hosting activities that are visible to the
// user, so we'd prefer they don't disappear. Value set in
// system/rootdir/init.rc on startup.
SECONDARY_SERVER:
// This is a process holding a secondary server -- killing it will not
// have much of an impact as far as the user is concerned. Value set in
// system/rootdir/init.rc on startup.
HIDDEN_APP:
// This is a process only hosting activities that are not visible,
// so it can be killed without any disruption. Value set in
// system/rootdir/init.rc on startup.
CONTENT_PROVIDER:
// This is a process with a content provider that does not have any clients
// attached to it. If it did have any clients, its adjustment would be the
// one for the highest-priority of those processes.
EMPTY_APP:
// This is a process without anything currently running in it. Definitely
// the first to go! Value set in system/rootdir/init.rc on startup.
// This value is initalized in the constructor, careful when refering to
// this static variable externally.
These 6 categories are reflected by 6 memory limits which are configured for the lowmemorykiller in the kernel.
Fortunately, it is possible to configure the lowmemorykiller at runtime!
(But only if you are root). The configuration is set in the file: "/sys/module/lowmemorykiller/parameters/minfree"
So if you want to see the current settings, you can do:
Code:
# cat /sys/module/lowmemorykiller/parameters/minfree
This should produce output like this (or similiar):
Code:
1536,2048,4096,5120,5632,6144
These values are the 6 memory limits on which Anedroid starts to kill processes of one of the 6 categories above. Be careful, the units of these values are pages!! 1 page = 4 kilobyte.
So the example above says that Anddroid starts killing EMPTY_APP processes if available memory goes below 24MB (=6144*4/1024). And it starts to kill unused CONTENT_PROVIDERs if available memory goes below 22MB (=5632*4/1024).
So if you want to try if your Hero goes faster when fewer processes are running you can try to adjust these settings. For example if you practically do not want any empty processes you can set the corresponding value very high. For example, you can set the values like this:
Code:
# echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree
This example will tell Android to kill unused Content providers if less then 60MB is available and kill empty processes if available memory goes below 90MB.
All other processes will stay untouched! Do you see the advantage compared to process killers?
One word about durabilty:
If you change the settings like this, they are NOT PERMANENT. They will be gone after the next restart of your phone. So you can try to play around a little bit. Please share your results if you find some improvements!
To make this settings survive also reboots you need to somehow set this at startup. I am running Modaco's custom rom and added the command to the startup script /system/init.d/ramzswap.sh, but there may be other ways to do this.
Currently I also disabled compcache on my Hero and set the lowmemkiller very aggressive, as it seems to me that this makes my hero very responsive.
So these are my (current) settings:
Code:
echo "1536,3072,4096,21000,23000,25000" > /sys/module/lowmemorykiller/parameters/minfree
(and compcache disabled)
But play around.. I am glad about any feedback.
Please also give feedback if I am wrong or missed something!
Thx!

i would be interested in changing the application which is startet when i long press on home (normally its the task changer of sense ui, but i want another program to be started)

this is excellent!, I just updated the ramzswap.sh to your settings and I can tell you it does an excellent job so far of running for like 20minutes, my ram is around 76 MB with facebook with all the htc widgets running, it usually drops to around 50 MB, does compcache save alot of ram when you disable it?
Thanks so much for the amazing info!, its hard someone to explain everything for you like you did.

woah!! i cannot stand my phone when RAM is less than 100mb
i keep it around 115~130
anyway whats new in ur method? why not use the Kill-All widgets after setting the ignore list ..or smth like "Automatic Task Killer" ??

inkredi said:
anyway whats new in ur method? why not use the Kill-All widgets after setting the ignore list ..or smth like "Automatic Task Killer" ??
Click to expand...
Click to collapse
Its more sensitive, and doesn't require any more input from the user, whilst having a constant effect

The difference of this method compared to task killers like "Automatic Task Killer" is that there is no separate application involved.
There is no widget or taskkiller process which needs to be run.
Instead you configure the Android kernel itself how to handle processes. While taskkillers need to be run regularly (automatically or by hand) to check memory and kill processes, the way I described this gets done complete automatically by the Android kernel, immediately when available memory goes under the configured limits.
There is also no need for ignore-lists or something like this, as the Android kernel knows which applications it can kill and which not. Furthermore you can configure much more fine-grained when to kill which processes and the kernel is using the internal "last recently used" list and kills the least needed processes first.
External task killer only can kill processes "blindly", they cannot see which processes are "empty" (not hosting an Activity) or which have been in the background for the longest time, and so on..
When people tell you that taskkillers are evil, they mean that taskkillers interfere with Androids process management in a way this was never intended. The way I described you still let Android handling processes itself, but you just tell it to be more restrictive.
So this is far less invasive into the Android system and (should ) have less side-effects..
But I'm still learning. I am a programmer who wants to understand things. And fortunately here we have the source to do so..

These values can be directly edited in your initrc
*APP_ADJ, *APP_MIN_ADJ, *ADJ, *PROVIDER_MEM, *SERVER_MEM and *APP_MEM

Thanks for the info!
Hmm.. but how can I change the init.rc? As it is placed directly in the root directory remounting and changing the file seems not to work (like on the the /system partiton).
I can remount and change the file, but the changes are gone after a reboot. The root dir is mounted as "rootfs".. No idea how to change files in there (without building a new ROM).

Well, you can extract the initrc from the boot.img (first you need to extract the ramdisk)
Edit, and repack.

Very interesting
My minfree: 1536,2048,4096,5120,15360,23040 (compcache disabled)
The system is very fluid and responsive. I dont know if this is by the tweak or compcache, but I see in EStrong Task Manager just the necesary process, no more empty process and more space for hidden process, second.
Very curious.

@adwinp: Ok, i thought already about this. I will try when I have some time. Thanks for the info.

Great Post !!
I try this for 12h
Code:
# echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree
with compcache active and MCR 3.1 and hero has an incredible boost ! Apps load more quickly and fluidity is improved very well and i don't use anymore any "killall" app.
Background service also works perfectly.
Without this tweak, i noted random delay when many apps are loaded.
There is a way for disable compcache in MCR ?

@Xfight: Glad to see, I could help you.
Regarding compcache: I disabled it (for testing) on MCR by commenting out the line
Code:
/system/xbin/insmod /system/lib/modules/ramzswap.ko disksize_kb=XXXXX
in "/system/init.d/ramzswap.sh"
Or just temporarily (until next restart):
Code:
# swapoff /dev/block/ramzswap0

So exciting to hear this Anyway, I am some kind of new in linux programing. Would help a lot, if there is a step by step to add the command to the startup script /system/init.d/ramzswap.sh Do I have to go to recovery mode to do so? And use which application or just normal text editor to edit the script?
Thnks,

Anybody tried this on 2.1 Eclair AOSP ROMs?

I get permission denied when I try to change the values
# echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree

Tzira said:
I get permission denied when I try to change the values
# echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree
Click to expand...
Click to collapse
you need a rooted device for do this

This is just superb idea. I was looking for something like this for ages. Nice one mate.
By the way...
Tzira
I get permission denied when I try to change the values
# echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree
Click to expand...
Click to collapse
Did you try type "su" and then the command ?

UPDATE to make more clear what these 6 values mean, when you enter a command like this:
Code:
echo "1536,2048,4096,5120,15360,23040" > /sys/module/lowmemorykiller/parameters/minfree
[B] #1 #2 #3 #4 #5 #6[/B]
Important: The unit of these numbers are "pages" (1 page = 4 kilobyte)
These define 6 limits of minimum "available" memory (which is not necessary equivalent to "free" memory under Linux, but this is an other story). These 6 limits are associated with 6 categories of processes under Android.
If the available memory goes below one of these limits, the kernel starts to kill processes of the corresponding category.
On Android the "ActivityManagerService" takes care of assigning processes into one of these categories (which means nothing more than setting an appropriate "oom_adj" value).
Details on the 6 categories:
#1: FOREGROUND_APP:
Only the current application in the foreground. This is the activity that is the focus for the user's actions.​
#2: VISIBLE_APP:
Applications which are not in the foreground but are still visble to the user. That is, another activity lies on top of it and that activity either is transparent or doesn't cover the full screen.​
#3: SECONDARY_SERVER:
First: The "HOME" application (or SenseUI on Hero) also falls into this category! So do not set this limit to high!
Further: All (secondary) services, which are currently running. These are all normal services as we know them from applications. ("Primary" services are life-critical services like the PhoneService which never will get killed by the lowmemorykiller.) ​
#4: HIDDEN_APP:
Any other Activity which falls not under #1 or #2. So any Activity as soon as it is not visible anymore (i.e. in the background, because of pressing Home, or starting another Activity).​
#5: CONTENT_PROVIDER:
Processes which host a content provider that does not have any clients connected to it.
For explanation: Content providers store and retrieve data and make it accessible to all applications. Examples are: the contacts content provider, the calendar content provider, the sms content provider, and so on. These allow different applications to access the same underlying data (contacts, calendar, ...).​
#6: EMPTY_APP:
This is a process without anything currently running in it. On Android a prgrammer can call "finish()" to close an activity. The system still can decide to keep the "empty" process running, to avoid the startup overhead when the user needs the activity again. All processes in this group are empty processes.​
So, to sum up a little bit:
I definitely would be careful with the first 3 values, as they may affect directly the user experience! But it seems there is a wider range of settings we can try at the last 3 values. These applications could be safely killed. So try around until you find appropriate values for your needs.
As long as you just perform the "echo ..." command and do not change any startup script or something like this you should be on the safe side. If something goes wrong, just restart your phone and everything should be normal again.
Hope that helps..
[edit]
All said about this should apply to any Android device. Not only the Hero and not only Android 1.5. So try it also on Eclair!
[/edit]

eujene said:
Anybody tried this on 2.1 Eclair AOSP ROMs?
Click to expand...
Click to collapse
Im using it on the AOSP 2.0.1 rom for the CDMA Hero. I don't notice a whole lot of difference.

[Testing] Workaround fix for GPS data validity (0,0 position) bug

I've been working on fixing the GPS data validity bug (where positions are reported at a lat/long of approximately 0,0 prior to lock)
Attached is a version of libhardware_legacy.so that should do the following:
Improve debugging of GPS operation (change printf()s in the main GPS library file to Android logging macros)
Fix/workaround the 0,0 bug (I say workaround because I have yet to identify the root cause of the issue - however it is "fixed" from the point of view of an end user
A few "under the hood" cleanups/fixes
Things that are NOT implemented/fixed in this library:
XTRA (driver/library support for QuickGPS data loading)
Obtaining satellite status prior to GPS lock on Rhodiums (behavior on non-Rhodium unknown, but this should not change actual behavior at all except for the false 0,0 fixes)
Any methods for improved lock speed - all this does is prevent you from appearing south of Africa prior to lock
To test this fix (Intended for FRX05, may work with other 2.2.2 based builds that are derived from xdandroid FRX05):
Unzip the attached zip file
Place libhardware_legacy.so somewhere on your SD card. For organization, I use bindfiles/system/lib/libhardware_legacy.so
Open conf/froyo.user.conf in your favorite text editor
Within the custom_shells{} section of froyo.user.conf, add:
mount --bind /sdcard/bindfiles/system/lib/libhardware_legacy.so /system/lib/libhardware_legacy.so
Restart, and at this point:
1) 0,0 false locks should go away
2) You'll see lots of new GPS debugging info in ADB logcats
Edit: For testing, I usually use the "GPS Status and Toolbox" app from the market, since Google Maps does not show sat status.
With the stock GPS libraries, GPS Status and Toolbox will immediately report a 0,0 fix on startup
With this library, you should see that funky "wait for it circle" in the lower status area until you are locked. As mentioned above - you will not see satellite signal strength reports prior to lock

I was just looking at setting up the kernel build environment myself the other day.
The main useful reference I found was this:
http://forum.ppcgeeks.com/tp2-andro...modules-tinboot-nand-boot-more-beginners.html
However, that one's a bit of a firehose, too, since it deals with a lot of stuff specific to NAND.
In short clone these two repositories into the same directory:
Code:
git clone git://android.git.kernel.org/platform/prebuilt.git
git clone git://gitorious.org/linux-on-qualcomm-s-msm/linux-msm.git
The first is the vanilla kernel, and the second is the XDAndroid kernel modifications. You'll need the first to compile.
From that guide, compile:
Code:
cd android
mkdir modules
cd linux-msm
make clean
make ARCH=arm htc_msm_android_defconfig
make ARCH=arm CROSS_COMPILE=~/android/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- INSTALL_MOD_PATH=~/android/modules zImage modules modules_install
Follow that guide for putting together the modules for wifi and the location of your compiled files.

Thanks! I will take a look at that, although I get the impression from reading through things that that GPS handling is at a layer somewhere above the kernel but below where we start having to deal with Java. I just can't quite figure out where since I have never done any Android development before.
I am probably going to poke at the kernel at some point though to try and fix the LED behaviors. It is clear from the "sleep of death fix" test kernels that there is knowledge of how to change these behaviors - at the very least I want to make it turn things *off* when in deep powersave. (Seems nonsensical to me to indicate that the device is in a deep power save mode by turning on a bright power-burning LED, although maybe the LED consumption is negligible even when the device is asleep.)

Entropy512 said:
Thanks! I will take a look at that, although I get the impression from reading through things that that GPS handling is at a layer somewhere above the kernel but below where we start having to deal with Java. I just can't quite figure out where since I have never done any Android development before.
I am probably going to poke at the kernel at some point though to try and fix the LED behaviors. It is clear from the "sleep of death fix" test kernels that there is knowledge of how to change these behaviors - at the very least I want to make it turn things *off* when in deep powersave. (Seems nonsensical to me to indicate that the device is in a deep power save mode by turning on a bright power-burning LED, although maybe the LED consumption is negligible even when the device is asleep.)
Click to expand...
Click to collapse
Whoops, didn't read carefully enough at where you'd narrowed the problem down to. I haven't gotten around to setting up an environment for the system build yet, sorry I couldn't be more of a help!

Yup, http://gitorious.org/xdandroid/hardware_libhardware_legacy/blobs/master/gps/gps_msm7k.c is my first target. There may also be issues in gps-rpc.c

http://xdandroid.com/wiki/Getting_the_Source goes thru how to build the system image. It starts with getting the source and cascades all the way thru building a system image.
I'm setup to build it as well, and I've always wondered how we could fix this problem... Love to see it squashed!

Thanks! I'll start working on that, although probably not until after the weekend is over at this point.
The ghetto approach as an interim fix would be to not set GPS_LOCATION_HAS_LAT_LONG if both are exactly zero - This is not the right way to do it, but the chances of it affecting anyone before a proper validity condition is identified are slim. (Even if you ARE near lat/long of 0/0, there will be enough noise in the GPS solution that you'll almost never actually be blanked).
Probably should assume that all of the other validity flags should not be set if we don't have a position fix. (Assumption: The MSM7k GPS does not take inputs from the magnetometer or accelerometer, if the Rhodium even has a magnetometer, didn't think it did.)
Of course, I haven't quite figured out how GPS_LOCATION_HAS_LAT_LONG and such roll up to higher levels. There's some odd interactions in terms of when SV status becomes available, for example.

Entropy512 said:
Thanks! I'll start working on that, although probably not until after the weekend is over at this point.
The ghetto approach as an interim fix would be to not set GPS_LOCATION_HAS_LAT_LONG if both are exactly zero - This is not the right way to do it, but the chances of it affecting anyone before a proper validity condition is identified are slim. (Even if you ARE near lat/long of 0/0, there will be enough noise in the GPS solution that you'll almost never actually be blanked).
Probably should assume that all of the other validity flags should not be set if we don't have a position fix. (Assumption: The MSM7k GPS does not take inputs from the magnetometer or accelerometer, if the Rhodium even has a magnetometer, didn't think it did.)
Of course, I haven't quite figured out how GPS_LOCATION_HAS_LAT_LONG and such roll up to higher levels. There's some odd interactions in terms of when SV status becomes available, for example.
Click to expand...
Click to collapse
Yup, definitely no magnetometer in the Rhodium.
Good luck with this, it'll be a nice little fix if you can get GPS to stop reporting locks before it has one.

Source downloaded, have a build going. (First an unchanged one...)
I'm working on a Froyo tree for the moment, since I think in the Gingerbread alphas GPS is simply "not working", although the degree of "not working" was not defined. Once I'm more familiar with the GPS handling code I might take a look at how it works for Gingerbread.
A few notes about the Froyo repo in its current state:
The URL for Google Apps that device/xdandroid/msm/unzip-files.sh is outdated. cyanogen-mirror.local.host.name does not exist any more. android.local.host.name does but doesn't have the HDPI Froyo apps. I forget which mirror I used - the list is in the CyanogenMod wiki if you search for gapps
The froyo build scripts direct you to http://source.android.com/download - URL no longer exists, it is http://source.android.com/source/download.html now
The process for installing Sun Java 5 on Ubuntu 10.10 is in the URL above - you need it to do a froyo build.
Also, the wiki instructions are missing lib32readline5-dev as an Ubuntu package that needs to be installed (it's in the source.android.com docs tho) - I'll try to update the wiki later.

Entropy512, glad to see someone is interested in looking at the GPS code. I helped phh with it in the last go around to get the RPC messaging part working working, but nothing has been done since.
The NMEA parsing stuff you see in the current gps lib is unused, all the data comes from RPC. Before getting the data directly from RPC was working, we took advantage of the fact that NMEA is output to smd27 and parsed that string data. In any case, once the GPS is brought up, that NMEA data is still viewable by catting /dev/smd27.
If you want to check out other similar code, look at the vogue gps code. I think it supposed to work pretty well, and the RPC behind it is similar. Theirs is a bit different in that they split the gps processing across the kernel and userland, where ours is all userland.
Ultimately, this stuff needs a bit of a rewrite, because the libhardware_legacy interface to GPS that the current lib is written to, is gone for Gingerbread. If we could just get the RPC stubs generated, we might be able to plug into the reference Qualcomm implementation and take advantage of that well sorted code. Check out the cyanogenmod libhardware gps to see what that looks like.

Thanks for the additional pointers bzo.
I'm at the stage where I managed to build the froyo tree, but have not yet had a chance to test the built system ext2 image. That's a goal for tomorrow.

OK, dumb question - Since I'm now trying to understand that RPC code - Where do all those printfs in gps-rpc.c print to?
edit: Never mind, figured it out - it's buried in the logcat... Was trying to go back in time using Android System Info, but adb logcat lets me view it as it happens.
edit 2: Nope, those are D() statements in gps_msm7k.c - don't know where the printf()s in gps-rpc.c are going - nowhere? Should these be D() statements???

those printfs were from when that code was a console test application. Not surprising that they wouldn't show up by default in the logcat. I'm sure there is some way to make them show up. Dunno off hand, but some googling on android debug logging and redirection of stdout and such may dig up that info.

bzo said:
those printfs were from when that code was a console test application. Not surprising that they wouldn't show up by default in the logcat. I'm sure there is some way to make them show up. Dunno off hand, but some googling on android debug logging and redirection of stdout and such may dig up that info.
Click to expand...
Click to collapse
Ah. That makes sense why they aren't D() statements like in gps_msm7k.c
I tried changing as many of the printf()s to D() macros as I could, I'll test it tonight.
Edit: Had a chance to test it this morning. No output from any of the printf()s that I changed to D()s. Either I did something wrong, or none of those code paths are hit in a no-signal/low-signal situation prior to lock. Doing a make clean followed by a rebuild to make sure.

Those debug statements don't display by default. You'll have to change some compile and/or android settings to have them show up.
btw, if you're not already doing this, building just the gps lib and doing a mount --bind with just the lib in your startup.txt is a big timesaver, as opposed to updating the entire build

bzo said:
Those debug statements don't display by default. You'll have to change some compile and/or android settings to have them show up.
btw, if you're not already doing this, building just the gps lib and doing a mount --bind with just the lib in your startup.txt is a big timesaver, as opposed to updating the entire build
Click to expand...
Click to collapse
Hmm, got any pointers in this regard? They are working for gps_msm7k.c, but not my changes to gps-rpc.c - these are built by the same Makefile and components of the same library as far as I can tell. Is there a log tag filter somewhere?
Thanks for the mount --bind tip - will try that on my next build attempt.

if you copied over the same #define for D(...) from gps_msm7k.c, it seems like it should work the same in the other file. I haven't looked that much into android logging though.

For some reason my copy-and-pasted #defines for D() were failing.
Using LOGD() directly works.
I'm adding another set of LOGD()s now - It appears that something is calling update_gps_location() with bogus data.
BINGO! - It appears we are receiving PDSM_PD_EVENT_HEIGHT and PDSM_PD_EVENT_VELOCITY events prior to a position fix. No clue why - but even though GPS_LOCATION_HAS_LAT_LONG is not set, apps assume lat/long is valid when an update_gps_position() callback occurs.
Going to make it so we only do the update_gps_location() callback when GPS_LOCATION_HAS_LAT_LONG is set. Also going to try and figure out the right situations where we can call update_gps_svstatus() - right now it is only done when we get a PDSM_PD_EVENT_POS.

bzo said:
btw, if you're not already doing this, building just the gps lib and doing a mount --bind with just the lib in your startup.txt is a big timesaver, as opposed to updating the entire build
Click to expand...
Click to collapse
This is a good suggestion, but the bind mount statement would go in the froyo.user.conf, not the startup.txt .

arrrghhh said:
This is a good suggestion, but the bind mount statement would go in the froyo.user.conf, not the startup.txt .
Click to expand...
Click to collapse
yea, yea, that's what I meant , thanks for the correction

[Kernel] [EAS] Nebula: Energy Aware Scheduling: V10.1.0.O [09/20/2017]

{
"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"
}
Nebula Strikes Again​
What is EAS?
Energy Aware Scheduling (EAS) is an enhancement to Linux power management, unifying CPU power control under the Linux kernel. EAS extends the Linux kernel scheduler to make it fully aware of the power/performance capabilities of the CPUs in the system, to optimize energy consumption for advanced multi-core SoCs including big.LITTLE. With EAS, the Linux kernel will use the task load and a CPU ‘Energy Model’ to control task placement to select the optimal CPU to run on.
[ Features And Additions ]​
CPU governors: SCHED, SCHEDUTIL *NEW*
Extra I/O schedulers: BFQ, FIOPS, SIO, FIFO, SIOPLUS, TRIPNDROID, VR, ZEN, MAPLE
Overclock up to 2265MHz big cluster and 1728MHz little cluster
GPU Overclock 133Mhz up to 652Mhz
Sound Control mod that allows users to adjust digital audio gains
Backlight Dimmer
Button Light Notification
KCAL Color Control
Double Tap Fingerprint To Sleep and Sweep To Sleep
Fading/Pulsating Notification LED
Sweep2Sleep
Optional Disable FSYNC
Optional Disable magnetic cover
Home button Mapper
USB FastCharge
Various patches and fixes
Updated with the latest from CAF branch LA.UM.5.5.r1-xxxxx-8x96.0 and EAS from Google's experimental branch.
And Various Other Features...
Known Bugs: (Work Arounds)
Sound Mod: While playing Music, Switch off/on BoomSound
SD Card corruption:
[Untested Fix]
Reboot back to recovery
Mount USB storage
Unmout it
Reboot
[Tested Fix]
Flash the last kernel that worked
Reboot
Flash the latest again
Reboot
XDA:DevDB Information
Nebula: Energy Aware Scheduling, Kernel for the HTC 10
Contributors
Eliminater74, thewalkingdude, INDIAN-MAfIA, prstorero
Source Code: https://github.com/DevHTC10/htc10.pme.msm8996.kernel
Kernel Special Features: Energy Aware Scheduling [EAS]
Version Information
Status: Beta
Created 2017-02-06
Last Updated 2017-09-20

Downloads:
Nebula: EAS: DOWNLOADS
EMPTY
Extra's:​
NOTE: @Freak07 Was kind enough to tweak out the init.nebula.rc scripts..

Reserved

reserved 11

Reserved 434

Thank You To The Following:​ @INDIAN-MAfIA <--- Helped so much with this project
@flar2
@buckmarble
@tbalden
@franciscofranco
@Sultanxda
@squid2 (sultanqasim)
@shminer
@osm0sis
@neobuddy89
@Alucard24
@Myself5
@andip71
@RenderBroken
@myfluxi
@dorimanx
@frap129
@Cl3Kener
@nvertigo (First person to teach me to Build roms)
@Chainfire
@Tasssadar
@nkk71
@Captain_Throwback
@ZeroInfinity (Even know we had out Differences)
@Mostafa Wael (same as above)

Proper Way To Report a Bug: [/CENTER]
There are several apps that can do this process for you, Here is one: PlayStore: SysLog
And here is another: PlayStore: Andy Log (ROOT)
ramopps: is an oops/panic logger that writes its logs to RAM before the system
crashes. It works by logging oopses and panics in a circular buffer. Ramoops
needs a system with persistent RAM so that the content of that area can
survive after a restart.
logcat: the logoutput of the Android system
kernel log: (kmsg / dmesg): the kernel messages
Additionally there's the last_kmsg which is a dump of the kernel log until the last shutdown.
radio log: the log outpur ot your System / BB / RIL communication
4
ramopps: Some Documentation on Ramopps
Normal Logcat:
Code:
adb logcat -v time -d > logcat.log
Radio Logcat:
Code:
adb logcat -b radio -v time -d > logcat_radio.log
Ramoops:
Code:
adb shell su -c cat /sys/fs/pstore/console-ramoops > kmsg.txt
Kernel Log:
Code:
adb shell su -c dmesg > dmesg.log
Last_Kmsg: NOTE:
New location of last_kmsg on Android 6.0 and above: /sys/fs/pstore/console-ramoops
Code:
adb shell su -c "cat /proc/last_kmsg" > last_kmsg.log
NOTES:
-v time will include timestamps in the logcats
-d will export the complete log.
If you want to save a continuous log you can remove the -d parameter - then you need to cancel the logging process via CTRL+C.
To export a continuous kernel log use adb shell su -c "cat /proc/kmsg" > dmesg.log (and cancel it via CTRL+C again).
PS: This Document was taked from another XDA Thread Called: [Reference] How to get useful logs
URL: http://forum.xda-developers.com/showthread.php?t=2185929
Also check this one out: [Tutorial] How To Logcat
I only Revived it a bit for ramopps.
I will update this more at a later time..
[DMESG Help Commands]
Code:
Usage:
dmesg [options]
Display or control the kernel ring buffer.
Options:
-C, --clear clear the kernel ring buffer
-c, --read-clear read and clear all messages
-D, --console-off disable printing messages to console
-E, --console-on enable printing messages to console
-F, --file <file> use the file instead of the kernel log buffer
-f, --facility <list> restrict output to defined facilities
-H, --human human readable output
-k, --kernel display kernel messages
-L, --color[=<when>] colorize messages (auto, always or never)
colors are enabled by default
-l, --level <list> restrict output to defined levels
-n, --console-level <level> set level of messages printed to console
-P, --nopager do not pipe output into a pager
-r, --raw print the raw message buffer
-S, --syslog force to use syslog(2) rather than /dev/kmsg
-s, --buffer-size <size> buffer size to query the kernel ring buffer
-u, --userspace display userspace messages
-w, --follow wait for new messages
-x, --decode decode facility and level to readable string
-d, --show-delta show time delta between printed messages
-e, --reltime show local time and time delta in readable format
-T, --ctime show human readable timestamp (may be inaccurate!)
-t, --notime don't print messages timestamp
--time-format <format> show time stamp using format:
[delta|reltime|ctime|notime|iso]
Suspending/resume will make ctime and iso timestamps inaccurate.
-h, --help display this help and exit
-V, --version output version information and exit
Supported log facilities:
kern - kernel messages
user - random user-level messages
mail - mail system
daemon - system daemons
auth - security/authorization messages
syslog - messages generated internally by syslogd
lpr - line printer subsystem
news - network news subsystem
Supported log levels (priorities):
emerg - system is unusable
alert - action must be taken immediately
crit - critical conditions
err - error conditions
warn - warning conditions
notice - normal but significant condition
info - informational
debug - debug-level messages
[LOGCAT Help Commands]
Code:
Usage: logcat [options] [filterspecs]
options include:
-s Set default filter to silent.
Like specifying filterspec '*:S'
-f <filename> Log to file. Default is stdout
-r <kbytes> Rotate log every kbytes. Requires -f
-n <count> Sets max number of rotated logs to <count>, default 4
-v <format> Sets the log print format, where <format> is:
brief color long printable process raw tag thread
threadtime time usec
-D print dividers between each log buffer
-c clear (flush) the entire log and exit
-d dump the log and then exit (don't block)
-t <count> print only the most recent <count> lines (implies -d)
-t '<time>' print most recent lines since specified time (implies -d)
-T <count> print only the most recent <count> lines (does not imply -d)
-T '<time>' print most recent lines since specified time (not imply -d)
count is pure numerical, time is 'MM-DD hh:mm:ss.mmm'
-g get the size of the log's ring buffer and exit
-L dump logs from prior to last reboot
-b <buffer> Request alternate ring buffer, 'main', 'system', 'radio',
'events', 'crash' or 'all'. Multiple -b parameters are
allowed and results are interleaved. The default is
-b main -b system -b crash.
-B output the log in binary.
-S output statistics.
-G <size> set size of log ring buffer, may suffix with K or M.
-p print prune white and ~black list. Service is specified as
UID, UID/PID or /PID. Weighed for quicker pruning if prefix
with ~, otherwise weighed for longevity if unadorned. All
other pruning activity is oldest first. Special case ~!
represents an automatic quicker pruning for the noisiest
UID as determined by the current statistics.
-P '<list> ...' set prune white and ~black list, using same format as
printed above. Must be quoted.
filterspecs are a series of
<tag>[:priority]
where <tag> is a log component tag (or * for all) and priority is:
V Verbose (default for <tag>)
D Debug (default for '*')
I Info
W Warn
E Error
F Fatal
S Silent (suppress all output)
'*' by itself means '*:D' and <tag> by itself means <tag>:V.
If no '*' filterspec or -s on command line, all filter defaults to '*:V'.
eg: '*:S <tag>' prints only <tag>, '<tag>:S' suppresses all <tag> log messages.
If not specified on the command line, filterspec is set from ANDROID_LOG_TAGS.
If not specified with -v on command line, format is set from ANDROID_PRINTF_LOG
or defaults to "threadtime"

reserved 5

First post!

NFO NEWS: V7.2.2 is accessible from here as well as the others.
I will clean it up as I can.. I am doing 50 things at once here.. and this part is the most pain in the butt of it all...........
V7.3.0 Is in the works.................................................... Its finished for the most part.. but doing some testing to make sure its stable before I push it up............
Please bare with me on this thread................
Thank you all..

Teaser. ?

TheKnux said:
Teaser. ?
Click to expand...
Click to collapse
Well it boots
How does it perform?

The concept of a simple power-performance tunable that is wholly scheduler
centric is implemented by patches [01-04].
This is where we introduce a ‘global task boosting’ knob which is integrated
with schedutil to allow the scheduler to bias OPP selection. These first 5
patches allow to dynamically tune schedutil up to the point where it behaves
like the existing ‘performance’ governor.
Patches [05-07] extend the basic mechanism to use different boost values for
different tasks. This allows informed runtimes (e.g. Android and ChromeOS) to
feed the scheduler with information related to their knowledge about the
specific demand of different tasks and/or use-cases.
Thanks to SchedTune’s defined interface, the scheduler is now able to collect
simple yet powerful information about tasks: how much the user cares about
their performance.
Although it can be argued that something similar is already provided by the
existing concept of task priority, we believe that the proposed interface is
much more generic and can be further extended to support both OPP selection and
task placement, thus leading in the future to a more comprehensive energy-aware
scheduler driven solution.
These patches enable schedutil to service interactive workloads like touch
screen interaction. Only out of tree cpufreq governors like the Interactive
governor were thus far able to service such use cases.
The last patch in the series introduces the concept of ‘negative boosting’.
Negative boosting is beneficial for mobile devices in scenarios where it is
desired to intentionally reduce the performance of a task by running it at a
lower frequency than the one selected by schedutil.
For certain tasks, like compute intensive background operations or memory
bounded tasks, negative boosting can have measurable energy-saving benefits.
In these cases, a negative SchedTune value allows to bias schedutil towards the
selection of a lower OPP. Importantly, this can be achieved using the same
SchedTune interface.
This patch allows to dynamically tune schedutil up to the point where it
effectively replaces the “powersave” governor.
The patches are based on tip/sched/core:
a225023 - sched/core: Explain sleep/wakeup in a better way
For testing purposes an integration branch, providing the required dependencies
as well as a set of debugging tracepoints, is available here:
git://www.linux-arm.com/linux-pb eas/stune/rfcv2
Test results
============
Extensive testing of the proposed solution has already been done as SchedTune
is shipping on a production mobile device, with benefits observed for key
use-cases (e.g. improved responsiveness and performance of key workloads).
The following synthetic focused tests are used to show functional benefits and
report overheads. All these tests have been performed on an HiKey board, an
octa-core (ARM CortexA53 @1.2GHz) SMP platform, running a Debian image on a
mainline kernel and using schedutil configured with a 1ms rate limit value.
Performance boosting validation
-------------------------------
The functional validation of the boost mechanism has been performed considering
a ramp task generated using the rt-app provided by the LISA testing suite [2].
The ramp is configured as a 16ms periodic task which increases its utilization
by 5% every second, starting from 5% up to 60%. The task is pinned to run on a
single CPU and executed with different boost values:
0%, 15%, 30%, 60% and -100%.
The following table reports:
- the value used to boost the task in each experiment
- the rt-app’s reported performance index:
PerfIndex Avg (the higher the better)
which expresses the average time left from completion of a task
activation (i.e. a fixed amount of work) until its next activation
- the CPU average frequency (FreqAvg)
- the actual boost measured for the PerfIndex and FreqAvg
Boost PerfIndex Actual FreqAvg Actual
value Avg Std Boost [MHz] Boost
0 0.53 0.12 0% 606 0%
15 0.61 0.07 17% 658 9%
30 0.68 0.07 26% 739 22%
60 0.71 0.05 40% 852 41%
-100 -98.84 120.00 -2K% 363 -36%
For positive boost values, SchedTune can improve the performance of a task
(i.e. its time to completion) by a quantity which is proportional to the boost
value. This is reported by the increasingly higher values of the PerfIndex Avg
as well as the average frequencies used to execute the task.
For negative boost values the performance is progressively reduced, in the
reported case of -100% boost we verified that the system runs most of its time
at one of the lowest OPPs (thus providing a behavior similar to the powersave
governor) while still running at higher OPPs when other (not negative boosted)
tasks needs to run. That’s why the reported average frequency (363MHz) is
slightly higher than the minimum OPP (208MHz).
A graphical representation of the task’s behaviors at different boost values
and the corresponding CPUs frequencies is available here:
https://gist.github.com/derkling/8be0a8ac365c935b3df585cb24afec6c
Impact on scheduler performance
-------------------------------
Performance impact has been evaluated using the hackbench test provided by perf
with this command line:
perf bench sched messaging --thread --group 25 --loop 1000
Reported completion times (CTime) in seconds are averages over 10 runs:
| | SchedTune (per-task) boost value |
| Schedutil | 0% | 10% | 90% |
------------------+-----------+------------+------------+------------+
CTime | 12.93 | 13.08 | 13.32 | 13.27 |
vs Schedutil [%] | | 1.1% | 3.0% | 2.7% |
SchedTune currently introduces overheads when used on saturated systems such as
the one generated by running the hackbench test. This is possibly due to the
currently used locking schema which can be further optimized.
On the other hand, the SchedTune extension is mainly useful for lightly loaded
systems (mobile devices, laptops, etc.) where the additional overhead has been
verified to be compensated by the performance benefits due to (for example) a
faster task completion. Some of these benefits are reported in the following
section.
ChangeLog
=========
Changes since v1:
- Rebase on tip/sched/core:
A225023 sched/core: Explain sleep/wakeup in a better way
- Integrated with schedutil (in replacement of SchedFreq)
- Improved tasks accounting for correct boostgroups activations
- Added support for negative boosting
- Extensively tested on production-grade devices
Credits
=======
[*] This work has been supported by an extensive collaborative effort between
ARM, Linaro and Google, targeting production devices.

Ufff extensive and intensive
Can`t wait to try it out.

TheKnux said:
Teaser. ?
Click to expand...
Click to collapse
Holy C$$$$!! :good:

As much as i would like to understand, i cant.. I work in the hospital so i i dont have a background.. Hands down to eliminater74, really..

Lite thread cleaning.
I know there will be sides when it comes to development teams but out of respect for everyone involved. Keep the drama off XDA. This includes subtle jabs at each other, or just plain calling out. This will be the only warning as we have already gave out enough warnings to everyone.
Thanks
Wolf

grega_slo said:
Well it boots
How does it perform?
Click to expand...
Click to collapse
And camera works. still waiting for everything to settle, finally got my charge cycle in last night while I was sleeping, so don't know the exact results yet. Amazing so far. Way quicker and more efficient than the old EAS, that's for sure. But, a public version will probably be out soon, so my results wouldn't matter anymore since this is a test build.

Excited to try it out.

Holy.....
Looks like SchedUtil has quite a bit of tuning to get it working as expected.

[Bash/fish] CLI Productivity Config

Background
Mostly inspired by DOS and the 1200+ batch files I was gifted in early 2017, CLI Productivity Config is a project to port the concepts over to the Linux shell (whether it be for Bash or fish shell). This project has been developed and tested on Debian 9 (Stretch), but should also work great on Ubuntu 17 (Zesty Zapus, Artful Aardvark).
If using the Ubuntu Xenial LTS or any derivative (e.g. Linux Mint 18.x), you may find that the columnar expression for the 'dirw' command is not aligned. This is due to a package (BSDMainUtils) being ever-so-slightly too old (9.0.6) for the required feature to appropriately handle escaped characters (9.0.7). Since Ubuntu and the derivatives are currently catching up to a newer version (first LTS being Bionic Beaver), instead of making anyone face an upgrade path, I built from source an updated (9.0.7) package, for both i386 and amd64 architectures for Ubuntu 18.04 and derivatives. Or you can make your own update with 'debuild'.
Installation
Getting these tools is relatively easy. The method used below assumes the 'git' package is installed. If not (and don't care to install it either) you can download the package directly.
Code:
git clone https://github.com/joelmaxuel/cli-productivity-config.git
cd cli-productivity-config
./INSTALL.sh
For the last command, you can either choose which shell you use (or both) as part of the guided script. Will also prompt for installation of standalone scripts (below), if desired.
Functions
Currently, every function available for Bash is available for fish, and vice versa. Arguably the only exception to this is fish has a function called 'sudo!!' where Bash already has the equivalent 'sudo !!'.
cdb
cdfl
cdh
clihelp
dirw
dirlast / dirprev / actlast / actprev
editadd
mked
sudo!!
timer
Scripts
The theory is that all of these will be built from Bash. They deploy differently (which have it's perks and drawbacks) than functions. Also, the scripts will likely fit a more specific purpose than functions.
wakessh
Support
I am finding myself very delayed in adding features or finding/fixing issues. Either can be nudged along to my attention by either an issue, posting in this thread (being thorough pays off here) or better yet, a pull request if you have code to back up a particular solution.
Source
Found on GitHub: https://github.com/joelmaxuel/cli-productivity-config

Functions/Scripts in Detail
cdb
Performs a search (based on name) below the current working directory to change to any specified matched directory. As this uses a live search, you may not want to use this when then there is a very deep directory structure below, or you will find yourself waiting on the search results.
Code:
[email protected] ~/B/g/android_kernel_asus_msm8916> cdb arm
a 1) ./virt/kvm/arm
b 2) ./arch/arm
c 3) ./Documentation/devicetree/bindings/arm
d 4) ./Documentation/arm
e 5) ./Documentation/zh_CN/arm
f 6) ./sound/arm
g 7) ./tools/perf/arch/arm
h 8) ./drivers/scsi/arm
Select directory by letter or number: 2
[email protected] ~/B/g/a/a/arm>
cdfl
Move anywhere in the filesystem without having to type out or tab through a full path - enter the first letter of every path level instead. '~' and '/' can be used as a prefix (to start with home or root, respectively), or use '.' anywhere in the parameter to go up one level.
Code:
[email protected] /u/l/bin> cdfl ~B.
[email protected] ~> cdfl .
[email protected] /home> cd
[email protected] ~> cdfl Bg
a 1) ./Build/github
b 2) ./Build/genymotion
c 3) ./Build/git:
Select directory by letter or number: 1
[email protected] ~/B/github> cdfl ..
[email protected] ~> cdfl /ulb
a 1) /usr/lib/blt2.5
b 2) /usr/lib/binfmt-support
c 3) /usr/lib/binfmt.d
d 4) /usr/local/bin
Select directory by letter or number: 4
[email protected] /u/l/bin>
cdh
Displays a history of visited directories to allow changing back to one of them.
Code:
[email protected] ~/B/g/a/a/arm> cdh
c 3) ~/Build
b 2) ~
a 1) ~/Build/github/android_kernel_asus_msm8916
Select directory by letter or number: 3
[email protected] ~/Build> cdh
d 4) ~/Build
c 3) ~
b 2) ~/Build/github/android_kernel_asus_msm8916
a 1) ~/Build/github/android_kernel_asus_msm8916/arch/arm
Select directory by letter or number: 3
[email protected] ~>
clihelp
A helper message about common keyboard shortcuts. Can also be invoked by pressing ^h (CTRL + H)
Code:
[email protected] ~> clihelp
Keyboard Shortcuts:
CTRL + C – Cancels current command
CTRL + S – Repeats the last command with sudo
CTRL + L – Provide directory listing in current working directory
CTRL + U – Cuts text up until the cursor
CTRL + K – Cuts text from the cursor until the end of the line
CTRL + W – Cut word behind cursor
CTRL + Y – Pastes text
CTRL + E – Move cursor to end of line
CTRL + A – Move cursor to the beginning of the line
ALT + Backspace – Delete previous word
CTRL + Left – Move cursor one word to the left
CTRL + Right – Move cursor one word to the right
Home – Move cursor to beginning of line
End – Move cursor to end of the line
Tab – Autocomplete current command/argument
[email protected] ~>
dirw
A compact listing of the current directory with colour. Long names are truncated in the listing. Can also be invoked by pressing ^l (CTRL + L)
Code:
[email protected] ~/B/g/android_kernel_asus_msm8916> dirw
android/ AndroidKernel.mk arch/ block/
COPYING CREDITS crypto/ Documentation.../
drivers/ firmware/ fs/ include/
init/ ipc/ Kbuild Kconfig
kernel/ lib/ MAINTAINERS Makefile*
mm/ net/ README REPORTING-BUGS
samples/ scripts/ security/ sound/
tools/ usr/ virt/
[email protected] ~/B/g/android_kernel_asus_msm8916>
dirlast / dirprev / actlast / actprev
These functions either display or act (copy, move or remove) upon files that match a certain age (modified date), whether they are newer than a specific week/day/hour/minute (dirlast/actlast) or older (dirprev/actprev). The searches can also include a (wildcarded) name search as well.
Code:
[email protected] ~/B/g/cli-productivity-config> dirlast D 5 '*.fish' -rl
-rw-r--r-- 1 joel joel 2850 Sep 1 17:53 ./fish/functions/dir-core.fish
-rw-r--r-- 1 joel joel 50 Sep 1 17:05 ./fish/functions/actlast.fish
-rw-r--r-- 1 joel joel 3826 Sep 1 17:53 ./fish/functions/act-core.fish
-rw-r--r-- 1 joel joel 50 Sep 1 17:13 ./fish/functions/dirprev.fish
-rw-r--r-- 1 joel joel 50 Sep 1 17:15 ./fish/functions/dirlast.fish
-rw-r--r-- 1 joel joel 50 Sep 1 17:12 ./fish/functions/actprev.fish
-rw-r--r-- 1 joel joel 2634 Sep 4 09:25 ./fish/functions/cdh.fish
[email protected] ~/B/g/cli-productivity-config> actprev W 2 cp ..
Action: cp
The following files will be affected:
./README.md
./INSTALL-fish.sh*
./LICENSE
./INSTALL-Bash.sh*
Do you wish to continue? [yes|no]: y
[email protected] ~/B/g/cli-productivity-config>
editadd
Opens a file in your default editor, and then marks it for inclusion in the next git commit ('git status' is also run to verify the addition).
Code:
[email protected] ~/B/g/cli-productivity-config> editadd Bash/.bash_functions
M Bash/.bash_functions
[email protected] ~/B/g/cli-productivity-config>
mked
Makes and enters a specified directory (or several nested ones when applicable).
Code:
[email protected] ~/B/g/cli-productivity-config> mked examples/Bash
[email protected] ~/B/g/c/e/Bash>
sudo!!
Repeats the last command, with sudo preceeded. In bash, this already exists as 'sudo !!'. Can also be invoked in either shell by pressing ^s (CTRL + S)
Code:
[email protected] ~> apt-get update
Reading package lists... Done
W: chmod 0700 of directory /var/lib/apt/lists/partial failed - SetupAPTPartialDirectory (1: Operation not permitted)
E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)
E: Unable to lock directory /var/lib/apt/lists/
W: Problem unlinking the file /var/cache/apt/pkgcache.bin - RemoveCaches (13: Permission denied)
W: Problem unlinking the file /var/cache/apt/srcpkgcache.bin - RemoveCaches (13: Permission denied)
[email protected] ~> sudo!!
[sudo] password for joel:
Ign:1 http://mirror.its.dal.ca/debian jessie InRelease
Ign:2 http://mirror.its.dal.ca/debian stretch InRelease
Hit:3 http://mirror.its.dal.ca/debian stretch-updates InRelease
Hit:4 http://mirror.its.dal.ca/debian jessie-backports InRelease
Hit:5 http://mirror.its.dal.ca/debian jessie Release
Hit:6 http://mirror.its.dal.ca/debian stretch Release
...
timer
A cut down 'time' command showing only the "wall clock" time a command has run for.
Code:
[email protected] ~> timer sleep 1
Ran for 0:01.00 min:sec
[email protected] ~>
wakessh
Invokes Wake-On-LAN (WOL) for a PC defined by a profile, then remotes into the system once online.
Code:
[email protected] ~> wakessh android
192.168.1.111 not turned on. WOL packet sent at 19:23
Waiting a Minute...
Trying again.....
192.168.1.111 is UP as on 19:24
Attempting to SSH [email protected]
Linux terminatrix 4.14.0-0.bpo.3-amd64 #1 SMP Debian 4.14.13-1~bpo9+1 (2018-01-14) x86_64
Last login: Sat Mar 10 11:33:38 2018 from 192.168.1.101
[email protected]:~$

I love the topic! Command-line for life! Lets work together!
I too have become re-acquainted with my life-long friend the Command-line. My history with my keyboard goes way back:
In 1985, I inherited a Commodore VIC-20 computer which plugged into the bunny-ears antennae of my 13" television in my bedroom. Its operating system was Commodore BASIC with access to 3kilobytes of its advertized 20KB of RAM.
In 1989, I received an 80286-12 MHz PC/generic with 512kb of RAM and a 40MB Hard drive for my 8th birthday, first coming with DOS 3.2, gradually upgraded to MSDOS 5 after a motherboard replacement to a 386-SX 16 MHz and a whole 2 MEGABYTES of RAM.
At some-point after years of begging for more RAM and a C compiler, I was happily bestowed with a 486-sx 33 and an SVGA card. The new-fangled Windows 3.1 software annoyed me, because other than the pretty colors, my favorite software ran better under the command line, and I had written my own OS extensions as batch scripts to provide me multitasking and shortcuts.
Fast forward through many boring years of high school, windows machines (self-built AMD machines all), my friend, Dom introduced me sometime my senior year (class of 1999) to Slackware Linux, by bringing a floppy disk to one of my Doom LAN-parties (I proudly had a 100MB ethernet switch and a Cable modem, in the days of 14.4kbaud)...
At my University, I never went to classes because I spent freshman & sophomore years working through the LinuxFromScratch.org guide & flirting with girls. Fortunately, dropping out of school freed up my schedule the next year to build an industrial grade FreeBSD server from scratch, and configuring the software exactly how I wanted to keep it, for Co-location at the HE.net Network Operations Center in Freemont California, at only $88/month. This was potentially my version of Command-line heaven, with 8 friends offering to pay $10/month for their own websites, and the nude-modeling website of my fiance fast growing in monthly subscriptions.
Unfortunately, fate conspires against the honest, as after 12 months the co-location fee doubled to $168/month, my fiancee abruptly realized that people could see her nude photos on the internet, after her sister told her mom who blamed me, and ordered me to abandon my first successful business and refund the 200 subscribers their $10 monthly fees. My web-hosting customers quickly realized that they could just post to a public blog or photo-site for free, and stopped paying me, so their websites (and hours of tech support) became a charity I provided. My entrepeneurial ambitions of 2000-2005 of a public database showing the graph network of the photos and interactions of my friends, called buddylist.org (pending AOL negotiations), including its special messaging modes which integrated group texting across web and sms text messages, were set aside to pay for my obscenely high rent.
Through working at Microsoft-only employers, I remained familiar with the progress of Command.com and the features of Microsoft's Developer Command Console (might have forgotten the name)...
For the past decade, Debian Linux & Bash has been my OS command-line, and after falling in love with Computer Algebra, then, seeking the most openly licensed platform for my Scientific Computing Ambitions, and a more marketable programming language for my resume, I discovered Python.org & SageMath.org . The Computer Algebra luminaries who I followed developed their own command console called IPython.org which has now caught-on as the highly popular JuPyTer (Julia and Python Terminal), that supports this elegant console-style of programming in many more programming languages!
Most recently, I discovered a shell (and its fork) that proposes to offer the features of Bash & the Python programming language on top of the JuPyTer environment, as a suitable replacement for any Unix Login shell!
These 2 are named "xonsh" & "xosh", one is at http://xon.sh and the other is in the http://pypi.python.org index. The easiest way to install for a python user is: pip install xosh xonsh
I hope that by telling you this, you can practice one of my favorite Design Patterns of the Unix philosophy: "Don't Reinvent the Wheel". You can investigate the state of progress of xonsh to see which of those batch scripts is advantageous,
I am also in the early stages of evaluating the terminal features of the "terminology" sub-project of the Enlightenment GUI project, because I am building some foundational tools for a standardized client experience centered around an elegant Linux keyboard + console experience to mentor & inspire bright young adults into participation with the sophistication of the Unix tradition as a core element of my mission to teach International Collaboration on Open Source & Open Content Projects to all of Asia, China especially. I realized that they have an enormous amount of engineering talent in China, and a fledgling young Open-Source movement emerging alongside the emergence of capitalism. I hope to spread the wisdom of the immense value of public knowledge crystallized in the form of Open Source Projects as essential to the intellectual progress of the world, and the cross-pollination of ideas across the globe produces immeasurable value in the form of common wealth available to all who are aware of how to find it.
The elegant text console experience I am developing is relevant to Android, because these devices are suitable clients for remotely-booting (either through an unlocked bootloader or a root-mode package) my platform which will load a slick color Unicode console that is also an IDE built around my polyglot ideas for mixing many programming languages together with LLVM tooling that feels interpreted but is fully capable of being compiled into a distributable app, a Firefox fullscreen browser, and a remote terminal viewer, each fullscreen in a Wayland windowing system (Weston for now, rustc built "way-cooler" eventually), switchable by the volume keys. This project is competing for my attention among my several other ambitious projects, including REPOS to help unify the dozens of software repository tools I use, and STARS to help sort my favorites/bookmarks within individual projects (think GitHub, GitLab, Mercurial, Firefox, Chromium, Alternatives) in a unified manner.
I realize that one lifetime may not be long enough to finish all of my ambitions, so I have a project idea for that as well: Open Ambitions github.com/open-ambitions is my proposal to form a community where people can learn how to be thorough with their due-diligence of discovery about which aspects of their project idea are already being worked towards, have already been proposed, or already in existence, and which aspects are feasible or infeasible and why, and then a process for communal contemplation of the merits and costs of each proposal, including honest advocacy for contributions to existing projects, mergers of complementary or redundant projects, and prudent council on the process of forking an existing project with the least harm to the principle of reuse of code, and minimizing duplication of efforts.
Maybe you are perfect to be a co-founder of my Charitable Open Source Mentoring Non-Profit Organization, named Dandelion Labs? ( dandelionlabs.org & a dozen subdomains coming soon)

merbst said:
I hope that by telling you this, you can practice one of my favorite Design Patterns of the Unix philosophy: "Don't Reinvent the Wheel". You can investigate the state of progress of xonsh to see which of those batch scripts is advantageous
Click to expand...
Click to collapse
Hmm, as I understand it, since a good deal of what CLIPC does is modify the current environment (typically within that change the working directory), forking out to another environment to do something is well and good in a fork, but I am not aware of the voodoo needed for the changes resulting in that fork coming back. This is a big reason why I work on Bash and fish in parallel. It would be nice to be able to call on other interpreters and have it mean something later on, but this is quite different than calling on a 4DOS function while in DR-DOS.
There is probably a way to shim, but that provides the next problem. I want to be able to provide CLIPC with as few extras not already found in a vanilla install. Even if extras need to be installed, it can be a quick package grab away. According to Debian, xonsh is currently not yet mature enough to be mainline.
Don't get me wrong, I appreciate the alternative perspective. At this time however, since this hobby has slowed to a crawl due to other hobbies (a collection of servers, most of which are not mine; Commodore 64 repair; teasing possibilities with Soekris net4511 & Linksys WRT54GS network devices; odd soldering jobs) and being reasonably satisfied with the effect currently.
At some point I will revisit the old batch files for more ideas; and I will check out what xonsh can do as well. But when it comes to actively leveraging it, seems doubtful, at least for the moderate time frame.
Thanks for the info.

SOLVED: aptxui, CABLService, colorservice, Perfdump, SecProtect, SVIService, TimeServ

For a while now I've been asking about some of these and searching online, but no one seems to know too many details about these apps. Recently I decided to dive deep and find out.
In the latest 5.0.3 build for the 5T, I see 7 apps in /system/vendor/app/
/system/vendor/app/aptxui/aptxui.apk
This one appears to be a codec manager for bluetooth audio settings. In another thread someone pointed out it has annoying popup notifications. The entire apk could be deleted if it's annoying enough.
/system/vendor/app/CABLService/CABLService.apk
Inside the app is /res/values/strings.xml which shows CABL stands for "Content Adaptive Backlight Settings", for which the backlight can be automatically adjusted based on the screen content. It says, "Lower quality level indicate CABL will try to save as much power as possible without significantly affecting content being displayed. Auto visual quality level means CABL will try to maximize power savings based on auto detecting type of content being displayed."
/system/vendor/app/colorservice/colorservice.apk
This apk "Allows the application to directly affect the device's display paramter" and calls native_getAdaptiveBacklightScale, native_getBacklightQualityLevel, and native_getColorBalance. I believe it changes the screen color balance at sunrise and sunset. The way it's written seems insanely over-complicated.
/system/vendor/app/Perfdump/Perfdump.apk
Perfdump is a "Performance Tool by Qualcomm" which allows devs to grab details of the system (device storage, external storage, hardware test, logs) into a compiled report. The inclusion of <action android:name="android.provider.Telephony.SECRET_CODE"/> does seem odd though.
The full list of report objectives includes: Graphics, Input, View System, WebView, Window Manager, Activity Manager, Sync Manager, Audio, Video, Camera, HAL, Application, Resource Loading, Dalvik VM, RenderScript, Bionic C Library, Power Management, Package Manager, System Server, Database, CPU Scheduling, CPU Frequency, CPU Idle, CPU Load, Memory Reclaim, Binder Driver, Binder Lock, Synchronization, Workqueues, Regulators, Page Cache, IRQ Events, Disk I/O, MDSS, GPU, Screen Capture, and Overlay Alpha Setting.
/system/vendor/app/SecProtect/SecProtect.apk
SecProtect allows users or devs to encrypt or decrypt files. "Please set password first before encrypting/decrypting. You need to provide this password for decrypting the encrypted file later." What is being encrypted? No idea. XML tools include:
change_password_layout.xml
create_password_layout.xml
encryptdata.xml
encryptdata_operation.xml
file_explorer.xml
list_item_authaccess_settings.xml
/system/vendor/app/SVIService/SVIService.apk
SVI Display Settings can "Enhance the viewing based on the ambient condition", it's some sort of automatic screen brightness adjustment tool. The line ".method public abstract unlinkToDeath(Landroid/os/IHwBinder$DeathRecipient)Z" is a little disturbing.
/system/vendor/app/TimeService/TimeService.apk
TimeServiceBroadcastReceiver uses action.TIME_SET and action.DATE_CHANGED to maintain the correct time and date on Android devices. There are only a few lines of code in here, and no NTP servers listed, it's difficult to see how it works.

Great info, thanks for your findings, but I don't think these apps can be deleted? or is it ok to remove them? cheers

Can they be removed? Not sure yet. I'm going to remove the following and test on my 5T.
/system/vendor/app/CABLService/
/system/vendor/app/Perfdump/
/system/vendor/app/SecProtect/
/system/vendor/app/SVIService/