From Boeffla WIKI
Jump to: navigation, search

Google Play Protect says Boeffla-Config is a dangerous app

Ok, Google is known to go over the top from time to time. It seems, since 17th of December 2017, Google Play Protect classifies Boeffla-Config as a dangerous and/or malicious app.

Of course this is complete nonsense! This affects not only my app, also other apps like Viper4Android and many more are all of a sudden "dangerous" now.

Nobody knows what Google does or scans in order to believe Boeffla-Config would be dangerous. Google is also not really communicative or responsive when they get asked what the problem is. So we will not find out and all we can do is to switch that "false alarm" off forever.

This is how it needs to be done:


Basically this setting will avoid, Google tries to scan and check (and report complete bullshit, which is even insulting me because it is so wrong) for apps you have not installed via Play Store.

I recommend using a different virus scanner instead of Play Protect, that is more reasonable. Personally I use Bitdefender Antivirus Free, which never let me down so far.

Needless to say, Google Play Protect is the worst security service you can even think of: https://www.theinquirer.net/inquirer/news/3019900/google-play-protect-scores-rock-bottom-of-anti-malware-test

You might now ask: Why should I trust you, how can I be sure Google is not right?

This is a good question. Of course, when you root your phone and install a kernel, you need to have some trust. Same goes for the app that tweaks the kernel of course. I can only say, I am not interested in getting your data, doing weird stuff on your phone - because I have a proper job and do not need to fool people + I have other hobbies than doing criminal stuff.

So in short, you just have to trust me. If not, just install stock kernel again and unroot your phone, this is the only way.

But I can only recommend, you upload the Boeffla-Config apk to a Meta-Virus-Scanning portal like www.virustotal.com, which checks the App with more than 60 different virus scanning engines. Not much more to say :)

I have battery drain since installed Boeffla-Kernel

First you need to understand that battery drain only comes from a kernel when something is significantly wrong in the kernel. All my kernels are tested in a way, these significant issues are not existing. I make sure I do not put in any additional wake locks, so it is almost impossible the drain comes from the kernel.

This said, 99% of the time battery drain issues come from apps, the rom or background processes. And you need to find out what exactly is causing it by using helping tools. The best tools in my humble opinion is BetterBatteryStats. While you can find it for free here, I still recommend to support the developer and purchase it from Play store. When you have this tool installed, you can let it run for a while and then check for deep sleep rate partial wake locks (these are the wake locks coming from processes and apps / rom) kernel wake locks (mostly coming from the communication interfaces like wifi, 3g etc.) When you have this done, post the screenshots of these sections and we might be able to advice.

In general, the following apps and processes are known to be battery killers sometimes:

  • Google apps (especially when put on some CM versions, then there is no deep sleep anymore)
  • Media scanner service (when it comes across a corrupted media file, it sometimes hangs)

Also feel free to read a similar article written by kernel developer colleague ElementalX - Click here.

OnePlus models / Galaxy S5: Boeffla sound does not show me all the options than on the S3

The OnePlus models and the Galaxy S5 use a completely different audio hub (Qualcomm WDCxxx) compared to the S3 where a Wolfson Micro audio hub wm8994 is used. While there was documentation available for the wm8994, this is not the case for the chip used in the OPO and the S5. Qualcomm also does not give that documentation out for non system-integrators. Therefore it is widely unknown what this audio hub can do at all, and even more how it can be utilized. Therefore I have no way to implement more than speaker and headphone volume control at the moment. The deal is: You get me the full documentation on the WM9320 chip and I can check what is possible.

Others upstream their kernels to higher Linux versions, why don't you do that?

I did that multiple years on the S3 and also for a long time on the OnePlus One and S5 kernels. However, the benefits of upstreaming to higher Linux kernel versions is close to zero. On the flip side it usually introduces new issues as the Android kernels are highly tailored and optimized for the specific devices. So I decided to stop upstreaming as the benefits are neglectable.

I have phone "abc", can you create a kernel for it?

I have a golden rule, and this says, I am only building kernels for devices I personally own. The reason for it is quite simple: I want to be able to test myself to ensure I meet my high quality standards before I ship something out.

So the answer is: Typically no, unless you somehow manage to get me your specific device (sponsoring, crowd-funding etc.)

Please note: I dumped Samsung as a vendor completely. So even if you would get me a Samsung phone sponsored, I will not work anymore on Samsung phones. Not as long as Samsung continues to be that dev-unfriendly, using nonsense as Knox, flash counters, e-fuses etc.

This said, I provide kernels only for:

  • OnePlus 5, 3T, 3, 2, 1, X
  • Samsung Galaxy S5 SM-G900F
  • Samsung Galaxy S3 i9300
  • Galaxy Tab 10.1 n8000 and n801x

Galaxy S3: For CM and Omnirom there are normal kernels and a so called "NG" kernel, what is the difference?

