Database Info

Droidwall intercepts packets from kernel to Google, MS, xda

I like Droidwall. Here's my review: Droidwall is a nifty program which can easily be configured to block wifi and/or data communication for each individual application. Perhaps allows small savings in battery, data usage, and slight improvement in security. Particularly when app had no logical purpose to acces internet other than advertisements etc. Also does not cost any significant cpu or memory resources... just modifies a table somewhere.
Now onto my question:
One of the applications that I blocked was labeled “(Kernel) – Linux Kernel”
Blocking the “kernel” has no effect on items like browser, gmail etc.
Based on Droidwall log, over the past several weeks since I installed the program, it has blocked 397 outbound packets from “kernel” which were destined for a variety of IP’s that all seems to be associated with Google, XDA, or Microsoft.
Below is an example of three of the IP’s:
Google
74.125.227.140
https://ipdb.at/ip/74.125.227.140
xda
50.23.216.69
https://ipdb.at/ip/50.23.216.69
Microsoft
65.52.32.12
https://ipdb.at/ip/65.52.32.12
Another thing I noticed, these are the only log entries where the external IP is recorded in the log. In all the other non-kernel blocked-application log entries, the IP recorded is my router IP.
I’m using Entropy’s DD kernal on GB.
It seems to me a little strange that these outbound transmissions are associated with the kernel. And at the same time, they don’t seem to be associated with any obvious legitimate purpose....because my phone works fine on normal internet application even with “kernel” blocked by Droidwall.
Does anyone have any ideas what would be the explanation for these packets sent from kernel to Google, MS, xda ?

Well I don't know much of anything about programming, however some people say that it isn't just apple that collects information about people without them knowing. Could be that or I could be completely wrong.
Just for curiosity, do you allow anonymous data to be collected and sent to Google?
Sent from my SGH-I997 using xda app-developers app

If no answer here, maybe post your question here: http://forum.xda-developers.com/showthread.php?t=1957231

