Database Info

Proposal for mod rom versioning

One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.

I do my best
I do my best ... with the "limited space" we're given for Thread Titles on the forum.
~enom~

I support this though I find it unnecessary. The new beginner user will most likely READ atleast the first post of the thread and they will know what the ROM is based off of. The end user will of course know to read the thread before doing any flashing of any kind so organizing mod rom versioning isn't a necessity. It's convienent but not necessary

I support this because it would make ROM catalogs easier to build, which would benefit the whole community.

why not just post what android version the rom is based on in the first post. First post should always hold the most info anyways.

Since this thread hasn't been moved from the Dev section so far.
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?

alritewhadeva said:
The end user will of course know to read the thread before doing any flashing of any kind
Click to expand...
Click to collapse
rofl. Funniest thing i've read all week.

+1
how about shorthand naming such as
for example:
CyanogenMod = CM-AOSP1.6r1-v4.20

If you're talking about cyanogen mod, you might want to add a couple more zeroes at the end. Anyway, I had proposed this too a while ago. I like your format, and I'll go one better; let's do cook-androidVersion-buildVersion-feature.bugfix
for example, the build I made this morning would be "jm-1.6-Donut eng.jubeh.20090930.070211-0.0"
jm is what I use for my builds (short for jubehMod)
1.6 is the current android branch (as per build.prop, no 1.6_r1 yet)
Donut eng.jubeh.20090930.070211 is the build number the compiler assigned to my build, people who work off of modding factory releases or build for dream_open are the ones who usually come up with things like CRC or DRC etc, I build for "AOSP for Dream" (it's a new "vendor" added)
first 0 is feature number, at this point my build is nothing but stock AOSP donut, no Google apps, no a2sd, no netfilter, no compcache, no bfs, just stock donut, so say I were to add a2sd, then I'd go up to 1, as I would have added one or more features (and this would be listed at the change log), basically, anything added that improves the build (and that's not a fix) is a +1 to feature
second 0 is bugfix. For example, right now my build works correctly in every sense, but I have a problem with the video camera where video is of very poor quality (real problem, I'm trying to figure it out), so say i get it fixed, then my bugfix number would go up 1, so basically, anything changed in the build strictly because it didn't work as intended is a bugfix
the last two numbers would be allowed to go past 9, so no more pressures to add .1s at the end like cyanogen was doing to prevent jumping to build # 4.2

karthikjr said:
+1 for the versioning.
Also, how about we all stick to one benchmarking app (or is there any one app that we CAN rely on)
to test performance of ROMs, so that there's an objective way of figuring out
whether the latest frankenROM (thanks devs! ) is faster than X or Y?
Benchmark Pi has a score that's difficult to figure out, seeing as it throws up an
awesome number on a fairly sluggish HERO whereas the score for a fast-as-light
cyan ROM is way way worse. I know that Benchmark Pi isn't the answer,
not by a long shot. So is there a better alternative out there?
I'm tired of posts that go "THIS IS WAY FASTER! THANKS!" only to find
that the supposed speed increase is more rooted in perception than in
reality.
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
yes just bench mark. its much better than benchmark pi only test the cpu really

by the way, I've been saving pretty much all roms that have been posted here (notable exceptions are haykuro's, jf's, and theduded's roms, I haven't been here THAT long) and I have them all saved on my computer separated by /cook/build/ for the Dream roms and /build/cook/ for the Hero ports. I guess I could run a quick filesystem lister and upload that list for people to see so they can sort of get an idea what mod release corresponds to what build

Here we go, I had to upload it inside a zip because of the stupid 2kb limitation on text files (this is 10kb)

lbcoder said:
One of the big issues I have noticed is that there is no rationale behind the version number assignment for a lot of the mod firmware. There are different modders using their own versioning, and there isn't even a hint of what version of android they are using, so we have things like;
"KiNgxKxROM Version 1.1r1"
"The Official Blur - Hero-V1.5.7 by Drizzy"
"JACxHEROSkiv2.2"
"CyanogenMod 4.1.11.1"
*** these all have the same problem... what version of android do they correspond to? How new IS each one of them?
I would like to propose a new standard to be adopted by everyone.
name-officialversion-modversion.
Of the form i.e.
"superxmod-1.6.DRC83-0.1.0.0"
***WHERE the modversion RESETS TO ZERO each time the official version increases, so for example, "CyanogenMod 4.1.11.1" should be called "CyanogenMod-1.6.DRC63-0.1.11.1".
* this will allow the user to immediately know where this rom comes from in terms of the official android versions and approximately how old it is.
Click to expand...
Click to collapse
................................

Hi jubeh,
Thanks, this kind of cataloging is exactly why the OP's suggestion will be helpful.

karthikjr said:
We need definitive numbers for ModelNumber+ROMVersion+CC/SwapSettings combinations.
Any help?
Click to expand...
Click to collapse
I'm not so sure that we do...
I think that that should be more of a "details" thing.
Maybe we can go with "name-officialversion-modversion[-custom]" (square braces mean optional). Name might be a good place to keep modelnumber (I assume you mean by that "dream", "magic", "hero", etc.),
i.e.: supercustomrom(DREAM)-1.6r1-0.0.0.0.0.0.0.1-cc_swap_a2sd

Milkdrop/androp amazing music visualization live wallpaper

AerialX said:
Alright, thanks for the results everyone. I asked because I wanted to decide which framebuffer method would be selected as the default... I decided on the "slow" version - 8bdefb7e - as it's the most compatible option. The "fast" version can be chosen as a preference for those who prefer the speed. It may not work on all devices, and seems to produce artifacts and some tearing, though it probably is preferable for most simply due to the speed.
So, here you go, latest version: Download
Built for ARM and ARMv7, does not include the NEON extensions. You may want to uninstall the old one before installing this.
EDIT: Fine, have a NEON build too: Download
Hint: the main change is the inclusion of settings. I consider this build to be very close to the initial release for the application on the Android Market. Just a few things remain...
What's Left
In order of priority...
Filtering of non-white-screen presets. The app will include the projectM preset library by default, excluding any that just result in a white screen. I don't believe I will be able to distribute any of the Winamp/MilkDrop library itself, as awesome as it is.
Stability enhancements. It's probably still somewhat crashy. I'm not sure how much, though. I'd love to get some detailed reports on how stable/crashy it is for you guys.
snoop() support, otherwise the wallpaper requires 2.3... I don't have anything older though. Would anyone be able to test on an older OS for me if I supplied a build?
x86 support. Means writing a few missing STL pieces.
NEON detection, and the loading of an appropriate optimized library. I get the feeling that this is just a placebo, but will try to get it in.
Optimizations. Would be nice if it didn't essentially restart every time you visit your home screen. I'm probably leaving this for a 1.1 release though.
Localizations. If anyone wants to help translate the settings page into their native tongue, I'll happily include them.
Anything else I forgot...
What I Need
It would be great if anyone who tries it can comment on its stability. Whether it often dies, reverts to some other wallpaper, completely kills your system, or whatever. Just give me your overall experience with the wallpaper. I'm not necessarily interested in hearing about its performance at this point - if it runs slowly on your phone, I suggest switching to the "fast" render method and only using presets that run speedily. Of course, miscellaneous suggestions / comments / criticism are welcome as well!
Another thing I was hoping someone could do is go through all the presets and filter out the bad "white" ones. The new settings page makes it easy to test a single preset at will. So if anyone is willing to do this, I could really use two zips: one containing all working presets from the projectM set, one containing all from the MilkDrop set.
As a base for the projectM set, please use this: Download
For the base MilkDrop set, find the attachment from a few pages ago.
You may also want to note any that run particularly slow, but please don't exclude them from these packages.
EDIT: As a test, feel free to try the exact same preset on both the non-NEON and NEON builds and see if there's any noticeable improvement there.
Click to expand...
Click to collapse
Hands down best app ever
Sent from my LG-P999 using XDA App

Any screenshots?

Um seems to be a few post missing in this thread... Usually when something starts like this:
Alright, thanks for the results everyone. I asked because I wanted to decide which framebuffer method would be selected as the default...
Click to expand...
Click to collapse
What results are we talking about here? What is this exactly? Kinda like writing a book that starts:
But when the baby came out looking like death on a hot tin roof, Jim finally found the nerve to call her out and say, "Devil wench, I will not accept that thing as my my spawn! I know you have been sleeping with your brother!"

[MOD][TWEAKS] Seeder (For lag reduction and performance boost)

Again since Sensation XE doesn't have people promoting seeder too much, I brought it here for those who are not familiar with this.
Please don't post negative things here. I only understand theory of this mod that's all. And I held no credit to any of the content.
Requirements:
1. S-Off
2. Custom recovery
3. Rooted
4. Init.d Support for flashable version
CREDITS FIRST:
lambgx02 (for the original seeder and APK format) http://forum.xda-developers.com/showthread.php?t=1987032
ryuinferno (for flashable version) http://forum.xda-developers.com/showpost.php?p=36479461&postcount=1924
FAQ:
What is seeder?
Its a mod that increases resource in your device so it wont suffer any starvation(lag).
Above is the easiest way to explain it.
What is the difference between APK and Flashable version?
APK version provides more options to tune method it provides resource and the frequency of it.
Flashable version will be automated in your device as long as your device have init.d support.
How can you prove it significantly improves performance?
Well I can't really tell, Dev's in sensation department is extremely good all ROM's are well tweaked. Its good enough without it, but IMHO it will be better with it.
To .zip version user only
Once you flashed it. Go to terminal emulator. Enter
su
seeder
A menu will show up. It will indicate if seeder is working in your device or not.
Thank the developers of this awesome invention, then Thank me if you think its good for me to bring it here.
Cheers!
TIP: Try on those high load games, the loading speed improvements are the best ways I can see after using this.

good
downloaded the app using the QR code and never installed. wheb you select it tin the task bar it doesnt go into the instalation menu. however when i went to the downloads in my phone it opened the installer. it tried too install but took a very long time. but in the end worked thansk made a slight difference to the lag on my phone. :good:
HTC sensation 4G
ROM: CM 10.1-20130212-albinoman887-pyramid

Although this improves performance slightly, the only thing it really does is run your CPU at a higher frequency. This'll cost precious battery life.

ridder215215 said:
Although this improves performance slightly, the only thing it really does is run your CPU at a higher frequency. This'll cost precious battery life.
Click to expand...
Click to collapse
Can't say you're wrong at the battery life part. But IMHO, it doesn't actually touches the frequency part. Frequency is something that runs instructions, but this thing provides additional resource aka fuel for your device. It don't make your engine combust quicker, it will only make your engine combust cleaner, and more fuel that's all.

KiD3991 said:
Can't say you're wrong at the battery life part. But IMHO, it doesn't actually touches the frequency part. Frequency is something that runs instructions, but this thing provides additional resource aka fuel for your device. It don't make your engine combust quicker, it will only make your engine combust cleaner, and more fuel that's all.
Click to expand...
Click to collapse
I'm just going to leave this quote from a CM maintainer here:
“IMNSHO the recent entropy pool fad is bull***. The only users of /dev/random are libcrypto (used for cryptographic operations like SSL connections, ssh key generation, and so on), wpa_supplicant/hostapd (to generate WEP/WPA keys while in AP mode), and the libraries that generate random partition IDs when you do an ext2/3/4 format. None of those 3 users are in the path of app execution, so feeding random from urandom does nothing except make random… well… less random.
The only conceivable reason some devices may feel faster is because by constantly polling the PRNG, it keeps the device’s I/O in constant use (which in turn, depending on device, will make the CPU stick to higher clock frequencies to keep up and/or ramp up the IO scheduler).”
Source
Don't get me wrong, if it seems to help for you, that's great. But I'm not going to use it.

ridder215215 said:
I'm just going to leave this quote from a CM maintainer here:
“IMNSHO the recent entropy pool fad is bull***. The only users of /dev/random are libcrypto (used for cryptographic operations like SSL connections, ssh key generation, and so on), wpa_supplicant/hostapd (to generate WEP/WPA keys while in AP mode), and the libraries that generate random partition IDs when you do an ext2/3/4 format. None of those 3 users are in the path of app execution, so feeding random from urandom does nothing except make random… well… less random.
The only conceivable reason some devices may feel faster is because by constantly polling the PRNG, it keeps the device’s I/O in constant use (which in turn, depending on device, will make the CPU stick to higher clock frequencies to keep up and/or ramp up the IO scheduler).”
Source
Don't get me wrong, if it seems to help for you, that's great. But I'm not going to use it.
Click to expand...
Click to collapse
I promoted this because it seemed great on my previous device. But in sensation the effect is much lesser than anticipated. Works in my friend's S2 though. Maybe its for low end devices only tsk tsk tsk.
But still, no harm experimenting on everything.

KiD3991 said:
I promoted this because it seemed great on my previous device. But in sensation the effect is much lesser than anticipated. Works in my friend's S2 though. Maybe its for low end devices only tsk tsk tsk.
But still, no harm experimenting on everything.
Click to expand...
Click to collapse
Seeder was designed for older versions of android. It is stated in the thread that it is solved in newer versions of android.

[DEV][APP] waut.ch! - Calibration for Android - version 145

Utility for background calibration, curation and tuning of the device towards an intuitive interface.
Subsystems being battery, entropy, encryption, disk, cpu, memory, filesystem, ui, scheduler, and network, all safe and open source technology.
Presented in this educational gaming metric format with infinite feedback and an interestingly assymetric chance. scribble anywhere, check in some stress, or find the 8!
waut.ch! does one hope to receive from this?
Well, increasing degrees and amounts of a certain "Je ne sais quoi" or responsiveness from the user interface for a start. Better battery life perhaps. Better quality of life, maybe.
And waut.ch! can only perhaps be described as "A qualified quantification of the placebo effect"
waut.ch! might benefit from this?
In the Android device space:
Designers
Users
Manufacturers
Recyclers
Developers
Compilers
Support personnel
OEMs
The Friendly Neighborhood Nerd/Technician.
“Make the most of yourself....for waut.ch! is all there is of you.” - Ralph Waldo Emerson ( paraphrase )
All along the waut.ch! tower - Bob Dylan
waut.ch! - Sometimes used in some colloquium as "watch!", keen upon reducing the TDP of mobile devices to 1.0 watt!
ARM variants of Android only Donut 1.6+
Please uninstall either Seeder or CrossBreeder prior to using this.
Root recommended, else reactivity metric is interesting and introduces uniqueness into the entropy pool anyway. Metric may demonstrate a certain asymmetry that is expected from predictable human actions. Efforts have been made to remove time seed logic from haveged in order to improve upon encryption and system-wide performance and security.
Also numerous other subsystems require careful calibration to facilitate this process.
Rewritten code, subset of functionality for upstream project - CrossBreeder ( https://forum.xda-developers.com/showthread.php?t=2113150 )
Please feel free to view and analyze source and functionality and report bugs and discuss etc on the XDA forum:
( https://forum.xda-developers.com/android/apps-games/app-waut-ch-calibration-android-t3549967 )
Google Play store:
( https://play.google.com/store/apps/details?id=ch.waut )
Please visit: /data/data/ch.waut/files/bin on the device itself for partial shell source code and XDA Downloads section and Github for full source code.
Reboot at convenience liberally or sparingly to reseed the entropy pool or as is known in common parlance, for good luck!
Thanks.
Havged source code:
https://github.com/Openand-I/haveged
Adhoc Payment URL to support development efforts : https://paypal.me/openand/10
Frappe ( "free-paid" ) same-version to support development efforts : http://waut.ch
Custom haveged source code as used in this piece of software: https://github.com/Openand-I/haveged
=====
Version Name: 59a6333e-9ed9-43f8-8dad-51ed46c17e28
cb.sh: cache pressure - 500
cb_io.sh: read_ahead - 0
cb_io.sh: nr_requests - 0
$ md5sum *.apk
661c30b02b2321300624af98feaa5bad *145-waut.ch.apk
661c30b02b2321300624af98feaa5bad *oi.apk
$ sha256sum *.apk
6d23b8da87dc5516583a55a3203c9f5068ea8fe8765ece489080ef663c8aee15 *145-waut.ch.apk
6d23b8da87dc5516583a55a3203c9f5068ea8fe8765ece489080ef663c8aee15 *oi.apk
https://github.com/Openand-I/haveged
https://github.com/openand-inc/waut.ch
https://forum.xda-developers.com/devdb/project/?id=19218#downloads
https://forum.xda-developers.com/android/general/app-waut-ch-calibration-android-version-t3858365
https://github.com/openand-inc/waut.ch/raw/cb0c60025f86a4fdc4778506e97ee80eb1c00b45/oi.apk
https://github.com/openand-inc/waut.ch/raw/master/145-waut.ch.apk
-------------------------
Recommended:
- ntp: automatic system time update from internet is enabled.
please check the clock and fiddle around with the timezone settings in case of any issues. one may need to set the timezone manually.
then simply run the app to initiate a time sync
the network time sync happens at around 3am. so the time to check is in the morning.
- Please disable mount namespace separation in the superuser app to take advantage of the mount optimisations.
- Reboot once and occasionally to reseed the entropy pool. It's good luck!
- Do ensure that the waut.ch service has started upon reboot. Just run if it doesn't start it automatically!
Note: Please note that the haveged binary in the APK is a static binary and works on both PIE and non-PIE environments. It is also UPX compressed. UPX for Android didn't compile. So UPX for linux was used to compress the executable file. It is an elegant solution as both on disk and in memory space(?) is reduced by 70% per executable. One is welcome to decompress the file using 'upx -d'.
Full source code is provided on Github and build scripts are attached here and on Github.
There is no license required to both install the app or distribute it, both within the developer ROM community or in commercial form. Adhoc payment URL to support development - https://www.paypal.me/openand/10
Again do note that the license to use the APP and source code is free worldwide and irrevocable in full or partial form. All other open source components simply inherit their license. But under no circumstances is any use thereof legally binding or relevant.
--------
Utility for background calibration, curation and tuning of the device towards an intuitive interface.
Subsystems being battery, entropy, encryption, disk, cpu, memory, filesystem, ui, scheduler, and network, all safe and open source technology.
Presented in this metric format with infinite feedback and an interestingly assymetric chance. scribble anywhere, check in some stress, or get lucky for that matter!
-----
ARM variants of Android only Donut 1.6+ ( should even be compatible with the latest ARM Android 9+ )
Please uninstall either Seeder or CrossBreeder prior to using this. And other "mods" or "tweaks".
Root recommended, else reactivity metric is interesting and introduces uniqueness into the entropy pool anyway. Metric may demonstrate a certain asymmetry that is expected from predictable human actions. Efforts have been made to remove time seed logic from haveged in order to improve upon encryption and system-wide performance and security.
Also numerous other subsystems require careful calibration to facilitate this process.
Rewritten code, subset of functionality for upstream project - CrossBreeder ( https://forum.xda-developers.com/showthread.php?t=2113150 )
Please feel free to view and analyze source and functionality and report bugs and discuss etc on the XDA forum:
( https://forum.xda-developers.com/android/apps-games/app-waut-ch-calibration-android-version-t3858365 )
Google Play store:
( https://play.google.com/store/apps/details?id=ch.waut )
Please visit: /data/data/ch.waut/files/bin on the device itself for partial shell source code and XDA Downloads section and Github for full source code.
The app will amongst other maintenance tasks tune sqlite databases regularly and reseed the entropy pool or as is known in common parlance, for good luck!
Thanks.
Payment URL: https://paypal.me/openand/10
XDAevDB Information
waut.ch!, App for all devices (see above for details)
Contributors
idcrisis
Source Code:
[url]https://github.com/Openand-I/haveged[/URL]
[url]https://github.com/openand-inc/waut.ch[/URL]
[url]https://forum.xda-developers.com/devdb/project/?id=19218#downloads[/URL]
Previous Version Information - 144
305bd30f-0c8a-40d8-baf5-330c68f62d51
Status: Stable
Created 2017-01-01
Last Updated 2020-08-18
$ md5sum *.apk
8ea8e8c132a584767a12e394f7975654 *144-waut.ch.apk
8ea8e8c132a584767a12e394f7975654 *oi.apk
$ sha256sum *.apk
4925066a106c83b18ac6e563f03331c56b72777e66973db591c9776d706595e3 *144-waut.ch.apk
4925066a106c83b18ac6e563f03331c56b72777e66973db591c9776d706595e3 *oi.apk
https://github.com/Openand-I/haveged
https://github.com/openand-inc/waut.ch
https://github.com/openand-inc/waut.ch/raw/master/144-waut.ch.apk
https://github.com/openand-inc/waut.ch/raw/f699d3763507ec1f91d82b9ce25c53036b460a9e/oi.apk
-----
Version notes:
haveged: static non upx binary used
cb.sh: lock fixes
Recommended:
- ntp: automatic system time update from internet is enabled.
please check the clock and fiddle around with the timezone settings in case of any issues. one may need to set the timezone manually.
then simply run the app to initiate a time sync
the network time sync happens at around 3am. so the time to check is in the morning.
- Please disable mount namespace separation in the superuser app to take advantage of the mount optimisations.
- Reboot once and occasionally to reseed the entropy pool. It's good luck!
- Do ensure that the waut.ch service has started upon reboot. Just run if it doesn't start it automatically!
Please support development, simply use https://paypal.me/openand/10 or the payment URL.
Or you can simply buy the "frappe" ( free-paid ) version of the app: http://waut.ch

Recommended:
- ntp: automatic system time update from internet is enabled.
please check the clock and fiddle around with the timezone settings in case of any issues. one may need to set the timezone manually.
the network time sync happens at around 3am. so the time to check is in the morning.
- Please disable mount namespace separation in the superuser app to take advantage of the mount optimisations.
- Reboot once and occasionally to reseed the entropy pool. It's good luck!
- Do ensure that the waut.ch service has started upon reboot. Just run if it doesn't start it automatically!

Issues:
- superuser - Please disable mount namespace separation in the superuser app ( for optional but recommended mount options ). Also please revisit the app entry inside the superuser app to ensure the waut.ch service can run on boot unattended. One can see the logs on another day to ensure that the scheduler ran correctly in the night.
- Non root users - User Interface can help in clearing the random device. Please try and obtain root to avail of most features
- Some Samsung users - One is also requested to raise a ticket with Samsung who may be running old PE detection rules that flag any compressed EXE.
- x64 users - Reports are that the binaries run on 64 bit as they are static! Please compile one's variant of the binary if required. Entropy generations removes CPU jitter and hence runs cooler and more secure.
- Intel users - User Interface can help in clearing the random device. Please compile one's variant of the binary if required. Entropy generations removes CPU jitter and hence runs cooler and more secure.
- Maintenance scheduler VACCUUMS and INDEXES "ALL" SQLITE databases. Some folks may not like that. But given that they're no WAL mode anyway, it's a bottleneck worth removing safely.
- There is a concerned effort to state that 32-bit ARM Android Go/One < 1 GB RAM devices are all that's required for long term functioning. Higher no issues.
- Please try and use a heap size of 96MB. Attempts have been made to set heap size dynamic but ideally this should be done in the build.
- Please clear cache or factory reset upon issues to gain at least another year of MTTR ( Mean Time To Recovery ) for each device.
Thank you!

License
License concerns:
haveged - inherited - https://github.com/Openand-I/haveged
busybox - inherited - https://github.com/openand-inc/busybox
- Busybox simple extract, possibly edit the .config file in 'vi' and type 'make'
The requisite tools are installed using:
apt-get install gcc-arm-linux-gnueabi
apt-get install libncurses5-dev
apt-get install gawk
The following is a step in another direction as the 'make' command works perfectly after extraction, but this is provided for posterity:
wget http://busybox.net/downloads/busybox-1.24.1.tar.bz2
tar -xjf busybox-1.24.1.tar.bz2
cd busybox-1.24.1/
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- defconfig
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- menuconfig
At the menu, you can configure BusyBox options. Once configured, you can build BusyBox:
make ARCH=arm CROSS_COMPILE=arm-linux-gnueabi-
sqlite3 - inherited - https://github.com/openand-inc/sqlite
waut.ch - 'none', non legally binding, and non legally relevant on a worldwide scale and irrevocable ( derived works are allowed to add their own licenses as long as the import ( meaning ) of the phrase "non legally binding and non legally relevant" is implied throughout ( not required to include text at all )) and does not reflect upon future updates of this software in any manner adversely.

He is back! Welcome back! Looking forward to this great new project! The only thing I might be missing is the dnsmasq filtering, which in my opinion if by far better solution than any kid of firewall/blocker
Sent from my Galaxy Tab 2 3G using Tapatalk

qWantUS said:
He is back! Welcome back! Looking forward to this great new project! The only thing I might be missing is the dnsmasq filtering, which in my opinion if by far better solution than any kid of firewall/blocker
Sent from my Galaxy Tab 2 3G using Tapatalk
Click to expand...
Click to collapse
Mate!
There are some serious issues with DNSMASQ.
- It crashes on wrong syntax of any option. Cannot do for a server.
- Command line syntax changes between original branch, Android and Cyanogen MOD. Not merged.
- Android fork far behind main branch
- Consumes port 53 on server run without sharing interfaces. This is on the Android branch. Main branch has this resolved.
- CPU loop for most Android DNS versions that show up only upon server run, rather than the tethering run. Possibly hijacked open source branch.
- Tethering modifications to Android branch ( command line addons ) not required any more as the main branch has incorporated methods to dynamically change IP addresses on the fly.
- It is probably encumbered by coding standards and export issues with only one developer. It is emblematic of most such over-reused projects.
- Hash table in memory, therefore future block list will use up RAM. Some others have disk based caching.
- Static blocklists are fairly not scalable for 10 years hence. Needs wildcard blocklists.
- DNS cache poisoning/overloading ( leading to denial of service) possible by any process/app.
It is therefore recommended to use either of:
pdnsd
unbound
djbdns
and standalone dhcp clients and servers from the Entware repository. And also these are interesting:
DANE
DNSSEC over TLS
BTW, all Android is encumbered by simple denial of service attack simply by reading from /dev/random by any app.
In order to try and package this into a simplish product, deleting /dev/random was not implemented.

idcrisis said:
Mate!
There are some serious issues with DNSMASQ.
- It crashes on wrong syntax of any option. Cannot do for a server.
- Command line syntax changes between original branch, Android and Cyanogen MOD. Not merged.
- Android fork far behind main branch
- Consumes port 53 on server run without sharing interfaces. This is on the Android branch. Main branch has this resolved.
- CPU loop for most Android DNS versions that show up only upon server run, rather than the tethering run. Possibly hijacked open source branch.
- Tethering modifications to Android branch ( command line addons ) not required any more as the main branch has incorporated methods to dynamically change IP addresses on the fly.
- It is probably encumbered by coding standards and export issues with only one developer. It is emblematic of most such over-reused projects.
- Hash table in memory, therefore future block list will use up RAM. Some others have disk based caching.
- Static blocklists are fairly not scalable for 10 years hence. Needs wildcard blocklists.
- DNS cache poisoning/overloading ( leading to denial of service) possible by any process/app.
It is therefore recommended to use either of:
pdnsd
unbound
djbdns
and standalone dhcp clients and servers from the Entware repository. And also these are interesting:
DANE
DNSSEC over TLS
BTW, all Android is encumbered by simple denial of service attack simply by reading from /dev/random by any app.
In order to try and package this into a simplish product, deleting /dev/random was not implemented.
Click to expand...
Click to collapse
Very comprehensive explanation indeed! I am no expert in Linux, only an average user [emoji6]
I was not aware of so many obstacles using dnasmasq, but aware of it's unreliability while using it for blocking stuff in pfsense. But I must say, I had similar experience with unbound, however, probably due to the lack of linux knowledge.
The way I understand is that host blocking is no longer viable due to scales of blocking required today. But sadly there is no alternative for that on android. I have been trying another tool, called sharkmasq but developer sadly abandoned it, while it seems very unfinished and unreliable. I also understand the reasons behind leaving netfiltering out of your development, just, in desperation, I search for the hope [emoji3]
P. S.
Thank you very much for your reply and for your time putting it together. Nevertheless I will look forward to further developments of this new exciting project!
Sent from my LG-D855 using Tapatalk

Uhm, my device seems more responsive even when I use a very low CPU frequency, but is it normal that the app doesn't ask for root permission even if I'm fully rooted? I'm using a Nexus 5 running Nougat. Thank you
Inviato dal mio Nexus 5 con Tapatalk 2

Hi, yes, part of the design criteria. Without root, the metric is interesting. With root, it will automatically start the background processes including the daily cleanups.
Best way to know that the background processes are running is to install Seeder ( but whatever you do don't start it! . Entropy should show around 4096.

Still in the testing phase, does it worth excluding the app from "android optimisation list"? I also use "power nap", not sure will that cause any side effects...
Sent from my LG-D855 using Tapatalk

Let us know If Seeder has RNGD off and still reports ~ 4096 entropy then all is hunky dory.

The new update asked me for root permission, all right here now

Have been busy lately with life, but had occasionally played with phone. So my findings so far: I use this app on my old galaxy tab 2 3g on slim6. Seeder shows entropy being filled in no time at all. Can't really say much about performance, but it seems that it behaves a little smoother. I also use it on my daily LG G3 on stock MM rom with custom kernel, but seeder is reporting very low entropy, if seeded is left on for 1 minute, I can see that entropy never goes above 900? Goes up slowly but then gets used, and then very slowly goes up again and gets used.
Sent from my LG-D855 using Tapatalk

Reboot once after first install kicks in the animation changes. And good luck
New version uploaded with haveged updates. Build scripts also added.
Feedback solicited about the compiler flags etc. Basically the idea is that the ARM v5 binaries should work for all past and future versions of 32-bit Android without modification.
UPX binary could only be compiled for x86 linux.
To answer question, second device, not running, may need to check su logs
Also backend binaries are 32 bit, may not work on 64 bit. GUI's ok.

I am very confused about the frontend of this app that looks like some number game that I really don't understand . Also, I don't understand the description very well. Finding the 8??? Reboot when animation kicks in? What animation?? Nothing seems to happen. I just see a still of a beach with a red number
But something DID happen though, so I am in business. I will keep you curious for a moment, while firstly giving you a good reason for a hard laugh:
I am trying to revive an LG L3 E400! Yep, that's right . Just for fun and educion. In fact I already succeeded quite a bit. I flashed JellyCast V7rev1, used some stuff from V6 SuperCharger (not entropy thingie coz I already intended to use CrossBreeder for that) and 3 scripts from Fly-On Mod. I came here via the CrossBreeder thread (of course). I have already tried CrossBreeder 7.2.13 (I followed advise from @f3tus here, he advised to use that older version). Entropy went up (so it worked) but I did not experience much performance improvement. I did experience more "not responding" issues though. So I reverted to the pre-CrossBreeder backup. And then came your app.....
So that's a very short summary of the many, many, many hours I spent last 2 weeks on this ancient minimalistic but very adorable phone. Now... back to this Waut.ch! app. Presuming that it had done something, I checked the entropy level after first reboot: still a jumpy number between 150 and 200 or so. Despite the fact that the service shows up as running. Then, a lot more playing with the "game" without understanding what I was doing. Just hoping for some wonder. Some message.... just...... something! But nothing. Just a beach with a red number. And a clock. And a questionmark. Or exclamation mark. Pffffff.. So.... let's reboot again. Then eat a sandwich and drink (more) coffee. Then check entropy again. And there it is! Steady at 4089! At first I thought his app was failing because the number didn't change anymore. Just steady. With the old CrossBreeder 7.2.13 I got 4096 a lot but it was a very jumpy number, going even below 1000 a lot. Well, some time passed while writing this post so let's check again: Wow, right now it says 4091 (99%)! One hour later: 4092! (It had spontaneous reboots inbetween).
I am testing it now for a few hours and have these problems:
"Not responding" issues (same as old CrossBreeder).
Spontaneous reboots (3 already). One of them failing to boot at all (stuck at JellyCast logo).
Two times, after a reboot, GPS was disabled. Not consistently though.
No noticable performance gain.
By the way, I am testing like real world usage. Just opening, using and closing apps. I use the same apps all the time so that gives a very good feeling about performance. More meaningful than benchmarks to me. My goal is to make this phone suitable for normal daily usage.
Your app is using a combination of serveral mods, right? I would like to be able to enable / disable each one separately. How can I do that? For example, I have a gut feeling that my "not responding" issues (and reboots?) do not come from the entropy mod but perhaps from governor tweaks or something else. Any chance that you will add enable buttons in the app? Or supply seperate scripts?

Update: I DO have performance gain! Not consitently though. Apps sometimes starting faster than ever. Also still the aforementioned quirks. Last hours no more auto-reboots. Entropy reaching 4096 now, just a little bit wobbly. There seems to be a lot of potential.

The stutter was an issue with the last version.
Do try the latest one and let us know.
Also better if you install the Play store also so the updates are automatic.
Version name is changed GUID if comparing. Better than comparing version numbers.
GUI is non functional, just a visual representation of haptic feedback and actual randomness spread.
It's like drawing points in the whites of a poached egg. If you can see a pattern, you'll be rich in the stock market

Today I removed the app. The biggest problem is random reboots for me. As said, it has potential because sometimes apps started faster than ever on my ancient LG L3. But not consistently. So maybe I 'll try again later.
Sorry for my first post, probably tl;dr. I will repeat my most important question: can you provide us with separate scripts? I mean: I would like to test the entropy thing without the other tweaks as you described in the OP.

Dude!
You're probably using an old version. We'll never know. Will we? Will we now?
There's a small trick that borders on superstition. The famous random device block gremlin tends to disappear if you run the GUI in scribble mode. Basically what may be happening is the block is hit and then the stupid kernel makes whatever decision it makes. Usually at the cost of usability in favour of some stupid religious Linux fervour. Someone should report that to LINUX.
Or another entropy generator, haveged or RNGD or Seeder may be running. Which is a big no! Best to run it on stock ROMS or full custom ROMs ( please ask the developer if they're running any variant of above and to recommend coexistence or better variant of any subcomponents or piece of code. ). In other words, open source!
Also, the separate scripts are in the /bin directory on the phone itself. May require bash and ADB skills.
And full source on XDA and GitHub.
I'll construe this as a possible request to also post the shell scripts from GitHub into the XDA project as separate attachments. Which I can do. In due course
Cheers.

Well, I took it from Play Store. Is that an old version?

Removed

Removed

I just google things and muddle my way through a couple of articles / code comments until they get to the point and give me information I can understand. The trick is to skip past the technical "how" and "why" that often flies over my head too, and find the actual "what" that explains each option's effect. Then I pass things on the way I understood them so you get the condensed version.
Do you notice any hiccups or delays with these settings? They all put battery over performance.
One note: sched_tunable_scaling isn't just enabled or disabled. At least in the stock version (as in all the way upstream, not your phone's default software) its values are:
0 = don't adjust sched_latency_ns
1 = adjust sched_latency_ns logarithmically
2 = adjust sched_latency_ns linearly

TrenchFullOfSlime said:
I just google things and muddle my way through a couple of articles / code comments until they get to the point and give me information I can understand. The trick is to skip past the technical "how" and "why" that often flies over my head too, and find the actual "what" that explains each option's effect. Then I pass things on the way I understood them so you get the condensed version.
Do you notice any hiccups or delays with these settings? They all put battery over performance.
One note: sched_tunable_scaling isn't just enabled or disabled. At least in the stock version (as in all the way upstream, not your phone's default software) its values are:
0 = don't adjust sched_latency_ns
1 = adjust sched_latency_ns logarithmically
2 = adjust sched_latency_ns linearly
Click to expand...
Click to collapse
Got it
I don't have any performance issues. I usually play Fifa and PES on my device and they seem to have no problem with the modifications.
Thank you

This is by no means universal. You didn't include the phone you use, the kernel you used, the version of Android.. These settings 'work' for your phone and the way you use it, but that does not mean it will work for all phones and how other people use their devices.
I think you need to go research what you are suggesting and don't rely on 5-10 year old linux kernel discussions on stackoverflow. Glancing over your suggestions I see a few settings that make no sense at all.

bobbarker2 said:
This is by no means universal. You didn't include the phone you use, the kernel you used, the version of Android.. These settings 'work' for your phone and the way you use it, but that does not mean it will work for all phones and how other people use their devices.
I think you need to go research what you are suggesting and don't rely on 5-10 year old linux kernel discussions on stackoverflow. Glancing over your suggestions I see a few settings that make no sense at all.
Click to expand...
Click to collapse
Thanks
Could you please mention which ones doesn't make sense and guide me to a place where I can learn more about it?

@arter97
Sir, I know this might never reach you. But if you could take two minutes of yours and point out the things that are wrong in this post, it would make my day.
Thank you