NG stands for "Next Generation". As only difference, it uses pure Samsung kernel source code only, not the smdk4412 kernel sources of the CM or Omnirom team. As the CM and Omnirom kernel developers did lots of tweaking and also their own upstream to quite old Samsung sources, the NG pure Samsung kernel sources should considered to be "cleaner".

Galaxy S3: I have music stutter problems with Boeffla-Kernel when my screen goes off

Most likely you are using zzmoove as governor. This governor is mainly done to be a good battery saver. hence it limits the CPU frequency during screen off to a low value. This is sometimes too low to have music still playing without stutter.

You can try two things:

  • Increase the minimum CPU frequency from 200 to something like 400 or 500 MHz in Boeffla-Config
  • If you have the donation version of Boeffla-Config, switch to profile "tunable" and increase the value for "freq_limit_sleep" to a slightly higher value.

Also make sure, you are not using extremely high readahead buffers for your SD memory, as this also can cause this problem.

I cannot configure setting abc... in Boeffla-Config app, it is greyed out

Then the reason is: The kernel does not support this option. Or I have intentionally disabled this for some good reason.

Example: On CM and Omnirom kernels, you cannot switch off the kernel logger, it is grayed out. I intentionally do not allow this as the past showed, disabling the kernel logger led to glichtes in sound output. Weird, but proven.

Galaxy S3: I am on the Galaxy S3 Samsung kernel, my camera does not work?

Known issue, easies way to make it working again is:

  • flash stock kernel once (many stock kernels available in the download section here)
  • Open camera, take a picture
  • Now flash Boeffla Kernel back and it will work

Galaxy S3: My device charges very slow since I am using Boeffla kernel

The S3 is known to come with a very weak charger (stock charger). As Boeffla-Kernel by default slightly increases standard charging rate from 1000 to 1100 mA, this sometimes uncovers how bad the charger or the USB cable used for it are.

You have 3 ways to fix that:

  • Buy a proper charger for a few Euros or Dollars, which has many benefits like higher charging rates and no issues anymore. THIS IS THE HIGHLY RECOMMENDED way to fix it.
  • Change the USB cable you use, and clean the plugs, this sometimes helps as well
  • Enable the switches in Boeffla-Config to ignore instable power and security margins. This will make your device load as much as your charger can deliver. Although there are no reports of damaged chargers, bypassing the security logic in the S3 adds in theory some risk to burn your charger. So please do on own risk only.

Do I need to wipe, wipe cache, or wipe dalvik cache before or after flashing your kernel?

This is one of the fairy-tales which just survive now for many many years. The simple answer to that is: No.

And the reason is as simple as the answer: The kernel does not even "see" cache or dalvik cache. This is something handled a few layers above the kernel by rom, the Dalvik VM etc. So how should the kernel be concerned about something that is out of reach for him?

But: It is also not wrong to do it generally as it sometimes fixes weird issues with some apps, so I also do it from time to time. But it is not related to the kernel flash at all, just to make that clear again.

I am having freezes, reboots, hot boots...

Most likely this is due to the configuration you have selected. In particular undervolting and/or overclocking are known to create all possible kind of issues. Especially as every device is different and reacts in a different way to voltages. So when your friend can use 50mV undervolting on his device, it does not mean your device can do that as well.

This is the main reason, I recommend to not undervolt and not to overclock unless you have a very good reason and you are happy to take the hit.

Important is when you overclock your GPU: Do not forget to overvolt (yes, OVERvolt) your GPU a little bit (25 or 50mV should be enough most of the time) to keep it stable.

Galaxy S3: I want to use a CM or Omnirom based firmware, which kernel should I take?

This is pretty easy.

Omnirom Boeffla-Kernel for:

  • Omnirom
  • SlimKat
  • Carbon
  • AOKP
  • CM11 Boeffla-kernel for:

CM11 original

  • Temasek unofficial CM11

Galaxy S3: Can you implement LG's double touch to wake feature to the S3?

Technically yes, but not in a useful way.

The LG has hardware support for this feature, whilst the S3 is lacking that hardware support. This makes the LG device still being able to deep sleep while it can listen to the double tap gesture.

To reach this on the S3, we would need to prevent deep sleep completely and keep the touchscreen powered on. This would drain battery massively (would be down in some hours), so it does not make sense to implement this feature.

Use touch-to-wake as a light alternative instead.

I really would like to see feature xyz in your kernel...

Yes, I understand. Many people have many different requirements and wishes. But it is not possible to make everyone happy.

So I decided on a very simple decision matrix if I put something in or not (as I primarily build the kernels for myself):

  • when I like it, I put it in
  • when I would probably never use it, I do not put it in
  • if it goes against my objectives (i.e. "close to stock"), I will not put it in
  • if it can damage the device or is very tricky for the users, I do not put it in