Well I don't know much of anything about programming, however some people say that it isn't just apple that collects information about people without them knowing. Could be that or I could be completely wrong.
Just for curiosity, do you allow anonymous data to be collected and sent to Google?
Click to expand...
Click to collapse
I generally answer no the the “anonymous data collection”.... thinking about battery, data usage, and privacy. I think several apps have that question. I don’t doubt there are a lot of programs trying to communicate for a variety of non-obvious (possibly suspicious) reasons regardless of how you set up the options. ....there were a several installed Apps attempting access that had no obvious reason to do so.
What initially struck me as strange was that this was attributed to the kernel.. that didn’t quite compute. Trying initially to formulate an intelligent thought about what that meant, I utterly failed and came up with the notion that these items must somehow be related to programming by the developer of the kernel. When I actually engaged my brain, I realized that was just plain silly because:
1 – That would be Entropy. Enough said.
2 – The kernel is open source.
3 – There are several different destination ip’s. If one person was trying to collect data, he wouldn’t send it to different places. So it must be several applications interacting with the kernel.... just shows up attributed to the kernel by Droidwall.
If no answer here, maybe post your question here: [afwall link][
Click to expand...
Click to collapse
Thanks Pony Ex. I didn’t know that program afwall existed. Looks like it might have some good improvements to an already-great program (Droidwall). Will definitely give it a try. But I’m not bold enough to post this type of question in the developer’s thread though... several others were scolded for non-appropriate posts in that thread.

To my limited understanding, and I apologize if I am wrong, entropy just modified the kernel that was already there? Hence why the new ICS and jelly bean ROMs are still using a gingerbread kernel.
So who actually wrote the kernel? Samsung? Google? Both?
I agree I don't see entropy gathering personnel data.
However, apple was caught doing it and to the conspiracy minded individual, Google (a company that made it's fortune with information) would be in a similar position to do the same.
Again I have no evidence or knowledge to back up anything I'm saying, however what better way to collect information then distributing a free open source program with 100's of millions of users?
Sent from my SGH-I997 using xda app-developers app

electricpete1 said:
Thanks Pony Ex. I didn’t know that program afwall existed. Looks like it might have some good improvements to an already-great program (Droidwall). Will definitely give it a try. But I’m not bold enough to post this type of question in the developer’s thread though... several others were scolded for non-appropriate posts in that thread.
Click to expand...
Click to collapse
electricpete,
http://forum.xda-developers.com/showpost.php?p=35352916&postcount=256
I'll fade the heat.
Edit: His first reply: http://forum.xda-developers.com/showpost.php?p=35360652&postcount=257

Pete,
Are you using the Droid Wall to stop the outgoing packets to ensure privacy or are you using it to stop the wakelocks that may be contributing to the wifi drain bug on gingerbread?

Here is a reply from someone else... pretty good read:
http://forum.xda-developers.com/showthread.php?p=13148076#post13148076
post # 47

Pony Express said:
Here is a reply from someone else... pretty good read:
http://forum.xda-developers.com/showthread.php?p=13148076#post13148076
post # 47
Click to expand...
Click to collapse
Thanks Pony Express, for posting that question. Good info in the responses and other links.
qkster said:
Pete,
Are you using the Droid Wall to stop the outgoing packets to ensure privacy or are you using it to stop the wakelocks that may be contributing to the wifi drain bug on gingerbread?
Click to expand...
Click to collapse
There is the potential to improve all three (limit data usage, limit battery usage, improve privacy).
I think the improvements in battery life and data usage are probably relatively small (especially because I also manage those by turning my connections off when not in use while away from home wifi)... whereas I think the improvement in privacy may be substantial... so I guess that's my main interest (improving privacy).
But since the $ cost and resource cost is basically zero, it almost seems to me like no-brainer choice to use it regardless of the level of benefit we expect (unless there is some hidden disadvantage...which I haven't seen yet).
I wasn't aware of a particular wakelock problem on Gingerbread. I haven't particularly noticed a change in batteryusage one way or the other (and I really wouldn't expect to notice unless it was a dramatic change), but it stands to reason that reducing traffic from unwanted Ads, pinging, data-gathering etc could help. Here are some links that may support that view:
http://gizmodo.com/5894572/in+app-ads-are-destroying-your-battery-life
http://www.theverge.com/2012/3/19/2884902/android-apps-battery-efficiency-study
There was one poster in the AFwall thread that suggested an App that is denied access will keep trying again and again, and therefore use more juice..... which also sounds plausible, but several others disagreed with that.
* I have installed AFwall now, in place of Droidwall. It is the same program with a few improvements (fixed hole in the security wall during reboot) and a lot of extra features. But still keeps the same basic simple user interface.

SEEDER [ Lag Reduction APP ]

ONLY FOR ROOT USERS
GUYSS This is a App Called Seeder . This App Is Used For Reducing Lags in Phone (Like in Games etc.)
INSTRUCTIONS : INSTall The App & Press ON Button It Will Be Automatically Reduce Lags In Ur Phone
_______________________________________________________________________________________________________________________
Lag reduction for ROOT USERS ONLY!
Many Android tasks run slower than they should for one simple, yet not-so-obvious reason: they consume large amounts of random data from a limited source. Random data is used to generate session keys and unique identifiers, in SSL and wifi, while starting processes, and during inter-process communication.
This data (entropy) runs out frequently, and that causes processes reading from the blocking device (if any) to temporarily stop responding (lag). These processes cannot continue until the Linux kernel repopulates the entropy pool, which takes time. In addition, input events are pulled from the user interface (to refill the pool), which may also contribute to the problem.
Seeder is a service for root users. It assists the kernel in "topping off" the entropy pool by re-seeding it with data from the non-blocking (high performance) random device. Optionally, it can also help alleviate MMC I/O contention by extending the I/O queue, allowing the I/O scheduler to make better decisions, and combine more writes.
On some devices, applications load significantly faster (particularly large ones like Facebook, Chrome, and Youtube), and task switching becomes effortless. Fewer visual "hiccups" occur.
You MUST be running a rooted device to use this application! If you don't know what this means, Seeder will probably not work on your device!
MOD Edit: Please download from here: http://forum.xda-developers.com/show....php?t=1987032

buddy this is not ur work right???
then according to the rules
12. Using the work of others.
If you are developing something that is based on the work of another Member, you MUST first seek their permission, and you must give credit to the member whose work you used. If a dispute occurs about who developed / created a piece of work, first try to settle the matter by private message and NOT in open forum. If this fails then you may contact a moderator with clear evidence that the work was created by you.
Convincing evidence will result in copied work being removed. If there is no clear evidence you created the work then in the spirit of sharing all work will remain posted on the forums.
As an addition, developers have the right to hold exclusivity over their work for as long as it is deemed necessary by the dev or freely share it. However, if the work is claimed as exclusive, it must remain as such. No selective sharing will be allowed (ie allowing certain people to use it and not others). Should the dev decide to start sharing the work with others, the work automatically becomes fair game for all to use.
In regards to permissions, same rules remain for this but if permission was already given, unless there is a very valid reason, it cannot be revoked (same applies to major updates on the work). Under that same premise, permissions cannot be denied unless the work is exclusive or under severe circumstances.
In plain English: If you want to keep your work exclusive, go for it. However, if you are going to share your work, do it fairly.
These rules apply to all software posted on XDA (including but not limited to ROMs, RUUs, apps, games, kernels, themes, icons, etc) unless that software comes with a license that waives these rules.
Click to expand...
Click to collapse
and here is the original thread http://forum.xda-developers.com/showthread.php?t=1987032 by @lambgx02 in android development and hacking so its of no use for creating multiple thread in all mobile forums

Yess.. This Is Not Mine Work
tejkkarani said:
buddy this is not ur work right???
then according to the rules
and here is the original thread http://forum.xda-developers.com/showthread.php?t=1987032 by @lambgx02 in android development and hacking so its of no use for creating multiple thread in all mobile forums
Click to expand...
Click to collapse
Yupp Its True This is Not Mine Work. Im Just Share This App :angel:

[GUIDE][Kernel] Comprehensive Guide to Kernels. [UPDATE:21.12.16]

If I answer the question of "what is a kernel" it wouldn't tell you much, besides there are enough other threads on XDA and other websites to answer this question.
The best question is "Why to use a custom Kernel?", which answers not only what it is, but also what it can do.
I like the way its explained here:
http://www.makeuseof.com/tag/consider-using-custom-android-kernel/
The next most important thing you need besides the custom kernel is an app to manage it.
Yes, you can change the code directly, but for most non-nerds an app tends to be best, providing a nice GUI to facilitate tuning.
And since I am aiming for this guide to be N00b proof, I am gonna provide as much information as possible.
There aren't many apps which give you control over all features of the kernel and, personally, I hate having to download multiple apps to control every feature of the kernel.
So these are my top 3 recommendations:
The original app from the kernel's dev. You know, the one made specifically for use with that Kernel?
Device Control [root] by Alexander Martinz (Not gonna explain why, just go and test it for yourself or at least look at the play store page)
Kernel Adiutor by Willi Ye (It has a nice material GUI, + Extra features such as tweaking low memory killer, sysctl & sysfs)
What I most found lacking in other kernel guides was a well organised and comprehensive list of things custom kernels can offer. And since there is so much a Kernel could offer I'm going to try to provide it in categories with a couple examples so you get a good idea.
If I there is anything not accounted for, you are welcome to reply to this post and I will be checking every day to expand with any new info.
So without any further ado:
Feature List
General Settings:
These are things which do not fall within any of the other categories to follow. They are things which are usually classed separately in the App used to control the kernel. Examples include but are not limited to Fast Charge, Gesture (Knock on, Swipe2Wake), Color Calibration, Vibration Strength.​
Advanced Settings:
These are similar to the general settings, but as the name suggests they are a bit more advanced and require a bit more knowledge/research to use effectively.
This includes Entropy (if you have no idea what this is look for Seeder App. The description of the App explains this very well.), Voltage Control (Ever heard of UnderVolting?), TCP Congestion Control (As a Networking Student I had no trouble understanding the technical documents about this, but knowing many who will be reading aren't knowledgeable of technical jargon I have included a nice link.)
http://androidmodguide.blogspot.co.uk/p/tcp-algorithms.html
As I know that there will probably be things I'm missing here, if you find anything which I have not explained, a quick google might be very helpful. Otherwise you are welcome to post a reply to this thread (even including the results of your Google if you need someone to explain it to you in a simple way.)
UPDATE 21/12/16: After getting my new HTC 10 I begun doing some research to understand the big.LITTLE configuration. It turns out that there are in fact some tweakable tunables for this. I won't be providing any recommended settings, since currently I am using a modded PnP which dynamically manages Kernel tunables for me, and as far as I know this is a feature unique to HTC.
But for those interested in finding out more here is a guide you could look through, if you want to learn more. The tunables are at the very end.
https://android.googlesource.com/ke...llow-dr/Documentation/scheduler/sched-hmp.txt​
CPU Settings:
This is what you're most likely here for, this is the home of Over (and Under) Clocking.
But it also provides other very useful settings which might not look so simple at first. Here you can select a CPU governor (No guys, I will not list and explain what each one is, there are just too many and too many with stupid names. Instead I will leave you guys with a link to another guide specific about CPU Govs.)
http://androidmodguide.blogspot.co.uk/p/blog-page.html
While we're still talking about CPU Governors, there is a further option that you have if your app supports it. You can tune the specific tunables for each specific Governor, to get the best result possible and most suited to you. Whether you want more performance or battery savings from that specific governor.
Here you can also find toggles for HotPlugging or its counter part CPUquiet (Available only for NVIDIA CPUs I believe.) Hotplugging is simply the technology which decides when and which cores to turn off. CPUquiet is similar but rather than turning off the cores it simply makes the idle. The advantage is debated but the possibility is still there.​
GPU Settings:
This one doesn't have many features (That I know of), it allows you to Over/UnderClock your GPU and also change its Governor.​
Memory Settings:
(EDIT: I have included a Memory settings after doing a bit more of research about it, since its slightly more complicated compared to the other settings. Although most of these settings are available in both custom or stock kernels they can be tweaked to experience performance and battery improvements. So I'll try to cover as much as I can.)
Here you can tweak anything related to RAM and Cache. For tweaking these settings I suggest using the app Kernel Adiutor which I recommended earlier.
Things which you can find in all kernels are Low Memory Killer (Out of memory killer function on Android.) There is no need for me to explain it, what it does is self explanatory, to better understand the tunables I will provide this link:
http://forum.xda-developers.com/showthread.php?t=622666
You can also find tunables for Virtual Memory (Caching parameters), which is part of "sysctl" in the kernel. Tweaking this improves cache management, helping improve load times of cached apps, battery saving by emptying cache less often etc...
Here is a link which will give you a description for each parameter: https://www.kernel.org/doc/Documentation/sysctl/vm.txt
But there are also things which are not active or part of all kernels. zRAM is part of stock, and some custom kernels disable it. While KSM (Kernel Samepage Merging) can be added by some customs.
zRAM is just compressed RAM space. So you can store more in RAM by compressing the data you can fit more data inside your RAM.
Now obviously it is slower than actual normal RAM (since you have to encrypt and decrypt the data), but apparently it still is faster than using swap (which is in your internal memory rather than RAM). The principle works based on that Android prefers to keep data stored as much as possible in RAM to keep recently used apps running quickly. The more you use an app the more priority it has, therefore will stay in normal RAM, things you use sometimes but not very often are kept in zRAM (regardless of how full your actual RAM is), but since you don't use this very often you don't notice the performance hiccup of decrypting that data.
Then last case scenario things you barely use are kept in swap.
For you IT enthusiasts you should have realised already that "z" is the technology prefix for Compression. So it shouldn't come as a surprise that zRAM is compressed RAM.
KSM (Kernel Samepage Merging), this is simple, but it requires knowledge of some terminology. I will try to explain as simple as possible.
It allows the system to merge/share identical memory pages in RAM from different Applications/Processes. Thus it frees up RAM memory.
The only drawback to this is that it's up to your CPU to perform this task, therefore while it will increase performance it will also use up battery. But this is negligibly small (In my experience).
Therefore my recommendation is that if your Kernel offers this keep it turned on.​
File System Settings:
The most desired setting available here is I/O schedulers. Again, I will not specify each scheduler since there are enough guides on the interbebs to give you all the info you need. On the other hand, I will leave you with my favourite of those guides.
http://androidmodguide.blogspot.co.uk/p/io-schedulers.html
The next most interesting settings is Read Ahead Buffer, this simply lets you choose how much data to load the buffer cache with. According to most benchmarks/tests the best value for this is 3 mb aka 3072 kb. This link gives you a better idea of it: https://broodplank.net/?p=788​
Thermal Driver:
Here you can find toggles to manage overheating of the CPU and GPU. An example of which is MSM-Thermal and Core Control. I'm not gonna go into detail about these, since they are pretty self explanatory, and in my experience they both had descriptions beneath the toggles.
The most important thing to keep note of here is that only one should be on at any given time. If you turn 2 or more of these on together it may give you some issues. (It did with me.)​
Tips & Recommendations
This is where as usual the writer gets to voice his opinion
Don't hate if you don't agree, just reply with your own opinion!!
I believe that any good custom Kernel should consistently provide some common settings.
We could say the minimum required to be considered a good custom Kernel.
Here is my list of basics:
General Settings:
Knock On (AKA double tap to wake)
Fast Charge
Advanced Settings:
Entropy
TCP Congestion Control
CPU Settings, all of it.
File System Settings, all of it.
Also my recommendation and tips for ideal CPU tuning and I/O schedulers.
FIrstly, CPU governors can be tuned to improve performance or battery saving. I found a good guide which explains the tunables:
http://forum.xda-developers.com/galaxy-s2/general/ref-kernel-governors-modules-o-t1369817
My recommendations will not take into account all the possible governors, but obviously if you take into account my recommendations and swap my choice of governor for an improved version of the same, or a similar one, then it should be even better.
While regarding the I/O schedulers, they are extremely under documented in comparison to CPU governors. And I have not managed to find a guide on how to best tune the tunables for the schedulers, so I will not cover this. If any one reading has any idea about this, please feel free to share your knowledge with us lowly humans!!
Actual testing reports and comparisons among schedulers are extremely difficult to find. So I will only recommend ones which I have found enough articles for or ones which I have tested myself.
Now for my list of recommendations:
Ideal CPU Governor
For general use, with a battery saving focus I would recommend the Conservative governor. And if you need a bit more of performance then it can be tuned to provide such.
For performance I would use Wheatley. If unavailable, then Elemental X or Interactive will be fine.
N/B: I added wheatley as an update after using it for a couple months, it has a double focus on both performance and battery saving. It follows the idea of "race to idle", that since idle saves the most battery then dealing with processes quicker means more time spent in idle. Therefore it will scale up to higher frequencies than ondemand and interactive, and it will try to deal with all processes in as quick a time as possible.
But it also focuses on battery, and if a process queue is taking long it will resort to scaling down the frequency to save battery while still getting work done.
In my experience I have not felt it glitch, and its very stable. It has improved my battery life (not as much as conservative), but it also has allowed me to use my device at full power.
But as with anything, there's always a downfall, which for wheatley is that it is a rare governor to find in most kernels. Currently I only have it on skydragon kernel. Most other kernels do not feature this governor.
EDIT 29/02/2016: I have learned of a new way to tune the parameters for Interactive governor, for optimum efficiency, when wheatley governor is unavailable. Since Interactive is always available - it is one of the stock governors.
In short it is tuning the parameters to use and spend more time in efficient frequency steps, in order to save battery while keeping the performance as high as possible. Using the fastest frequency steps before a huge jump in voltage consumption.
The links which helped me do it are the following:
http://forum.xda-developers.com/showthread.php?t=2769899
https://vjnaik.wordpress.com/2015/06/25/kernel-tweak-interactive-governor-paramaters-rooted-phone/
Ideal I/O Scheduler
For general use of your phone or tablet I would recommend using ZEN. It can provide good performance and better than average multitasking while having an average battery consumption. Being considerably better than ROW while at only slightly more battery intensive.
Obviously ROW is second choice, but if both of the above are unavailable, then B] FIOPS[/B] is a good replacement, ensuring an above average visual experience, good battery saving, at the expense of multitasking capabilities.
If battery isn't an issue, or you stream a lot of videos, then BFQ appears to provide similar experience to FIOPS plus excellent multitasking, at the expense of battery.
For Gaming, this was hard to find since there weren't any specific articles focusing on this, but from the descriptions and certain comments it appears that SIO provides a good experience. Others mentioned BFQ since it reduces lag.
For gaming you should absolutely avoid ROW and FIOPS since both have reported to increase lag during gaming.
For best battery saving the recommendation is definitely FIOPS. While it isn't the most battery saving scheduler (Noop is), it will provide the most battery saving while also efficiently giving you a great user experience.
For general multitasking the best one is BFQ. It will provide the best transfer rates (aka copy paste and install kind of thing), best for streaming & watching HD videos, and great for keeping loads of apps open at the same time.
N/B: I added ZEN to the list after using it for a couple months. At the time I first released this guide I could not find a kernel which offered this scheduler to test it. But after a while it started becoming more popular, and now it is easily accessible through most major kernels.
In my experience with it it has improved my multitasking slightly, while also reducing lag on general use. Battery increase unnoticeable.
Virtual Memory tuning
This one is a bit more complicated, and I have heard a whole bunch of stuff... Which is why I decided to test it myself and then come back to give you guys a report for it. The effects of VM tuning are not obvious at first glance and but affects the overall feel of the device. (Whether it feels like new, or sluggish etc...)
The main tunables you need to worry about are: Dirty Ratio, Dirty Background Ratio, Overcommit Ratio and Swappiness.
The guide I added above under "Memory Settings" will explain what each of these are.
Dirty Ratio & Dirty Background Ratio - Most people say that these need to be high, so that more stuff is stored in Cache. This will make your phone quick. Because cache is quick. But in reality this is only good advice if all you need to load on your phone is the system UI. Because as soon as you start loading different apps this cache fills quickly, and whenever you want to open an app/file/webpage that is not in cache, your CPU is tasked with both emptying whatever is filling up cache memory and load your new app into cache. Thus making multitasking a nightmare within the first day. A simple reboot of the phone is not enough, nor is clearing RAM (Note: Cache is not RAM).
Often the only solution to speed up your device is to Wipe Cache and Dalvik Cache from recovery every day. And for people with 150+ Apps installed which need to be optimized on boot, this means a lot of time is wasted.
My personal recommendation is to keep Dirty Ratio at around 40, which is double the stock value. Thus you have enough room before your phone freezes to free up cache. While Dirty Background Ration at 10, so that in the background without freezing the app you're currently in the kernel is constantly clearing cache. Allowing enough space for whatever you need to load.
Overcommit Ratio - While increasing allows more multitasking, I recommend leaving this at 0. It keeps RAM from completely filling up, thus avoiding "app xxx not responding" issues.
Swappiness - You have three kinds of fast memory on your phone, from quickest to slowest: Cache, RAM, Swap.
Swap is the last resort for your phone's memory. It is usually used when your RAM is nearly full. Swap is used for app data which is not currently being used, but part of the group of apps you use the most. (This is related to the Low memory killer, so for more information check that link. )
Since app data stored in Swap is stuff you don't use often it doesn't affect your phone greatly. But the more data kept in RAM, rather than Swap, the better.
Therefore after loads of try and testing I found that 40 is the perfect sweet spot. Allowing higher performance while keeping some data rather than completely deleting it when RAM is full.
This is my Guide to Kernels, if you find that it has helped you and would like to thank me remember to press thanks.
If you have any questions please do ask them, I'll answer the best I can.
If you would like to add more, dispute any of the things I said, give extra info on any specific thing which you believe deserves a more thorough breakdown, then go ahead, fell free to comment below.
Thank you for reading this Guide.

Nice guide and thanks for linking to my website
gsstudios

gsstudios said:
Nice guide and thanks for linking to my website
gsstudios
Click to expand...
Click to collapse
It was a pleasure, you have one of the most well informed and well organised guides to the stuff I could find.
Most others are just all over the place.
Keep blogging!

Very useful guide
Just a question: would it be possible gathering info about the "power suspend mode" that is often found in Kernel Adiutor?
{
"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"
}
What are the differences among the available options?
Thanks again for your guide

luke! said:
Very useful guide
Just a question: would it be possible gathering info about the "power suspend mode" that is often found in Kernel Adiutor?
What are the differences among the available options?
Thanks again for your guide
Click to expand...
Click to collapse
It took me ages to research, because initially when I did I found nothing. Whenever I searched this I would only find stuff about wakelocks. The wakelock system is more important to developers than actual users, so it was of no use to me.
But after a bit of research I THINK I found the original source code for this feature...I will put a couple links at the bottom for the enthusiasts to see.
(N.B. I will keep researching as I get more time to see if I can find more info on this, because it puzzles me also.)
Before I explain anything you must understand what the suspend state is, usually it is called sleep.
I usually cba to explain anything...since I am awful at explaining stuff in written form...I usually like to explain verbally. So I will leave you with a couple links:
Power suspend in Linux - http://unix.stackexchange.com/questions/162886/what-does-pm-suspend-hybrid-do
Power suspend in Android - http://bamboopuppy.com/android-suspend-a-brief-overview/
How it interacts with the hardware - https://source.android.com/devices/sensors/suspend-mode.html
Now for this kernel feature... I seems from what I have read that it is not activating or deactivating suspend mode....instead it is simply deciding on what "metric" to use.
Generally you could say that suspend state would be achieved on request by the kernel. But what if you want to automate the process so that it uses less requests, and thus goes to sleep quicker and more efficiently?
You make it so it bases on something else's output in order to initiate the count down.
This could be screen on/off (LCD panel), idle time (autosleep function), hybrid (autosleep & LCD panel whichever comes first), or userspace (defined by user.)
In all honesty, how it all works in detail I have no idea. But that is the basic idea.
I also have no idea why it keeps locking to userspace, as if it was default.
It seems that this function is not fully functional yet, or maybe it needs some fixing.
The gerrit page for the source code says that this project was abandoned by the main devs.
Gerrit page - https://gerrit.omnirom.org/#/c/9137/2
In summary, from other things I have read they say that Hybrid is the best one for battery life. But for me it never stays on Hybrid, it keeps resetting to userspace. Therefore I am unable to give you any further information about this.
I hope I helped.

Thank you, thank you, thank you, for putting this up so organized, the only problem on xda is proper guides, I can understand how much time and energy you have put into finding and putting up this guide, and the best part you have given links to the original author and not just copied their hard work and spread their knowledge combined. Well Done mate. That's a real example of how member of xda should be. this will help a lot of people. will share links to this thread.
Edit: added your thread link in my signature, hope you don't mind. I thought it would be better this way for people to see.

luke! said:
Very useful guide
Just a question: would it be possible gathering info about the "power suspend mode" that is often found in Kernel Adiutor?
What are the differences among the available options?
Thanks again for your guide
Click to expand...
Click to collapse
I have some new info about this, I don't remember specifics of where I got this, but it was in a thread about custom kernels.
A lost of people were asking why the setting was stuck.
And if I remember correctly it seems that this feature is a left-over stub from a failed project, which now has been superseded by Doze on Marshmallow.
It works exactly as I described, with the exception of Userspace, which rather than being defined by user it is defined by app. e.g. when app x says it's time to sleep phone will sleep. The other options are automated, and hybrid is the default option and we as users have no way to change it. It's been this way for a while, idk why Adiutor still has the option available.
Also finally understood fully why wakelocks kept popping up when I searched for this...it's because apps can set wakelocks to prevent the "power suspend" from happening, or even to wake the phone from a "power suspend" in order to not stop the app from running. This would be things like facebook, or other messenger apps which want to have a constant running service.
This created huge battery drains in KK and Lollipop, but now in Marshmallow Doze is a bit tougher to get around. Simple wakelocks won't do anymore.
billysam said:
Thank you, thank you, thank you, for putting this up so organized, the only problem on xda is proper guides, I can understand how much time and energy you have put into finding and putting up this guide, and the best part you have given links to the original author and not just copied their hard work and spread their knowledge combined. Well Done mate. That's a real example of how member of xda should be. this will help a lot of people. will share links to this thread.
Edit: added your thread link in my signature, hope you don't mind. I thought it would be better this way for people to see.
Click to expand...
Click to collapse
It's honestly been a pleasure.
I have been learning even more and soon I will re-update this thread with a lot of new info I have found.
I'm glad you liked this Guide, it did take me time and it's good that it has been recognized. You've made my day
This brings to mind the fact that I have been thinking on a new guide to newcomers into rooting and XDA, just explaining all that which is possible in a short but well organized guide .
Feel free to copy the link and share however you would like, it is honestly a huge help!

Thank you for making this guide, it helped me to understand my device further more

Thanks!
Android小楼阁-QQ群 439637151
来自搭载Android 2.3 GingerBread的华为Y220-T10

hello dude can i get your screenshot your setting on your kernel adiutor for daily, power save, and Gaming

.c.t.r. said:
hello dude can i get your screenshot your setting on your kernel adiutor for daily, power save, and Gaming
Click to expand...
Click to collapse
Unfortunately I don't keep presents.
I change on the fly as needed.
It just works better for testing rather than having specific presets to use, because I am constantly changing the actual values I use, also as apps get updated and their RAM usage increase or decrease, the values are always very fluid for me. I just keep changing until I find a comfortable value.
If there is anything specific you would like to know ask, and I'll advise you accordingly.

Thermal Driver:
Here you can find toggles to manage overheating of the CPU and GPU. An example of which is MSM-Thermal and Core Control. ...
Click to expand...
Click to collapse
Is there a way to manually set a temperature at which the CPU is clocked down to a specific MHz?
For example:
Temperature rises to 38 ° C = CPU clocks not higher than 800Mhz

thanks for this thread bro...
i have zero knowledge about kernel issues
and im so curious about how it work's and what it did
to our mobile phone's. but now i found your thread.
thanks for specific and detailed explanation..
even though i did understand only a little part of it
only the specific settings. I didn't know exactly how to use by changing
the number's of each settings under each codes and how it will
response to the performance of the device ..
i hope i will get it soon.. thanks again for putting this thread
it is very helpful in the likes of me newbie with zero knowledge
but willing to learn and understand how it is..
very big thanks bro...:highfive::good:

heross said:
Thermal Driver:
Here you can find toggles to manage overheating of the CPU and GPU. An example of which is MSM-Thermal and Core Control. ...
Is there a way to manually set a temperature at which the CPU is clocked down to a specific MHz?
For example:
Temperature rises to 38 ° C = CPU clocks not higher than 800Mhz
Click to expand...
Click to collapse
Unfortunately I don't know if that is even possible, you might have to mess with source code and add your own patches.
Good luck finding this out!
If and when you do share the knowledge with the community!

bearthing said:
thanks for this thread bro...
i have zero knowledge about kernel issues
and im so curious about how it work's and what it did
to our mobile phone's. but now i found your thread.
thanks for specific and detailed explanation..
even though i did understand only a little part of it
only the specific settings. I didn't know exactly how to use by changing
the number's of each settings under each codes and how it will
response to the performance of the device ..
i hope i will get it soon.. thanks again for putting this thread
it is very helpful in the likes of me newbie with zero knowledge
but willing to learn and understand how it is..
very big thanks bro...:highfive::good:
Click to expand...
Click to collapse
Dude, it's an absolute pleasure. It's mainly for people like you that I have made this guide.
I was like you too, and i didnt find a straightforward guide to help me out in the beginning...
There was a wealth of information but it was all over the place. A bit here a bit there.
I urge you to keep researching and keep learning. If ever you find that something you need doesn't exist, then make your own research and create that which you needed so that others who follow after you don't have to go through the same struggle!

Kyuubi10 said:
Dude, it's an absolute pleasure. It's mainly for people like you that I have made this guide.
I was like you too, and i didnt find a straightforward guide to help me out in the beginning...
There was a wealth of information but it was all over the place. A bit here a bit there.
I urge you to keep researching and keep learning. If ever you find that something you need doesn't exist, then make your own research and create that which you needed so that others who follow after you don't have to go through the same struggle!
Click to expand...
Click to collapse
some device not supported the tuning like my lg g4 h818p the noop doesn't tunable and cubic? thanks again bro

bearthing said:
some device not supported the tuning like my lg g4 h818p the noop doesn't tunable and cubic? thanks again bro
Click to expand...
Click to collapse
it's not the device, but the Kernel.
If the developer of the kernel adds support for certain features you will be able to use them.
You need to search and find the custom Kernel which has the features you are looking for.

Kyuubi10 said:
it's not the device, but the Kernel.
If the developer of the kernel adds support for certain features you will be able to use them.
You need to search and find the custom Kernel which has the features you are looking for.
Click to expand...
Click to collapse
any kernel is compatible to my g4 h818p? or
i search for specific kernel that compatible to my device?
thanks bro

bearthing said:
any kernel is compatible to my g4 h818p? or
i search for specific kernel that compatible to my device?
thanks bro
Click to expand...
Click to collapse
Find the thread for your device and you'll pretty much have found jackpot

i need help.i use kernel auditor to increase my headphones volume when playing music.( just use hdp slider to increase )
but happens that wen i unplugg the headphones and awnser a call the other persons dont hear me.
what to do?

Thoughts on Doze and its effect on safety applications

I wanted to start this thread to discuss Doze and its impact on reliability, primarily on safety applications.
I'd like to start with a general statement: the days of our devices being merely telephones are long behind us. We still call them cell phones, but as we - especially here - know, our devices are so much more. They truly are wearable computers. They're our music, our cameras, our navigators, our communicators, our personal databases.. and for some of us, safety equipment. And they must be reliable.
Now, battery life is important. No question about that. But.. and I'm trying to put this delicately.. Doze was forced upon us with no option to globally disable, and even "whitelisting" applications doesn't fully release them from the confines of the new battery management policy. For some of us, Doze has made our devices less reliable.
The application category I'd like to call attention to first is marine anchor alarms. For those who don't boat, anchor alarms monitor a vessel's position with the GPS. If the anchor drags a certain distance (and the boat moves more than it should), an alarm is issued to alert the crew to the danger. It is entirely possible to drift (particularly when anchored in current) without triggering the significant motion sensors, limiting even whitelisted apps to 15-minute GPS polls. A lot can happen in 15 minutes.
Obviously using a portable device as your sole means of anchor drag detection is not a wise idea. Yet, many people with smaller boats do it, because that's all they have. Some of us with larger vessels do it as well, with a secondary system as a backup (since anchor alert applications make it much easier to define the anchor scope and exclusion zones precisely). This is all very much beside the point.
This category of application can no longer function reliably on Android! As of Android 6.0, anchor alerts can no longer monitor the GPS position reliably 24 hours per day unless:
1. The device is plugged in (and the power supply hasn't failed), or,
2. The application uses media input/output (a battery-wasting hack).
Unlikely as it may be, it is possible that someone will lose their small vessel this summer because their device failed to notify them that they'd slipped off the anchor, even if they knew enough to whitelist the app!
This is a pretty serious regression, and there are others. AIS (Automatic Identification System) and radar warning apps that communicate directly with ship systems via IP are no longer reliable. Tasker can no longer respond to local events with a granularity better than 15 minutes. Sleep monitoring applications are broken as well. And this is after you've manually whitelisted these applications!
I don't want this thread to sound like a rant. Doze is a fantastic addition to Android. But I would like to get the conversation started so that more people recognize that it imposes a fairly significant cost for some people.. especially those of us with extended batteries who feel virtually no benefit.
I was hoping people could respond with:
1. Other categories of applications, or individual applications that are no longer reliable on Android 6+ (particularly those related to safety),
2. A "me too" if you want the ability in custom or official roms to a) completely/situationally disable Doze without root, or b) properly whitelist applications, and,
3. Whether or not you've personally experienced critical notification delays, missed alarms, or other negative effects you attribute to Doze.
If anyone does need to disable Doze in the meantime, there is a straightforward (not well documented) way to do it if you are rooted:
Code:
dumpsys deviceidle disable
The change is non-persistent.

Privacy with Play Services

Hello all! I'm sure most of you are familiar with Google Play Services, the base of Google's Android framework and the brains behind all the Google things you do on your phone. Less of you, however, might also know that Play Services is notorious for being a beast of an application that no one truly knows the function of.
Below here is a rough explanation of Play Services from what I know about it. You can skip this if you already know and move on to the bread and butter of this post.
Play Services is proprietary software, meaning that its source code is not available to the public. All of Google's apps are proprietary like this as well. While developers like Chainfire have legitimate reasons to close off their app source code so others don't steal it, and so does Google, it is extra worrying from a company that makes a profit off of collecting userdata. Many people, including me, do not trust Google with our data, so we try to avoid their products as much as possible.
I thought that it would be nice to create a megathread of sorts with various users' suggestions on how to subvert the constant surveillance of Play Services, while also attempting to maintain the useful functionality of it. Below are some of the primary methods that I have thought of, and that I and some others have tried:
LineageOS/CyanogenMod Privacy Guard - If you are using LineageOS or any derivative thereof, you can go to Privacy Guard and deny certain permissions from Play Services. I and another user have denied permissions from Play Services without side effects, but your mileage may vary. @javelinanddart said on Reddit that Privacy Guard does indeed block permissions from Play Services and other system apps, so rest assured that Privacy Guard actually does something rather than being a placebo.
XPrivacyLua - This is an Xposed module that feeds false data to apps rather than blocking it entirely. I haven't tried this method myself, but the XDA post I linked above reports that XPrivacyLua works, even in tandem with Privacy Guard.
microG - microG is an open-source alternative to Play Services. It emulates many key functions of Play Services - push notifications, location services, etc - without the data collection running alongside such functionality. To clarify, this is a full replacement for Play Services, so you would flash a microG package instead of a GApps package. There are lots of bugs, though, even admitted by the developer. If you want to learn more, I suggest you visit the XDA thread for it, or view the implementation progress for various pieces of functionality.
There is nothing else that I know of, so if anybody knows of another viable method or can provide their own experiences with the above ones, your contributions would be appreciated by me and the rest of the privacy community.

Thanks for thread.
My only reason to use custom ROM is because they are GApps-free. In nearly every other aspect stock ROMs are better. Phones without good custom ROM I simply setup without Google account and install f-droid and yalp stores.
Another idea:
Imagine: Google is not as evil as we think: there are many privacy related settings in your Google account. You can login with a web browser and try through all these settings - and hope.

Device is a Samsung i9305 with RR-N-v5.8.5-final, Magisk v16.0, XPosed, XPrivacyLua, microG (via NanoDroid). No genuine Google services; Google Play Store is the one and only Google application installed.
I hope it suits into this thread (thanks very much for creating it!), and I'd like to share my settings. Please refer to the screenshots; I think it's self-explaining where they where taken from.
Actually no restrictions to microG, only to Play Store.
Remarks: µG has no restrictions in the firewall (AFWall+ Donation Beta); Play Store only granted internet access via WiFi and VPN. Just for completeness; running a RaspberryPi in the home network with Pi-Hole installed and acting as the DNS-server in the network. Unless using the home network i.e. using a foreign WiFi network or mobile data, ALWAYS establishing my own secure VPN to my RaspberryPi (with PiVPN installed) via OpenVPN and again the Pi acting as the DNS-server. If interested in further details please refer to this thread.

Thanks for this.
I was considering asking for a forum section here devoted to privacy, but it doesn't seem like a popular subject here. (After all, most of the people who have already picked the most snoopery OS in the world could be assumed to be not particularly worried about privacy. ? )
I come from a different motivation: the hope that by using a somewhat hackable OS, one can theoretically modify it in ways to achieve one's objectives, including privacy. But the last few years have made it rather clear that the Big G is working determinedly to foil such efforts.
Lately that seems to take the form of pushing more and more essential services into the Gplay frameworks, and deprecating perfectly working things like GCM in favor of intertwining it with Firebase, which may saddle us with that analytics data vacuum in order to get another essential service, push notifications.
Re: revoking permissions from Gplay frameworks, I feel like Google's determination to get their hands on data by hook or by crook (eg their ignoring of user preferences to disable various radios and enabling them in the background anyway, to track location and such) means they will quite possibly circumvent these preferences at some point as well.
As I mentioned in another thread I've experienced various problems in the past when I tried to aggressively restrict perms on the Gplay services using CM/LOS Privacy Guard, but perhaps some of that came from choosing interactive restriction prompts rather than blanket revoking. I do know that so many essential services are tied-into the Gplay frameworks these days that blocking tons of perms will inevitably cause breakage of some things depending how you use your device.

Jrhotrod said:
...
There is nothing else that I know of, so if anybody knows of another viable method or can provide their own experiences with the above ones, your contributions would be appreciated by me and the rest of the privacy community.
Click to expand...
Click to collapse
Due to your request above, please allow me to draw your attention to two threads by me. In these threads I tried about one and a half year ago to initially capture but also to update how I believe to have enhanced the battery duration, privacy and security of my GT-i9305 and how I went for a GApps-free device with microG.
Over the time until today, some of the described implementations, applications and measures became absolete or were replaced by others (e.g. using NanoDroid - or Nanomod as it was called in the beginning, since it has come out). Some changes occured due to the step from Marshmellow to Nougat or the non-availabilty of the official Xposed framework for Nougat in the very beginning. However, over all the time I've tried to maintain both threads updated and amended but currently not to much occuring on that frontline, probably because I've received a privacy status on our devices that obviously satisfies me in my personal opinion.

Oswald Boelcke said:
Due to your request above, please allow me to draw your attention to two threads by me. In these threads I tried about one and a half year ago to initially capture but also to update how I believe to have enhanced the battery duration, privacy and security of my GT-i9305 and how I went for a GApps-free device with microG.
Over the time until today, some of the described implementations, applications and measures became absolete or were replaced by others (e.g. using NanoDroid - or Nanomod as it was called in the beginning, since it has come out). Some changes occured due to the step from Marshmellow to Nougat or the non-availabilty of the official Xposed framework for Nougat in the very beginning. However, over all the time I've tried to maintain both threads updated and amended but currently not to much occuring on that frontline, probably because I've received a privacy status on our devices that obviously satisfies me in my personal opinion.
Click to expand...
Click to collapse
Wow, this is really great! Very high-quality thread.
Will add to OP later today

I apologise for the double post (original in my thread here) but I guess it also suits in this thread.
Found the below quoted post by @jawz101 in the XPrivacyLua thread here. Pretty interesting, and therefore I like to share:
Looking around on Data Transparency Lab website http://datatransparencylab.org/ - they fund grants for research in privacy stuff.
...I found an app called AntMonitor, an academic research project that does a MITM SSL cert + local VPN to look at sensitive traffic - even that which is encrypted. https://play.google.com/store/apps/d...it2.anteatermo
Anyways, it shows some apps trying to send my gps coordinates even though it doesn't have Android permission. Like, my coordinates are actually attempting to be sent encrypted to a destination. XPrivacyLUA doesn't trigger so I can only assume they grab my coordinates in a way that circumvents the traditional Android permission model.
To test, just try the app and open a few apps. I think it's apps with the Facebook graph API that is maybe doing it.
If you like ANTMonitor another app that does an SSL cert+ VPN is Lumen Privacy Monitor- a project by Berkely, but it doesn't seem to detect raw coordinates like ANTMonitor does.
Click to expand...
Click to collapse
However, I suggest to also follow the discussion/conversation between jawz101 and M66B, which has developed after this post.

Oswald Boelcke said:
Found the below quoted post by @jawz101 in the XPrivacyLua thread here. Pretty interesting, and therefore I like to share:
However, I suggest to also follow the discussion/conversation between jawz101 and M66B, which has developed after this post.
Click to expand...
Click to collapse
This is certainly an important discovery, thanks for the news.
Now for the sidenote that's 10x longer than the main comment. ?
One of the key issues I have with the various "privacy tools" is trying to figure out whether or not I trust all these entities that produce these diagnostic things to not be a solution worse than the problem when it comes to possessing and safeguarding my sensitive personal data.
It's getting to the point where I'm no longer enamored of giving *anyone* access to such stuff if I can help it, no matter *who* they are.
Even if they're not lying about their intentions and their commitment to security/privacy, there are still matters like carelessness/incompetence and targeted attacks to worry about.

@Exabyter: You're statement and expressed concerns are abolutely correct. Nothing to add except that I wouldn't limit it to "privacy tools" but especially include all applications that require root (and get it granted by the user) or all Magisk and Xposed modules. The latter should definitely concern.
My personal decision:
I'm not willing to trust anybody from the very beginning but I'm willing to trust single persons, groups or agencies. I've developed my own, private criteria, to which I stick but I've also admit the final decision isn't always based on rationality but also a lot on my feeling (in my stomage).
I don't held any confidential data on my device but privacy related ones, and I don't use my device for any kind of banking, shopping or payments.
I consider to use tools, modules and applications if their functionality rests within my defined specifications for the use of my device. Then I go for "the shopping tour" while I try to look into the details of the tools under closer examination, which includes where is it from, who's the developer etc.
I'll continue with the measures already described in one of my threads.

Oswald - I think we have largely similar stances on such things. In my case I will sometimes sway towards the pragmatic over the pedantic when the pedantic involves so many inconveniences that the tech becomes more of a burden than a help to me.
For example, I really don't like the idea of 3rd-parties keeping data pertaining to my daily geographic movements, but I also use several tools and services that by their nature rely on location data which could in some cases end up in the hands of parties I'd rather didn't have access to it. So I have to regularly weigh the apparent cost/benefit of such services and there are certainly some of them which have a high enough value to me that I willingly lower my default "protection level" in order to keep the other benefits of such tools/services.
Certainly microG is an important tool in that toolchest as it has a major disruptive impact on some of the most common ways Google and other parties snoop on users. But some of its imperfections also threaten to keep me from my ultimate goal of carrying a single phone which performs all the tasks I need to accomplish with it without undermining my privacy in a major way. (And ultimately, my freedom and agency as a citizen in a nominally and allegedly "free and democratic society", which is the actual "big picture" problem with privacy incursions in general IMHO)
I have spent several years now, with varying degrees of effort and success, trying to come up with a hardware/software solution to this problem, and I've never reached a point where I'm fully satisfied with the results. The fact that I am still carrying several mobile devices with me everyday is proof enough that I haven't achieved my objective in this regard and it gets tiring. As does all the time spent on venues such as XDA, researching, discussing and keeping-up with all the relevant issues, not to mention the large amount of time spent tinkering with HW/SW in order to keep all the special measures working. (And after we finally get things working more or less the way we want, we are faced with the particularly customized hardware wearing out, becoming unsupported, 3rd-party ROM and other compatible and necessary software being abandoned/deprecated, and so on and so forth.)
Truth to tell I'm a bit bitter about the amount of time/energy I have to spend to achieve something which should have been part of the mobile platforms in the first place. The current de-facto mobile platform duopoly certainly doesn't help matters.
---------- Post added at 03:39 PM ---------- Previous post was at 02:57 PM ----------
Now that I've gotten that philosophical rant out of the way ? ...
So as far as technical specifics:
microG of course is a big help as it either neuters or removes many troublesome anti-privacy vectors. For example, at the present time it does not support Firebase Analytics at all, which means (as far as I can tell) any app that expects to get telemetry on users via Firebase Analytics will not get anything if the app user's device is Gapps-free and using microG instead. (It remains to be seen if adding Firebase Cloud Messaging capability to microG will negate this presumed benefit. Cynics like myself are inclined to think one of Google's key objectives in deprecating Google Cloud Messaging and rolling push notification frameworks into Firebase instead was specifically to undermine the ability of users to avoid/circumvent Firebase Analytics)
XprivacyLUA looks interesting and is on my list to test. I found its predecessor Xprivacy to be an extremely tedious and labor-intensive option so I never seriously pursued it after my initial testing.
There are various tools I find handy to help get a sense of how dangerous certain apps may be to privacy. Here are a few:
AppBrain Ad Detector
https://play.google.com/store/apps/details?id=com.appspot.swisscodemonkeys.detector
Addons Detector
https://play.google.com/store/apps/details?id=com.denper.addonsdetector
Checkey (also on f-droid)
https://play.google.com/store/apps/details?id=info.guardianproject.checkey
Applications Info (also on f-droid)
https://play.google.com/store/apps/details?id=com.majeur.applicationsinfo
Permission Friendly Apps
https://play.google.com/store/apps/details?id=org.androidsoft.app.permission