[Kernel] [EAS] Nebula: Energy Aware Scheduling: V10.1.0.O [09/20/2017] - HTC 10 ROMs, Kernels, Recoveries, & Other Developm

{
"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.

Related

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.

[WIP] How a computing system works + Why processor speed nowadays isn't important

This is still a real WIP. I'm writing bits between classes and such. (Had some formatting issues so I switched some of the text to pictures).
The processor I (with my group) built from scratch:
{
"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"
}
Some terminology:
bit - a signal either 'off' or 'on' --> '0' or '1'
nibble - 4 bits (e.g. "0100")
byte - 8 bits (e.g. "10010110")
kilobyte - 1024 bytes
This will give you guys a better idea of how devices like computers and our phones work and process. It'll go into the basic functioning and then some limitations that most people don't know.
This will also help you understand and I'll also explain why processor clock speed actually really doesn't matter that much and also why small optimizations in code (i.e. 30% "speed increase" or less) really actually are insignificant and inconsequential. If you have any questions feel free to ask!
Part 1:
The very most basic fundamentals of processing…. 0s and 1s!!:
Put your minds in base 2 (binary). That is, counting from 0 to 5 goes like this: 0, 1, 10, 11, 100, 101. Addition, subtraction, multiplication, etc all still work the same way and you can do it all by hand in the same way.
Lots of you (undoubtedly all of you) know that binary has something to do with how computers work. I'm willing to bet that almost none of you, however, could tell me how electricity, some computer chips, and wires can tell me that 1101 + 0111 = 10100.
The trick is logic. Computer processing is completely and entirely built on various groupings of logic functions and truth tables (e.g. AND [i.e. 0 AND 0 is 0…. 0 AND 1 is 0…. 1 AND 1 is 1], OR, XOR, NOT, etc). A truth table is basically just a visual representation of the logic functions, for example:
A XOR B -- XOR, or "exclusive or" is like saying "A OR B but not A AND B"
In fact, you could theoretically build an entire processor using nothing but the logic function NAND, but that would be exceedingly stupid and time, space, and speed wasting.
So, how does one construct a "gate" that takes two signals and translates it into the result? The easiest way to visualize this is water "gates." If you have a bucket with two hoses (inputs) feeding into one side of the bucket and one hose (output) feeding out of the other side, you can make different "gates" by varying the design of the bucket. For example, if you put a hole in the bottom that is the same size as one of the input hoses, you have built an "AND" gate. If water pumps in through both of the input hoses, the bucket can't drain fast enough to prevent water from reaching the output hose so the output hose will expel water (a "1") only when both of the input hoses are pumping water in (1 AND 1 is 1). However, if only one hose is on, the hole in the bottom will be able to drain it and the output hose will be a "0." To make an "OR" gate, you could just make the output hose stick out of the bottom of the bucket. So, yes, you COULD make a computer that runs on flowing water… but electricity runs a <sarcasm>teensy</sarcasm> bit faster and cleaner than water in buckets…
Making addition:
So, how does, say, addition rise out of these logic gates? It's actually oddly simple… You first write up a truth table for what you are trying to accomplish -- in this case let's do 1 bit addition.
A + B = Result
(Since we are only using 1 bit, we can't express that 1 + 1 = 10 (we have an overflow error)).
Now that we have the truth table, all we need to do is figure out what logic function(s) ties together A and B so that the output is Result! If you don't recognize it, it's simply A XOR B YAY! We've built a 1-bit adder… kind of!
Building a better one bit adder takes a slightly bigger truth table (and you can see where this starts getting a bit complex….).
[a potential carry in bit] + A + B = [a potential carry out bit] Result
There are several techniques and tricks and rules (similar to the type of rules you would use to factor x(x+2) into x^2 + 2x) that can be used to help solve bigger truth tables but I won't get into them because they are relatively insignificant for understanding how these work. The logic works as follows for the above table (note these may be simplify-able but I'm lazy:
So now you can build a 1 bit adder with a carry in and carry out using the logic above. Therefore, you can build an x-bit adder by stringing a bunch of 1 bit adders together (the previous C(out) leads into the next C(in)). Simple! That's how pretty much all processes are built -- logic!
Key parts of a really basic processing unit (note: a "clock" is an input into basically every single component of a processor. The clock signal is what tells things "okay, next step" so everything can move on to the next step. A 1.2GHz processor will "clock" the system 1.2 billion times per second):
Incrementor: Incrementors add 1 to a number on each "clock" cycle (this is how a processor will step through instructions in addresses in RAM).
Flip-flop (also called a "latch"): Super basic memory storage. Can be simply made with cross-coupled NOR gates. (See: http://en.wikipedia....ile:R-S_mk2.gif)
Register: Usually a series of latches (so we can store, for example, a byte rather than a bit). Stores a single input value for later access when "clock"ed. When clocked again, the old value is overwritten to make way for the next input signal. This type of memory is volatile -- i.e. when the power goes off, **poof** this stuff is gone.
Multiplexor: Multiplexors take in multiple inputs but have only one output. There is a 'deciding' input that tells which of the multiple inputs to output (e.g. there may be 4 inputs to the multiplexor (000, 010, 011, 110 [random]) with a deciding input of 01. This means that the 2nd input, 010, will be the output of the multiplexor when a clock signal arrives.
This list may grow….
And yes, all the above can be constructed with logical combinations.
Part 2:
Basic layout of my 8-bit processor
There are quite a few parts to a basic processor like the one depicted above. It's the general idea of how processors work, but ultra simplified!
Main Memory -- the "RAM" or really what stores the lines of code. The processor can also load, jump to, and store to different memory locations. Each memory address is an 8-bit address (meaning there are 256 [2^8] possible memory slots). Each 8-bit address holds 1 byte of information (the 'word' size is 8 **more on this later**).
Instruction pointer -- an incrementer that is incremented by a clock cycle. Starts at 0 (code put into Main Memory should start at memory address 0) and increments until it receives a "HALT" signal.
Accumulator -- the output of everything. All results to all commands and instructions will be displayed on the accumulator.
Control Unit -- dispatches the necessary deciding/control bits for various multiplexors, read/write enables, and any other controls that other components in the processor might need. The input is whatever the operator is in the current instruction (**more on this in the next section**).
Branching Control -- controls "branching." Branching is where if a given condition is satisfied, the instruction pointer will 'jump' to a different specified memory location (this is how loops work!). This control will make sure the processor branches without messing anything else up.
Arithmetic Logic Unit (ALU) -- one piece of the processor that handles all the math stuff it takes in two input 'words' and, via a multiplexor controlled by the control unit, outputs the result you are looking for.
So, you have an instruction pointer that starts at 0 and increments on every clock press. There is a program in Main Memory starting at address zero. The first line of code will have some instruction in it's upper 4 bits, and an operand (**more on this in the next section**) in the lower 4 bits. The instruction gets broken off and taken to several locations (the main of which is the control unit). The lower four bits get broken off and taken elsewhere. The signals flow through and the accumulator is set to whatever results from this line of code.
Example:
Addition program:
Instruction 00000000: First you set the accumulator to a certain number (e.g. 00110110) [you technically have to do this in two steps--set lower nibble and set upper nibble--but I'm consolidating it now for simplicity's sake]
Instruction 00000001: Then you copy that number into one of the four available registers (we could only have four registers in the processor for an 8-bit machine since you need to be able to specify two registers per command **more on this in the next section**) [e.g. to register A]
Instruction 00000010: Then you set the accumulator to another number (e.g. 00000011)
Instruction 00000011: Then you copy that number into a different register (you can't overwrite the register you already used or that first number will be totally gone!) [e.g. to register B]
Instruction 00000100: Then you send the command to add register A to register B --> the accumulator will now read 00111001
Part 3:
It's all just words...
What is a 'word'? A word is what a single unit of information is called. The word size varies by processor -- a 32-bit processor has, you guessed it, 32-bit words! That means each individual word is 32 bits long. The processor I built in my project *above* was an 8-bit processor -- 8-bit word size. In my processor, 4 of the 8 bits were dedicated to a certain command (an instruction or operator as discussed above) and the last 4 bits were the arguments of that particular command (for example, registers or bits you want to set the accumulator to). Word size also determines the amount of available memory a computer can access. Since everything needs an "address," if you've got a 32-bit processor and 32-bit word size, that means you can only generate/access 2^32 different address spaces (or around 4GB of memory ---> ahhhhhhhh, I see!). Hence the recent transition to 64-bit systems (4GB cap on memory [incl RAM] just isn't a lot anymore --> 2^64 [64-bit word size] gives us a 17 billion GB cap on memory).
Since in my processor we had an 8-bit word size, we could only use 4 bits for the operator, and therefore we could only have 2^4, or 16 commands. The commands were as follows:
HALT (stops the entire program)
LOAD (loads a value from Main Memory)
STOR (stores a value to a location in Main Memory)
AND ("and"s the bits of two numbers bit-wise)
OR ("or"s the bits of two numbers bit-wise)
NOT ("not"s the bits of one number bit-wise)
ADD (add two numbers)
SUB (subtract two numbers)
SEQ (displays a "1" if two numbers are equal)
SLT (displays a "1" if first number is less than second)
SGT (displays a "1" if first number is greater than second)
COPY (copies a value from accumulator [output] to a register)
SLA (sets the lower 4 bits of the accumulator to a specified 4 bits)
SUA (sets the upper 4 bits of the accumulator to a specified 4 bits)
BRIS (Branch if set [basically done for a kind of loops while reading from memory])
BRIC (Branch if clear [another way to do loops])
Each of these commands is assigned a different 4-bit pattern. For example, "COPY" was 0001, "ADD" was 0101, "SLA" was 1110, and "SUA" was 1111. The four registers, A, B, C, and D were each assigned 2-bit patterns 00, 01, 10, 11 respectively. Guess what... now we can write the addition program that I went through earlier in binary (unconsolidated)!
Code:
Addition program:
First you set the accumulator to a certain number (e.g. 00110110)
SLA to 0110 ==> 1110 0110
SUA to 0011 ==> 1111 0011
**accumulator will now read '00110110'**
Then copy that number to register A
COPY to 00xx ==> 0001 00xx [the 'xx' means that anything can go there and it doesn't matter]
Then set the accumulator to another number (e.g. 00000011)
SLA to 0011 ==> 1110 0011
SUA to 0000 ==> 1111 0000 **this command technically isn't necessary since SLA in this design will set the accumulator to 00000000 prior to setting values**
**accumulator will now read '00000011'**
Then copy that number into register B
COPY to 01xx ==> 0001 00xx
Then send the command to add register A to register B
ADD 00 and 01 ==> 0101 00 01
**accumulator will now read '00111001'**
Here it all is together ;)
Memory location What's in it
0b00000000: 11100110
0b00000001: 11110011
0b00000010: 000100xx
0b00000011: 11100011
0b00000100: 11110000
0b00000101: 000100xx
0b00000110: 01010001
0b00000111: 00000000 [HALT]
You can see how more commands and capabilities become available as the word size increases from 8 bits to 32 bits and even to 64 bits. With a 64 bit word size you can have 32 bits dedicated to the operator, which allows 2^32 possible instructions (vs. 2^4 for my 8-bit processor).
If you know how hex works and why it's used go ahead and skip this next paragraph!
When you have an 8-bit word size, it's not that hard to write a command in binary (e.g. 01010001). When you have a 32-bit word size, however, there's gotta be an easier (and clearer) way to write a command than 10101001010010001010110110110101 (you can imagine how big 64-bit would be...). So now we are led to hexadecimal, or a base 16 numbering system. In this, we split the command into nibbles. Each nibble gets it's own hexadecimal digit (counting in hex goes as follows: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 1A, 1B, 1C, 1D, 1E, 1F, etc). You can see how these cleans up the binary: 0b01010001 [b for binary] becomes 0x51 [x for hex] (0101 --> 5 and 0001 --> 1).
Part 4:
Processor speed/limitations..
So tell me.. what determines a processor speed? Most would say, "clock speed" (i.e., 3.0GHz is faster than 1.2GHz). What would you say if I told you that a 6.0GHz processor would be no faster than a 3.0GHz processor? Well it's true.. There actually is a current limit in clock speed because at this point increasing clock speed does absolutely nothing (which is why processor designers have moved to multiple cores + smaller processors). Actually, processors would be far less effective without something called 'pipelining.' First, however, I'll explain why increasing the clock speed doesn't increase the speed of the processor past a certain point.
Limit 1: You have the actual speed of the electrical signals. Imagine again a processor made of water gates I explained above. If you were to send clock signals to a series of connected water gates at a rate of even 5 times a second (let alone 2 billion times a second), you could intuitively see the problem that we'd have -- the clock speed is faster than the signals can even flow through the processor. The same situation arises when you are sending a clock signal to the processor at billions of times per second.
Limit 2 (the BIG one): Hierarchy of Cache, RAM, and even HD speed. Sure the registers in the processor itself can handle the clock speed, but can the cache, RAM, and HD? As you get bigger and bigger storage spaces (more and more addresses), it takes longer and longer to look up the piece of memory you are trying to find. The materials also get more and more expensive (A LOT MORE). It's fine to use expensive (and very fast) electronics for, say, the registers and cache because those are so small and there are so few that it's not costly. However, when you hit RAM and a HD, the cost skyrockets.
Say your processor is a 1GHz processor, so you are clocking 1 billion times per second. That means you are clocking once per nanosecond. The access time for a register is that -- one nanosecond [these are ballparks from within the past 5 years]. The lookup time in the cache is more -- two nanoseconds (which means if you are accessing the cache, you will already have a wasted clock cycle ON TOP OF all the clock cycles that go by as the signals are flowing through all the gates/other parts of the processor). The lookup time in RAM is even larger -- ten nanoseconds (9 "wasted" clock cycles while you're waiting for what you asked for). The lookup time in a hard drive is 10,000,0000 nanoseconds (solid state drives lower this by about a factor of 10) -- if we didn't have a cache or main memory, our devices would be unbelievably slow...
DEVICE SPEED IS LIMITED BY THE WEAKEST LINK (longest path) IN THE HARDWARE.
So, you ask, if even the register lookup time (by far the fastest memory in the processor) is barely 'good enough' for a 1GHz processor, why do we have 3GHz processors? This is thanks to a lovely thing called pipelining. How I've described a processor thus far is you have an instruction that flows through the processor until the accumulator spits out the answer (meanwhile you've wasted a bunch of clock cycles doing nothing [remember: just the lookup in a register takes the same amount of time as a single clock cycle -- the signals still need to flow through all sorts of gates and parts before reaching the accumulator]).
This is like building a car factory that starts with the instructions of how to build the car. When you send a clock signal to the factory they start building a car and the process flows through until a car is spit out the other end (you can keep sending clock cycles as fast as you want -- they won't start the next car until the previous car is spit out the other end). Pipelining is breaking that up into chunks (or like creating an assembly line in the factory), so that on each clock press, another answer (or car) can be spit out the other end -- this allows us to increase processor speed without wasting a ton of cycles. There is a limit to this too, because there is a limit to how many chunks you can break a single processor into [around 20 I believe] (which is why we've hit a limit around 3GHz).
So next time you're shopping for a device, you should realize that a 1.8GHz processor is really not going to make a big difference compared to a 3GHz processor, because while clock speeds kind of matter, the actually process itself is hugely limited by the slow speed of RAM and the HD. In fact, I'd even prefer a <2GHz processor with a solid state hard drive over a 3+GHz processor with a regular hard drive. Fast RAM also really helps.
Coming next....
Why most optimizations are useless...
Also reserved...

[Kernel] Advanced / Standard V7.2.2 [20170201]

{
"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 Rises Again​
[Features Coming-Soon]​
Available Flavours:
Standard : Close to stock but with CAF updates and some minor additional stuff giving a balanced profile. Uses stock pnp manager and thermal engine.
Advanced : CAF Kernel with added basic HTC stuff. Uses custom thermal engine providing a performance profile. Added with sound mods and updates from higher 4.4 kernels.
EAS: Energy Aware Scheduler- Very intelligent kernel developed by linaro. Decides the frequencies and idle efficiently for smooth experience with great battery life.
Known Bugs: (Work Arounds)
Sound Mod: While playing Music, Switch off/on BoomSound
XDA:DevDB Information
Nebula Kernel, Kernel for the HTC 10
Contributors
Eliminater74, thewalkingdude, indian-mafia
Source Code: https://github.com/DevHTC10/htc10.pme.msm8996.kernel
Kernel Special Features:
Version Information
Status: Beta
Current Stable Version: 7.1.0
Current Beta Version: 7.0.0
Created 2016-09-07
Last Updated 2017-03-25
Downloads:
Downloads​
Source: UM 5.5 C1/R1: Android N
Nebula: [Standard Downloads]
Nebula: [Advanced Downloads]
Nebula: [Public Testing Downloads]
Extra's:​
@Freak07, Has been kind enough to create a few scripts that are heavy tuned to nebula Kernel only.
Post-826
Post-796
Remember to thank this guy for his hard work...
This was posted with his Permission:
NFO:
Features:
Extra I/O schedulers: BFQ, FIOPS, SOI, FIFO, SIOPLUS, TRIPNDROID, VR, ZEN
Overclock up to 2265MHz big cluster and 1728MHz little cluster
GPU Overclock 133 up to 652mhz
GPU: Full Pixel's GPU Drivers
Sound Control mod that allows users to adjust digital audio gains
Backlight Dimmer
Button Light Notification
KCAL Color Control
Double Tap Fingerprint To Sleep
Fading/Pulsating Notification LED
Sweep2Sleep
Optional Disable FSYNC
Optional Disable magnetic cover
Home button Mapper
Various patches and fixes
[ Features And Additions ]​
IOSCHEDS: Added
bfq-iosched
fiops-iosched
sio-iosched
fifo-iosched
sioplus-iosched
tripndroid-iosched
vr-iosched
zen-iosched
GOVS: Added
impulse
elementalx
cpufreq_zzmoove
CPU-Boost
Overclock able
Sound Control By @GuneetAtwal, Modifications by @Eliminater74 to get it to work for HTC, @flar2 for intial modifications
Early Queue Merge (EQM) to BFQ-v7r7 for 3.18.0
Support USB Keyboard
Expose PVS Level visa sys
sys kernel interface to configure linux printk logging
Expose GPU used frequency statistics in a new sysfs (New Condensed Version)
lcd notifier
Notification LED control - V1.1b
msm_adreno_tz: add adrenoboost parameter By @tbalden
homebutton: add sysfs enable and vib_strength
homebutton: make visible to apps
mdss mdp: kcal for htc 10 (pme) Porting By @flar2 And or @tbalden
backlight dimmer
HomeButton: Press to Wake/Sleep By: @tbalden
Many more.. Will Finish later.. as well as more credits......
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"
Is this gonna be for stock roms?
Nice to see another Kernel for our beloved 10
Keep up mate.
#PowerOf10
reserved
Not sure what blue is lol.its nice to see you here on htc 10 and look forward to trying your kernel.
Welcome and you'll always have a sprint tester here. You can always get a hold of me here or on Google+. Nice to see you back in the drivers seat. :good:
Hey,
Great to see another kernel in development.
I'm currently running a cm based ROM and would be happy to test to see if it works (based on your comments in the second post).
More choice is always good for the community
gillim74 said:
Not sure what blue is lol.its nice to see you here on htc 10 and look forward to trying your kernel.
Click to expand...
Click to collapse
Blue is dev talk for BlueTooth.
jmkarnai01 said:
Welcome and you'll always have a sprint tester here. You can always get a hold of me here or on Google+. Nice to see you back in the drivers seat. :good:
Click to expand...
Click to collapse
I will keep that in mind... I havent even added the sprint dtsi files just yet.... But im getting there.
rav101 said:
Hey,
Great to see another kernel in development.
I'm currently running a cm based ROM and would be happy to test to see if it works (based on your comments in the second post).
More choice is always good for the community
Click to expand...
Click to collapse
I currently have a build now, its running on my device as I type this. But I like to run things on my device for a while
before I feel conferrable enough to release it to the public. Memory Leaks can take up to 3 days before they are noticed.........
I will prob request a few HTC 10 owners that wish to do some testing for me. But them users will have to be willing to join a hangouts group channel
with me, so that I can get instant feedback and send out tests quicker.
One thing people must understand about me, I go for performance.. Stable is a must too.. but Me personally am willing to Risk a fraction of Stableness to gain the performance that
I want. But my key factors are, Temp Control and Speed all while keeping stable enough not to destroy anything..
If anyone remembers me from the LG G3 Threads, I manged to get the G3 clocked up to 3 ghrz stable all the while keeping the temps down to idle 82f and Max active at 120f..
at 3ghrz running though aututu bench marking.. Run all the way though with no issues. LG's are known for heat issues.. So that is my #1 priority..
Also another big thing for me with kernels are options...... I believe a user of his device should have full control over how the kernel runs..
So I try and add as many sysfs options allowing total control of kernel. Now some options are not in any app.. and I dont feel like coding another kernel app..
But since the new Kernel Adiutor allows adding commands to its settings, you can add in the missing options...........
I know my current build running on my device now, allows the CPU Big: to sleep at 92% while the CPU Little: to sleep at 60%.
My personal fav Gov outside the default interactive is zzmoove....
Well enough for now.. Just giving a little nfo on what to expect from me.............
you can also check out my other threads from the G3 and V10 area to see what kinda work I do on kernels..
Nice!
Sent from my HTC 10 using XDA-Developers mobile app
To be fair,
I hardly tax my phone so I might not be the best tester for you but happy to help if you want.
Running European Unlocked phone and preferably will be using CM. Will check out your other dev threads to see about your work
Eliminater74 said:
If anyone remembers me from the LG G3 Threads, I manged to get the G3 clocked up to 3 ghrz stable all the while keeping the temps down to idle 82f and Max active at 120f..
at 3ghrz running though aututu bench marking.. Run all the way though with no issues. LG's are known for heat issues.. So that is my #1 priority..
Click to expand...
Click to collapse
Well you're perfect here xD The HTC10 loves to get really hot and then throttles down.
I'm totally up for putting my 10 back in the Freezer and run some Benchmarks at 3ghz or more^^
Haldi4803 said:
Well you're perfect here xD The HTC10 loves to get really hot and then throttles down.
I'm totally up for putting my 10 back in the Freezer and run some Benchmarks at 3ghz or more^^
Click to expand...
Click to collapse
Its near impossible to run the msm8996 at 3ghrz, Qualcomm lowerd the frq rates cause its 64bit and no need for the higher freq settings.
I am almost positive we can reach 2.0/2.4 which is what the 8996pro aka SnapDragon 821 reaches......
The 821 is just a highly optimized 820....... I study the Dif between them both and see nothing other then coding update.
but when you compare 820 cpu to the 821 cpu, its near identical...........
But the 3ghrz days are over... that was with a 32bit device..........
Nice, i miss some gov's and wish me zzmove and much more Settings like I/O Scheduling i come from the LG G2 and Lord @dorimanx have done a good job for the Device!
I can test on verizon for you
NFO_caution: Ok peepz, I am originally from the LG Threads for the G3 and V10, The HTC Scene is pretty new to me, Before I dug into Kernel Development for the HTC, I did a little
research and testing.. I have T-Mobile Device, My HTC 10 was De-branded and converted to US Unlocked version.... Yes im S-off,
Anyhow, From what I gather, Most devices are now on the 1.9x rom base.. So your device should work, If it doesnt. Then, I am sorry. I dont wanna create back ports on kernels....
This is early testing stages... Use at your own RISK................
I will list all features and more soon................
PS: Yes I added the sprint dtsi files..........
hmm, anyone else get a corrupted external sd card using this kernel?

[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/

Categories

Resources