Hence, things you can ask for but I will not implement are:

  • f2fs (because it is tricky for users, some are having big trouble going back to ext4 + I am not convinced of the benefits + it is not close to stock anymore)
  • dual boot (I have multiple devices + it goes far away from stock)

But come up with your suggestions, there is nothing else than can happen apart from me saying yes or no :)

Is integration with Tasker app possible?

With tasker (which is quite complex, you need to dig in a little bit to understand it) you can define any rule you want and trigger the load of a Boeffla-Config profile based on your rule. All you need to do is to send an intent from tasker to Boeffla Config with the profile name you want to load.

Here is the configuration of the intent:

  • Action: android.intent.action.MAIN
  • Cat: None
  • MIME Type: (keep empty)
  • Data: (keep empty)
  • Extra: profile:xxx
  • Extra: (keep empty)
  • Package: de.andip71.boeffla_config_v2
  • Class: de.andip71.boeffla_config_v2.ProfileShortcutActivity
  • Target: Activity

Please replace xxx by the profile name you want to load (case sensitive!).

Why is showing Boeffla-Config app different memory than I see in the rom settings?

You are looking at two very different things:

Boeffla-Config is a kernel configuration app, therefore it displays used memory from kernel view. This memory is supposed to be used (full) as much as possible as a virtual machine (ART / Dalvik) is loaded which provides and handles the memory for the rom.

The rom memory view in fact is what the virtual machine provides to the rom. So: The kernel memory should be almost used, as the VM should occupy as much as it can get.

Where does this strange name "Boeffla-Kernel" come from?

Well, the story behind is (I hope you understand, because it is much related to German language): It all started when I created my first mods for the Samsung Galaxy S1 almost a year go. After I decided to release it for public, I needed a name. And during brainstorming with my wife, she said: Call it Boefflamott. Just because Mod and Mott does sound very similar. Now you need to know, Boefflamott is a French dish, which my Grandmum cooked many times for me when she was still alive. So I thought, in remembrance of my Grandmum I call my first mod Boeffla-Mod. And this is how it started. There were many versions of the mod following each other, even now again on the S3 (see my signature) so it became somewhat like a brand. Hence, it was only logical to also call my own kernel "Boeffla-Kernel" now. So, all credits for the name to my wife and my Grandmum!

What is your opinion on the file system F2FS?

I think I mentioned that hundreds of times in all different threads. But once again:

ext4 is proven stable and fast. It has no compatibility issues whatsoever and is proved in both Linux and Android. We can consider it being super-mature.

f2fs gives slightly higher benchmark numbers, this is why many people hype it a lot. But in real life there is no real noticeable difference. However, there is a long track record of instabilities and issues. This latest superso thing is just one of many. I have seen enough reports of people losing their data, having inconsistent data. And for long time f2fs was not well supported by recoveries (maybe still the case, I do not know as I would never use it myself) and rest of the infrastructure (like custom kernels). This leads me to the question: Why using a hyped file system that does not give me any real life benefits but putting danger on my data? Does not make any sense for me. (and yes, I am not the one showing to others how big the balls are my smartphone has, this is kiddie stuff)

That is my personal opinion and motivation. I need a fast and robust file system which I can always trust - and this is ext4 and certainly not f2fs.

Why do you recommend to switch off file system tweaks?

Yes, it is true: Since my very first kernel for the Galaxy S3 in year 2011, I always implemented the file system tweaks, consisting of ext4 tweaks and dynamic fsync. And I also recommended to use them, as especially dynamic fsync can boost your IO quite a lot.

However, times have changed and I saw some negative effects of these two tweaks lately. It is very prominent on the OnePlus 3/3T devices on latest Oreo stock firmware OOS 5. With enabled file system tweaks, I could reproduce sporadic loss of information, i.e. some apps were "forgetting" their systems after a reboot, wifi suddenly was disabled and so on. These are really weird effects, and it is completely against my objectives to compromise on stability and even more on data integrity.

By disabling these two functionalities I could not reproduce these data integrity issues anymore, hoorray.

Hence, I nowadays recommend to not take the risk (if you do not need to impress your mates with super high benchmark figures, in real life you will not feel and see any difference anyways) and not compromise on your data. If you never had any issues and still want to use it - no problem, I have intentionally not removed the functionalities to give you the freedom to decide on your own - and take the risk or not.

Now a bit more technical explanation on what these tweaks do:

Ext4 tweaks enabled caused the /data and /cache volues to be remounted with a commit time of 20 seconds. This means, the file system was buffering write requests to the sd memory up to 20 seconds and the flushing it. Very clear, in "bad-comes-to-worse" situation data los is inevitable.

Dynamic fsync was blocking sync calls to write data to the sd memory as long as the display is on. Once the discplay goes off, the data was flushed. Also when a kernel panic occured or the device was rebooted, a flush was executed. Nevertheless, there seem to be some gaps in this handling as otherwise no data loss should ever have happened.